Read

Choking Algorithm Simulator

BitTorrent has no central scheduler telling peers who should upload to whom. Instead, every peer independently runs a choking algorithm that decides which of its connected peers get to download from it right now. "Choked" means "you get nothing from me at the moment"; "unchoked" means "you may request pieces from me." This lesson implements the classic algorithm from Bram Cohen's original 2003 design document.

Why choking exists

Upload bandwidth is scarce and every peer wants to maximize their own download rate. BitTorrent's answer is tit-for-tat: peers preferentially unchoke the peers who are uploading well to them, creating an incentive to reciprocate. A peer that only leeches without uploading tends to stay choked by everyone.

Two kinds of unchoke slots

1. Regular (reciprocal) unchokes, recomputed on a fixed cadence (every 10 seconds in the reference client). The client ranks all interested peers by their observed upload rate to us and unchokes the top 4. This rewards peers who are giving us good throughput.
2. The optimistic unchoke, recomputed on a slower cadence (every 3 regular cycles, i.e. every 30 seconds). This slot ignores upload rate entirely and unchokes essentially at random (in this exercise, whichever peer the OPT command names). Its purpose is discovery: a new peer that just joined has no upload history yet, so without an optimistic slot it could never get a chance to prove itself and start reciprocating. It's how the swarm bootstraps new/slow peers instead of always favoring the same fast peers forever.

Combining the two

The final unchoked set for any moment is the union of the current regular top-4 and the current optimistic peer:

If the optimistic peer happens to already be in the top 4 by rate, the union just has 4 members that tick; otherwise it's effectively 5 unchoke slots at once (4 regular + 1 optimistic) until the next optimistic cycle rotates.

Ranking with ties

When ranking peers by upload rate, ties need a deterministic tiebreak — otherwise two implementations (or two runs) could disagree about who's in the top 4. Sorting by (-rate, peer_id) gives "higher rate first, alphabetically first among equal rates":

Things to watch for

• State is cumulative, not snapshot-per-tick. TICK updates a peer's current observed rate; the next REGULAR command re-ranks using whatever the latest rate is for every peer, not just the ones ticked since the last regular unchoke.
• Fewer than 4 interested peers just means everyone with a rate gets unchoked — there's no requirement to always fill exactly 4 slots.
• The optimistic slot persists across regular unchokes until a new OPT command replaces it — it doesn't get cleared by REGULAR.

In a full client, this algorithm runs continuously and interacts with "anti-snubbing" (temporarily bumping the optimistic-unchoke frequency if we haven't been unchoked by anyone recently) — but the core top-4-plus-one-wildcard shape is exactly what you're implementing here.