Read

Endgame Mode

Near the very end of a download, BitTorrent clients hit a subtle performance problem: the last handful of pieces are often the slowest ones to arrive, because — purely by chance — they tend to be held by a small number of peers, some of which may be slow or already saturated with other requests. If you keep requesting each remaining piece from only one peer (as usual), you can end up waiting on a single slow connection while everything else in the swarm sits idle. This is called the "last piece problem," and endgame mode is the fix.

The idea

When the number of pieces still missing drops below a threshold, switch strategy: instead of requesting each missing piece from exactly one peer, request it from every peer that has it. Whichever peer's block arrives first "wins" — the client accepts that data and sends CANCEL messages to the other peers it double-requested from, so their in-flight work isn't wasted a second time.

This trades a burst of duplicate (wasted) bandwidth — usually negligible, since it only applies to a handful of remaining pieces — for a large reduction in tail latency at the very end of the download.

Two pieces of logic to implement

1. Mode detection. Track how many pieces you still don't have (remaining = pieces_total - pieces_you_have). You're in endgame mode once remaining <= threshold (a small constant, e.g. 5); otherwise you're in normal mode.

2. Multi-peer request expansion. For a given missing piece, instead of picking one peer, enumerate every peer whose bitfield says they have it — excluding yourself, since if you already have the piece there's nothing to request:

Bitfields as the underlying data structure

Both "do I have this piece" and "does peer X have this piece" are naturally represented as bitfields — one bit per piece index, indexed from piece 0. A MY-HAVE or PEER bitstring like "101100" means piece 0 and 2 are held, others aren't. This is the same representation used in the real wire protocol's bitfield and have messages, so getting comfortable indexing into it here pays off directly when you implement the peer wire protocol itself.

Edge cases

• A piece you already have should report (none) for an endgame request — there's nothing left to fetch.
• A piece nobody in your peer set has yet (rare, but possible if peers haven't sent their have updates) also reports (none).
• Mode is a function of your missing-piece count only — it doesn't matter how many peers are connected or what they have.
• The threshold is configurable; a small torrent might enter endgame almost immediately, while a large one only enters it for the truly final pieces.

In a production client, entering endgame also changes how you handle incoming blocks: you need to track, per outstanding request, which peers you asked, so that when a block finally lands you know exactly which other peers need a CANCEL.