How a transfer works

BitTorrent, the protocol that defines how this happens, gives every participating machine two jobs at the same time: it asks for the pieces it is missing, and it hands out the pieces it already holds. A program that speaks the protocol, such as qBittorrent, Transmission or Deluge, keeps a map of which pieces have arrived, which are outstanding, and which connected machines can supply them. The whole group working on the same data is the swarm, and the transfer is finished when every numbered piece has arrived and passed its own check.

What peer to peer file sharing is

Peer to peer file sharing is a way of moving data in which every machine is both a source and a destination, so no single server carries everybody. The ordinary web works the other way around: a browser asks one server for a file, and if a thousand people ask at once the server carries all thousand. In a peer to peer network the thousandth arrival is also the thousandth supplier, so the more people who want the data, the more capacity exists to move it. That inversion is why a popular set of data moves faster on BitTorrent than an unpopular one.

The idea predates BitTorrent. Napster, which appeared in 1999, kept a central index of who held what, so the network stopped when the index did. Gnutella removed the index and passed questions between neighbors, while eDonkey and eMule added hashing so the same data could be recognized under different names. BitTorrent, published in 2001, dropped searching altogether: it moves a known set of data between the machines that want it, and leaves finding to something else.

How a transfer begins: a torrent file or a magnet link

A transfer begins with one of two things, and neither of them contains the data. A torrent file is a small file, usually a few tens of kilobytes, that lists the names and sizes of everything in the set, states the piece length, and carries a hash for every piece. A magnet link does the same job in one line of text: it carries the hash of that description rather than the description itself, so a client has to fetch the description from the swarm before it can begin.

That difference is why a magnet link sits still for a moment after you add it, showing something like downloading metadata, while a torrent file starts allocating disk space at once. The client cannot ask for piece 417 until it knows how many pieces exist and how long each one is. Once the description has arrived from a peer the two routes are identical: same pieces, same hashes, same swarm.

How your client finds the machines that have the pieces

Your client finds the other machines through four mechanisms, and most transfers use more than one at once. A tracker is a server named inside the torrent whose only job is to answer who else is working on this exact set of data. A distributed hash table spreads the same address book across the clients themselves, so no server has to be running. Peer exchange lets two machines that are already talking tell each other about the peers they know. Local peer discovery sends a short message on your own network in case another machine in the same building has the data.

None of the four moves any data. They produce addresses. What arrives is a list of hosts and ports, and the client then connects to each one, states which pieces it holds, and listens to the same claim coming back. The swarm is the resulting mesh of connections. A client that cannot accept incoming connections, because a router is not forwarding its port, is described as firewalled: it can reach out but nothing can reach in, which cuts it off from a large share of the swarm.

How the pieces arrive, and why they arrive out of order

Pieces arrive in whatever order the swarm can supply them, not from beginning to end. The client asks for the rarest pieces first, because a piece held by one machine is the one most likely to vanish. Each piece is requested in small blocks, commonly 16 kibibytes at a time, from whichever peers answer fastest, so a single piece can be assembled from blocks that came from several machines.

Every completed piece is hashed and compared against the hash in the description. A piece that matches is kept and announced to the swarm; a piece that does not is discarded whole and requested again from somebody else. This is why nobody has to trust the peers: a corrupted or tampered block cannot survive the comparison. Near the end most clients switch to an endgame mode and request the last outstanding blocks from every available peer at once, so one slow machine cannot hold the finish hostage.

Why giving is what makes receiving fast

Giving is not a courtesy in BitTorrent, it is the rate control. Each client keeps a small number of peers unchoked, meaning it is currently willing to send to them, and it picks them by who has been sending to it. A peer that gives you data gets your upload slot; a peer that takes and gives nothing gets choked. Because every client runs the same logic independently, a machine that uploads nothing is squeezed out of the fast connections.

One slot is reserved for a peer chosen without regard to what it has given, which is called optimistic unchoke. It exists so a client that has just joined with nothing to trade can still get a first piece. This is why an upload limit set very low often slows the download too: it starves the mechanism that was earning the download.

What seeding is, and when a transfer is actually finished

Seeding is what a client does once it holds every piece: it stops asking and only gives. A machine with the complete set is a seeder, a machine still collecting is a leecher, and both are peers. A swarm with no seeder can still finish if the leechers between them hold every piece, and it stalls permanently the moment one piece exists nowhere, which is what a transfer stuck near the end for days usually means.

Seeder

A machine that holds every piece and is only uploading.

Leecher

A machine still missing pieces, whether or not it is uploading.

Peer

Any machine in the swarm, seeder or leecher.

Ratio

Bytes uploaded divided by bytes downloaded, counted per torrent and in total.

Availability

How many complete copies the connected peers add up to. Below 1.000 means at least one piece is missing from everyone you can see.

Seeding costs upload bandwidth and nothing else, and stopping it does not damage what has arrived. The glossary collects these words in one place, and the swarm page follows what the connections look like while all this is happening.

What the programs are, and where they run

The programs that speak the protocol are ordinary applications, and most in current use are open source. qBittorrent presents a desktop window and a web interface and runs on the libtorrent engine. Transmission is built around a daemon with separate interfaces attached, which suits a machine with no screen, and Deluge splits the same way. On Android the choice is narrower and the platform intervenes, suspending background work to save battery. In every case the build should come from the project that publishes it.

What the protocol decides, and what it does not

BitTorrent decides how bytes move and nothing else. It has no opinion about what the bytes are, which is why the same mechanism carries a Debian installation image, an Internet Archive item, a scientific dataset and a game patch. Large projects publish release images this way because demand arrives in a single spike, and a swarm handles a spike better than a server farm does.

Whether a particular transfer is lawful is a question about the material rather than the protocol, and copyright law differs by country and by case. The technology cannot answer that. What it can tell you is the mechanical part: the pieces, the hashes, the swarm and the choking, all of which happen the same way whatever the data turns out to be.