indexCustom Binary Protocol#protocol#framing#serialization

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/htonl and 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