Peer-to-peer file transfer

BitTorrent, specified in BEP 3, is the worked-out case. The file is split into pieces. Each piece has a hash in a metainfo file. A peer that finishes a piece and checks the hash tells other peers it has that piece. Connections are symmetric: data can flow either way.

The point of the design is load. BEP 3 says that when many downloads of the same file run at once, downloaders upload to each other, so the original source does not carry every copy. A tracker, or a distributed hash table, helps peers find each other. The tracker is not the file store. A dead tracker with live peers can still finish a transfer if the peers already know one another.

A lab publishes a 16 GB dataset as a torrent. The metainfo lists piece hashes. Fifty campuses start the download on a Monday. The lab's seed uploads the first copies of each piece. By afternoon most bytes on the wire are campus-to-campus. A peer at 70 percent drops off the network. Its partial pieces stay local. When it returns, it asks for the missing piece indexes only. A piece that fails the hash is discarded and requested again. The HTTP equivalent would have been fifty full GETs against one origin, or a CDN bill for 800 GB.

Peer-to-peer is a poor fit for a one-off private file. With a single recipient there is nobody else to upload to, and the privacy model is different: peers learn who is fetching the content. A client portal link does not publish the recipient's address to other recipients. Checksum is load-bearing here. Without the piece hash, a peer can serve garbage and every downloader keeps it.

Do not call every direct device copy peer-to-peer. AirDrop and a cable are local transfers with no swarm and no piece market. The term, in this frame, means the swarm pattern BEP 3 describes.