Noesis
4.3.18 · D5Computer Networks

Question bank — UDP — header, use cases, checksum

1,387 words6 min read↑ Back to topic

True or false — justify

Cover the answer, decide true/false, and state the reason before revealing.

UDP performs no error detection whatsoever.
False. UDP carries a 16-bit checksum that detects corruption; it simply never fixes it — corrupt datagrams are dropped silently, not retransmitted.
UDP is a byte stream just like TCP but faster.
False. UDP is message-oriented: one send() becomes exactly one datagram becomes one recv(), so message boundaries are preserved. TCP has no boundaries at all.
A UDP sender must complete a handshake before sending its first byte of data.
False. UDP is connectionless — the very first packet carries application data immediately, which is why a DNS lookup can finish in a single round trip.
If the UDP checksum verifies, the payload is guaranteed intact.
False. The checksum is only 16 bits, so paired errors can cancel (one word , another ) and still pass. It catches most single-bit flips, not all corruption.
The UDP Length field is redundant because IP already carries a total-length field.
False. Length lets the receiver split header from data without trusting IP arithmetic, and it is folded into the pseudo-header checksum — defensive, not wasteful.
Sending a UDP checksum of 0x0000 means "the checksum came out to zero."
False. 0x0000 is the reserved code for "no checksum computed." A genuine zero result is transmitted as 0xFFFF instead (both mean zero in one's complement).
The UDP checksum only covers the UDP header and payload.
False. It also covers a pseudo-header (source IP, dest IP, protocol = 17, UDP length) borrowed from the IP layer, so a datagram delivered to the wrong machine fails the check.
In IPv6, a UDP sender may skip the checksum to save time.
False. The checksum is optional only in IPv4. In IPv6 it is mandatory, because IPv6 has no header checksum of its own to catch address corruption.
UDP provides ordering — datagrams arrive in the order sent.
False. UDP offers no ordering. Two datagrams can take different paths and arrive reversed; if order matters, the application must number them itself (as QUIC does).

Spot the error

Each statement below contains a flaw. Find it, then reveal the correction.

"UDP adds 20 bytes of header, same minimum as TCP."
Wrong number. UDP's header is only 8 bytes (four 16-bit fields). TCP's minimum is 20 bytes — the 12-byte saving plus no handshake is UDP's whole appeal.
"UDP guarantees a lost packet will be re-sent quickly."
UDP never retransmits. Lost means gone; recovery is entirely the application's responsibility. That "no recovery" is exactly what unreliable means.
"Because it's unreliable, UDP has no way to identify which program should receive a datagram."
Reliability and addressing are separate. UDP still carries source and destination port numbers (16 bits each) for multiplexing to the right process.
"The checksum uses ordinary two's-complement addition."
It uses one's-complement addition — overflow past 16 bits is wrapped around and added back into the low 16 bits, so no carry information is lost. See One's complement arithmetic.
"Streaming video should use TCP so no frame is ever lost."
Timeliness beats completeness here. A retransmitted old frame arrives too late to display — better to drop it and move on, which is why live media favours UDP.
"A UDP datagram with an empty payload has a Length field of 0."
Minimum Length is 8, not 0 — the header itself is 8 bytes, and Length counts header + data.
"The receiver, on a checksum failure, sends back an error message to the sender."
No such message exists in UDP. The corrupt datagram is dropped silently; the sender is never told. Notification, if wanted, must be built by the app.

Why questions

Why does the pseudo-header include the destination IP address in the checksum?
So a datagram accidentally delivered to the wrong machine fails verification — the wrong IP corrupts the folded-in checksum. It's a deliberate layering "violation" accepted for safety.
Why does one's-complement addition wrap the overflow carry back in?
To keep the running sum inside 16 bits without discarding information — the carry that spilled past bit 16 is recycled into the low bits rather than lost.
Why send the complement of the sum rather than the sum itself?
Because is all-ones, the receiver can add everything including the checksum and simply check for 0xFFFF, needing no subtraction or comparison.
Why does DNS prefer UDP for a normal query?
One tiny request, one tiny reply — a three-packet TCP handshake would cost more than the lookup itself, so UDP's zero-handshake wins.
Why does UDP include a Length field when IP has one too?
For convenience and a sanity check: the receiver need not subtract the IP header size to find where UDP data ends, and Length participates in the checksum.
Why is a late video frame worse than a missing one?
A frame that arrives after its display moment is useless clutter; skipping it lets playback stay in sync, so dropping beats waiting.
Why does QUIC build on UDP instead of TCP?
To implement custom reliability, ordering, and encryption in userspace and dodge TCP's rigid, kernel-baked rules — UDP gives the thin, transparent base it needs.
Why can't a strong integrity guarantee come from the UDP checksum alone?
16 bits is far too small to resist deliberate or compensating errors; real integrity needs a cryptographic hash such as those in TLS.

Edge cases

What happens if the one's-complement sum genuinely equals 0x0000 before complementing?
The transmitted checksum would be 0xFFFF (the complement of zero), which is fine — the reserved 0x0000 code is never produced this way, keeping "disabled" distinguishable.
A datagram carries a correct checksum but arrives out of order — does UDP fix it?
No. The checksum only confirms the bits are intact; ordering is outside UDP's job, so the application must reorder if it cares.
A UDP datagram is duplicated in the network and both copies arrive. What does UDP do?
Nothing — UDP has no duplicate detection, so the application receives the datagram twice unless it adds its own sequence numbers.
An IPv4 sender sets checksum 0x0000; a bit later flips in the payload. Is it detected?
No. With the checksum disabled there is nothing to verify against, so the corrupted payload is delivered as-is — one reason IPv6 makes the checksum mandatory.
Two independent bit errors flip word A up by 1 and word B down by 1. Does the checksum catch it?
No — the changes cancel in the sum, so verification still yields all-ones and the corruption slips through. This is the fundamental limit of a 16-bit checksum.
A datagram is delivered to the right machine but the wrong port. Does the checksum notice?
No — the port numbers are covered by the checksum, but the network delivers by IP+port lookup; a checksum failure would only arise if the port bits were corrupted, not merely mismatched to an idle port.
Recall One-line self-test

Name the single word that separates "UDP detects errors" from "UDP fixes errors." Answer ::: Recovery. UDP detects (via checksum) but never recovers (no retransmit) — that missing recovery is precisely the meaning of "unreliable."