LEARN. PRACTICE. GROW.A read does not define a record
Producer and consumer need to agree on how to recognize a message. In the original lab, two messages have bodies of 12 and eight bytes, each preceded by a two-byte length. One sendall call supplies all 24 bytes to the socket; the consumer requests at most three bytes per recv. The parser reconstructs both messages. The eight observed reads belong to the application API. No packets were captured, so they do not establish eight TCP segments. This distinction prevents changing packet sizes when the defect lies in the parser.
Accumulate, extract and retain the remainder
The parser keeps a buffer of unconsumed bytes. It interprets length only after receiving the complete header and emits a message only after receiving the complete body too. It then removes exactly those bytes and checks for another message. In a fictional positions feed, this supports half a header or several nearby messages without losing alignment. The runner also checks all 25 possible positions for splitting the same 24 bytes into two parts. These are parser checks, additional to actual reads, rather than an exhaustive network simulation.
End of stream with incomplete work
In another experiment, the header announces ten bytes, but the producer sends only abc and ends its write direction. The consumer receives EOF with seven body bytes missing. The parser rejects that outcome as an incomplete message. The transport layer can end in an orderly way without satisfying the application contract. In the handover, report expected length, received bytes, flow identity and absence of a complete message. Do not adjust the length to the received result. Do not assume another connection automatically continues the previous stream either: that recovery needs its own contract.
End the request without losing the response
A protocol may use the end of the request direction as a delimiter. The lab client sends REPORT END and calls shutdown(SHUT_WR). The server reads to EOF and only then sends REPORT RECEIVED; the client still receives that response. Ending writes and releasing the entire socket are different operations. For a real integration, establish that the protocol supports this behavior and define response framing and a deadline. The synthetic message demonstrates the direction that remained open, but it does not represent financial-report acceptance, persistence or business authorization.
Send completion is one stage
The sequential experiment also calls sendall before any server read. Sending completes while the remote application read count is still zero. The runner later reads the 19 synthetic bytes. That ordering is enough to show that send completion does not imply application consumption. There was no ACK capture or database. When a send API raises an exception, do not invent a safe offset for retrying part of the request. Retain the operation identity and use the reconciliation mechanism defined for uncertain outcomes.
Accept a feed correction
In the fictional positions case, inserting a delay between messages may hide an incorrect parser. Acceptance should vary byte splits and include consecutive messages, mid-message EOF and lengths outside the agreed limit. The executed lab covers small reads, two-part splits and an interrupted body; it does not measure load or execute every proposed boundary case. Also define the total deadline for completing a message and the action when it expires. Reconciling records affected by the release is part of recovery alongside the technical fix and evidence for RUN.
One 24-byte write produced eight three-byte reads and two valid messages. A second experiment received five framing bytes but rejected an incomplete body announced as ten bytes.
Common pitfalls
Using a read as a message; interpreting EOF as business completion; calling close while a response is still needed; confusing sendall return with reading or persistence; presenting chunks as captured packets.
Related topics: Transport, acknowledgement, and messages · States, queues, and flow control · Diagnosis in the application context
The application contract defines the message and acknowledgement. Preserve parser state, bounds and evidence for each stage even when transport ends without an explicit error.
Reference: Transmission Control Protocol · BigSavant TCP/IP 2026-09; TCP RFC 9293; IPv6 RFC 8200 with RFC 9673 update; Linux socket and iproute2 guidance