P2P Kademlia DHT XOR Distance & BitTorrent Swarm Simulator (2026)

Proposed by Petar Maymounkov and David Mazières in 2002, the XOR distance d(x, y) = x ⊕ y (interpreted as an unsigned integer) is a true mathematical metric that is strictly unidirectional: for any point x and distance Δ, there is one and only one point y at that exact distance. This ensures all lookup paths for the same target InfoHash converge through the exact same sequence of nodes regardless of where the query starts.

Each node maintains a routing table of 'k-buckets', where bucket i stores peers whose IDs share the first i prefix bits with the node's own ID. At every lookup hop, the node queries a peer in the bucket matching the target's prefix, correcting at least 1 additional leading bit per hop. Because log2(10,000,000) ≈ 23.25, lookups complete in ~20–24 hops (and even fewer when routing multiple bits per hop).

In a traditional Client-Server architecture, N clients divide the server's fixed upload bandwidth U_s, so per-user speed drops as U_s / N. In a P2P swarm using Rarest-First piece selection and Tit-for-Tat choking, every downloading peer (leecher) simultaneously uploads already-completed pieces at rate u_i, scaling total system capacity to U_s + Σ u_i.

In BitTorrent v1, every piece requires a 20-byte SHA-1 hash inside the .torrent file. If you use 32 KB pieces for a 100 GB file, the .torrent metadata balloons to over 60 MB! Conversely, if you set piece size to 64 MB, a single corrupted byte forces re-downloading the entire 64 MB chunk and delays peers from sharing verified pieces.

Each peer continuously measures which connected peers are uploading data to it at the highest rate and 'unchokes' its top 4 reciprocators (while rotating 1 'Optimistic Unchoke' slot every 30 seconds to discover faster newcomers and bootstrap brand-new peers). Peers that refuse to upload get choked by high-bandwidth nodes.