bittorrentspecification.htm

关于ＢＴ的协议文档

</li><li> <b>port</b>: peer's port number (integer)
</li></ul>
</li></ul>
<p>As mentioned above, the list of peers is length 50 by default.  If there are fewer peers in the torrent, then the list will be smaller.  Otherwise, the tracker randomly selects peers to include in the response.  <i>The tracker may choose to implement a more intelligent mechanism for peer selection when responding to a request.  For instance, reporting seeds to other seeders could be avoided.</i>
</p><p>Clients may send a request to the tracker more often than the specified interval, if an event occurs (i.e. stopped or completed) or if the client needs to learn about more peers.  However, it is considered bad practice to "hammer" on a tracker to get multiple peers.  If a client wants a large peer list in the response, then it should specify the <b>numwant</b> parameter.
</p><p><i><b>Implementer's Note</b>: Even 30 peers is <b>plenty</b>, the official client version 3 in fact only actively forms new connections if it has less than 30 peers and will refuse connections if it has 55. <b>This value is important to performance</b>. When a new piece has completed download, HAVE messages (see below) will need to be sent to most active peers. As a result the cost of broadcast traffic grows in direct proportion to the number of peers. Above 25, new peers are highly unlikely to increase download speed. UI designers are <b>strongly</b> advised to make this obscure and hard to change as it is very rare to be useful to do so.</i>
</p>
<div class="editsection" style="float:right;margin-left:5px;">[<a href="/index.php?title=BitTorrentSpecification&amp;action=edit&amp;section=20" title="Edit section: Tracker 'scrape' Convention">edit</a>]</div><a name="Tracker_.27scrape.27_Convention"></a><h2> Tracker 'scrape' Convention </h2>
<p>By convention most trackers support another form of request, which queries the state of a given torrent (or all torrents) that the tracker is managing.  This is referred to as the "scrape page" because it automates the otherwise tedious process of "screen scraping" the tracker's stats page.
</p><p>The scrape URL is also a HTTP GET method, similar to the one described above.  However the base URL is different.  To derive the scrape URL use the following steps:  Begin with the announce URL.  Find the last '/' in it.  If the text immediately following that '/' isn't 'announce' it will be taken as a sign that that tracker doesn't support the scrape convention. If it does, substitute 'scrape' for 'announce' to find the scrape page.
</p><p>Examples: (announce URL -&gt; scrape URL)
</p>
<pre>
  ~http://example.com/announce          -&gt; ~http://example.com/scrape
  ~http://example.com/x/announce        -&gt; ~http://example.com/x/scrape
  ~http://example.com/announce.php      -&gt; ~http://example.com/scrape.php
  ~http://example.com/a                 -&gt; (scrape not supported)
  ~http://example.com/announce?x&lt;code&gt;2%0644 -&gt; ~http://example.com/scrape?x&lt;/code&gt;2%0644
  ~http://example.com/announce?x=2/4    -&gt; (scrape not supported)
  ~http://example.com/x%064announce     -&gt; (scrape not supported)
</pre>
<p>Note especially that entity unquoting is '<i>not</i> to be done.  This standard is documented by Bram in the <a href="/BitTorrent" title="BitTorrent">BitTorrent</a> development list archive: <a href="http://groups.yahoo.com/group/BitTorrent/message/3275" class="external free" title="http://groups.yahoo.com/group/BitTorrent/message/3275" rel="nofollow">http://groups.yahoo.com/group/BitTorrent/message/3275</a>
</p><p>The scrape URL may be supplemented by the optional parameter <i>info_hash</i>, 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 <i>info_hash</i> parameter when at all possible, to reduce the load and bandwidth of the tracker.
</p><p>You may also specify multiple info_hash parameters to trackers that support it. While this isn't part of the official specifications it has become somewhat a defacto standard - for example:
</p>
<pre>
 http://example.com/scrape.php?info_hash=aaaaaaaaaaaaaaaaaaaa&amp;info_hash=bbbbbbbbbbbbbbbbbbbb&amp;info_hash=cccccccccccccccccccc
