The swarm
A leecher in a BitTorrent swarm is any peer that does not yet hold every piece of the torrent, so it is still downloading, and in almost every case uploading the pieces it already has while it does so.
The word sounds like an accusation and is not one. In the protocol a leecher is simply an incomplete peer, and the moment its last piece verifies it becomes a seeder. Every figure your client puts in the peers column is describing one set of machines from two angles: who has all of it, and who does not.
Seeder, leecher and peer: the three words for the machines around you
A client uses seeder, leecher and peer for three overlapping groups, and the overlap is what confuses people. Peer is the general word for any other machine your client has an open connection to. Seeder and leecher split those peers by one property only, how much of the torrent they hold.
- Seeder
- A peer that holds every piece and has verified all of them. It uploads and never needs to download. One reachable seeder is enough for a torrent to be completed by everybody else.
- Leecher
- A peer missing at least one piece. It downloads, and unless somebody has deliberately capped it, it uploads the pieces it already holds at the same time. Nearly everybody in a busy swarm is a leecher for the first part of a transfer.
- Peer
- Any machine in the swarm, complete or not. Some clients use peers in the narrow sense of the incomplete ones only, which is why the same torrent can show slightly different figures in qBittorrent and in Deluge.
- Swarm
- Everybody on that torrent at once, whether your client has managed to reach them or not. Your client only ever connects to a slice of it.
None of these words describe a person or an intention. They describe a state of completeness, which is the only thing the protocol knows about any participant. How those pieces actually move between the machines is the subject of How a transfer works.
What each number in the peers column means
The numbers in the peers column count connections, not people, and most clients show two figures side by side: how many your client is talking to right now, and how many it has been told exist. qBittorrent puts the second in parentheses, so a seeds figure reading 5 (120) means five seeders connected out of a hundred and twenty that the tracker and the DHT have reported between them. The gap between those two numbers is normal. A client opens a limited number of connections on purpose, and a large share of the addresses a tracker hands back belong to machines that have since gone offline or cannot accept an incoming connection.
| What the client shows | What it counts | What a low figure tells you |
|---|---|---|
| Seeds | Complete peers you are connected to, with the number known to the tracker and the DHT in brackets | Few or no complete copies are reachable. The torrent can still finish if the leechers hold every piece between them |
| Peers | Incomplete peers you are connected to, with the known total in brackets | Almost nobody is trading. A torrent with seeds and no peers is usually just old rather than broken |
| Availability | How many complete copies exist across the peers you are connected to, counted piece by piece | Below 1.000 at least one piece is missing from every peer you can reach, and the transfer will stop short of the end |
| Progress, per peer | The share of the torrent that one particular peer holds | A peer sitting far below your own progress has little you need yet |
| Down and up speed, per peer | What that single connection is carrying at this moment | Zero on most rows is ordinary. Peers choke and unchoke each other constantly |
Two rows in that table are worth reading together. Seeds counts machines, availability counts pieces, and availability is the more honest of the two when a torrent is old.
Leecher against seeder: the difference that decides whether a torrent finishes
The difference between a leecher and a seeder is completeness, and completeness is what decides whether a torrent can finish at all. A seeder can serve any piece anybody asks for. A leecher can only serve the pieces it happens to have, so a swarm made entirely of leechers finishes only if the pieces they hold, added together, cover the whole torrent. When they do not, every client in that swarm stops at the same percentage and stays there, because the missing piece is missing everywhere.
This is why the seeder count matters more than the peer count on an old torrent and matters less on a new one. On a busy release the leechers are the useful connections: they are downloading the same pieces you are, they get different ones first, and they trade with you immediately. The protocol is built around that trade. Each client prefers the peers that give it the most, a mechanism called choking, and reserves a rotating slot for a stranger, called optimistic unchoke, so that a peer with nothing yet can get its first piece and join in.
Why a swarm with more seeders behaves differently
A swarm with more seeders behaves differently because pieces stop being scarce. With several seeders reachable, your client can request rare pieces directly instead of waiting for a leecher to acquire one and pass it on, and the rarest-first ordering that clients use has plenty of choices. With one seeder and a crowd of leechers, that single machine's upload capacity is divided among everybody, and the swarm moves at the speed the seeder can push its rarest pieces out into circulation.
- Many seeders, few leechers: transfers usually run at whatever your own connection allows, and finish without drama.
- Many seeders, many leechers: still fast, because the seeders keep new pieces entering circulation and the leechers multiply them.
- One seeder, many leechers: slow at the start and faster near the end, as pieces the seeder released early begin circulating among the leechers.
- No seeder, many leechers: it depends entirely on availability. Above 1.000 it can finish. Below, it cannot.
- No seeder, no leechers: nothing will happen until somebody with the data opens the torrent again.
None of this is something a setting can override. The swarm is other people's machines, other people's upload capacity and other people's schedules, and it is the first thing worth checking when a transfer is slow.
Availability, and what a figure below 1.000 means
Availability is the count of complete copies distributed across the peers your client can currently reach, and it is shown with decimals because it is arrived at piece by piece rather than machine by machine. A figure of 2.400 means every piece is reachable at least twice over and some pieces far more often. A figure of 0.980 means the swarm you can see is very nearly complete and one stretch of the torrent exists nowhere among your connections.
Availability moves as peers come and go, so a figure below 1.000 is not permanent. A seeder returning restores it instantly. It is also local to you: another machine connected to a different slice of the same swarm may see a different figure at the same moment.
Where your client shows the swarm
Every client shows the swarm, in a different place and under different labels. qBittorrent gives each torrent a seeds column and a peers column in the main list, and a peers tab underneath that names every connection, its client software, its country flag and how much of the torrent it holds. Deluge and Transmission present the same information with different wording, and the desktop and web interfaces of one client do not always agree on how much of it to show. The clients covers what each program does with that data.
The figures behave the same way on Windows, macOS and Linux, because the swarm is a property of the torrent rather than of your computer. What the operating system changes is whether your machine stays awake long enough to keep those connections open, and whether anything on it is blocking incoming connections. A client that reports itself as firewalled is still able to reach out to peers, but no peer can start a connection to it, so it sees a smaller swarm than actually exists.
What the swarm numbers do not tell you
The peers list is a list of network addresses and client version strings, and that is the whole of what the protocol exchanges about identity. It does not tell you who is on the other end, and it does not tell you anything about the data itself beyond the piece hashes both sides have already agreed on. It works in the other direction too: joining a public swarm means announcing an address that everybody else in that swarm can see, because a connection cannot be made to a machine that has not said where it is. Is it safe? deals with what follows from that.
A last caution about the word leecher. In everyday use it is also applied to somebody who stops uploading the instant a transfer completes, which is a behavior rather than a state, and none of the numbers in your client distinguish the two. What the client calls a leecher is only ever a peer that has not finished yet.