Check piece availability before reading the score
Can a swarm continue after its seeders leave?
It can only obtain a missing piece if some remaining peer has it. This model shows sixteen piece flags per peer; a high average completion fraction does not establish that every distinct piece is still available.
This is a browser simulation, not a BitTorrent client. The policy score is fixed, speed is a static display, and estimated time is an authored formula. Transfers occur every fifteenth simulation frame, not on a measured network clock.
Try a worked example
Suppose two peers each hold the same 15 of 16 pieces. Mean completion is 15/16, about 94%, but the absent sixteenth piece cannot be supplied. Compare their columns in the bitfield matrix before treating the completion score as availability.
What actual peers exchange
BEP 3 defines bitfield and have messages to advertise pieces, along with request and piece messages for transfer. It also specifies verifying a downloaded piece against its hash before announcing it. Here, Boolean flags change directly; no bytes, sockets or hashes are exchanged. BEP 3: The BitTorrent Protocol Specification
Choking and interest are separate
In the specification, transfer depends on interest and an unchoked connection. This page selects a random provider with the chosen piece; its policy selector does not implement reciprocal ranking or optimistic unchoking. A displayed fixed score cannot measure cooperation. BEP 3: The BitTorrent Protocol Specification
Compare strategies with care
Rarest-First uses counts across this model’s full swarm, including missing pieces with zero providers; such a choice can stall. Random Piece samples missing pieces rather than downloading sequentially. Initial pieces are randomized, so separate resets do not hold conditions constant. Export retains the original config keys and adds metric definitions and scope.
Sources and further reading