Protocol in Code · Track

Packet Parser

headers as offset promises, bit masks, and one-line checksums

5 sessions Course material (English)

Sessions

Packet Parser track sessions

Session 01

Bytes Have a Shape

A frame arriving off the wire is just a run of bytes — how does the parser know which bytes are the destination address, which are the source, and which name the layer above, without reading anything but position?

Open Session 01
Session 02

Peel One Layer, Find the Next

Once a header has been sliced off, something has to decide what kind of bytes come next — how does a number like 0x0800 or 6 turn into a decision about which parser to call?

Open Session 02
Session 03

Bits Don't Align to Bytes

Ethernet fields sit on clean byte boundaries — IPv4 doesn't. A version number and a header length share one byte, and three flag bits share a half-word with a 13-bit fragment offset. How does the parser pull an exact field out of the middle of a byte?

Open Session 03
Session 04

The Checksum Is Arithmetic, Not Magic

The IPv4 checksum is not a hash, not a CRC, and not a library call — it is 16-bit addition with the overflow folded back in. What exactly does that addition do, and why does a valid header sum to all-ones instead of zero?

Open Session 04
Session 05

Build the Toy Pcap Reader

A pcap file is bytes on disk, with no framing beyond "read the next header, then the next record." What does it take to turn that stream into the same layered read — Ethernet, then IPv4, then a checksum verdict — that the last four sessions built one layer at a time?

Open Session 05