bittorrentspecification.htm

关于ＢＴ的协议文档

</p><p>For example: '-AZ2060-'...
</p><p>known clients that uses this encoding style are:
</p>
<ul><li> 'AG' - <a href="http://aresgalaxy.sourceforge.net/" class="external text" title="http://aresgalaxy.sourceforge.net/" rel="nofollow">Ares</a>
</li><li> 'A~' - <a href="http://aresgalaxy.sourceforge.net/" class="external text" title="http://aresgalaxy.sourceforge.net/" rel="nofollow">Ares</a>
</li><li> 'AR' - <a href="http://dev.int64.org/arctic.html" class="external text" title="http://dev.int64.org/arctic.html" rel="nofollow">Arctic</a>
</li><li> 'AX' - <a href="http://www.analogx.com/contents/download/network/bitpump.htm" class="external text" title="http://www.analogx.com/contents/download/network/bitpump.htm" rel="nofollow">BitPump</a>
</li><li> 'AZ' - <a href="http://azureus.sf.net" class="external text" title="http://azureus.sf.net" rel="nofollow">Azureus</a>
</li><li> 'BB' - <a href="http://www.btvampire.com" class="external text" title="http://www.btvampire.com" rel="nofollow">BitBuddy</a>
</li><li> 'BC' - <a href="http://www.bitcomet.com" class="external text" title="http://www.bitcomet.com" rel="nofollow">BitComet</a>
</li><li> 'BF' - <a href="http://bitflu.workaround.ch/" class="external text" title="http://bitflu.workaround.ch/" rel="nofollow">Bitflu</a>
</li><li> 'BG' - <a href="http://btg.berlios.de/" class="external text" title="http://btg.berlios.de/" rel="nofollow">BTG (uses Rasterbar libtorrent)</a>
</li><li> 'BR' - <a href="http://www.bitrocket.org" class="external text" title="http://www.bitrocket.org" rel="nofollow">BitRocket</a>
</li><li> 'BS' - <a href="http://btslave.sourceforge.net" class="external text" title="http://btslave.sourceforge.net" rel="nofollow">BTSlave</a>
</li><li> 'BX' - ~Bittorrent X
</li><li> 'CD' - <a href="http://www.rahul.net/dholmes/ctorrent/" class="external text" title="http://www.rahul.net/dholmes/ctorrent/" rel="nofollow">Enhanced CTorrent</a>
</li><li> 'CT' - <a href="http://ctorrent.sourceforge.net" class="external text" title="http://ctorrent.sourceforge.net" rel="nofollow">CTorrent</a>
</li><li> 'DE' - <a href="http://www.deluge-torrent.org" class="external text" title="http://www.deluge-torrent.org" rel="nofollow">DelugeTorrent</a>
</li><li> 'EB' - <a href="http://dywt.com.cn/" class="external text" title="http://dywt.com.cn/" rel="nofollow">EBit</a>
</li><li> 'ES' - <a href="http://electricsheep.org" class="external text" title="http://electricsheep.org" rel="nofollow">electric sheep</a>
</li><li> 'HL' - <a href="http://www.binarynotions.com/halite.php" class="external text" title="http://www.binarynotions.com/halite.php" rel="nofollow">Halite</a>
</li><li> 'KT' - <a href="http://ktorrent.org" class="external text" title="http://ktorrent.org" rel="nofollow">KTorrent</a>
</li><li> 'LP' - <a href="http://www.lphant.com" class="external text" title="http://www.lphant.com" rel="nofollow">Lphant</a>
</li><li> 'LT' - <a href="http://libtorrent.sf.net" class="external text" title="http://libtorrent.sf.net" rel="nofollow">libtorrent</a>
</li><li> 'lt' - <a href="http://libtorrent.rakshasa.no" class="external text" title="http://libtorrent.rakshasa.no" rel="nofollow">libTorrent</a>
</li><li> 'MP' - <a href="http://www.moopolice.de" class="external text" title="http://www.moopolice.de" rel="nofollow">MooPolice</a>
</li><li> 'MT' - <a href="http://www.moonlighttorrent.com" class="external text" title="http://www.moonlighttorrent.com" rel="nofollow">MoonlightTorrent</a>
</li><li> 'qB' - <a href="http://www.qbittorrent.org" class="external text" title="http://www.qbittorrent.org" rel="nofollow">qBittorrent</a>
</li><li> 'QT' - Qt 4 Torrent example
</li><li> 'RT' - <a href="http://www.halogenware.com/software/retriever.html" class="external text" title="http://www.halogenware.com/software/retriever.html" rel="nofollow">Retriever</a>
</li><li> 'S~' - <a href="http://shareaza.sourceforge.net" class="external text" title="http://shareaza.sourceforge.net" rel="nofollow">Shareaza alpha/beta</a>
</li><li> 'SB' - ~Swiftbit
</li><li> 'SS' - SwarmScope
</li><li> 'ST' - seen in the field but the source implementation is unknown
</li><li> 'SZ' - <a href="http://shareaza.sourceforge.net" class="external text" title="http://shareaza.sourceforge.net" rel="nofollow">Shareaza</a>
</li><li> 'TN' - TorrentDotNET
</li><li> 'TR' - <a href="http://transmission.m0k.org" class="external text" title="http://transmission.m0k.org" rel="nofollow">Transmission</a>
</li><li> 'TS' - <a href="http://www.torrentstorm.com" class="external text" title="http://www.torrentstorm.com" rel="nofollow">Torrentstorm</a>
</li><li> 'TT' - seen in the field but the source implementation is unknown
</li><li> 'UL' - uLeecher!
</li><li> 'UT' - <a href="http://www.utorrent.com" class="external text" title="http://www.utorrent.com" rel="nofollow">碌Torrent</a>
</li><li> 'XT' - <a href="http://www.xantorrent.pwp.blueyonder.co.uk/xantorrent.zip" class="external text" title="http://www.xantorrent.pwp.blueyonder.co.uk/xantorrent.zip" rel="nofollow">XanTorrent</a>
</li><li> 'XX' - <a href="http://www.xtorrent.com" class="external text" title="http://www.xtorrent.com" rel="nofollow">Xtorrent</a>
</li><li> 'ZT' - <a href="http://www.ziptorrent.com" class="external text" title="http://www.ziptorrent.com" rel="nofollow">ZipTorrent</a>
</li></ul>
<p>Shadow's style uses the following encoding:
one ascii alphanumeric for client identification, three ascii digits for version number, '----', followed by random numbers.
</p><p>For example: 'S587----'...
</p><p>known clients that uses this encoding style are:
</p>
<ul><li> 'A' - <a href="http://pingpong-abc.sourceforge.net/" class="external text" title="http://pingpong-abc.sourceforge.net/" rel="nofollow">ABC</a> (it uses only 2 dashes. A310--XXXXX has been seen in the field)
</li><li> 'O' - <a href="http://osprey.ibiblio.org/" class="external text" title="http://osprey.ibiblio.org/" rel="nofollow">Osprey Permaseed</a>
</li><li> 'R' - <a href="http://www.tribler.org/" class="external text" title="http://www.tribler.org/" rel="nofollow">Tribler</a>
</li><li> 'S' - <a href="http://bt.degreez.net/" class="external text" title="http://bt.degreez.net/" rel="nofollow">Shadow's client</a>
</li><li> 'T' - <a href="http://bittornado.com" class="external text" title="http://bittornado.com" rel="nofollow">BitTornado</a> (it may use non digit in the version. T03H----XXXX has been seen in the field)
</li><li> 'U' - <a href="http://aaron2003.myftp.org/upnpclient.html" class="external text" title="http://aaron2003.myftp.org/upnpclient.html" rel="nofollow">UPnP NAT Bit Torrent</a>
</li></ul>
<p>Bram's client now uses this style... 'M3-4-2--' or 'M4-20-8-'.
</p><p><a href="http://www.bitcomet.com/" class="external text" title="http://www.bitcomet.com/" rel="nofollow">BitComet</a> does something different still. Its peer_id consists of four ASCII characters 'exbc', followed by two bytes x and y, followed by random characters. The version number is x in decimal before the decimal point and y as two decimal digits after the decimal point. <a href="http://www.bitlord.com/" class="external text" title="http://www.bitlord.com/" rel="nofollow">BitLord</a> uses the same scheme, but adds 'LORD' after the version bytes. An <a href="http://solidox.org/bc/" class="external text" title="http://solidox.org/bc/" rel="nofollow">unofficial patch</a> for BitComet once replaced 'exbc' with 'FUTB'. The encoding for BitComet Peer IDs changed to Azureus-style as of BitComet version 0.59.
</p><p><a href="http://xbtt.sourceforge.net/client/" class="external text" title="http://xbtt.sourceforge.net/client/" rel="nofollow">XBT Client</a> has its own style too.  Its peer_id consists of the three uppercase characters 'XBT' followed by three ASCII digits representing the version number.  If the client is a debug build, the seventh byte is the lowercase character 'd', otherwise it is a '-'.  Following that is a '-' then random digits, uppercase and lowercase letters. Example: 'XBT054d-' at the beginning would indicate a debug build of version 0.5.4.
</p><p><a href="http://snapshot.opera.com/" class="external text" title="http://snapshot.opera.com/" rel="nofollow">Opera 8 previews</a> use the following peer_id scheme:
The first two characters are 'OP' and the next four digits equal the build number. All following characters are random lowercase hexdecimal digits.
</p><p><a href="http://mldonkey.sourceforge.net/Main_Page" class="external text" title="http://mldonkey.sourceforge.net/Main_Page" rel="nofollow">MLdonkey</a> use the following peer_id scheme:
the first characters are '-ML' followed by a dotted version then a '-' followed by randomness. e.g. '-ML2.7.2-kgjjfkd'
</p><p><a href="http://www.bitsonwheels.com/" class="external text" title="http://www.bitsonwheels.com/" rel="nofollow">Bits on Wheels</a> uses the pattern '-BOWAxx-yyyyyyyyyyyy', where y is random (uppercase letters) and x depends on the version. Version 1.0.6 has xx = 0C.
</p><p><a href="http://queenbee.se/" class="external text" title="http://queenbee.se/" rel="nofollow">Queen Bee</a> uses Bram's new style: 'Q1-0-0--' or 'Q1-10-0-' followed by random bytes.
</p><p>Many clients are using all random numbers or 12 zeroes followed by random numbers (like older versions of <a href="http://www.bittorrent.com/" class="external text" title="http://www.bittorrent.com/" rel="nofollow">Bram's client</a>).
</p>
<div class="editsection" style="float:right;margin-left:5px;">[<a href="/index.php?title=BitTorrentSpecification&amp;action=edit&amp;section=28" title="Edit section: Messages">edit</a>]</div><a name="Messages"></a><h3>Messages</h3>
<p>All of the remaining messages in the protocol take the form of &lt;length prefix&gt;&lt;message ID&gt;&lt;payload&gt;.  The length prefix is a four byte big-endian value.  The message ID is a single decimal character.  The payload is message dependent.
</p>
<div class="editsection" style="float:right;margin-left:5px;">[<a href="/index.php?title=BitTorrentSpecification&amp;action=edit&amp;section=29" title="Edit section: keep-alive: &amp;lt;len=0000&amp;gt;">edit</a>]</div><a name="keep-alive:_.3Clen.3D0000.3E"></a><h4>keep-alive: &lt;len=0000&gt;</h4>
<p>The <b>keep-alive</b> message is a message with zero bytes, specified with the length prefix set to zero.  There is no message ID and no payload.  Peers may close a connection if they receive no messages (<b>keep-alive</b> or any other message) for a certain period of time, so a keep-alive message must be sent to maintain the connection <i>alive</i> if no command have been sent for a given amount of time. This amount of time is generally two minutes.
</p>
<div class="editsection" style="float:right;margin-left:5px;">[<a href="/index.php?title=BitTorrentSpecification&amp;action=edit&amp;section=30" title="Edit section: choke: &amp;lt;len=0001&amp;gt;&amp;lt;id=0&amp;gt;">edit</a>]</div><a name="choke:_.3Clen.3D0001.3E.3Cid.3D0.3E"></a><h4>choke: &lt;len=0001&gt;&lt;id=0&gt;</h4>
<p>The <b>choke</b> message is fixed-length and has no payload.
</p>
<div class="editsection" style="float:right;margin-left:5px;">[<a href="/index.php?title=BitTorrentSpecification&amp;action=edit&amp;section=31" title="Edit section: unchoke: &amp;lt;len=0001&amp;gt;&amp;lt;id=1&amp;gt;">edit</a>]</div><a name="unchoke:_.3Clen.3D0001.3E.3Cid.3D1.3E"></a><h4> unchoke: &lt;len=0001&gt;&lt;id=1&gt; </h4>
<p>The <b>unchoke</b> message is fixed-length and has no payload.
</p>
<div class="editsection" style="float:right;margin-left:5px;">[<a href="/index.php?title=BitTorrentSpecification&amp;action=edit&amp;section=32" title="Edit section: interested: &amp;lt;len=0001&amp;gt;&amp;lt;id=2&amp;gt;">edit</a>]</div><a name="interested:_.3Clen.3D0001.3E.3Cid.3D2.3E"></a><h4> interested: &lt;len=0001&gt;&lt;id=2&gt; </h4>
<p>The <b>interested</b> message is fixed-length and has no payload.
</p>
<div class="editsection" style="float:right;margin-left:5px;">[<a href="/index.php?title=BitTorrentSpecification&amp;action=edit&amp;section=33" title="Edit section: not interested: &amp;lt;len=0001&amp;gt;&amp;lt;id=3&amp;gt;">edit</a>]</div><a name="not_interested:_.3Clen.3D0001.3E.3Cid.3D3.3E"></a><h4> not interested: &lt;len=0001&gt;&lt;id=3&gt; </h4>
<p>The <b>not interested</b> message is fixed-length and has no payload.
</p>
<div class="editsection" style="float:right;margin-left:5px;">[<a href="/index.php?title=BitTorrentSpecification&amp;action=edit&amp;section=34" title="Edit section: have: &amp;lt;len=0005&amp;gt;&amp;lt;id=4&amp;gt;&amp;lt;piece index&amp;gt;">edit</a>]</div><a name="have:_.3Clen.3D0005.3E.3Cid.3D4.3E.3Cpiece_index.3E"></a><h4> have: &lt;len=0005&gt;&lt;id=4&gt;&lt;piece index&gt; </h4>
<p>The <b>have</b> message is fixed length.  The payload is the zero-based index of a piece that has just been successfully downloaded and verified via the hash.
</p><p><i>Implementer's Note: That is the strict definition, in reality some games may be played. In particular because peers are extremely unlikely to download pieces that they already have, a peer may choose not to advertise having a piece to a peer that already has that piece. At a minimum "HAVE supression" will result in a 50% reduction in the number of HAVE messages, this translates to around a 25-35% reduction in protocol overhead. At the same time, it may be worthwhile to send a HAVE message to a peer that has that piece already since it will be useful in determining which piece is rare.</i>
</p><p><i>A malicious peer might also choose to advertise having pieces that it knows the peer will never download. Due to this attempting to model peers using this information is a <b>bad idea</b></i>.
</p>
<div class="editsection" style="float:right;margin-left:5px;">[<a href="/index.php?title=BitTorrentSpecification&amp;action=edit&amp;section=35" title="Edit section: bitfield: &amp;lt;len=0001+X&amp;gt;&amp;lt;id=5&amp;gt;&amp;lt;bitfield&amp;gt;">edit</a>]</div><a name="bitfield:_.3Clen.3D0001.2BX.3E.3Cid.3D5.3E.3Cbitfield.3E"></a><h4> bitfield: &lt;len=0001+X&gt;&lt;id=5&gt;&lt;bitfield&gt; </h4>
<p>The <b>bitfield</b> message may only be sent immediately after the handshaking sequence is completed, and before any other messages are sent.  It is optional, and need not be sent if a client has no pieces.
</p><p>The <b>bitfield</b> message is variable length, where X is the length of the bitfield.  The payload is a bitfield representing the pieces that have been successfully downloaded.  The high bit in the first byte corresponds to piece index 0.  Bits that are cleared indicated a missing piece, and set bits indicate a valid and available piece.  Spare bits at the end are set to zero.
</p><p><i>A bitfield of the wrong length is considered an error. Clients should drop the connection if they receive bitfields that are not of the correct size, or if the bitfield has any of the spare bits set.</i>
</p>
<div class="editsection" style="float:right;margin-left:5px;">[<a href="/index.php?title=BitTorrentSpe