Datagram Model

## Two delivery models A transport either moves **messages** or moves **bytes**. UDP moves messages: the unit the application hands down is the unit that travels and the unit the receiver gets back. TCP moves bytes: the application writes into a stream, and TCP decides how to cut that stream into segments. | Question | UDP | TCP | |---|---|---| | Unit of delivery | the datagram | the byte | | Three 100-byte sends arrive as | up to three 100-byte datagrams | 300 bytes, cut anywhere | | Can one read return parts of two messages? | no | yes | | Can one message arrive partly? | no — whole or not at all | yes, across several reads | | Order | not guaranteed | guaranteed | | Every byte arrives | not guaranteed | guaranteed while the connection lives | The table is the whole trade: UDP keeps the edges and gives up the guarantees; TCP keeps the guarantees and gives up the edges. ## What the UDP receiver gets - **One send is one datagram.** RFC 768 describes UDP as a way "to send messages to other programs"; each send produces exactly one datagram carrying one UDP header. - **One receive returns one datagram.** Never two merged, and never the rest of one on a later receive. The protocol hands up whole datagrams; if the application's buffer is smaller than the datagram, how the excess is handled is an API matter owned by the sockets topic. - **Whole or not at all, even when fragmented.** If a datagram exceeds the path MTU, IP fragments it and the receiving host reassembles it before UDP sees anything. RFC 8085 §3.2: losing any single fragment loses the entire packet. Boundaries survive; delivery probability falls. - **Empty is valid.** RFC 8085 §5 notes a receiver can get a valid datagram with a zero-length payload — still one message, useful as a heartbeat. On TCP, a read returning zero bytes means the peer closed its direction. - **Nothing about order or completeness.** Three datagrams may arrive as 2, 1, 3, or only 1 and 3. ## What the TCP receiver gets RFC 9293 §3.7: individual segments "often do not correspond one-for-one" to send calls, and TCP "guarantees no correlation" between segment boundaries and the application's read or write buffers. For three 100-byte writes, all of these are legal read sequences: 1. one read of 300 bytes; 2. 150 bytes, then 150 bytes; 3. 1 byte, then 299 bytes; 4. 100, 100, 100 — which happens often in testing and is never promised. Case 4 is why framing bugs survive into production: on a quiet local link each write often does arrive alone, and the code that assumed so breaks under load or across a slower path. ## Framing: who marks the edges On TCP the application protocol must define where a message ends. Two common approaches: - a **length prefix** — each message begins with its size, so the reader knows how many bytes to collect; - a **delimiter** — messages end with a reserved byte sequence, such as a line terminator in text protocols. On UDP the datagram *is* the frame. The receiver never has to reassemble a message from pieces or split a read into several messages. That is a real simplification, and one reason request-response protocols such as DNS started life on UDP. ## A telemetry sender as the worked case Consider a service that emits one metric line per event to a collector over UDP: - Each line goes out as **one datagram**, so the collector parses exactly one record per receive — no buffering of partial lines, no searching for newlines across reads. - A lost datagram costs **one record**, and never corrupts the next one, because nothing is spread across two datagrams. - The sender must never split a record across datagrams: the halves could arrive in either order, or only one could arrive, and UDP offers nothing to rejoin them. - Keeping each datagram under the path MTU avoids fragmentation, whose all-or-nothing loss multiplies the drop rate; the exact size limits belong to the UDP header topic. The design rule that falls out: **one self-contained message per datagram**. Everything the receiver needs to act on the message — identity, value, sequence or timestamp — travels inside that one datagram.