Designing a Peer-to-Peer Network

P2P networks distribute data and computation across participants, with no central server.

P2P vs Client-Server

Client-Server:
  Clients ← Server → Clients
  Central bottleneck, single point of failure

P2P:
  Peer ↔ Peer ↔ Peer ↔ Peer
  Decentralized, scales with participants

Unstructured P2P

Peers connect randomly, discovery via flooding.

Gnutella style:
Node A asks neighbors "Who has file X?"
Neighbors forward to their neighbors (TTL-limited)
Owner responds directly to A

Cons: High bandwidth for search, doesn't scale.

Structured P2P — DHT (Distributed Hash Table)

Determines exactly which peer stores which data.

Chord DHT:
  Each node and key hashed to ID space (0 to 2^160)
  Key stored at successor node (next node clockwise)

  store(key, value):
    node_id = hash(key)
    route to responsible node

  get(key):
    node_id = hash(key)
    route to node → retrieve

Lookup: O(log N) hops.

BitTorrent Protocol

.torrent file: Contains metadata + tracker URL
Tracker: Maintains list of peers for a torrent
Swarming: Download different pieces from different peers

Piece selection: Rarest-first strategy
Tit-for-tat: Prioritize uploading to peers who upload to you

Kademlia DHT

Used by BitTorrent, Ethereum, IPFS:

XOR metric for distance between nodes
Bucket routing table (k-buckets)
Parallel lookups (α = 3 concurrent)
O(log N) lookups

NAT Traversal

Peers behind NAT can't receive direct connections.

STUN: Discover external IP/port
ICE: Coordinate NAT traversal
TURN: Relay server (last resort)

IPFS (InterPlanetary File System)

Content-addressed storage on Kademlia DHT:

File → Hash (CID) → Distributed across DHT nodes
Retrieve by CID → Find holders → Download

Conclusion

DHT provides O(log N) lookup in truly decentralized networks. BitTorrent demonstrates swarming at scale. IPFS applies DHT to content-addressed storage.