What Arrives, and What Does Not

The one guarantee UDP gives, and the five things it does not

Step 1 of 2 — understand the idea. Read this first and the packet trace will confirm what you already expect, instead of teaching you two things at once.

What you'll be able to do

▸Explain why datagram boundaries survive but ordering does not
▸List what the network may do to a datagram in flight
▸Say why a UDP application needs its own pacing for bulk data

Before this lesson — it builds directly on:

The Eight-Byte Header

UDP promises almost nothing about delivery. But it promises one thing absolutely, and it is the thing TCP will not: a datagram arrives whole, or not at all. Send 5 bytes and the receiver reads 5 bytes in one go. Send 6 more and they read 6, separately. The two never merge, and neither is ever split. TCP does not work like that. Send 5 bytes then 6 and the receiver may read 11 in one lump, or 3 then 8, or any other division — because TCP delivers a stream of bytes and your write boundaries are not part of it. That is why HTTP has to carry a Content-Length and DNS does not.

Posting letters, versus feeding paper into a fax machine. Each letter arrives in its own envelope, complete, and nobody has to work out where one ends and the next begins. A fax delivers a continuous roll: everything you sent comes out, in order, but the page breaks are yours to find.

one letter, one envelope: → one send() is one datagram is one recv()
the size written on the envelope: → the UDP length field, making the boundary explicit
the continuous roll of fax paper: → TCP's byte stream
finding the page breaks yourself: → Content-Length and chunked encoding in HTTP

Where it breaks down: Letters arrive — that is rather the point of posting them. A UDP datagram may simply never arrive, with nobody told. The guarantee is about SHAPE, not about delivery, and confusing the two is the mistake this lesson exists to prevent.

✗ Common misunderstanding: Because UDP preserves message boundaries, a message either arrives correctly or the sender finds out.

Why that's wrong: The boundary guarantee is about shape, not delivery. A lost datagram is lost silently; a datagram that arrives is complete. Those are two separate facts.

Correct model: UDP guarantees that what arrives is exactly what was sent, as one unit. It guarantees nothing whatever about whether anything arrives.

The packets prove it: The loss lab drops a datagram and the trace that follows contains no error, no timer and no retransmission — while the two that did arrive are each complete.

Watch these fields in the lab: udp.length · udp.payload

1Deliver them. The common case, and the one that hides everything below it.
2Lose them. A queue overflows or a link errors. Nobody is told, and the sender's send() already returned successfully.
3Reorder them. Two datagrams take different paths, or one queues behind a burst. They arrive in the wrong order and nothing puts them back.
4Duplicate them. A retransmitting link layer or a routing loop delivers the same datagram twice. The application sees it twice and has to cope.
5Corrupt them. Caught by the checksum, then discarded silently — so from the application's side corruption and loss are indistinguishable.
6Fragment them. A datagram larger than the path MTU is split by IP and reassembled at the destination. Lose one fragment and the whole datagram is lost.

✗ Common misunderstanding: Reordering does not really happen — packets follow the same path.

Why that's wrong: Equal-cost multipath, link bonding and queueing all reorder traffic routinely. A protocol that assumes otherwise fails intermittently, which is the hardest kind of failure to diagnose.

Correct model: Assume reordering. If order matters, number your own messages in the payload — which is what every UDP protocol that needs ordering actually does.

The packets prove it: The reordering lab delivers datagrams out of order and the receiving application sees them in the order they arrived, not the order they were sent.

Watch these fields in the lab: udp.length

✓ Concept check — before you open the packets

These test the idea, not the trace. You should be able to answer them from the explanation above.

An application sends 5 bytes, then 6 bytes, over UDP. What does the receiver read?

A UDP application must be able to handle a datagram arriving twice. Why?

Now that you understand the concept, observe how it appears in the packet exchange.

The lab runs a real simulated capture — pause, step, click any packet, and inspect every byte.