UDP recv buffer truncation

The idea

TCP is a byte stream: a read hands you whatever bytes have arrived, and message boundaries are yours to recover. UDP is different — it preserves datagram boundaries, so one recvfrom returns exactly one datagram, no more and no less.

That guarantee has a sharp edge. If a datagram is larger than the buffer you pass, the kernel copies only as many bytes as fit and silently discards the rest of that datagram. The excess is gone — the next recvfrom returns the next datagram, never the leftover tail. On Linux, the MSG_TRUNC flag lets you learn the datagram's true length so you can at least detect that loss happened.

How it works

You hand recvfrom a buffer and its length. It copies one datagram, capped at that length, and returns how many bytes it wrote. Without help, a truncated read looks identical to one that fit exactly — both just return a count. Pass MSG_TRUNC and the return value becomes the datagram's real length, so a value larger than your buffer is the tell that bytes were dropped.

// UDP receive with truncation detection (Linux)
char buf[8];                       // deliberately small buffer
ssize_t n = recvfrom(fd, buf, sizeof buf, MSG_TRUNC,
                     (struct sockaddr *)&src, &srclen);
if (n < 0) { perror("recvfrom"); return; }

// With MSG_TRUNC, n is the datagram's TRUE length,
// not how many bytes landed in buf.
if ((size_t)n > sizeof buf) {
    // *** TRUNCATION: n - sizeof(buf) bytes were discarded ***
    // buf holds only the first sizeof(buf) bytes; the tail is gone.
    log_drop(n - sizeof buf);
}
// Fix: size buf to the maximum datagram you can receive.

Cost & trade-offs

Watch out for

• Silent loss by default. A short read raises no error — recvfrom just returns a count. Without MSG_TRUNC you cannot tell a perfectly-sized read from a truncated one.
• Sizing to typical, not maximum. A buffer big enough for the common case overflows on the occasional large datagram. Size to the largest datagram the protocol allows, not the average.
• Expecting the leftover next time. The discarded tail does not arrive on the next read. The next recvfrom returns a different, whole datagram.
• Ignoring MSG_TRUNC. The flag is your only signal that truncation occurred. Skip it and corrupted, half-parsed messages flow downstream unnoticed.
• Fragmentation and MTU surprises. Large datagrams get IP-fragmented; a lost fragment drops the whole datagram, and small receive buffers compound the surprise.

Worked example

A sensor emits a 1500-byte reading as a single UDP datagram, but the receiver loops on recvfrom with a 512-byte buffer. Each read returns 512 bytes and the kernel discards the remaining 988 bytes — silently, with no error. The reader parses a truncated payload and never notices the gap. The fix is to size the buffer to the maximum datagram (65535 is the conventional ceiling for the UDP payload), and to pass MSG_TRUNC so any future oversize is flagged rather than swallowed.

Check yourself