UDP — header, use cases, checksum: Visual walkthrough

Before line one, two words we must earn:

Step 1 — Why sum anything at all?

WHAT. We take the data we want to protect and chop it into 16-bit words. Our example: three words $w_{1} = 0x4500, w_{2} = 0xF6CB, w_{3} = 0x0000 .$

WHY. Bits flip in transit — a router glitches, a cable picks up noise, and a 0 silently becomes a 1. We want a cheap way to notice. The idea: squash all the data into one small number (a "fingerprint"). Send the fingerprint too. If any bit flips, the fingerprint changes and won't match. Summing is the cheapest fingerprint a computer can make — addition is one CPU instruction.

PICTURE. Look at the red word: it's the one we'll watch as it flows through every step. The three words are just three rows of switches lined up, waiting to be added.

Here $w_{1}$ = the first slice, $w_{2}$ = the second, $w_{3}$ = the third. Each is a plain integer between $0$ and $65535$ . Nothing magic yet — we're only slicing.

Step 2 — Add the first two words (and hit a wall)

WHAT. Add $w_{1} + w_{2}$ as ordinary numbers: $w_{1} 0x4500 + w_{2} 0xF6CB = 5 hex digits! 0x13BCB$

WHY. Plain addition is our fingerprint machine. But look — the answer has five hex digits ( $1 3BCB$ ), and a 16-bit word only holds four ( $FFFF$ ). The leading 1 is a 17th bit that overflowed the row of switches. We can't just throw it away — that would lose information, and a lost bit means a corrupted word could sneak past unnoticed.

PICTURE. The red 1 on the far left is the overflow carry — it fell off the left edge of the 16-switch row. Everything to the right of it ( $3BCB$ ) still fits; the red 1 does not.

$0x13BCB$ = the honest full sum.
The red 1 (worth $0x10000$ ) = the part that won't fit in 16 bits.
$0x3BCB$ = the part that does fit.

Step 3 — Wrap the carry around (the clever trick)

WHAT. Take the overflow 1 and add it back onto the low 16 bits: $low 16 bits 0x3BCB + recycled carry 0x1 = 0x3BCC .$ This "add the carry back in" move is what makes it one's-complement addition (as opposed to ordinary addition).

