Finding peers without a tracker
A client can find the other machines in a swarm without any tracker at all, through three mechanisms: a distributed hash table, peer exchange, and local peer discovery.
Peer exchange is a message one connected peer sends to another, listing the addresses of other machines it is already talking to in the same swarm, and it costs nothing extra, because the message travels down a connection that already exists. The term has nothing to do with academic peer review or with peer to peer foreign exchange.
What finding peers without a tracker means
Finding peers without a tracker means using three mechanisms that live in the clients rather than on a server: a distributed hash table, specified as BEP 5; peer exchange, the extension message of BEP 11; and local peer discovery, BEP 14. The distributed hash table answers the cold start, when your client knows an info hash and nothing else. Peer exchange widens a set of connections that already exists, and local discovery finds a machine in the same building without either of the others.
All three produce addresses and none of them moves data, which is exactly what the tracker did. What they replaced was a single point that could be switched off.
| Mechanism | What it answers | What it needs first |
|---|---|---|
| Distributed hash table | Who holds this info hash, anywhere on the network | A bootstrap node, and nothing else |
| Peer exchange | Who the peers you already have are talking to | At least one existing connection |
| Local peer discovery | Who on this network holds the same torrent | A second machine on the same network |
How a magnet link finds its first peers with no tracker in it
A magnet link with no tr fields starts entirely in the distributed hash table, from bootstrap nodes compiled into the client. The client asks a bootstrap node for the nodes closest to its own identifier, fills a routing table from the answers, asks for the nodes closest to the info hash, then asks those for the peers registered under it. That is several rounds of small UDP messages, usually tens of seconds, which is the honest reason a trackerless magnet link sits still at first.
Once a single peer answers the picture changes quickly. The client requests the metadata from that peer, and peer exchange messages begin arriving at the same time, each carrying addresses that peer already knows. A swarm can go from one connection to dozens inside a minute on peer exchange alone, and how a transfer works follows from there.
How to check whether DHT and peer exchange are running
Both mechanisms report their state in the client's status bar, and the figure to read is the node count. A healthy distributed hash table shows thousands of nodes after a few minutes, and a client showing zero, or the word disabled, has been switched off in settings or is being blocked at the network. qBittorrent puts the DHT node count in the bottom bar.
- Read the DHT node count in the status bar, which should climb into the thousands rather than sit at zero.
- Open the connection settings and confirm all three mechanisms are enabled.
- Open the peer list on a running torrent and read the source column, which marks how each peer was found.
- Check whether the torrent carries the private flag, because that flag disables all three by design.
How a distributed hash table keeps the address book
The distributed hash table is a single global network shared by every client that has it enabled, storing which peers announced themselves under which info hash. It follows the Kademlia design: every node takes a random identifier from the same space as the info hashes, and information about a hash is stored on the nodes numerically closest to it. A lookup means asking whoever you know for someone closer, each round roughly halving the distance.
One detail surprises people. The table is one network rather than one per torrent, so nodes learned during an unrelated transfer answer the next lookup, which is why a client left running finds peers faster.
What peer exchange adds, and what turns it off
Peer exchange adds addresses at almost no cost, but it cannot start anything. It is carried inside an existing peer connection, so it only tells you about the neighbors of machines you have already found. Its value is keeping a swarm connected as peers come and go: a client running for an hour has usually learned more addresses from exchange messages than the tracker gave it.
Two things turn it off. The private flag in a torrent's info dictionary instructs clients to disable peer exchange, the distributed hash table and local discovery for that torrent, leaving the tracker as the only route. And it is not one specification: the widely used form originated in uTorrent, while the Vuze family has its own, so two clients can both support peer exchange and still not exchange peers.
Local peer discovery, and why it only helps on one network
Local peer discovery finds machines on the same local network by sending a small multicast message announcing an info hash and listening for the same from others. When a second machine on that network holds the same torrent, the two connect directly with neither the tracker nor the distributed hash table involved. The message does not leave the network, because multicast of this kind is not forwarded by the router.
It is the least used of the three and the most useful when it applies. Two machines in one household downloading the same distribution image pull it once from outside, then trade it at the speed of the local wiring. On a network with no other participant it does nothing, at no cost.
libtorrent and uTorrent are not the same kind of thing
Comparing libtorrent with uTorrent compares a library with a program. libtorrent is an implementation of the protocol as reusable code, with no window of its own, and it is the engine underneath several clients including qBittorrent and Deluge. uTorrent is a finished application with its own engine built in, so the real comparison is between the clients built on libtorrent and the ones that are not.
Both matter to peer finding for one reason. The peer exchange format most of the network speaks, and the µTP transport of BEP 29 that lets a transfer yield to other traffic, came out of the uTorrent line and were then implemented widely, libtorrent included. That is why these mechanisms work across clients sharing no code at all. Peer to peer as a broader idea covers the other systems that made the same choice.