Peer-to-peer

Why it matters

Peer-to-peer is the architecture with no privileged node: no server to overload, to take down or to trust. BitTorrent moves a large share of the internet's bulk data this way, blockchains and IPFS are built on it, and video calls traverse it. Even inside conventional systems, the structured overlays P2P invented (distributed hash tables, consistent hashing, gossip) are how clusters of ordinary servers organise themselves. Understanding P2P is understanding how a system coordinates when nothing is in charge.

The idea

In a peer-to-peer system every participant runs the same software and plays both roles: it requests resources from others and serves resources to others. There is no central coordinator for the data path; nodes find each other and route requests through an overlay network, a logical topology built on top of the internet. The design questions are how peers find content, how the network survives peers constantly joining and leaving (churn), and why anyone contributes.

Unstructured versus structured overlays

	Unstructured (Gnutella, early file sharing)	Structured: distributed hash table (Chord, Kademlia, Pastry)
Topology	Random connections between peers	Peers arranged by node id in a key space with defined neighbour rules
Finding content	Flood or random-walk queries with a hop limit	Hash the key to an id; route to the peer responsible for that id
Cost per lookup	Many messages; rare content may not be found	O(log N) hops, deterministic; always found if present
Churn handling	Trivial; connections are arbitrary	Maintenance protocol keeps routing tables correct as peers come and go
Used by	Early networks; gossip-based membership today	BitTorrent trackerless mode, IPFS, Ethereum discovery, many storage systems internally

How a DHT routes

Chord places nodes and keys on a ring (the same ring as consistent hashing) and gives each node a finger table: pointers to the nodes responsible for ids at distances 1, 2, 4, 8 and so on around the ring. A lookup forwards to the finger closest to but not past the target, halving the distance each hop, so any key is found in about log N hops among N nodes. Kademlia uses XOR distance between 160-bit ids and keeps k-buckets of peers per distance range, which makes routing tables self-healing from ordinary traffic and is why it won in practice (BitTorrent's Mainline DHT, IPFS). Keys are stored on the responsible node and replicated to its neighbours so churn does not lose them.

Incentives and churn

Peers leave without notice, so data must be replicated and routing tables refreshed continuously; a DHT with high churn spends much of its bandwidth on maintenance. Peers also have no obligation to contribute, so systems add incentives: BitTorrent's tit-for-tat uploads to peers that upload to you, and rarest-first piece selection keeps swarms healthy; blockchains pay in tokens. Without incentives, free riding collapses the network.

NAT traversal and bootstrapping

Most peers sit behind NAT and cannot be reached directly. The WebRTC lesson's machinery, STUN to learn public addresses, hole punching, and TURN or relay peers as a fallback, applies to every P2P system. New peers need a way in: bootstrap nodes with known addresses, which are the one centralised ingredient most networks retain (trackers, seed lists, DNS seeds).

Where P2P ideas live today

Fully decentralised consumer systems are rare outside file sharing, cryptocurrencies and real-time media. The ideas, though, are everywhere inside data centres: Dynamo and Cassandra are DHT-like rings of equal nodes with gossip membership; consistent hashing came from the same research; service meshes and CDNs use overlay routing. The most common modern use is hybrid: a central service for discovery, identity and incentives, with peers exchanging the heavy data directly (game updates, video calls, large downloads).

	Client-server	Peer-to-peer
Scaling	Add servers; cost grows with users	Capacity grows with users; each brings bandwidth and storage
Single point of failure or control	The server	None for the data path; bootstrap nodes for entry
Consistency and trust	Central authority is simple	Must verify content (hashes) and handle untrusted peers
Latency and predictability	Controlled infrastructure	Variable; depends on peers' links and churn
Fits	Most applications	Bulk distribution, censorship resistance, real-time media between participants, decentralised ledgers