bit torrent specification.htm

由delphi实现的bt下载器示例程序

  peers, aka "leechers" (integer) 
  <LI class="tightenable top">
  <P class="tightenable top bottom"><B>peers</B>: The value is a list of 
  dictionaries, each with the following keys:</P>
  <UL>
    <LI class="tightenable top bottom"><B>peer id</B>: peer's self-selected ID, 
    as described above for the tracker request (string) 
    <LI class="tightenable top bottom"><B>ip</B>: peer's IP address (either IPv6 
    or IPv4) or DNS name (string) 
    <LI class="tightenable top bottom"><B>port</B>: peer's port number (integer) 
    </LI></UL></LI></UL>
<P class=tightenable>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 class=tightenable>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. <I>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.</I></P>
<P class=tightenable><I>Implementer's Note: Even 30 peers is <B>plenty</B>, the 
official client 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 crucial 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>
<H2>Tracker 'scrape' Convention</H2>
<P class=tightenable>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 class=tightenable>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 class=tightenable>Examples: (announce URL -&gt; scrape URL)</P><PRE class=tightenable>  http://spam.com/announce          -&gt; http://spam.com/scrape
  http://spam.com/x/announce        -&gt; http://spam.com/x/scrape
  http://spam.com/announce.php      -&gt; http://spam.com/scrape.php
  http://spam.com/a                 -&gt; (scrape not supported)
  http://spam.com/announce?x=2%0644 -&gt; http://spam.com/scrape?x=2%0644
  http://spam.com/announce?x=2/4    -&gt; (scrape not supported)
  http://spam.com/x%064announce     -&gt; (scrape not supported)</PRE>
<P class=tightenable>Note especially that entity unquoting is <B>not</B> to be 
done. This standard is documented by Bram in the <A class=wiki 
href="http://wiki.theory.org/BitTorrent">BitTorrent</A> development list 
archive: <A class=namedurl 
href="http://groups.yahoo.com/group/BitTorrent/message/3275"><SPAN 
style="WHITE-SPACE: nowrap"><IMG class=linkicon alt="" 
src="Bit Torrent Specification.files/http.png" 
border=0>http://groups.yahoo.com/group/BitTorrent/message/3275</SPAN></A></P>
<P class=tightenable>The scrape URL may be supplimented by the optional 
parameter <B>info_hash</B>, 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 <B>info_hash</B> parameter when at all possible, 
to reduce the load and bandwidth of the tracker.</P>
<DL>
  <DT class=tightenable>The response of this HTTP GET method is a "text/plain" 
  document consisting of a bencoded dictionary, containing the following keys 
  <DD class=tightenable>
  <UL>
    <LI class="tightenable top bottom">
    <P class="tightenable top bottom"><B>files</B>: a dictionary containing one 
    key/value pair for each torrent for which there are stats. If 
    <B>info_hash</B> 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:</P>
    <UL>
      <LI class="tightenable top bottom"><B>complete</B>: number of peers with 
      the entire file, i.e. seeders (integer) 
      <LI class="tightenable top bottom"><B>downloaded</B>: total number of 
      times the tracker has registered a completion ("event=complete", i.e. a 
      client finished downloading the torrent) 
      <LI class="tightenable top bottom"><B>incomplete</B>: number of non-seeder 
      peers, aka "leechers" (integer) 
      <LI class="tightenable top bottom"><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></DD></DL>
<P class=tightenable>Note that this response has three levels of dictionary 
nesting. Here's an example:</P>
<P 
class=tightenable><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 class=tightenable>Where <TT>....................</TT> is the 20 byte 
info_hash and there are 5 seeders, 10 leechers, and 50 complete downloads.</P>
<H2>Peer wire protocol (TCP)</H2>
<H3>Overview</H3>
<P class=tightenable>The peer protocol facilitates the exchange of pieces as 
described in the <B>metainfo</B> file.</P>
<P class=tightenable><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 class="tightenable bottom">A client must maintain state information for each 
connection that it has with a remote peer:</P>
<UL>
  <LI class="tightenable top bottom"><B>choked</B>: 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. 

  <LI class="tightenable top"><B>interested</B>: 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. </LI></UL>
<P class="tightenable bottom"><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 class="tightenable top bottom"><B>am_choking</B>: this client is choking 
  the peer 
  <LI class="tightenable top bottom"><B>am_interested</B>: this client is 
  interested in the peer 
  <LI class="tightenable top bottom"><B>peer_choking</B>: peer is choking this 
  client 
  <LI class="tightenable top"><B>peer_interested</B>: peer is interested in this 
  client </LI></UL>
<P class="tightenable bottom">Client connections start out as "choked" and "not 
interested". In other words:</P>
<UL>
  <LI class="tightenable top bottom"><B>am_choking</B> = 1 
  <LI class="tightenable top bottom"><B>am_interested</B> = 0 
  <LI class="tightenable top bottom"><B>peer_choking</B> = 1 
  <LI class="tightenable top"><B>peer_interested</B> = 0 </LI></UL>
<P class=tightenable>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 class=tightenable>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>
<H3>Data Types</H3>
<P class=tightenable>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>
<H3>Message flow</H3>
<P class=tightenable>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>
<H3>Handshake</H3>
<P class=tightenable>The handshake is a required message and must be the first 
message transmitted by the client.</P>
<UL>
  <LI class=tightenable>
  <P class="tightenable top bottom"><B>handshake</B>: 
  &lt;pstrlen&gt;&lt;pstr&gt;&lt;reserved&gt;&lt;info_hash&gt;&lt;peer_id&gt;</P>
  <UL>
    <LI class="tightenable top bottom"><B>pstrlen</B>: string length of 
    &lt;pstr&gt;, as a single raw byte 
    <LI class="tightenable top bottom"><B>pstr</B>: string identifier of the 
    protocol 
    <LI class="tightenable top bottom"><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 class="tightenable top bottom"><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 class="tightenable top bottom"><B>peer_id</B>: 20-byte string used as a 
    unique ID for the client. This is the same peer_id that is transmitted in 
    tracker requests. </LI></UL></LI></UL>
<P class=tightenable>In version 1.0 of the BitTorrent protocol, pstrlen=19, and 
pstr="BitTorrent protocol".</P>
<P class=tightenable>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_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.</P>
<P class=tightenable>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 class=tightenable>If the initiator of the connection receives a handshake in 
which the peer_id does not match the expected peer_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.</I></P>
<P class="tightenable bottom"><A id=peer_id name=peer_id></A></P>
<H4>peer_id</H4>