Recover frames across arbitrary TCP reads
03TCP does not preserve an application’s send calls as matching receive calls. One read may stop inside a length prefix or message; another may contain several frames. The receiver buffers bytes and uses each frame’s declared length to decide when a complete message is available.
The last read adds B’s remaining 19 payload octets. Deliver B once; the buffer is empty. A had already been emitted and is not returned again. A separate premature close with partial data would stop without fabricating a complete message.
Source for this drawing: RFC 6587 · Read RFC section 3.4 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
A TCP read boundary is not a syslog message boundary.
- The stream grammar permits zero or more consecutive SYSLOG-FRAME values. Each frame contains one message. The RFC’s term TCP frame here is an application framing unit, not a promise of one TCP segment, packet or read per syslog message.
- After reading the decimal prefix and SP, consume exactly the declared number of message octets. Keep incomplete bytes for the next read and leave any following bytes to start the next frame. Do not split a message merely because the socket returned fewer bytes.
- Coalesced reads may complete one frame and contain another. Emitting each complete frame while advancing the stream position avoids re-emitting an already delivered frame when more data arrives.
- The demonstration retains complete messages before a later malformed or truncated frame. It never emits an incomplete payload. Its local stop on invalid prefix, size bound or premature end is a teaching implementation policy; RFC 6587 does not define an application error response or mandatory parser recovery algorithm.
Chunk sizes are chosen teaching examples, not TCP packet sizes, timers or mandatory read budgets. This bounded receiver models framing only; it does not implement TCP, syslog parsing, persistent storage or network interoperability.
Read the RFC section ↗