Peer-to-Peer

Peer-to-Peer#

A peer-to-peer (P2P) architecture has no central server. Each node is equally privileged (a peer) and can act as both client and server.

        flowchart LR
  A((Peer A))
  B((Peer B))
  C((Peer C))
  D((Peer D))
  E((Peer E))

  A --- B
  A --- C
  A --- D
  B --- C
  B --- E
  C --- D
  C --- E
  D --- E

Structure#

What a P2P system looks like under the hood. Discovery, connection, distribution of state, and coordination all happen without a central authority, which is what makes P2P powerful and what makes it hard to operate.

  • Nodes discover each other through bootstrap nodes, DNS, or local broadcast.

  • Connections are direct between peers (sometimes via NAT traversal).

  • State is distributed; each peer holds part (or all) of the data.

  • Coordination uses gossip, distributed hash tables (DHTs), or consensus protocols rather than a central authority.

Topologies#

The topologies a P2P network can take, sorted by how much hierarchy creeps in. Pure P2P is the academic ideal; in practice, most large systems end up either hybrid (super-nodes) or structured (DHT routing) for scalability.

  • Pure P2P, no special peers; everyone is equal (older Gnutella).

  • Hybrid, some peers act as super-nodes / supernodes / relays (Skype’s original architecture, BitTorrent trackers).

  • Structured, DHTs (Kademlia, Chord) define a routing topology.

  • Unstructured, gossip, flood-fill.

Strengths#

What P2P does that no client/server system can match. The absence of a central authority gives you fault tolerance, censorship resistance, and capacity that grows with the user base, properties no managed-service architecture can offer.

  • No single point of failure, the network survives any peer leaving.

  • Scales with participation, more users add capacity, not load.

  • Censorship-resistance, harder to take down a network with no central server.

  • Cost, peers carry the load; no central infrastructure bill.

  • Locality, peers can find geographically close peers without a CDN.

Costs#

The bill that comes with no central operator. Discovery, trust, consistency, and operational visibility all become harder problems, and residential network conditions add another layer of friction that production server fleets never face.

  • Discovery is hard, bootstrap, NAT traversal, peer churn.

  • Consistency is harder, no authority to break ties; eventual consistency by default.

  • Trust, malicious peers can poison data, lie about state, refuse to forward.

  • Operations, without a central observer, monitoring requires asking peers to report.

  • Network conditions, residential connections (asymmetric bandwidth, NAT, intermittent uptime) limit what peers can do.

Famous Examples#

The P2P systems most operators have actually used. BitTorrent and Bitcoin are the headline successes; Tor and IPFS are the operational systems behind a lot of OSINT work; WebRTC is the P2P transport hidden inside every modern video-conferencing app.

  • BitTorrent, file distribution; trackers (later DHTs) coordinate swarms.

  • Bitcoin / Ethereum, P2P consensus over a global ledger.

  • IPFS / Filecoin, content-addressable storage on a P2P network.

  • Tor, onion routing through a peer network.

  • Mastodon / ActivityPub, federated, not strictly P2P, but related philosophy.

  • Skype (original), super-node-based P2P voice.

  • WebRTC, browser-to-browser real-time communication; widely used for video conferencing, often relayed through TURN servers when direct connections fail.

Distributed Hash Tables#

DHTs are the backbone of structured P2P. Each peer owns a slice of the key space; lookups route through O(log n) hops to reach the responsible peer. They scale lookup; they don’t give you consensus, so writable shared state needs an additional layer.

  • Each peer is responsible for a slice of the key space.

  • Lookups route through O(log n) peers to reach the responsible one.

  • Common implementations: Kademlia (BitTorrent, Ethereum, IPFS), Chord (academic), Pastry, Tapestry.

DHTs give scalable lookup but not consensus; for shared writable state you still need extra protocols on top.

Federated vs. P2P#

A common point of confusion. Federated systems (email, XMPP, ActivityPub) have many servers communicating; P2P has no servers at all. Federated reaches most of the same goals (no single authority, censorship resistance through diversity) with durable servers that are easier to operate.

  • Federated, many independent servers communicate (email, XMPP, ActivityPub). Each user has a home server.

  • P2P, no servers; users themselves are nodes.

Federated systems are easier to operate (servers are durable, peers aren’t) and reach most of the same goals (no single authority, censorship resistance through diversity).

NAT Traversal#

The hardest practical problem in any P2P deployment. Most peers sit behind NAT; getting them to connect directly requires hole-punching, public-IP discovery, and (often) a relay server when the punching fails. Most “P2P” applications relay through a server when network conditions don’t allow direct connections.

  • STUN, discover your public IP and port.

  • TURN, relay traffic when direct connection fails.

  • ICE, combine STUN, TURN, and host candidates.

  • Hole punching for UDP and (less reliably) TCP.

Most “P2P” applications are actually relayed through a server when the network conditions don’t allow direct connections.

Security#

Where centralized systems delegate to a trusted operator, P2P has to bake security into the protocol. Crypto-derived identity, peer-to-peer authentication, and explicit Sybil and eclipse resistance are all required to make a P2P network safe to participate in.

  • Identity, public keys (or hashes) instead of usernames.

  • Authentication between peers via cryptographic protocols (Noise, TLS).

  • Sybil attacks, one attacker creating many peers; mitigations include proof-of-work, proof-of-stake, web-of-trust, or staking.

  • Eclipse attacks, attacker surrounds a victim’s peer connections.

Crypto / blockchain ecosystems have driven a lot of recent P2P research.

When to Pick P2P#

The use cases where P2P actually pays back its operational cost. Most are about properties that no managed service can provide; censorship resistance, real-time direct connections, or capacity that scales with users rather than infrastructure.

  • Censorship resistance is a goal.

  • No central operator is desired or affordable.

  • Scaling with users rather than infrastructure is essential.

  • Real-time direct connection between user devices (WebRTC for video conferencing, multiplayer games).

When Not to#

The cases where P2P’s operational cost outweighs its benefits. Strong consistency, mobile-first products, compliance regimes that require an identifiable operator, and teams that prioritize operational simplicity all push toward client/server.

  • Strong consistency requirements without a heavy consensus layer.

  • Operational simplicity is a higher priority than decentralization.

  • Mobile-first products where peers are offline most of the time.

  • Compliance regimes that require an identifiable operator (KYC, data residency).

Hybrid Reality#

Most “P2P” systems in production are actually hybrids. Pure P2P is a design ideal; pragmatic systems mix in central components for the parts where servers are cheaper than peer coordination (discovery, fallback relays, caching).

  • Discovery through centralized servers, even if data flows peer-to-peer.

  • Relays for clients that can’t connect directly.

  • CDN-style caching in front of P2P storage.

Pure P2P is a design ideal; pragmatic systems mix in central components where they pay off.

Contents