Custom Binary Protocol
Before this atlas touches RFC 6455, it makes you feel the problem RFC 6455 exists to solve. TCP gives you a stream of bytes with no message boundaries — nothing marks where one message ends and the next begins. This branch designs an application protocol from nothing: a framing scheme that delimits messages in that stream, a binary serialization format, a versioning scheme so old and new clients can coexist, and heartbeats so a silent connection can be told apart from a dead one. v1 of the chat runs on this protocol, working between N clients, deliberately without WebSocket.
This is the branch most people skip by reaching for a library on day one. Skipping it here would skip the point: a real standard's decisions (why WebSocket masks client frames, why it has three payload-length encodings, why ping/pong exists) read as arbitrary syntax until you've hit the same decisions yourself and picked worse answers first.
Planned notes
- Why "just send JSON over TCP" breaks the moment two messages arrive in one
read()call - Length-prefixed framing vs delimiter-based framing, and why length-prefixing wins for binary payloads
- Designing a minimal binary message format: a fixed header (type, length, version) plus a variable payload
- Endianness: choosing a wire byte order and enforcing it with
htons/htonland friends - Serializing structured data by hand: fixed-width fields vs variable-length strings and their length prefixes
- Protocol versioning: a version byte in the header, and what "unknown version" should do instead of crash
- Heartbeats and keepalive: detecting a silent-but-alive peer vs a silent-and-dead one without relying on TCP timeouts alone
- Building a minimal client and server that speak this protocol, incrementally: connect → auth → send → broadcast
- Where this protocol's design choices map onto WebSocket's actual frame format — the comparison that sets up the next branch
- Fuzzing your own framing: malformed lengths, truncated messages, and what "handle it gracefully" actually requires
Core sources
- Dan Kegel, "The C10K Problem" — for the design context this protocol will eventually need to survive.
- RFC 1122 — framing fundamentals at the internet-host level.
- Protocol Buffers' wire format (as a conceptual reference for length-prefixed framing patterns — not implemented here; this protocol is hand-designed, not generated).
Connects to: TCP Fundamentals · WebSocket Protocol from Scratch