Builder · Lesson 03

How do networks detect and correct transmission errors?

Signals can be altered or disappear on the way. Detection fields identify damage, while correction codes or retransmission help recover usable data.

Interpret the check

A checksum is evidence, not identity.

If the receiver calculates the expected value and it matches the received value, the data is likely unchanged under that check. A checksum is not encryption and does not prove who sent the data.

When an attacker can deliberately change both the data and an unprotected checksum, a simple integrity check may still match. Cryptographic integrity mechanisms such as a message authentication code or digital signature add a secret or a signing identity to answer the stronger question: who authorized this content?

Detection and authentication answer different questions.Checksums and CRCs are efficient detectors of accidental corruption; cryptographic mechanisms are designed to resist deliberate tampering.

Detect or recover

A receiver can notice damage, but detection is not correction.

Noise, interference, or a weak signal can change bits while a frame is travelling. A sender adds a small verification value; the receiver calculates it again and compares the result. If the values disagree, the frame is considered corrupted.

A lost frame is different: there is nothing to verify. A timeout or missing acknowledgement can suggest loss, while a failed check identifies corruption.

Detection answers “is this data intact?”Recovery answers “how should we obtain a usable copy?” The two questions may be handled by different layers.

Build the model

Four useful tools for reliable delivery

01

Checksum

A compact value calculated from data. IP, TCP, and UDP use checksums for different integrity checks.

02

CRC

A polynomial remainder designed to detect common patterns of bit corruption efficiently.

03

FCS

The Frame Check Sequence at the end of many link-layer frames carries an integrity check, often a CRC.

04

Retransmission

A sender or protocol obtains another copy after loss or a detected failure when its contract supports recovery.

Correct or retransmit

Some codes can repair a limited error in place.

Redundancy does more than announce that something went wrong. In a forward error correction (FEC) code, carefully placed parity bits let the receiver infer which bit is wrong and flip it back. A Hamming (7,4) code carries four data bits and three parity bits, enough to locate one bad bit.

Automatic repeat request (ARQ) takes another path: the receiver reports success or failure, and the sender transmits a fresh copy. FEC spends bandwidth on redundancy; ARQ spends time and feedback on another attempt.

Correction reconstructs; retransmission replaces.Neither mechanism is unlimited. A code has a correction capacity, and retransmission needs a return path plus a sender that still has the data.

Hamming (7,4) decoder

Codeword positions

0110011
SYNDROME 000Codeword valid

All parity checks agree. The four data bits are 1011.

Mini experiment

Inspect what the receiver sees.

Select a transmission outcome. Follow the evidence from the received frame to the next action.

HEADER1011 0010 0110FCS · 7A3C
CHECK PASSESFrame accepted

The receiver computes the same verification value and passes the payload to the next step.

The frame can continue across this local hop.

Knowledge check

Test your error-and-recovery model

Answer eleven questions. The answer order changes each time.

0 / 11