Message boundaries come from parser state, not socket reads

Consider a fictional protocol with a four-byte unsigned big-endian payload length followed by that many payload bytes. Its parser begins in a prefix state, retains partial prefix bytes across reads, checks the decoded length against a configured maximum, then enters a body state. Once the body is complete it emits exactly one message and returns to the prefix state. Any bytes remaining in the same read belong to subsequent parsing, not automatically to the emitted message. A zero-length body can be valid if the protocol explicitly permits it; an implementation should not invent a different rule silently.

A delimiter-based protocol needs equally precise rules for escaping, character encoding, and delimiters inside payloads. Closing the connection can delimit certain responses, but that makes reuse and distinguishing truncation more difficult. Different framing choices move complexity rather than eliminate it. Record the grammar, integer width, byte order, permitted lengths, and end-of-input behavior. The parser should be correct for every fragmentation of the same valid byte sequence: splitting a prefix into four reads must not change the messages produced compared with receiving the entire sequence in one read.

If only two prefix bytes have arrived, waiting for the remaining two is normal incremental parsing. If a complete prefix announces a body larger than the permitted maximum, the input violates the contract immediately; waiting for the entire announced body wastes resources. Validate lengths before allocating, account for aggregate buffered bytes across connections, and avoid arithmetic overflow when checking header-plus-body bounds. A compressed or nested payload can consume far more memory after decoding than its framed length, so decode limits and nesting limits belong beside wire-size limits rather than being assumed to follow from them.

End-of-input in the middle of a declared body is truncation, not successful completion of a shorter message. A peer that sends prefixes very slowly can also retain parser and connection resources without exceeding a size limit. Use appropriate progress and lifetime policies, while distinguishing a documented timeout from malformed syntax. Keep unconsumed bytes and parser state together so cancellation cannot accidentally reuse a buffer as the next message. Error responses should not leave an intermediary and backend interpreting the remaining connection differently; rejecting one request may require terminating that ambiguous connection safely.

HTTP/1.1 defines precedence rules for body length, including special response cases and transfer coding. A message containing both Transfer-Encoding and Content-Length can create request-smuggling risk if participants choose different boundaries. The specification defines handling and forwarding requirements; a gateway can adopt a stricter documented rejection policy. Do not repair ambiguous input by guessing which parser the next hop probably uses. HTTP/2 and HTTP/3 have different frame grammars, yet translating versions still requires preserving message semantics and rejecting invalid constructions consistently. Test the whole intermediary chain, not only a standalone parser fed neatly segmented examples.

The probability lab examines a smaller completeness assumption rather than implementing a parser. Reset, explicitly set BOTH delivery probability p=0.9 and trial count n=4, and predict that all four hypothetical independent pieces arrive with probability 0.9⁴ before Play or Step. Reset and re-set BOTH p=0.9 and n=10 for comparison. Playback highlights an exact distribution; it does not sample packets, split headers, or determine valid messages. A count of received pieces cannot establish byte order or framing. Use the worked state trace, not the bars, to decide when this protocol can emit a message.