Protocol in Code · Track

DHCP

broadcast discovery, offer deadlines, and lease expiry as shared state

6 sessions Course material (English)

Sessions

DHCP track sessions

Session 01

Discovery Is Shouting into the Dark

A DHCP client has no IP address yet. How does a message even get sent, and what does that fact do to the shape of the message itself?

Open Session 01
Session 02

An Offer Is a Proposal with a Deadline

A server that answers a DISCOVER has set an address aside for a client that might never come back. How long does it wait, and how does it find out — without ever hearing directly from the client — that it lost?

Open Session 02
Session 03

The Pool Hands Out What's Free

A server has a whole /24 to hand out addresses from. How does it decide which address is next, and how does it avoid handing the same address to two clients at once while an offer is still pending?

Open Session 03
Session 04

A Lease Is a Dict with an Expiry

A lease table looks nothing like a DNS cache on the wire — so why is the code that manages one identical, line for line, to the code that manages the other three expiring stores this course has already built?

Open Session 04
Session 05

Renewal Happens Before the End

If a lease is just a dict entry that expires, why does RFC 2131 make a client start asking for a new one long before the old one runs out — and who is it even allowed to ask, at each point in that countdown?

Open Session 05
Session 06

Build the Toy DHCP Server Loop

DORA is always described as four steps — Discover, Offer, Request, Ack. What does the server actually have to check, and in what order, to make those four messages come out right every time, including when two servers answer the same DISCOVER?

Open Session 06