</pre>
<p>The response of this HTTP GET method is a "text/plain" or sometimes gzip compressed document consisting of a bencoded dictionary, containing the following keys:
</p>
<ul><li> <b>files</b>: a dictionary containing one key/value pair for each torrent for which there are stats.  If <i>info</i>hash* was supplied and was valid, this dictionary will contain a single key/value.  Each key consists of a 20-byte binary info<i>hash value.  The value of that key is yet another nested dictionary containing the following:</i>
<ul><li> <b>complete</b>: number of peers with the entire file, i.e. seeders (integer)
</li><li> <b>downloaded</b>: total number of times the tracker has registered a completion ("event=complete", i.e. a client finished downloading the torrent)
</li><li> <b>incomplete</b>: number of non-seeder peers, aka "leechers" (integer)
</li><li> <b>name</b>: (optional) the torrent's internal name, as specified by the "name" file in the info section of the .torrent file
</li></ul>
</li></ul>
<p>Note that this response has three levels of dictionary nesting.  Here's an example:
</p><p><tt>d5:<i>files</i>d20:....................d8:<i>complete</i>i<b>5</b>e10:<i>downloaded</i>i<b>50</b>e10:<i>incomplete</i>i<b>10</b>eeee</tt>
</p><p>Where <tt>....................</tt> is the 20 byte info_hash and there are 5 seeders, 10 leechers, and 50 complete downloads.
</p>
<div class="editsection" style="float:right;margin-left:5px;">[<a href="/index.php?title=BitTorrentSpecification&amp;action=edit&amp;section=21" title="Edit section: Unofficial extensions to scrape">edit</a>]</div><a name="Unofficial_extensions_to_scrape"></a><h3> Unofficial extensions to scrape </h3>
<p>Below are the response keys are being unofficially used.  Since they are unnofficial, they are all optional.
</p>
<ul><li> <b>failure reason</b>: Human-readable error message as to why the request failed (string).  Clients known to handle this key: Azureus.
</li><li> <b>flags</b>: a dictionary containing miscellaneous flags.  The value of the flags key is another nested dictionary, possibly containing the following:
<ul><li> <b>min_request_interval</b>: The value for this key is an integer specifying how the minimum number of seconds for the client to wait before scraping the tracker again. Trackers known to send this key: BNBT. Clients known to handle this key: Azureus.
</li></ul>
</li></ul>
<div class="editsection" style="float:right;margin-left:5px;">[<a href="/index.php?title=BitTorrentSpecification&amp;action=edit&amp;section=22" title="Edit section: Peer wire protocol (TCP)">edit</a>]</div><a name="Peer_wire_protocol_.28TCP.29"></a><h2> Peer wire protocol (TCP) </h2>
<div class="editsection" style="float:right;margin-left:5px;">[<a href="/index.php?title=BitTorrentSpecification&amp;action=edit&amp;section=23" title="Edit section: Overview">edit</a>]</div><a name="Overview"></a><h3> Overview </h3>
<p>The peer protocol facilitates the exchange of pieces as described in the '<i>metainfo</i> file.
</p><p><i>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.</i>
</p><p>A client must maintain state information for each connection that it has with a remote peer:
'<i> </i>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.
'<i> </i>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.
</p><p><i>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:</i>
</p>
<ul><li> <b>am_choking</b>: this client is choking the peer
</li><li> <b>am_interested</b>: this client is interested in the peer
</li><li> <b>peer_choking</b>: peer is choking this client
</li><li> <b>peer_interested</b>: peer is interested in this client
</li></ul>
<p>Client connections start out as "choked" and "not interested".  In other words:
</p>
<ul><li> <b>am_choking</b> = 1
</li><li> <b>am_interested</b> = 0
</li><li> <b>peer_choking</b> = 1
</li><li> <b>peer_interested</b> = 0
</li></ul>
<p>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.
</p><p>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 up-to-date 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 vice-versa).
</p>
<div class="editsection" style="float:right;margin-left:5px;">[<a href="/index.php?title=BitTorrentSpecification&amp;action=edit&amp;section=24" title="Edit section: Data Types">edit</a>]</div><a name="Data_Types"></a><h3> Data Types </h3>
<p>Unless specified otherwise, all integers in the peer wire protocol are encoded as four byte big-endian values.  This includes the length prefix on all messages that come after the handshake.
</p>
<div class="editsection" style="float:right;margin-left:5px;">[<a href="/index.php?title=BitTorrentSpecification&amp;action=edit&amp;section=25" title="Edit section: Message flow">edit</a>]</div><a name="Message_flow"></a><h3> Message flow </h3>
<p>The peer wire protocol consists of an initial handshake.  After that, peers communicate via an exchange of length-prefixed messages.  The length-prefix is an integer as described above.
</p>
<div class="editsection" style="float:right;margin-left:5px;">[<a href="/index.php?title=BitTorrentSpecification&amp;action=edit&amp;section=26" title="Edit section: Handshake">edit</a>]</div><a name="Handshake"></a><h3> Handshake </h3>
<p>The handshake is a required message and must be the first message transmitted by the client.
</p><p><i>handshake: &lt;pstrlen&gt;&lt;pstr&gt;&lt;reserved&gt;&lt;info_hash&gt;&lt;peer_id&gt;</i>
</p>
<ul><li> <b>pstrlen</b>: string length of &lt;pstr&gt;, as a single raw byte
</li><li> <b>pstr</b>: string identifier of the protocol
</li><li> <b>reserved</b>: eight (8) reserved bytes.  All current implementations use all zeroes.  Each bit in these bytes can be used to change the behavior of the protocol.  <i>An email from Bram suggests that trailing bits should be used first, so that leading bits may be used to change the meaning of trailing bits.</i>
</li><li> <b>info_hash</b>: 20-byte SHA1 hash of the info key in the metainfo file.  This is the same info_hash that is transmitted in tracker requests.
</li><li> <b>peer_id</b>: 20-byte string used as a unique ID for the client.  This is usually the same peer_id that is transmitted in tracker requests (but not always e.g. an anonymity option in Azureus).
</li></ul>
<p>In version 1.0 of the BitTorrent protocol, pstrlen = 19, and pstr = "BitTorrent protocol".
</p><p>The initiator of a connection is expected to transmit their handshake immediately.  The recipient may wait for the initiator's handshake, if it is capable of serving multiple torrents simultaneously (torrents are uniquely identified by their info<i>hash).  However, the recipient must respond as soon as it sees the info_hash part of the handshake.  The tracker's NAT-checking feature does not send the peer_id field of the handshake.</i>
</p><p>If a client receives a handshake with an info_hash that it is not currently serving, then the client must drop the connection.
</p><p>If the initiator of the connection receives a handshake in which the peer_id does not match the expected peer<i>id, then the initiator is expected to drop the connection.  </i>Note that the initiator presumably received the peer information from the tracker, which includes the peer_id that was registered by the peer.  The peer_id from the tracker and in the handshake are expected to match.
</p>
<div class="editsection" style="float:right;margin-left:5px;">[<a href="/index.php?title=BitTorrentSpecification&amp;action=edit&amp;section=27" title="Edit section: peer_id">edit</a>]</div><a name="peer_id"></a><h4> peer_id </h4>
<p>There are mainly two conventions how to encode client and client version information into the peer_id, Azureus-style and Shadow's-style.
</p><p>Azureus-style uses the following encoding:
'-', two characters for client id, four ascii digits for version number, '-', followed by random numbers.