bit torrent specification.htm

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

<H4><B>request</B>: 
&lt;len=0013&gt;&lt;id=6&gt;&lt;index&gt;&lt;begin&gt;&lt;length&gt;</H4>
<DL>
  <DT class="tightenable bottom">The <B>request</B> message is fixed length, and 
  is used to request a block. The payload contains the following information 
  <DD class="tightenable top">
  <UL>
    <LI class="tightenable top bottom">index: integer specifying the zero-based 
    piece index 
    <LI class="tightenable top bottom">begin: integer specifying the zero-based 
    byte offset within the piece 
    <LI class="tightenable top bottom">length: integer specifying the requested 
    length. This value should normally be 2^14 (16384) bytes. Smaller values may 
    be used but are usually not needed except in rare cases like a piece length 
    not divisible by 16384. </LI></UL></DD></DL>
<P class=tightenable>The observant reader will note that a block is typically 
smaller than a piece (which is commonly &gt;= 2^18 bytes). A client may close 
the connection if it receives a request for more than 16384 bytes.</P>
<P class=tightenable>Mainline (version 4 and later) disconnects peers requesting 
blocks larger than 16 KiB by default.</P>
<H4><B>piece</B>: 
&lt;len=0009+X&gt;&lt;id=7&gt;&lt;index&gt;&lt;begin&gt;&lt;block&gt;</H4>
<DL>
  <DT class="tightenable bottom">The <B>piece</B> message is variable length, 
  where X is the length of the block. The payload contains the following 
  information 
  <DD class="tightenable top">
  <UL>
    <LI class="tightenable top bottom">index: integer specifying the zero-based 
    piece index 
    <LI class="tightenable top bottom">begin: integer specifying the zero-based 
    byte offset within the piece 
    <LI class="tightenable top bottom">block: block of data, which is a subset 
    of the piece specified by index. </LI></UL></DD></DL>
<H4><B>cancel</B>: 
&lt;len=0013&gt;&lt;id=8&gt;&lt;index&gt;&lt;begin&gt;&lt;length&gt;</H4>
<P class=tightenable>The <B>cancel</B> message is fixed length, and is used to 
cancel block requests. The payload is identical to that of the "request" 
message. It is typically used during "End Game" (see the Algorithms section 
below).</P>
<H4><B>port</B>: &lt;len=0003&gt;&lt;id=9&gt;&lt;listen-port&gt;</H4>
<P class=tightenable>The <B>port</B> message is sent by newer versions of the 
Mainline that implements a DHT tracker. The listen port is the port this peer's 
DHT node is listening on. This peer should be inserted in the local routing 
table (if DHT tracker is supported).</P>
<H2>Algorithms</H2>
<H3>Super Seeding</H3>
<P class=tightenable><I>(This was not part of the original 
specification)</I></P>
<P class=tightenable><I>The super-seed feature in S-5.5 and on is a new seeding 
algorithm designed to help a torrent initiator with limited bandwidth "pump up" 
a large torrent, reducing the amount of data it needs to upload in order to 
spawn new seeds in the torrent.</I></P>
<P class=tightenable><I>When a seeding client enters "super-seed mode", it will 
not act as a standard seed, but masquerades as a normal client with no data. As 
clients connect, it will then inform them that it received a piece -- a piece 
that was never sent, or if all pieces were already sent, is very rare. This will 
induce the client to attempt to download only that piece.</I></P>
<P class=tightenable><I>When the client has finished downloading the piece, the 
seed will not inform it of any other pieces until it has seen the piece it had 
sent previously present on at least one other client. Until then, the client 
will not have access to any of the other pieces of the seed, and therefore will 
not waste the seed's bandwidth.</I></P>
<P class=tightenable><I>This method has resulted in much higher seeding 
efficiencies, by both inducing peers into taking only the rarest data, reducing 
the amount of redundant data sent, and limiting the amount of data sent to peers 
which do not contribute to the swarm. Prior to this, a seed might have to upload 
150% to 200% of the total size of a torrent before other clients became seeds. 
However, a large torrent seeded with a single client running in super-seed mode 
was able to do so after only uploading 105% of the data. This is 150-200% more 
efficient than when using a standard seed.</I></P>
<P class=tightenable><I>Super-seed mode is <B>NOT</B> recommended for general 
use. While it does assist in the wider distribution of rare data, because it 
limits the selection of pieces a client can downlad, it also limits the ability 
of those clients to download data for pieces they have already partially 
retrieved. Therefore, super-seed mode is only recommended for initial seeding 
servers.</I></P>
<BLOCKQUOTE class=tightenable>
  <P class="tightenable top bottom"><I>Why not rename it to e.g. "Initial 
  Seeding Mode" or "Releaser Mode" then?</I></P></BLOCKQUOTE>
