bittorrentprotocolspecificationbt协议规范(编辑修改稿)

bittorrentprotocolspecificationbt协议规范(编辑修改稿)内容摘要：

rape page. Examples: (announce URL scrape URL) (scrape not supported) (scrape not supported) (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: The scrape URL may be supplimented by the optional parameter info_hash, a 20byte value as described above. This restricts the tracker39。 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 20byte binary info_hash value. The value of that key is yet another nested dictionary containing the following: o plete: number of peers with the entire file, . seeders (integer) o downloaded: total number of times the tracker has registered a pletion (event=plete, . a client finished downloading the torrent) o inplete: number of nonseeder peers, aka leechers (integer) o name: (optional) the torrent39。 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. Here39。 s an example: d5:filesd20:....................d8:pletei5e10:downloadedi50e10:inpletei10eeee Where .................... is the 20 byte info_hash and there are 5 seeders, 10 leechers, and 50 plete downloads. 4 Peer wire protocol 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 block is typically lesser in size than the piece. 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. Simply saying “when you are choked by the peer you can not download pieces from the peer until you are unchoked”.  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 it. Typically the peer will send this message after it had received a BitField message from the client telling the peer the list of pieces it has. 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:  am_choking: this client is choking the peer  am_interested: this client is interested in the peer  peer_choking: peer is choking this client  peer_interested: peer is interested in this client Client connections start out as choked and not interested. In other words:  am_choking = 1  am_interested = 0  peer_choking = 1  peer_interested = 0 A block is downloaded by the client when the client is interested in a peer, and that peer is not choking the client. A block is uploaded by a client when the client is not choking a peer, and that peer is interested in the client. It is important for the client to keep its peers informed as to whether or not it is interested in them. This state information should be kept uptodate with each peer even when the client is choked. This will allow peers to know if the client will begin downloading when it is unchoked (and viceversa). Data Types: Unless specified otherwise, all integers in the peer wire protocol are encoded as four byte bigendian values. This includes the length prefix on all messages that e after the handshake. Message flow: The peer wire protocol consists of an initial handshake. After that, peers municate via an exchange of lengthprefixed messages. The lengthprefix is an integer as described above. Handshake: The handshake is a required message and must be the first message transmitted by the client.  handshake: pstrlenpstrreservedinfo_hashpeer_id o pstrlen: string length of pstr, as a single raw byte . o pstr: string identifier of the protocol. o reserved: eight (8) reserved bytes. Each bit in these bytes can be used to change the behavior of the protocol. An from Bram suggests that trailing bits should be used first, so that leading bits may be used to change the meaning of trailing bits. o info_hash: 20byte SHA1 hash of the info key in the metainfo file. This is the same info_hash that is transmitted in tracker requests. o peer_id: 20byte string used as a unique ID for the client. This is the same peer_id that is transmitted in tracker requests. In version of the BitTorrent protocol, pstrlen=19, and pstr=BitTorrent protocol. A typical Hand Shake message in java will look like this “out” is the outputstream we are writing to Then Handshake is : (19)。 (“BitTorrent protocol.getBytes())。 byte[] reservedbytes = new。