BitTorrent Scrape Protocol Explained

The BitTorrent scrape protocol is a lightweight mechanism that allows torrent clients to request aggregate swarm statistics from a tracker without joining the swarm. By querying tracker metrics—specifically the number of seeders, leechers, and completed downloads—clients can display up-to-date torrent health and availability. This protocol provides a highly efficient alternative to the standard announce mechanism, significantly reducing bandwidth and processing overhead for both the client and the tracker.

The Problem with Announce Requests

Under normal operations, a client communicates with a tracker using an “announce” request. Announcing serves multiple purposes: it registers the client’s IP address and port, updates the user’s upload and download progress, and returns a list of active peers. Because an announce involves database writes, state management, and the generation of peer lists, it is resource-intensive. Using announce requests merely to check if a torrent is active or has enough seeders wastes significant network bandwidth and tracker CPU cycles.

How the Scrape Protocol Optimizes Queries

The scrape protocol solves this problem by decoupling status queries from peer registration. Instead of interacting with the active peer database, the scrape protocol performs a read-only query that returns only aggregate counter data:

• Complete: The number of active seeders (peers with the entire file).
• Incomplete: The number of active leechers (peers currently downloading).
• Downloaded: The total number of times the torrent has been completely downloaded (snatches).

Because the tracker only needs to return three integer values per torrent, the payload size is minuscule compared to a full peer list.

Multi-Torrent Batching

The primary driver of efficiency in the scrape protocol is batching. When a torrent client needs to update the status of dozens or hundreds of torrents in a user’s library, sending individual requests creates immense HTTP/UDP overhead.

The scrape protocol allows clients to append multiple torrent info-hashes to a single request URL (e.g., scrape?info_hash=HASH1&info_hash=HASH2). The tracker processes these hashes simultaneously and returns the statistics for all requested torrents in a single response dictionary. If the tracker supports it, a client can even send a scrape request with no info-hash specified to receive stats for all torrents hosted by that tracker.

HTTP vs. UDP Scrape Efficiency

The scrape protocol operates over both HTTP and UDP, with UDP providing the highest efficiency:

• HTTP Scrape: Uses a standard GET request and returns a compact bencoded dictionary containing the integer stats for each requested info-hash.
• UDP Scrape: Uses raw binary packets, eliminating HTTP header overhead. A single UDP scrape packet can bundle up to approximately 74 info-hashes into one small datagram. The tracker responds with a compact binary payload containing consecutive 12-byte blocks (4 bytes each for seeders, completed downloads, and leechers per hash).

Minimal Tracker Overhead

From the tracker’s perspective, scrape requests bypass the complex routing and state logic required for peer management. Trackers typically maintain running counters of seeders and leechers in fast, in-memory caches. Handling a scrape request requires only reading these cached numbers, making the operation computationally trivial and enabling trackers to serve millions of scrape requests per minute with minimal latency.