<H3>Piece downloading strategy</H3>
<P class=tightenable>Clients may choose to download pieces in random order.</P>
<P class=tightenable><I>A better strategy is to download pieces in <I><A 
class=named-wiki title=Availability 
href="http://wiki.theory.org/Availability">rarest first</A></I> order. The 
client can determine this by keeping the initial bitfield from each peer, and 
updating it with every <B>have</B> message. Then, the client can download the 
pieces that appear least frequently in these peer bitfields.</I></P>
<H3>End Game</H3>
<P class=tightenable>When a download is almost complete, there's a tendency for 
the last few blocks to trickle in slowly. To speed this up, the client sends 
requests for all of its missing blocks to all of its peers. To keep this from 
becoming horribly inefficient, the client also sends a cancel to everyone else 
every time a block arrives.</P>
<P class=tightenable><I>There is no documented thresholds, recommended 
percentages, or block counts that could be used as a guide or Recommended Best 
Practice here.</I></P>
<P class=tightenable><I>When to enter end game mode is an area of discussion. 
Some clients enter end game when all pieces have been requested. Others wait 
until the number of blocks left is lower than the number of blocks in transit, 
and no more than 20. There seems to be agreement that it's a good idea to keep 
the number of pending blocks low (1 or 2 blocks) to minimize the overhead, and 
if you randomize the blocks requested, there's a lower chance of downloading 
duplicates. More on the protocol overhead can be found here:</I> <A 
class=namedurl href="http://hal.inria.fr/inria-00000156/en"><SPAN 
style="WHITE-SPACE: nowrap"><IMG class=linkicon alt="" 
src="Bit Torrent Specification.files/http.png" 
border=0>http://hal.inria.fr/inria-00000156/en</SPAN></A></P>
<H3>Choking and Optimistic Unchoking</H3>
<P class=tightenable>Choking is done for several reasons. TCP congestion control 
behaves very poorly when sending over many connections at once. Also, choking 
lets each peer use a tit-for-tat-ish algorithm to ensure that they get a 
consistent download rate.</P>
<P class=tightenable>The choking algorithm described below is the currently 
deployed one. It is very important that all new algorithms work well both in a 
network consisting entirely of themselves and in a network consisting mostly of 
this one.</P>
<P class=tightenable>There are several criteria a good choking algorithm should 
meet. It should cap the number of simultaneous uploads for good TCP performance. 
It should avoid choking and unchoking quickly, known as 'fibrillation'. It 
should reciprocate to peers who let it download. Finally, it should try out 
unused connections once in a while to find out if they might be better than the 
currently used ones, known as optimistic unchoking.</P>
<P class=tightenable>The currently deployed choking algorithm avoids 
fibrillation by only changing choked peers once every ten seconds.</P>
<P class=tightenable>Reciprocation and number of uploads capping is managed by 
unchoking the four peers which have the best upload rate and are interested. 
This maximizes the client's download rate. These four peers are referred to as 
<I>downloaders</I>, because they are interested in downloading from the 
client.</P>
<P class=tightenable>Peers which have a better upload rate (as compared to the 
<I>downloaders</I>) but aren't interested get unchoked. If they become 
interested, the <I>downloader</I> with the worst upload rate gets choked. If a 
client has a complete file, it uses its upload rate rather than its download 
rate to decide which peers to unchoke.</P>
<P class=tightenable>For optimistic unchoking, at any one time there is a single 
peer which is unchoked regardless of it's upload rate (if interested, it counts 
as one of the four allowed <I>downloaders</I>). Which peer is optimistically 
unchoked rotates every 30 seconds. Newly connected peers are three times as 
likely to start as the current optimistic unchoke as anywhere else in the 
rotation. This gives them a decent chance of getting a complete piece to 
upload.</P>
<H4>Anti-snubbing (extension not in the official protocol)</H4>
<P class="tightenable top">Occasionally a <A class=wiki 
href="http://wiki.theory.org/BitTorrent">BitTorrent</A> peer will be choked by 
all peers which it was formerly downloading from. In such cases it will usually 
continue to get poor download rates until the optimistic unchoke finds better 
peers. To mitigate this problem, when over a minute goes by without getting a 
single piece from a particular peer, <A class=wiki 
href="http://wiki.theory.org/BitTorrent">BitTorrent</A> assumes it is "snubbed" 
by that peer and doesn't upload to it except as an optimistic unchoke. This 
frequently results in more than one concurrent optimistic unchoke, (an exception 
to the exactly one optimistic unchoke rule mentioned above), which causes 
download rates to recover much more quickly when they falter.</P>
<H2>Change Log</H2>
<P class=tightenable>Put your changes below this line, so that the most recent 
changes appear first. The change log should be purged from time to time. Please 
preserve the last month's worth of change logs.</P>
<P class="tightenable bottom">haylegend - 2006-01-08</P>
<UL>
  <LI class="tightenable top">Added Retriever's peer id. </LI></UL>
