The Socket That Answers

01 - THE SOCKET THAT ANSWERS the felt problem: bytes have no edges redis-cli (a client) PINGPINGPI NGPINGPING... (no gaps between words) P I N G P I N G P I N G P I a stream of raw bytes your server :6379 where does ONE command END? a socket never tells me. REAL LIFE: Someone reads their shopping list with NO pauses - "milkeggsbreadmilkeggs". You can't tell the items apart. TCP hands you bytes in exactly that shape: no commas, no edges. WHAT ONE recv() ACTUALLY HANDS YOU - never a clean command command #1 (split across 2 reads) command #2 starts mid-read "PIN" read #1 "G\r\nPI" read #2 "NG\r\n" read #3 The kernel doesn't know what a "command" is. It ships whatever bytes have arrived. Reassembling them into commands is 100% YOUR job. v01: we cheat (and it's fine for now) PING [enter] +PONG A human at nc presses ENTER after each word -> one clean line -> we get away with reading line-by-line. THE WALL: a real client speaks RESP *1\r\n$4\r\nPING\r\n what redis-cli actually sends our line-reader sees garbage -> -ERR The fix: a real protocol with lengths built in. That is board 02: RESP. THE ONE THING A socket gives you a STREAM of bytes, never messages. Framing - deciding where one command ends - is your job, not the network's. That one problem is the entire reason RESP exists.