http://spam.com/announce -> http://spam.com/scrape http://spam.com/x/announce -> http://spam.com/x/scrape http://spam.com/announce.php -> http://spam.com/scrape.php http://spam.com/a -> (scrape not supported) http://spam.com/announce?x=2%0644 -> http://spam.com/scrape?x=2%0644 http://spam.com/announce?x=2/4 -> (scrape not supported) http://spam.com/x%064announce -> (scrape not supported)
Note especially that entity unquoting is not to be done. This standard is documented by Bram in the BitTorrent development list archive: 
http://groups.yahoo.com/group/BitTorrent/message/3275
The scrape URL may be supplimented by the optional parameter info_hash, a 20-byte value as described above. This restricts the tracker's report to that particular torrent. Otherwise stats for all torrents that the tracker is managing are returned. Software authors are strongly encouraged to use the info_hash parameter when at all possible, to reduce the load and bandwidth of the tracker.
- The response of this HTTP GET method is a "text/plain" document consisting of a bencoded dictionary, containing the following keys
-
-
files: a dictionary containing one key/value pair for each torrent for which there are stats. If info_hash was supplied and was valid, this dictionary will contain a single key/value. Each key consists of a 20-byte binary info_hash value. The value of that key is yet another nested dictionary containing the following:
- complete: number of peers with the entire file, i.e. seeders (integer)
- downloaded: total number of times the tracker has registered a completion ("event=complete", i.e. a client finished downloading the torrent)
- incomplete: number of non-seeder peers, aka "leechers" (integer)
- name: (optional) the torrent's internal name, as specified by the "name" file in the info section of the .torrent file
-
Note that this response has three levels of dictionary nesting. Here's an example:
d5:filesd20:....................d8:completei5e10:downloadedi50e10:incompletei10eeee
Where .................... is the 20 byte info_hash and there are 5 seeders, 10 leechers, and 50 complete downloads.
Peer wire protocol (TCP)
Overview
The peer protocol facilitates the exchange of pieces as described in the metainfo file.
Note here that the original specification also used the term "piece" when describing the peer protocol, but as a different term than "piece" in the metainfo file. For that reason, the term "block" will be used in this specification to describe the data that is exchanged between peers over the wire.
A client must maintain state information for each connection that it has with a remote peer:
- choked: Whether or not the remote peer has choked this client. When a peer chokes the client, it is a notification that no requests will be answered until the client is unchoked. The client should not attempt to send requests for blocks, and it should consider all pending (unanswered) requests to be discarded by the remote peer.
- interested: Whether or not the remote peer is interested in something this client has to offer. This is a notification that the remote peer will begin requesting blocks when the client unchokes them.
Note that this also implies that the client will also need to keep track of whether or not it is interested in the remote peer, and if it has the remote peer choked or unchoked. So, the real list looks something like this:
