Fringe
TCP gives you ordered bytes, not messages. A read may contain half of a write, several writes together, or the seam between them. Fringe restores discrete application messages with a fixed header and binary length prefix.
Watch a stream become messages
Three frames are ready. Send fragments in the deliberately inconvenient order they arrived.
literal “FRINGE”+UInt32BE length
Before transport
Original messages → Fringe frames
Each frame begins with the literal six-byte ASCII string FRINGE, then a four-byte length and the content bytes.
0 of 9 fragments sent
Incoming bytes
One continuous stream
Fringe parser
Complete messages
What you are seeing: the first frame’s FRINGE header is split across two chunks; another chunk ends one frame and begins the next. That is normal for a byte stream: chunk boundaries carry no message meaning. Fringe waits for a valid header, then buffers exactly the declared payload length.
Small protocol, useful boundary
TCP is a byte stream: it preserves order, but it does not preserve the boundaries between the writes a sender thought of as messages. A receive can end halfway through a frame, contain several complete frames, or do both at once. Fringe writes a configurable fixed header plus a binary payload length so its parser can recover those boundaries incrementally.
The fixed header lets the parser reject invalid input immediately. The declared length tells it exactly how many bytes to buffer and consume, avoiding the scan-and-escape work of newline-delimited protocols when payloads may contain the delimiter themselves.
The encoder and parser are Node transform streams. Both can be extended with a translate method, so applications can frame plain text, JSON, MessagePack, or another serialized representation without coupling framing to a payload format.