indexProtocolo Binario Propio#protocol#framing#serialization
Esta nota todavía no está traducida, así que se muestra la fuente en inglés.

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