UDP: when losing packets is the right trade

What UDP declines to do

Every guarantee Module 6 relied on comes from TCP, not from IP. Strip TCP away and you get the User Datagram Protocol, which adds eight bytes of header — source port, destination port, length, checksum — to a raw IP packet and stops there.

So there is no connection: nothing is established and nothing is torn down. There is no ordering: two datagrams may arrive in either order, and nothing tells you which was sent first. There is no delivery guarantee: a datagram whose checksum fails is discarded silently by the network stack, and neither end is told. There is no flow control: a fast sender will happily overrun a slow receiver until packets start disappearing. And there is no retransmission, because nothing is tracking what arrived.

What you buy by declining

Latency, and the absence of head-of-line blocking. A TCP connection costs a three-way handshake before the first byte of payload moves, which is a full round trip you pay whether you are sending one datagram or a gigabyte. Worse for real-time work: when a TCP segment goes missing, everything behind it waits, because TCP owes the application an in-order stream. Your data has arrived, it is sitting in the kernel, and you cannot have it until the retransmission of an earlier segment lands.

For a live voice call that stall is the whole problem. A single lost 20-millisecond frame is a click nobody notices. A 300-millisecond gap while TCP repairs it is an audible break in the conversation — and by the time the repaired frame arrives it is stale and useless anyway. Discarding the loss is not a compromise here; it is strictly the better answer.

Where UDP is the right answer

The pattern is short exchanges with no useful history, or real-time data with a shelf life.

• DNS. A query and a reply, both small enough for one datagram. Establishing a connection would cost more round trips than the lookup itself. Lost query? Ask again.
• Real-time audio and video. Late data is worthless data.
• TFTP and NFS. Deliberately simple protocols that handle their own retries at the application layer.
• Service discovery and telemetry. Frequent, cheap, individually unimportant messages — and the natural home of the multicast you meet in L13.6.

The warning sign

You can build reliability on top of UDP. Number your datagrams, acknowledge them, retransmit on timeout, buffer to reorder, back off when losses climb. People have — NFS and TFTP both do a version of it.

Treat the urge as a diagnostic. Every one of those mechanisms is something TCP already implements, in the kernel, tuned over four decades and tested by the entire internet. If your requirements have driven you to reimplement three of them, the requirement was TCP and the choice was wrong. Choose UDP for what it is — cheap, connectionless, lossy, fast — not as a foundation to rebuild TCP badly on top of.

The role inversion: one socket serves every peer

The API consequence surprises people more than the protocol does. In TCP, addressing lives in the socket: a Socket is bound to one peer for its lifetime, and a server needs a separate ServerSocket whose only job is to manufacture one Socket per client.

In UDP, addressing lives in the packet. Every DatagramPacket carries its own source or destination address and port, so the socket only needs to know which local port to sit on. There is no DatagramServerSocket because there is nothing for it to do. One DatagramSocket receives from every peer on earth and sends to every peer on earth, and telling them apart is your job — you read the sender off each packet as it arrives.

Worked example — choose the transport for three services

A file transfer for a software update. Every byte must arrive, in order, intact. TCP, and the question is not interesting.

A name lookup service answering millions of one-shot queries. Each exchange is two small messages with no history. A TCP handshake would triple the cost of the operation, and the client can simply re-ask after a timeout. UDP — this is DNS, and it is why DNS is UDP.

A sensor network: 500 devices, one 40-byte reading each per second, dashboard tolerates gaps. A missed reading is a one-pixel hole in a graph; a stalled feed is a broken dashboard. UDP, with one DatagramSocket on the collector serving all 500 devices, and the sender identified from each packet. Note the shape of the win: it is not that UDP is faster on the wire, it is that the collector needs one socket and no per-device state at all.