<P class="tightenable bottom">uau - 2005-12-13</P>
<UL>
  <LI class="tightenable top bottom">Fixed sizes in request message description 
  AGAIN. They had been changed to incorrect values by <SPAN class=wikiunknown><A 
  onmouseover='window.status="Create: ElliotMitchell"; return true;' 
  title="Create: ElliotMitchell" onmouseout="window.status='';return true;" 
  href="http://wiki.theory.org/ElliotMitchell?action=create">?</A><U>ElliotMitchell</U></SPAN>. 

  <LI class="tightenable top">Removed "Queuing" section that had been added by 
  <SPAN class=wikiunknown><A 
  onmouseover='window.status="Create: ElliotMitchell"; return true;' 
  title="Create: ElliotMitchell" onmouseout="window.status='';return true;" 
  href="http://wiki.theory.org/ElliotMitchell?action=create">?</A><U>ElliotMitchell</U></SPAN>. 
  It had so many errors and inaccuracies that it did more harm than good as it 
  was, and I didn't feel like rewriting it. </LI></UL>
<P class="tightenable bottom">daniel-gl at gmx.net - 2005-07-29</P>
<UL>
  <LI class="tightenable top bottom">Completed <SPAN class=wikiunknown><A 
  onmouseover='window.status="Create: BitComet"; return true;' 
  title="Create: BitComet" onmouseout="window.status='';return true;" 
  href="http://wiki.theory.org/BitComet?action=create">?</A><U>BitComet</U></SPAN> 
  Peer ID according to <A class=namedurl 
  href="http://wiki.bitcomet.com/help/Inside_BitComet"><SPAN 
  style="WHITE-SPACE: nowrap"><IMG class=linkicon alt="" 
  src="Bit Torrent Specification.files/http.png" 
  border=0>http://wiki.bitcomet.com/help/Inside_BitComet</SPAN></A> 
  <LI class="tightenable top">Added 礣orrent (correct me if I'm wrong) and 
  Shareaza Peer ID </LI></UL>
<P class="tightenable bottom"><A class=wiki 
href="http://wiki.theory.org/BitBrat">BitBrat</A> andreas