WHY. We refused to discard the carry in Step 2. Recycling it back into the low bits keeps the result inside 16 bits without losing any information. Mathematically, wrapping a carry of $0x10000$ back as $0x1$ works because $0x10000 \equiv 0x1 (mod 0xFFFF)$ — every overflow is worth exactly +1 in this recycled arithmetic. (This is the One's complement arithmetic fact that makes the whole scheme click.)

PICTURE. The red arrow loops the overflow bit from the far left back to the far right and drops it into the low end. The switches settle to $0x3BCC$ .

$0x3BCC$ = the wrapped, back-in-range running sum.
Note the last digit went from B to C: the recycled +1 landed there.

Step 4 — Add the remaining word

WHAT. Fold in $w_{3}$ : $running sum 0x3BCC + w_{3} 0x0000 = 0x3BCC .$ No overflow this time, so no wrap is needed.

WHY. We repeat Steps 2–3 for every remaining word — add, and wrap if it overflows. Here $w_{3}$ is zero, so the sum doesn't budge. We keep going until every word has been folded in. What we're left with — $0x3BCC$ — is the complete fingerprint of the data.

PICTURE. Adding a row of all-off switches ( $0x0000$ ) changes nothing; the red running-sum bar stays put. This is the "no carry" branch of the loop.

$0x3BCC$ = the final sum over all data words.
Call this quantity $S = 0x3BCC$ . We'll use it in the next step.

Step 5 — Flip the bits to make the checksum

WHAT. Take the one's complement of the sum — flip every switch: $checksum = \overline{S} = \overline{0x3BCC} = 0xC433 .$ This $0xC433$ is what actually travels in the UDP header's Checksum field.

WHY send the flip and not $S$ itself? Because of one beautiful identity: a number plus its own flip is always all-ones, $x + \overline{x} = 0xFFFF (sixteen 1s) .$ Every switch that's OFF in $x$ is ON in $\overline{x}$ , and vice-versa — so together they light up all 16. This means the receiver won't need to know $S$ ; it can just add everything (data plus the checksum) and expect $0xFFFF$ . Sending the flip pre-loads that check.

PICTURE. Top row = $S = 0x3BCC$ . Bottom row = its flip, the red checksum $0xC433$ . Every switch in the bottom row is the opposite of the one above it.

$S = 0x3BCC$ = data fingerprint (stays with the sender's math).
$\overline{S} = 0xC433$ = the transmitted checksum.

Step 6 — The receiver checks by summing to all-ones

WHAT. The receiver adds up the data words and the checksum, one's-complement style: $sum of data S 0x3BCC + received checksum 0xC433 = 0xFFFF .$ All ones → accept. Anything else → drop silently.

WHY this works. The receiver re-adds the data to get $S$ again, then adds the checksum $\overline{S}$ . By Step 5's identity, $S + \overline{S} = 0xFFFF$ . So a clean datagram always sums to all-ones. If even one bit flipped in transit, $S$ changes, the sum is no longer all-ones, and the receiver knows. Note: it can detect the error but not fix it — dropping is all UDP does (recovery is the app's job, as the parent note stressed).

PICTURE. Two red bars ( $S$ and $\overline{S}$ ) merge into a single all-lit row $0xFFFF$ — the "green light."

$0xFFFF$ = the pass signal. Any other value = corruption.

Step 7 — Edge case: the sum is genuinely zero

WHAT. Suppose the data really does add up to $S = 0x0000$ . Then $\overline{S} = 0xFFFF$ . Fine — send $0xFFFF$ . But what if the checksum itself computes to $0x0000$ ? UDP forbids transmitting a literal $0x0000$ as the checksum; you send $0xFFFF$ in its place.

WHY. In one's-complement arithmetic there are two spellings of zero: $0x0000$ (all off) and $0xFFFF$ (all on, "negative zero"). They're equal. That freedom lets UDP reserve the exact value $0x0000$ to mean "I didn't compute a checksum — don't check me" (allowed in IPv4, forbidden in IPv6). So a real checksum of zero is always written as its twin $0xFFFF$ , keeping $0x0000$ unambiguous.

PICTURE. Two switch-rows, all-off and all-on, joined by an = — one labelled "means: no checksum", the other (red) "the value we actually send".

$0x0000$ = reserved flag: checksum disabled.
$0xFFFF$ = the real "zero" checksum you transmit instead.

The one-picture summary

Everything above is one loop and one flip. Here is the whole machine on a single canvas: slice → add-with-wrap (repeat) → flip → transmit; and on the far side, add-everything → expect all-ones.

Recall Feynman retelling — the whole walkthrough in plain words

I want to protect a message so my friend can tell if it got smudged. First I chop it into equal-size chunks and just add them all up — that's my fingerprint. But addition sometimes overflows past 16 digits; instead of throwing the spillover away (which would lose info), I loop the overflow back around and add it to the bottom — that's the "one's-complement" wrap. Once every chunk is folded in, I have one fingerprint number. Now the trick: instead of sending the fingerprint, I send its photo-negative (every 0↔1 flipped), because a number plus its own negative always lights up all sixteen bits. So my friend just adds everything I sent — the chunks and the negative — and if it comes out all ones, nothing got smudged; if not, they toss it and wait for the next one. One special rule: an all-zero result gets rewritten as all-ones before sending, because plain all-zeros is the secret code for "I skipped the checksum."

Recall Quick self-test

Why do we wrap the carry instead of discarding it? ::: Discarding the overflow bit would lose information, letting some corrupted datagrams pass undetected. Wrapping keeps the result in 16 bits while preserving every bit's contribution (an overflow of 0x10000 is worth +1 in this arithmetic). Why transmit the complement of the sum, not the sum? ::: Because $x + \overline{x} = 0xFFFF$ , so the receiver can simply add the data plus the checksum and check for all-ones, without needing to know the sum separately. What does a transmitted checksum of 0x0000 mean? ::: "No checksum was computed" (allowed in IPv4). A genuine zero result is sent as 0xFFFF instead so the two never collide.