Transport Protocols · Study deck

Error Detection: CRC and Checksums

Picture a pressure reading that reaches a pump controller with one changed bit.

Packet Pete is your guide for this deck.

error-detectionchecksumspacket-evidence

After studying this chapter

Learning objectives

You will be able to:

Explain: Error detection asks whether a receiver can notice a corrupted, malformed, repeated, or suspicious message before treating it as valid.
Explain: A simple checksum can catch many accidental changes, but a weak checksum may miss some error patterns.
Explain: For example, meter-12 sends a pressure sample with payload bytes, a sequence value, and a CRC.
Explain: The receiver must decide whether to accept, reject, ask again, or enter a safe unknown state.

Major section

Start With the Suspicious Packet

The receiver must decide whether to accept, reject, ask again, or enter a safe unknown state.

A red error light is useful only if that decision and its limit are clear.
A checksum is a small value calculated from a stated part of a message.
A cyclic redundancy check, or CRC, is a stronger form designed to catch common bit changes.

Major section

Overview: Detection Is a Bounded Claim

Error detection asks whether a receiver can notice a corrupted, malformed, repeated, or suspicious message before treating it as valid.

If the receiver drops the malformed frame and emits a diagnostic, the evidence supports bounded rejection.
For example, meter-12 sends a pressure sample with payload bytes, a sequence value, and a CRC.

Error-detection evidence becomes reviewable when every step connects a protected message to an observed receiver decision and a stated limit.

Major section

Practitioner: Build the Error-Detection Record

The method describes how the check is interpreted.

A routine telemetry sample might be dropped.
A command might be rejected and alarmed.

A compact record keeps method details, observed condition, receiver action, decision, limits, and retest ownership separate.

Major section

Under the Hood: Know What the Check Cannot Prove

A simple checksum can catch many accidental changes, but a weak checksum may miss some error patterns.

Parity can support a narrow bit-level check.
Error detection also sits below several other review layers.

A CRC review is repeatable only when both sides use the same protected byte range, profile, and comparison rule, and the record still limits the claim to packet-level error detection.

Major section

Retries and Sequence Numbers

A gateway is the unit that links one device group to another network or service.

Retries reduce some loss; they do not prove the result.
Under the Hood defines receiver state, duplicate rules, wrap, and side-effect limits.

Retry and sequence evidence should close the loop from observation to final state.

Deck summary

Key takeaways

The receiver must decide whether to accept, reject, ask again, or enter a safe unknown state.

Error detection asks whether a receiver can notice a corrupted, malformed, repeated, or suspicious message before treating it as valid.
The method describes how the check is interpreted.
A simple checksum can catch many accidental changes, but a weak checksum may miss some error patterns.
A gateway is the unit that links one device group to another network or service.

Retrieval practice

Recall check 1 of 6

Packet Pete says: answer from memory, then check your reasoning.

Q1A trace shows that a checksum rejected one corrupted datagram. What claim is supported?

AAll future corruption will be detected and safely handled

BThe payload was authorized because the checksum failed closed

CA bounded detection claim for this path

DRetest is unnecessary after message format or receiver changes

Show answer

Answer: C Checksum and CRC evidence should be tied to scoped messages, observed receiver actions, limits, and retest triggers.

Retrieval practice

Recall check 2 of 6

Packet Pete says: answer from memory, then check your reasoning.

Q2A receiver log shows that a frame was rejected after a CRC mismatch, but the record does not name the CRC profile or checked-byte scope. What is the best review response?

AKeep the rejection; request CRC profile and checked-byte scope

BAccept a full reliability claim because any CRC mismatch proves every corruption pattern is caught

CDiscard the log because packet captures are the only valid evidence

DTreat future payloads as correct because the receiver detected one bad frame

Show answer

Answer: A Error-detection evidence should connect the method, checked bytes, observed condition, receiver action, and limits.

Retrieval practice

Recall check 3 of 6

Packet Pete says: answer from memory, then check your reasoning.

Q3A packet passes its CRC check, but the application later applies the wrong actuator command because the payload was stale. What did the CRC evidence fail to prove?

AThat the receiver compared any check value at all

BThat the packet had any bytes

CThat CRCs can ever be useful in IoT reliability reviews

DFreshness, authorization, and side-effect safety

Show answer

Answer: D Error detection is one evidence layer.

Retrieval practice

Recall check 4 of 6

Packet Pete says: answer from memory, then check your reasoning.

Q4A command trace shows repeated retries after a missing acknowledgement, but no retry limit or final command state. What is the strongest review action?

AAccept the trace if retries are visible, because repeated attempts prove the path is reliable.

BHold until retry limit and final receiver state are visible.

CIgnore sequence state and duplicate rules because retry policy is only a sender concern.

DRemove acknowledgements from the design so there are fewer retry records to inspect.

Show answer

Answer: B Retry and sequence evidence must name the protected message boundary, the bounded retry decision, receiver state, and final state.

Retrieval practice

Recall check 5 of 6

Packet Pete says: answer from memory, then check your reasoning.

Q5A gateway receives sequence 42 again after a device reconnects. What should the receiver record before accepting, ignoring, or replay-protecting it?

APrior sequence state, reset boundary, duplicate rule, and receiver state.

BOnly the repeated value, without checking the receiver's stored sequence state or whether the command has a side effect.

COnly the transport protocol name, because the protocol determines every sequence decision.

DOnly a successful later message, because future success proves the duplicate was safe.

Show answer

Answer: A A retry or sequence record should connect the observed value to receiver state, reconnect boundary, duplicate policy, side effects, and the final accept/ignore/reject decision.

Retrieval practice

Recall check 6 of 6

Packet Pete says: answer from memory, then check your reasoning.

Q6A receiver accepts a command after a retry, then later receives the original delayed command. What evidence matters most under the hood?

AThe retry count alone, because a completed retry makes delayed originals harmless.

BThe sender log alone, because receiver state is outside the reliability decision.

CCommand identity, sequence state, duplicate guard, and final state.

DThe network path alone, because packet arrival order is the only reliability concern.

Show answer

Answer: C Under-the-hood review checks the state machine around late, duplicate, missing, reset, and wrapped values.

Print reference

Answers 1 of 2

Answer key.

C · Checksum and CRC evidence should be tied to scoped messages, observed receiver actions, limits, and retest triggers.
A · Error-detection evidence should connect the method, checked bytes, observed condition, receiver action, and limits.
D · Error detection is one evidence layer.
B · Retry and sequence evidence must name the protected message boundary, the bounded retry decision, receiver state, and final state.

Print reference

Answers 2 of 2

Answer key.

A · A retry or sequence record should connect the observed value to receiver state, reconnect boundary, duplicate policy, side effects, and the final accept/ignore/reject decision.
C · Under-the-hood review checks the state machine around late, duplicate, missing, reset, and wrapped values.