Read the matrix as a model, not a benchmark
Does the edge-rate sum respect each peer’s upload limit?
The page sums a separate min(upload, download)/2 term for each allowed directed link. It does not divide a peer’s shared capacity among all its links. Client names and rate values are authored fixtures, not measured comparisons.
Transfers update piece lists instantly. There are no sockets, byte buffers, integrity hashes or network timings. The model ranks configured rate parameters, rather than measuring which peers supplied useful data to each other.
Try a worked example
An uploader set to 10 Mbps with three allowed receivers set to 20 Mbps contributes 5 + 5 + 5 = 15 Mbps to the model’s edge-rate sum. That exceeds its 10 Mbps parameter. Use this calculation to inspect the formula, not predict a real download rate.
Separate real protocol behavior
BEP 3 defines choke and interest state, piece requests and hash-verified announcements. The matrix is a simplified allocation rule: two ranked slots plus a rotating optimistic slot. Its client labels do not establish interoperability, performance or conformance. BEP 3: BitTorrent Protocol Specification
Understand the graph scores
This page multiplies outgoing adjacency by a right vector. NetworkX’s directed eigenvector centrality instead uses a left vector that aggregates predecessors; direction matters. Here, each of five peers has three outgoing allowed links, so starting from an equal vector preserves equal scores, with λ = 3. First Max-Score Peer can therefore be the first tied peer, not a uniquely influential one. NetworkX: Eigenvector centrality
Use the controls to test assumptions
Compare the matrix before and after a rate adjustment, then step piece exchange and inspect the bitfields. Auto-Sim repeats the same authored rules. Export includes each peer’s fixture rates and the exact score definitions. A client recommendation would require separate measured evidence.
Sources and further reading