Where a UDP Datagram Can Lose Its Tail After Reaching the Host

Locate the boundary between queued data and application memory

Consider a supplier report that counts datagrams reaching a receiver and describes them as complete application inputs. That conclusion skips a local boundary: the amount of data space supplied for each receive. Successful arrival and a successful receive return do not, by themselves, establish that all the payload bytes were copied.

Linux's UDP manual describes ordinary message receives that preserve datagram boundaries. When the pending datagram exceeds the supplied data space, the receive truncates it. This is consumption of a message, rather than a partial read that leaves the same message's remaining bytes for later.

The discussion concerns successful, single-message receives on a Linux IPv4 UDP socket. It excludes peeking, which leaves data queued, and the special input MSG_TRUNC length-reporting behavior discussed below. It also excludes UDP_GRO aggregation: that Linux option can deliver multiple datagrams' worth of data in one larger buffer with segment-size information. The one-datagram example must not be extended to that mode.

References: [U1][U2][K1]

Follow 1,200 bytes and 300 bytes through two 800-byte buffers

Invent two valid UDP datagrams, A and B, with payloads of 1,200 and 300 bytes. Both are already queued at the receiving socket, in that order. Assume one consumer, no intervening arrivals or errors, and two successive receives, each with 800 bytes of writable application data space. These are teaching assumptions, not a trace from an installation. Every size here counts UDP payload bytes, excluding UDP, IP and Ethernet headers.

The first receive takes A. It copies A's first 800 bytes and discards A's final 400 bytes. Under the stipulated ordinary length reporting, the return is 800; with recvmsg, output MSG_TRUNC identifies the truncation.

The second receive takes B and returns its 300 bytes without data truncation. It does not retrieve A's 400-byte tail, and it does not combine that tail with B. The unused 500 bytes of this second buffer do not recover space that was missing from the first receive.

The accounting is 1,200 + 300 = 1,500 payload bytes queued; 800 + 300 = 1,100 copied; and 1,500 - 1,100 = 400 discarded locally. Both datagrams were present before either receive. The difference between arrived bytes and copied bytes therefore needs no missing network datagram to explain it.

References: [U1][U2][K1]

Separate the copied count, output flag and input flag

A return of 800 into 800 bytes of data space is ambiguous by itself: an exactly 800-byte datagram could fit, or a larger one could have been truncated. In recvmsg's returned msg_flags, output MSG_TRUNC means a trailing portion was discarded because the supplied data buffer was too small. The flag does not quantify that portion.

Linux also accepts MSG_TRUNC as an input flag for Internet datagram sockets. That requests the original datagram length as the return value even when less data fits. Applied to A in a separate version of the example, the reported length would be 1,200, while only 800 bytes would be copied. This changes the reported count, not the data space or the fate of the tail.

When reviewing a report, establish which length convention it records and whether it retains the output truncation result. A number labeled received bytes needs that definition before it can support a completeness claim.

References: [U2][K1]

Identify which receive buffer a proposal means

The 800-byte limit here belongs to application memory supplied for one message receive. Socket receive storage is a separate resource; Linux documents SO_RCVBUF as a socket receive-buffer limit. A NIC receive queue is another boundary again. A proposal using only the words receive buffer leaves the relevant object unidentified.

In this example the socket already holds both datagrams. Its ability to hold them does not enlarge the 800-byte destination supplied by the application. Conversely, the local copy shortfall supplies no evidence that a NIC queue or socket queue overflowed.

MTU concerns packet sizing along a network path. The linked MTU and MSS article examines that separate byte budget. Once A is stipulated to be queued intact, changing the interpretation of a wire-packet limit cannot account for the 400 bytes discarded during this receive.

References: [U1][U2][S1]

Decide whether the evidence reaches the application requirement

For a buyer evaluating an endpoint's data-handling claim, the useful evidence connects the identified datagram, the data space supplied, the copied or reported length, the truncation result and the application's disposition. These observations answer different questions; an arrival count alone cannot replace the later ones.

Suppose A is intended to carry one complete application record. Its 800-byte prefix cannot supply the stipulated 1,200-byte input. Suppose B fits without truncation. That establishes completeness at this copy boundary, while leaving its decoding and acceptance to the application's own evidence. Copying every byte does not establish a valid or successfully processed record.

The worked case identifies a local discard; it establishes neither wire loss nor a bad cable. Without timing observations, it also supplies no packet-rate or throughput result. Keep those proposed conclusions tied to evidence at their own boundaries, rather than attributing every difference between arrival and application counts to the physical network.

For QUIC-based offers, use the linked DATAGRAM analysis to review the transport delivery contract separately from this UDP application's copy boundary.

References: [U1][U2][K1]

Connect a separate cabling project to its physical scope

For a separately identified fiber or copper installation, Leviathan's Structured Cabling & Fiber Installation service can discuss agreed routes, endpoint labels, physical checks and connection records using customer-furnished or separately sourced materials. Share a nonconfidential outline of the endpoints, pathways, materials responsibilities and required handoff. Software receive handling and application qualification remain with the appointed platform and software owners.

References: [L1]