Stream boundaries and parser state

What this concept is

A stream presents ordered bytes rather than application message boundaries. The parser must carry state across calls: partial header, declared payload length and collected body. A call can finish zero, one or many messages.

Why it matters here

A sender’s write calls need not correspond to a receiver’s reads. Correctness must depend on wire bytes and framing rules, not the accidental segmentation observed on one machine. A single read that happens to contain one frame is weak evidence.

Concrete example

For payload abc the wire is 00 00 00 03 61 62 63. Reads of 00 00, then 00 03 61, then 62 63 must emit exactly abc once. Appending four zero bytes encodes a second, empty message; a coalesced read must preserve it.

Common confusion / misconception

An empty chunk passed to this parser is not EOF: feed and finish are separate API events. A socket adapter must translate recv returning zero bytes into finish. A protocol’s empty payload is four header bytes, not absence of input.

How to use it

Write a state transition for every byte. Accumulate at most four header bytes; decode big-endian length; validate it; collect exactly the body; emit and reset. Continue parsing trailing bytes in the same chunk. Test all partitions of a short stream as well as a large bytewise stream.

Check yourself

If a read ends after three header bytes, can you allocate the body? No: the length is incomplete. If two frames arrive together, is returning only the first safe? Only if the remainder is explicitly retained; discarding it loses valid messages.

Mini drill or application

Enumerate partitions of a two-frame stream and mark parser state after each chunk. Add an empty frame between two nonempty frames and predict outputs before execution.

Read this only if stuck

Return to protocol structure in Computer Networking chapter 1, then separate transport bytes from application frames in your trace.