BT9G LABS / DHT Deep Dive #13
Seeders and Leechers: What the Numbers Mean and How They Are Measured
Understand seeders, leechers, tracker scrape counters, DHT limitations, and why exact global swarm size is hard to measure.
BT9G Labs / DHT Deep Dive #13. Understand seeders, leechers, tracker scrape counters, DHT limitations, and why exact global swarm size is hard to measure.
Quick summary
- Topic: Seeders and Leechers: What the Numbers Mean and How They Are Measured
- Core keywords: seeders, leechers, tracker scrape, swarm size, BitTorrent peers
- Audience: backend engineers, protocol researchers, search engineers, and BitTorrent implementers
- Goal: explain the mechanism accurately enough to support real crawler and indexing architecture decisions
System view
Definitions first
A seeder has the complete content for a torrent and can upload pieces to others. A leecher, in common usage, is a participant that has not yet completed the content. Protocol documents often use the more neutral tracker counters complete and incomplete.
These labels describe content completion, not moral behavior. A peer can be incomplete and still upload significant data to the swarm.
Tracker scrape counters
When a tracker supports scraping, it can report the number of active peers it considers complete and incomplete for a given infohash. BEP 48 documents those fields. These are useful because they come from a service that sees announces from many clients using that tracker.
However, the numbers represent the tracker's own knowledge. Peers discovered only through DHT, PEX, another tracker, or private mechanisms may not be included.
Why DHT does not directly give exact seeder counts
BEP 5 stores peer locations. A DHT get_peers response does not inherently tell the requester whether each endpoint is a complete seeder or an incomplete peer. Determining completion generally requires additional swarm interaction or a tracker that tracks completion state.
This means a DHT search engine should avoid presenting an exact seeder/leecher number unless it can identify the measurement source and timestamp.
Better product semantics
For a public search interface, labels such as tracker-reported seeders, observed peers, and last activity are more defensible than a single unexplained "health" number. Freshness matters as much as magnitude.
An index can combine tracker scrapes, successful connections, metadata availability, and recent DHT observations into an internal ranking score while keeping the user-facing raw counters source-specific.
Implementation sketch
{
"source": "tracker_scrape",
"infohash": "...",
"complete": 142,
"incomplete": 37,
"observed_at": "2026-09-16T03:00:00Z"
}
Engineering notes for BT9G Labs
For an indexing system, protocol correctness and data semantics matter more than raw event volume. Keep durable content identity separate from volatile peer observations, retain timestamps on measurements, and make every network-derived field explicit about its source. This prevents the search layer from turning a short-lived observation into a permanent factual claim.
Where possible, record stage-level metrics rather than only total success or failure. That makes it possible to see whether the bottleneck is DHT lookup quality, peer reachability, extension support, metadata transfer, validation, storage, or search indexing.
Common mistakes
- Presenting a tracker count as the entire global swarm.
- Inferring seeder state directly from a DHT endpoint list.
- Displaying old counts without timestamps.
- Treating incomplete peers as non-contributors.
Related BT9G Labs articles
- BEP 10 Extension Protocol: How BitTorrent Negotiates Features Without Breaking Compatibility
- Tracker vs DHT vs PEX: Three BitTorrent Peer-Discovery Mechanisms Compared
- Why Torrent Metadata Retrieval Fails: 10 Real Causes and a Better Retry Model
- Designing a High-Performance DHT Crawler: Architecture, Queues, and Backpressure
References
← Previous: Tracker vs DHT vs PEX: Three BitTorrent Peer-Discovery Mechanisms Compared Next: Why Torrent Metadata Retrieval Fails: 10 Real Causes and a Better Retry Model →
This article explains public BitTorrent protocol behavior for engineering and research purposes. It does not imply that every observed swarm is available, valid, or authorized for redistribution.