torrent/BitTorrentSpecification.html

   1 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
   2 <html lang="en" dir="ltr">
   3 <head>
   4 <title>BitTorrentSpecification - TheoryOrg</title>
   5 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
   6 <meta name="generator" content="MediaWiki 1.16.5" />
   7 </head>
   8 <body class="mediawiki ltr ns-0 ns-subject page-BitTorrentSpecification skin-monobook">
   9 <div id="globalWrapper">
  10 <div id="column-content"><div id="content" >
  11         <a id="top"></a>
  12
  13         <h1 id="firstHeading" class="firstHeading">BitTorrentSpecification</h1>
  14         <div id="bodyContent">
  15                 <h3 id="siteSub"><a href="http://wiki.theory.org/BitTorrentSpecification">From TheoryOrg</a></h3>
  16                 <!-- start content -->
  17 <p><big><big><big> <i><b>Bittorrent Protocol Specification v1.0</b></i> </big></big></big>
  18 </p>
  19 <table id="toc" class="toc"><tr><td><div id="toctitle"><h2>Contents</h2></div>
  20 <ul>
  21 <li class="toclevel-1 tocsection-1"><a href="#Identification"><span class="tocnumber">1</span> <span class="toctext">Identification</span></a></li>
  22 <li class="toclevel-1 tocsection-2"><a href="#Purpose"><span class="tocnumber">2</span> <span class="toctext">Purpose</span></a></li>
  23 <li class="toclevel-1 tocsection-3"><a href="#Scope"><span class="tocnumber">3</span> <span class="toctext">Scope</span></a></li>
  24 <li class="toclevel-1 tocsection-4"><a href="#Related_Documents"><span class="tocnumber">4</span> <span class="toctext">Related Documents</span></a></li>
  25 <li class="toclevel-1 tocsection-5"><a href="#Conventions"><span class="tocnumber">5</span> <span class="toctext">Conventions</span></a></li>
  26 <li class="toclevel-1 tocsection-6"><a href="#Bencoding"><span class="tocnumber">6</span> <span class="toctext">Bencoding</span></a>
  27 <ul>
  28 <li class="toclevel-2 tocsection-7"><a href="#Bencoded_Strings"><span class="tocnumber">6.1</span> <span class="toctext">Bencoded Strings</span></a></li>
  29 <li class="toclevel-2 tocsection-8"><a href="#Integers"><span class="tocnumber">6.2</span> <span class="toctext">Integers</span></a></li>
  30 <li class="toclevel-2 tocsection-9"><a href="#Lists"><span class="tocnumber">6.3</span> <span class="toctext">Lists</span></a></li>
  31 <li class="toclevel-2 tocsection-10"><a href="#Dictionaries"><span class="tocnumber">6.4</span> <span class="toctext">Dictionaries</span></a></li>
  32 <li class="toclevel-2 tocsection-11"><a href="#Implementations"><span class="tocnumber">6.5</span> <span class="toctext">Implementations</span></a></li>
  33 </ul>
  34 </li>
  35 <li class="toclevel-1 tocsection-12"><a href="#Metainfo_File_Structure"><span class="tocnumber">7</span> <span class="toctext">Metainfo File Structure</span></a>
  36 <ul>
  37 <li class="toclevel-2 tocsection-13"><a href="#Info_Dictionary"><span class="tocnumber">7.1</span> <span class="toctext">Info Dictionary</span></a>
  38 <ul>
  39 <li class="toclevel-3 tocsection-14"><a href="#Info_in_Single_File_Mode"><span class="tocnumber">7.1.1</span> <span class="toctext">Info in Single File Mode</span></a></li>
  40 <li class="toclevel-3 tocsection-15"><a href="#Info_in_Multiple_File_Mode"><span class="tocnumber">7.1.2</span> <span class="toctext">Info in Multiple File Mode</span></a></li>
  41 </ul>
  42 </li>
  43 <li class="toclevel-2 tocsection-16"><a href="#Notes"><span class="tocnumber">7.2</span> <span class="toctext">Notes</span></a></li>
  44 </ul>
  45 </li>
  46 <li class="toclevel-1 tocsection-17"><a href="#Tracker_HTTP.2FHTTPS_Protocol"><span class="tocnumber">8</span> <span class="toctext">Tracker HTTP/HTTPS Protocol</span></a>
  47 <ul>
  48 <li class="toclevel-2 tocsection-18"><a href="#Tracker_Request_Parameters"><span class="tocnumber">8.1</span> <span class="toctext">Tracker Request Parameters</span></a></li>
  49 <li class="toclevel-2 tocsection-19"><a href="#Tracker_Response"><span class="tocnumber">8.2</span> <span class="toctext">Tracker Response</span></a></li>
  50 </ul>
  51 </li>
  52 <li class="toclevel-1 tocsection-20"><a href="#Tracker_.27scrape.27_Convention"><span class="tocnumber">9</span> <span class="toctext">Tracker 'scrape' Convention</span></a>
  53 <ul>
  54 <li class="toclevel-2 tocsection-21"><a href="#Unofficial_extensions_to_scrape"><span class="tocnumber">9.1</span> <span class="toctext">Unofficial extensions to scrape</span></a></li>
  55 </ul>
  56 </li>
  57 <li class="toclevel-1 tocsection-22"><a href="#Peer_wire_protocol_.28TCP.29"><span class="tocnumber">10</span> <span class="toctext">Peer wire protocol (TCP)</span></a>
  58 <ul>
  59 <li class="toclevel-2 tocsection-23"><a href="#Overview"><span class="tocnumber">10.1</span> <span class="toctext">Overview</span></a></li>
  60 <li class="toclevel-2 tocsection-24"><a href="#Data_Types"><span class="tocnumber">10.2</span> <span class="toctext">Data Types</span></a></li>
  61 <li class="toclevel-2 tocsection-25"><a href="#Message_flow"><span class="tocnumber">10.3</span> <span class="toctext">Message flow</span></a></li>
  62 <li class="toclevel-2 tocsection-26"><a href="#Handshake"><span class="tocnumber">10.4</span> <span class="toctext">Handshake</span></a>
  63 <ul>
  64 <li class="toclevel-3 tocsection-27"><a href="#peer_id"><span class="tocnumber">10.4.1</span> <span class="toctext">peer_id</span></a></li>
  65 </ul>
  66 </li>
  67 <li class="toclevel-2 tocsection-28"><a href="#Messages"><span class="tocnumber">10.5</span> <span class="toctext">Messages</span></a>
  68 <ul>
  69 <li class="toclevel-3 tocsection-29"><a href="#keep-alive:_.3Clen.3D0000.3E"><span class="tocnumber">10.5.1</span> <span class="toctext">keep-alive: &lt;len=0000&gt;</span></a></li>
  70 <li class="toclevel-3 tocsection-30"><a href="#choke:_.3Clen.3D0001.3E.3Cid.3D0.3E"><span class="tocnumber">10.5.2</span> <span class="toctext">choke: &lt;len=0001&gt;&lt;id=0&gt;</span></a></li>
  71 <li class="toclevel-3 tocsection-31"><a href="#unchoke:_.3Clen.3D0001.3E.3Cid.3D1.3E"><span class="tocnumber">10.5.3</span> <span class="toctext">unchoke: &lt;len=0001&gt;&lt;id=1&gt;</span></a></li>
  72 <li class="toclevel-3 tocsection-32"><a href="#interested:_.3Clen.3D0001.3E.3Cid.3D2.3E"><span class="tocnumber">10.5.4</span> <span class="toctext">interested: &lt;len=0001&gt;&lt;id=2&gt;</span></a></li>
  73 <li class="toclevel-3 tocsection-33"><a href="#not_interested:_.3Clen.3D0001.3E.3Cid.3D3.3E"><span class="tocnumber">10.5.5</span> <span class="toctext">not interested: &lt;len=0001&gt;&lt;id=3&gt;</span></a></li>
  74 <li class="toclevel-3 tocsection-34"><a href="#have:_.3Clen.3D0005.3E.3Cid.3D4.3E.3Cpiece_index.3E"><span class="tocnumber">10.5.6</span> <span class="toctext">have: &lt;len=0005&gt;&lt;id=4&gt;&lt;piece index&gt;</span></a></li>
  75 <li class="toclevel-3 tocsection-35"><a href="#bitfield:_.3Clen.3D0001.2BX.3E.3Cid.3D5.3E.3Cbitfield.3E"><span class="tocnumber">10.5.7</span> <span class="toctext">bitfield: &lt;len=0001+X&gt;&lt;id=5&gt;&lt;bitfield&gt;</span></a></li>
  76 <li class="toclevel-3 tocsection-36"><a href="#request:_.3Clen.3D0013.3E.3Cid.3D6.3E.3Cindex.3E.3Cbegin.3E.3Clength.3E"><span class="tocnumber">10.5.8</span> <span class="toctext">request: &lt;len=0013&gt;&lt;id=6&gt;&lt;index&gt;&lt;begin&gt;&lt;length&gt;</span></a></li>
  77 <li class="toclevel-3 tocsection-37"><a href="#piece:_.3Clen.3D0009.2BX.3E.3Cid.3D7.3E.3Cindex.3E.3Cbegin.3E.3Cblock.3E"><span class="tocnumber">10.5.9</span> <span class="toctext">piece: &lt;len=0009+X&gt;&lt;id=7&gt;&lt;index&gt;&lt;begin&gt;&lt;block&gt;</span></a></li>
  78 <li class="toclevel-3 tocsection-38"><a href="#cancel:_.3Clen.3D0013.3E.3Cid.3D8.3E.3Cindex.3E.3Cbegin.3E.3Clength.3E"><span class="tocnumber">10.5.10</span> <span class="toctext">cancel: &lt;len=0013&gt;&lt;id=8&gt;&lt;index&gt;&lt;begin&gt;&lt;length&gt;</span></a></li>
  79 <li class="toclevel-3 tocsection-39"><a href="#port:_.3Clen.3D0003.3E.3Cid.3D9.3E.3Clisten-port.3E"><span class="tocnumber">10.5.11</span> <span class="toctext">port: &lt;len=0003&gt;&lt;id=9&gt;&lt;listen-port&gt;</span></a></li>
  80 </ul>
  81 </li>
  82 </ul>
  83 </li>
  84 <li class="toclevel-1 tocsection-40"><a href="#Algorithms"><span class="tocnumber">11</span> <span class="toctext">Algorithms</span></a>
  85 <ul>
  86 <li class="toclevel-2 tocsection-41"><a href="#Queuing"><span class="tocnumber">11.1</span> <span class="toctext">Queuing</span></a></li>
  87 <li class="toclevel-2 tocsection-42"><a href="#Super_Seeding"><span class="tocnumber">11.2</span> <span class="toctext">Super Seeding</span></a></li>
  88 <li class="toclevel-2 tocsection-43"><a href="#Piece_downloading_strategy"><span class="tocnumber">11.3</span> <span class="toctext">Piece downloading strategy</span></a></li>
  89 <li class="toclevel-2 tocsection-44"><a href="#End_Game"><span class="tocnumber">11.4</span> <span class="toctext">End Game</span></a></li>
  90 <li class="toclevel-2 tocsection-45"><a href="#Choking_and_Optimistic_Unchoking"><span class="tocnumber">11.5</span> <span class="toctext">Choking and Optimistic Unchoking</span></a>
  91 <ul>
  92 <li class="toclevel-3 tocsection-46"><a href="#Anti-snubbing"><span class="tocnumber">11.5.1</span> <span class="toctext">Anti-snubbing</span></a></li>
  93 </ul>
  94 </li>
  95 </ul>
  96 </li>
  97 <li class="toclevel-1 tocsection-47"><a href="#Official_Extensions_To_The_Protocol"><span class="tocnumber">12</span> <span class="toctext">Official Extensions To The Protocol</span></a>
  98 <ul>
  99 <li class="toclevel-2 tocsection-48"><a href="#Fast_Peers_Extensions"><span class="tocnumber">12.1</span> <span class="toctext">Fast Peers Extensions</span></a></li>
 100 <li class="toclevel-2 tocsection-49"><a href="#Distributed_Hash_Table"><span class="tocnumber">12.2</span> <span class="toctext">Distributed Hash Table</span></a></li>
 101 <li class="toclevel-2 tocsection-50"><a href="#Connection_Obfuscation"><span class="tocnumber">12.3</span> <span class="toctext">Connection Obfuscation</span></a></li>
 102 </ul>
 103 </li>
 104 <li class="toclevel-1 tocsection-51"><a href="#Unofficial_Extensions_To_The_Protocol"><span class="tocnumber">13</span> <span class="toctext">Unofficial Extensions To The Protocol</span></a>
 105 <ul>
 106 <li class="toclevel-2 tocsection-52"><a href="#Azureus_Messaging_Protocol"><span class="tocnumber">13.1</span> <span class="toctext">Azureus Messaging Protocol</span></a></li>
 107 <li class="toclevel-2 tocsection-53"><a href="#WebSeeding"><span class="tocnumber">13.2</span> <span class="toctext">WebSeeding</span></a></li>
 108 <li class="toclevel-2 tocsection-54"><a href="#Extension_protocol"><span class="tocnumber">13.3</span> <span class="toctext">Extension protocol</span></a></li>
 109 <li class="toclevel-2 tocsection-55"><a href="#Extension_Negotiation_Protocol"><span class="tocnumber">13.4</span> <span class="toctext">Extension Negotiation Protocol</span></a></li>
 110 <li class="toclevel-2 tocsection-56"><a href="#BitTorrent_Location-aware_Protocol_1.0"><span class="tocnumber">13.5</span> <span class="toctext">BitTorrent Location-aware Protocol 1.0</span></a></li>
 111 <li class="toclevel-2 tocsection-57"><a href="#SimpleBT_Extension_Protocol"><span class="tocnumber">13.6</span> <span class="toctext">SimpleBT Extension Protocol</span></a></li>
 112 <li class="toclevel-2 tocsection-58"><a href="#BitComet_Extension_Protocol"><span class="tocnumber">13.7</span> <span class="toctext">BitComet Extension Protocol</span></a></li>
 113 </ul>
 114 </li>
 115 <li class="toclevel-1 tocsection-59"><a href="#Reserved_Bytes"><span class="tocnumber">14</span> <span class="toctext">Reserved Bytes</span></a></li>
 116 <li class="toclevel-1 tocsection-60"><a href="#Change_Log"><span class="tocnumber">15</span> <span class="toctext">Change Log</span></a></li>
 117 <li class="toclevel-1 tocsection-61"><a href="#Related_Links"><span class="tocnumber">16</span> <span class="toctext">Related Links</span></a></li>
 118 </ul>
 119 </td></tr></table><script>if (window.showTocToggle) { var tocShowText = "show"; var tocHideText = "hide"; showTocToggle(); } </script>
 120 <h2> <span class="mw-headline" id="Identification"> Identification </span></h2>
 121 <p><a href="/index.php?title=BitTorrent&amp;action=edit&amp;redlink=1" class="new" title="BitTorrent (page does not exist)">BitTorrent</a> is a peer-to-peer file sharing protocol designed by Bram Cohen.  Visit his pages at <a href="http://www.bittorrent.com" class="external free" rel="nofollow">http://www.bittorrent.com</a> BitTorrent is designed to facilitate file transfers among multiple peers across unreliable networks.
 122 </p>
 123 <h2> <span class="mw-headline" id="Purpose"> Purpose </span></h2>
 124 <p>The purpose of this specification is to document version 1.0 of the BitTorrent protocol specification in detail.  Bram's  <a href="http://bittorrent.org/beps/bep_0003.html" class="external text" rel="nofollow">protocol specification page</a> outlines the protocol in somewhat general terms, and lacks behaviorial detail in some areas.  The hope is that this document will become a <b>formal</b> specification, written in clear, unambiguous terms, which can be used as a basis for discussion and implementation in the future.
 125 </p><p>This document is intended to be maintained and used by the BitTorrent development community.  Everyone is invited to contribute to this document, with the understanding that the content here is intended to represent the current protocol (What if the current protocol is 2.0? The scope is then conflicting), which is already deployed in a number of existing client implementations.
 126 </p><p>This is not the place to suggest feature requests.  For that, please go to the <a href="http://lists.ibiblio.org/mailman/listinfo/bittorrent" class="external text" rel="nofollow">mailing list</a>.
 127 </p>
 128 <h2> <span class="mw-headline" id="Scope"> Scope </span></h2>
 129 <p>This document applies to the first version (i.e. version 1.0) of the BitTorrent protocol specification. Currently, this applies to the torrent file structure, peer wire protocol, and the Tracker HTTP/HTTPS protocol specifications. As newer revisions of each protocol are defined, they should be specified on their own separate pages, <b>not here</b>.
 130 </p>
 131 <h2> <span class="mw-headline" id="Related_Documents"> Related Documents </span></h2>
 132 <ul><li> <a href="http://bittorrent.org/beps/bep_0003.html" class="external text" rel="nofollow">Official protocol specification</a>
 133 </li><li> <a href="/BitTorrentWishList" title="BitTorrentWishList">Developer and user wishlist</a>
 134 </li><li> <a href="/BitTorrentTrackerExtensions" title="BitTorrentTrackerExtensions">Tracker protocol extensions</a>
 135 </li></ul>
 136 <h2> <span class="mw-headline" id="Conventions"> Conventions </span></h2>
 137 <p>In this document, a number of conventions are used in an attempt to present information in a concise and unambiguous fashion.
 138 </p>
 139 <ul><li> <i>peer</i> v/s <i>client</i>: In this document, a <i>peer</i> is any BitTorrent client participating in a download.  The <i>client</i> is also a peer, however it is the BitTorrent client that is running on the local machine.  Readers of this specification may choose to think of themselves as the <i>client</i> which connects to numerous <i>peers</i>.
 140 </li><li> <i>piece</i> v/s <i>block</i>: In this document, a <i>piece</i> refers to a portion of the downloaded data that is described in the metainfo file, which can be verified by a SHA1 hash.  A <i>block</i> is a portion of data that a <i>client</i> may request from at least one <i>peer</i>.  Two or more <i>blocks</i> make up a whole <i>piece</i>, which may then be verified.
 141 </li><li> <i>defacto standard</i>: Large blocks of text in <i>italics</i> indicates a practice so common in various client implementations of BitTorrent that it is considered a defacto standard.
 142 </li></ul>
 143 <p>In order to help others find recent changes that have been made to this document, please fill out the change log (last section).  This should contain a brief (i.e. one-line) entry for each major change that you've made to the document.
 144 </p>
 145 <h2> <span class="mw-headline" id="Bencoding"> Bencoding </span></h2>
 146 <p>Bencoding is a way to specify and organize data in a terse format.  It supports the following types: byte strings, integers, lists, and dictionaries.
 147 </p>
 148 <h3> <span class="mw-headline" id="Bencoded_Strings"> Bencoded Strings </span></h3>
 149 <p>Bencoded strings are encoded as follows: <i>&lt;string length encoded in base ten ASCII&gt;<b>:</b>&lt;string data&gt;</i>, or <i>key</i>:<i>value</i><br />
 150 Note that there is no constant beginning delimiter, and no ending delimiter.
 151 </p>
 152 <dl><dd><b>Example</b>: <i>4<b>:</b>spam</i> represents the string "spam"
 153 </dd></dl>
 154 <h3> <span class="mw-headline" id="Integers"> Integers </span></h3>
 155 <p>Integers are encoded as follows: <i><b>i</b>&lt;integer encoded in base ten ASCII&gt;<b>e</b></i><br />
 156 The initial <b>i</b> and trailing <b>e</b> are beginning and ending delimiters. You can have negative numbers such as <i><b>i</b>-3<b>e</b></i>. Only the significant digits should be used, one cannot pad the Integer with zeroes. such as <i><b>i</b>04<b>e</b></i>.  However, <i><b>i</b>0<b>e</b></i> is valid.
 157 </p>
 158 <dl><dd><b>Example</b>: <i><b>i</b>3<b>e</b></i> represents the integer "3"
 159 </dd></dl>
 160 <ul><li> <i>NOTE:</i> The maximum number of bit of this integer is unspecified, but to handle it as a signed 64bit integer is mandatory to handle "large files" aka .torrent for more that 4Gbyte.
 161 </li></ul>
 162 <h3> <span class="mw-headline" id="Lists"> Lists </span></h3>
 163 <p>Lists are encoded as follows: <i><b>l</b>&lt;bencoded values&gt;<b>e</b></i><br />
 164 The initial <b>l</b> and trailing <b>e</b> are beginning and ending delimiters. Lists may contain any bencoded type, including integers, strings, dictionaries, and even lists within other lists.
 165 </p>
 166 <dl><dd><b>Example:</b> <i><b>l</b>4:spam4:eggs<b>e</b></i> represents the list of two strings: [ "spam", "eggs" ]
 167 </dd></dl>
 168 <h3> <span class="mw-headline" id="Dictionaries"> Dictionaries </span></h3>
 169 <p>Dictionaries are encoded as follows: <i><b>d</b>&lt;bencoded string&gt;&lt;bencoded element&gt;<b>e</b></i> <br />
 170 The initial <b>d</b> and trailing <b>e</b> are the beginning and ending delimiters. Note that the keys must be bencoded strings.  The values may be any bencoded type, including integers, strings, lists, and other dictionaries.  Keys must be strings and appear in sorted order (sorted as raw strings, not alphanumerics). The strings should be compared using a binary  comparison, not a culture-specific "natural" comparison.
 171 </p>
 172 <dl><dd><b>Example</b>: <i><b>d</b>3:cow3:moo4:spam4:eggs<b>e</b> represents the dictionary { &quot;cow&quot; =&gt; &quot;moo&quot;, &quot;spam&quot; =&gt; &quot;eggs&quot; } <br /></i>
 173 </dd><dd><b>Example</b>: <i><b>d</b>4:spaml1:a1:b<b>ee'</b> represents the dictionary { &quot;spam&quot; =&gt; [ &quot;a&quot;, &quot;b&quot; ] } <br /></i>
 174 </dd><dd><b>Example</b>: <i><b>d</b>9:publisher3:bob17:publisher-webpage15:www.example.com18:publisher.location4:home<b>e</b></i> represents { &quot;publisher&quot; =&gt; &quot;bob&quot;, &quot;publisher-webpage&quot; =&gt; &quot;www.example.com&quot;, &quot;publisher.location&quot; =&gt; &quot;home&quot; }
 175 </dd></dl>
 176 <h3> <span class="mw-headline" id="Implementations"> Implementations </span></h3>
 177 <ul><li> <a href="http://funzix.git.sourceforge.net/git/gitweb.cgi?p=funzix/funzix;a=blob;f=bencode/bencode.c" class="external text" rel="nofollow">C</a> by <a href="/index.php?title=User:Vapier&amp;action=edit&amp;redlink=1" class="new" title="User:Vapier (page does not exist)">Mike Frysinger</a>
 178 </li><li> <a href="http://search.cpan.org/dist/Convert-Bencode/lib/Convert/Bencode.pm" class="external text" rel="nofollow">Perl</a>
 179 </li><li> <a href="http://www.koders.com/java/fid47111A56F2466C232E09AEF75A39915EC70D3536.aspx#L52" class="external text" rel="nofollow">Java</a>
 180 </li><li> <a href="/Decoding_bencoded_data_with_python" title="Decoding bencoded data with python">Python</a> by <a href="/index.php?title=User:Hackeron&amp;action=edit&amp;redlink=1" class="new" title="User:Hackeron (page does not exist)">Hackeron</a>
 181 </li><li> <a href="/Decoding_encoding_bencoded_data_with_haskell" title="Decoding encoding bencoded data with haskell">Decoding encoding bencoded data with haskell</a> by <a href="/index.php?title=User:Edi&amp;action=edit&amp;redlink=1" class="new" title="User:Edi (page does not exist)">Edi</a>
 182 </li><li> <a href="http://www.stupendous.net/projects/bencoding-obj-c-class/" class="external text" rel="nofollow">Objective-C</a> by <a href="/index.php?title=User:Chrome&amp;action=edit&amp;redlink=1" class="new" title="User:Chrome (page does not exist)">Chrome</a>
 183 </li><li> <a href="/JScript:_Converting_a_torrent_file_to_a_JScript_dictionary" title="JScript: Converting a torrent file to a JScript dictionary">JScript</a> by <a href="/index.php?title=User:Sergej_B.&amp;action=edit&amp;redlink=1" class="new" title="User:Sergej B. (page does not exist)">Sergej B.</a>
 184 </li><li> <a href="http://demon.tw/my-work/javascript-bencode.html" class="external text" rel="nofollow">JavaScript</a> by <a href="http://demon.tw" class="external text" rel="nofollow">Demon</a>]
 185 </li><li> <a href="http://demon.tw/my-work/vbs-bencode.html" class="external text" rel="nofollow">VBScript</a> by <a href="http://demon.tw" class="external text" rel="nofollow">Demon</a>]
 186 </li><li> <a href="http://nakkaya.com/2009/11/02/decoding-bencoded-streams-in-clojure/" class="external text" rel="nofollow">Clojure</a> by <a href="/index.php?title=User:Nakkaya&amp;action=edit&amp;redlink=1" class="new" title="User:Nakkaya (page does not exist)">nakkaya</a>
 187 </li><li> <a href="/Decoding_encoding_bencoded_data_with_erlang" title="Decoding encoding bencoded data with erlang">Erlang</a>
 188 </li><li> <a href="/Decoding_encoding_bencoded_data_with_PHP" title="Decoding encoding bencoded data with PHP">PHP</a>
 189 </li><li> <a href="http://code.google.com/p/php-bencode-extension/" class="external text" rel="nofollow">PHP Extension</a>
 190 </li><li> <a href="http://snipplr.com/view/37790/bencoding-encoder-and-decoder/" class="external text" rel="nofollow">C#</a> by <a href="/index.php?title=User:SuprDewd&amp;action=edit&amp;redlink=1" class="new" title="User:SuprDewd (page does not exist)">SuprDewd</a>
 191 </li><li> <a href="http://cvs.savannah.gnu.org/viewvc/mldonkey/mldonkey/src/networks/bittorrent/bencode.ml?view=markup" class="external text" rel="nofollow">OCaml</a> by <a href="http://mldonkey.sourceforge.net/Main_Page" class="external text" rel="nofollow">MLDonkey</a>
 192 </li><li> <a href="https://github.com/jsz/gorrent/tree/master/bencode" class="external text" rel="nofollow">Go</a> by <a href="http://jsz.github.com/" class="external text" rel="nofollow">Leon Szpilewski</a>
 193 </li></ul>
 194 <h2> <span class="mw-headline" id="Metainfo_File_Structure"> Metainfo File Structure </span></h2>
 195 <p>All data in a metainfo file is bencoded.  The specification for bencoding is defined above.
 196 </p><p>The content of a metainfo file (the file ending in ".torrent") is a bencoded dictionary, containing the keys listed below. All character string values are UTF-8 encoded.
 197 </p>
 198 <ul><li> <b>info</b>: a dictionary that describes the file(s) of the torrent.  There are two possible forms: one for the case of a 'single-file' torrent with no directory structure, and one for the case of a 'multi-file' torrent (see below for details)
 199 </li><li> <b>announce</b>: The announce URL of the tracker (string)
 200 </li><li> <b>announce-list</b>: (optional) this is an extention to the official specification, offering backwards-compatibility.  (list of lists of strings).
 201 <ul><li>The official request for a specification change is <a href="http://bittorrent.org/beps/bep_0012.html" class="external text" rel="nofollow">here</a>.
 202 </li></ul>
 203 </li><li> <b>creation date</b>: (optional) the creation time of the torrent, in standard UNIX epoch format (integer, seconds since 1-Jan-1970 00:00:00 UTC)
 204 </li><li> <b>comment</b>: (optional) free-form textual comments of the author (string)
 205 </li><li> <b>created by</b>: (optional) name and version of the program used to create the .torrent (string)
 206 </li><li> <b>encoding</b>: (optional) the string encoding format used to generate the <b>pieces</b> part of the <b>info</b> dictionary in the .torrent metafile (string)
 207 </li></ul>
 208 <h3> <span class="mw-headline" id="Info_Dictionary">Info Dictionary</span></h3>
 209 <p>This section contains the field which are common to both mode, "single file" and "multiple file".
 210 </p>
 211 <ul><li> <b>piece length</b>: number of bytes in each piece (integer)
 212 </li><li> <b>pieces</b>: string consisting of the concatenation of all 20-byte SHA1 hash values, one per piece (byte string, i.e. not urlencoded)
 213 </li><li> <b>private</b>: (optional) this field is an integer. If it is set to "1", the client MUST publish its presence to get other peers ONLY via the trackers explicitly described in the metainfo file. If this field is set to "0" or is not present, the client may obtain peer from other means, e.g. PEX peer exchange, dht. Here, "private" may be read as "no external peer source".
 214 <ul><li> <b>NOTE:</b> There is much debate surrounding private trackers.
 215 </li><li> The official request for a specification change is <a href="http://bittorrent.org/beps/bep_0027.html" class="external text" rel="nofollow">here</a>.
 216 </li><li> Azureus was the first client to respect private trackers, <a href="http://www.azureuswiki.com/index.php/Secure_Torrents" class="external text" rel="nofollow">see their wiki</a> for more details.
 217 </li></ul>
 218 </li></ul>
 219 <h4> <span class="mw-headline" id="Info_in_Single_File_Mode">Info in Single File Mode</span></h4>
 220 <p>For the case of the <b>single-file</b> mode, the <b>info</b> dictionary contains the following structure:
 221 </p>
 222 <ul><li> <b>name</b>: the filename.  This is purely advisory. (string)
 223 </li><li> <b>length</b>: length of the file in bytes (integer)
 224 </li><li> <b>md5sum</b>: (optional) a 32-character hexadecimal string corresponding to the MD5 sum of the file.  This is not used by BitTorrent at all, but it is included by some programs for greater compatibility.
 225 </li></ul>
 226 <h4> <span class="mw-headline" id="Info_in_Multiple_File_Mode">Info in Multiple File Mode</span></h4>
 227 <p>For the case of the <b>multi-file</b> mode, the <b>info</b> dictionary contains the following structure:
 228 </p>
 229 <ul><li> <b>name</b>: the file path of the directory in which to store all the files.  This is purely advisory. (string)
 230 </li><li> <b>files</b>: a list of dictionaries, one for each file. Each dictionary in this list contains the following keys:
 231 <ul><li> <b>length</b>: length of the file in bytes (integer)
 232 </li><li> <b>md5sum</b>: (optional) a 32-character hexadecimal string corresponding to the MD5 sum of the file.  This is not used by BitTorrent at all, but it is included by some programs for greater compatibility.
 233 </li><li> <b>path</b>: a list containing one or more string elements that together represent the path and filename.  Each element in the list corresponds to either a directory name or (in the case of the final element) the filename.  For example, a the file "dir1/dir2/file.ext" would consist of three string elements: "dir1", "dir2", and "file.ext".  This is encoded as a bencoded list of strings such as <i>l<b>4</b>:dir1<b>4</b>:dir2<b>8</b>:file.ext<b>e</b></i>
 234 </li></ul>
 235 </li></ul>
 236 <h3> <span class="mw-headline" id="Notes">Notes</span></h3>
 237 <ul><li> The <b>piece length</b> specifies the nominal piece size, and is usually a power of 2.  The piece size is typically chosen based on the total amount of file data in the torrent, and is constrained by the fact that too-large piece sizes cause inefficiency, and too-small piece sizes cause large .torrent metadata file.  Historically, piece size was chosen to result in a .torrent file no greater than approx. 50 - 75 kB (presumably to ease the load on the server hosting the torrent files).
 238 <ul><li>Current best-practice is to <i>keep the piece size to 512KB or less,</i> for torrents around 8-10GB, even if that results in a larger .torrent file.  This results in a more efficient swarm for sharing files.   The most common sizes are 256 kB, 512 kB, and 1 MB.
 239 </li><li>Every piece is of equal length except for the final piece, which is irregular.  The number of pieces is thus determined by 'ceil( total length / piece size )'.
 240 </li><li>For the purposes of piece boundaries in the multi-file case, consider the file data as one long continuous stream, composed of the concatenation of each file in the order listed in the <i>files</i> list.  The number of pieces and their boundaries are then determined in the same manner as the case of a single file.  Pieces may overlap file boundaries.
 241 </li></ul>
 242 </li><li> Each piece has a corresponding SHA1 hash of the data contained within that piece.  These hashes are concatenated to form the <i>pieces<b> value in the above </b></i><b>info</b> dictionary.  Note that this is <b>not</b> a list but rather a single string. The length of the string must be a multiple of 20.
 243 </li></ul>
 244 <h2> <span class="mw-headline" id="Tracker_HTTP.2FHTTPS_Protocol"> Tracker HTTP/HTTPS Protocol </span></h2>
 245 <p>The tracker is an HTTP/HTTPS service which responds to HTTP GET requests. The requests include metrics from clients that help the tracker keep overall statistics about the torrent. The response includes a peer list that helps the client participate in the torrent. The base URL consists of the "announce URL" as defined in the metainfo (.torrent) file.  The parameters are then added to this URL, using standard CGI methods (i.e. a '?' after the announce URL, followed by 'param=value' sequences separated by '&amp;').
 246 </p><p>Note that all binary data in the URL (particularly info_hash and peer_id) must be properly escaped.  This means any byte not in the set 0-9, a-z, A-Z, '.', '-', '_' and '~', must be encoded using the "%nn" format, where nn is the hexadecimal value of the byte. (See <a href="http://www.faqs.org/rfcs/rfc1738.html" class="external text" rel="nofollow">RFC1738</a> for details.)
 247 </p><p>For a 20-byte hash of \x12\x34\x56\x78\x9a\xbc\xde\xf1\x23\x45\x67\x89\xab\xcd\xef\x12\x34\x56\x78\x9a,<br />
 248 The right encoded form is&nbsp;%124Vx%9A%BC%DE%F1%23Eg%89%AB%CD%EF%124Vx%9A
 249 </p>
 250 <h3> <span class="mw-headline" id="Tracker_Request_Parameters">Tracker Request Parameters</span></h3>
 251 <p>The parameters used in the client-&gt;tracker GET request are as follows:
 252 </p>
 253 <ul><li> <b>info_hash</b>: urlencoded 20-byte SHA1 hash of the <i>value</i> of the <i>info</i> key from the Metainfo file.  Note that the <i>value</i> will be a bencoded dictionary, given the definition of the <i>info</i> key above.
 254 </li><li> <b><a href="#peer_id">peer_id</a></b>: urlencoded 20-byte string used as a unique ID for the client, generated by the client at startup.  This is allowed to be any value, and may be binary data.  <i>There are currently no guidelines for generating this peer ID.  However, one may rightly presume that it must at least be unique for your local machine, thus should probably incorporate things like process ID and perhaps a timestamp recorded at startup. See <a href="#peer_id">peer_id </a> below for common client encodings of this field.</i>
 255 </li><li> <b>port</b>: The port number that the client is listening on.  Ports reserved for BitTorrent are typically 6881-6889.  Clients may choose to give up if it cannot establish a port within this range.
 256 </li><li> <b>uploaded</b>: The total amount uploaded (since the client sent the 'started' event to the tracker) in base ten ASCII.  While not explicitly stated in the official specification, the concensus is that this should be the total number of bytes uploaded.
 257 </li><li> <b>downloaded</b>: The total amount downloaded (since the client sent the 'started' event to the tracker) in base ten ASCII.  While not explicitly stated in the official specification, the consensus is that this should be the total number of bytes downloaded.
 258 </li><li> <b>left</b>: The number of bytes this client still has to download in base ten ASCII.
 259 </li><li> <b>compact</b>: Setting this to 1 indicates that the client accepts a compact response. The announce-list is replaced by a peers string with 6 bytes per peer. The first four bytes are the host (in network byte order), the last two bytes are the port (again in network byte order). It should be noted that some trackers only support compact responses (for saving bandwidth) and either refuse requests without "compact=1" or simply send a compact response unless the request contains "compact=0" (in which case they will refuse the request.)
 260 </li><li> <b>no_peer_id</b>: Indicates that the tracker can omit peer id field in announce-list dictionary. This option is ignored if compact is enabled.
 261 </li><li> <b>event</b>: If specified, must be one of <i>started</i>, <i>completed</i>, <i>stopped</i>, (or empty which is the same as not being specified).  If not specified, then this request is one performed at regular intervals.
 262 <ul><li> <b>started</b>: The first request to the tracker <i>must</i> include the event key with this value.
 263 </li><li> <b>stopped</b>: Must be sent to the tracker if the client is shutting down gracefully.
 264 </li><li> <b>completed</b>: Must be sent to the tracker when the download completes.  However, must not be sent if the download was already 100% complete when the client started.  Presumably, this is to allow the tracker to increment the "completed downloads" metric based solely on this event.
 265 </li></ul>
 266 </li><li> <b>ip</b>: Optional.  The true IP address of the client machine, in dotted quad format or rfc3513 defined hexed IPv6 address.  <i>Notes: In general this parameter is not necessary as the address of the client can be determined from the IP address from which the HTTP request came.  The parameter is only needed in the case where the IP address that the request came in on is not the IP address of the client.  This happens if the client is communicating to the tracker through a proxy (or a transparent web proxy/cache.)  It also is necessary when both the client and the tracker are on the same local side of a NAT gateway.  The reason for this is that otherwise the tracker would give out the internal (RFC1918) address of the client, which is not routable.  Therefore the client must explicitly state its (external, routable) IP address to be given out to external peers.  Various trackers treat this parameter differently.  Some only honor it only if the IP address that the request came in on is in RFC1918 space.  Others honor it unconditionally, while others ignore it completely. In case of IPv6 address (e.g.: 2001:db8:1:2::100) it indicates only that client can communicate via IPv6.</i>
 267 </li><li> <b>numwant</b>: Optional.  Number of peers that the client would like to receive from the tracker.  This value is permitted to be zero.  If omitted, typically defaults to 50 peers.
 268 </li><li> <b>key</b>: Optional. An additional client identification mechanism that is not shared with any peers. It is intended to allow a client to prove their identity should their IP address change.
 269 </li><li> <b>trackerid</b>: Optional. If a previous announce contained a tracker id, it should be set here.
 270 </li></ul>
 271 <h3> <span class="mw-headline" id="Tracker_Response">Tracker Response</span></h3>
 272 <p>The tracker responds with "text/plain" document consisting of a bencoded dictionary with the following keys:
 273 </p>
 274 <ul><li> <b>failure reason</b>: If present, then no other keys may be present.  The value is a human-readable error message as to why the request failed (string).
 275 </li><li> <b>warning message</b>: (new, optional) Similar to failure reason, but the response still gets processed normally. The warning message is shown just like an error.
 276 </li><li> <b>interval</b>: Interval in seconds that the client should wait between sending regular requests to the tracker
 277 </li><li> <b>min interval</b>: (optional) Minimum announce interval. If present clients must not reannounce more frequently than this.
 278 </li><li> <b>tracker id</b>: A string that the client should send back on its next announcements. If absent and a previous announce sent a tracker id, do not discard the old value; keep using it.
 279 </li><li> <b>complete</b>: number of peers with the entire file, i.e. seeders (integer)
 280 </li><li> <b>incomplete</b>: number of non-seeder peers, aka "leechers" (integer)
 281 </li><li> <b>peers</b>: (dictionary model) The value is a list of dictionaries, each with the following keys:
 282 <ul><li> <b>peer id</b>: peer's self-selected ID, as described above for the tracker request (string)
 283 </li><li> <b>ip</b>: peer's IP address either IPv6 (hexed) or IPv4 (dotted quad) or DNS name (string)
 284 </li><li> <b>port</b>: peer's port number (integer)
 285 </li></ul>
 286 </li><li> <b>peers</b>: (binary model) Instead of using the dictionary model described above, the <b>peers</b> value may be a string consisting of multiples of 6 bytes. First 4 bytes are the IP address and last 2 bytes are the port number. All in network (big endian) notation.
 287 </li></ul>
 288 <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>
 289 </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.
 290 </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>
 291 </p>
 292 <h2> <span class="mw-headline" id="Tracker_.27scrape.27_Convention"> Tracker 'scrape' Convention </span></h2>
 293 <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.
 294 </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.
 295 </p><p>Examples: (announce URL -&gt; scrape URL)
 296 </p>
 297 <pre>
 298   ~http://example.com/announce          -&gt; ~http://example.com/scrape
 299   ~http://example.com/x/announce        -&gt; ~http://example.com/x/scrape
 300   ~http://example.com/announce.php      -&gt; ~http://example.com/scrape.php
 301   ~http://example.com/a                 -&gt; (scrape not supported)
 302   ~http://example.com/announce?x2%0644 -&gt; ~http://example.com/scrape?x2%0644
 303   ~http://example.com/announce?x=2/4    -&gt; (scrape not supported)
 304   ~http://example.com/x%064announce     -&gt; (scrape not supported)
 305 </pre>
 306 <p>Note especially that entity unquoting is <i>not</i> to be done.  This standard is documented by Bram in the <a href="/index.php?title=BitTorrent&amp;action=edit&amp;redlink=1" class="new" title="BitTorrent (page does not exist)">BitTorrent</a> development list archive: <a href="http://groups.yahoo.com/group/BitTorrent/message/3275" class="external free" rel="nofollow">http://groups.yahoo.com/group/BitTorrent/message/3275</a>
 307 </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.
 308 </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:
 309 </p>
 310 <pre>
 311  http://example.com/scrape.php?info_hash=aaaaaaaaaaaaaaaaaaaa&amp;info_hash=bbbbbbbbbbbbbbbbbbbb&amp;info_hash=cccccccccccccccccccc
 312 </pre>
 313 <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:
 314 </p>
 315 <ul><li> <b>files</b>: a dictionary containing one key/value pair for each torrent for which there are stats.  If <i>info_hash</i> was supplied and was valid, this dictionary will contain a single key/value.  Each key consists of a 20-byte binary <i>info_hash</i>.  The value of each entry is another dictionary containing the following:
 316 <ul><li> <b>complete</b>: number of peers with the entire file, i.e. seeders (integer)
 317 </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)
 318 </li><li> <b>incomplete</b>: number of non-seeder peers, aka "leechers" (integer)
 319 </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
 320 </li></ul>
 321 </li></ul>
 322 <p>Note that this response has three levels of dictionary nesting.  Here's an example:
 323 </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>
 324 </p><p>Where <tt>....................</tt> is the 20 byte info_hash and there are 5 seeders, 10 leechers, and 50 complete downloads.
 325 </p>
 326 <h3> <span class="mw-headline" id="Unofficial_extensions_to_scrape"> Unofficial extensions to scrape </span></h3>
 327 <p>Below are the response keys are being unofficially used.  Since they are unofficial, they are all optional.
 328 </p>
 329 <ul><li> <b>failure reason</b>: Human-readable error message as to why the request failed (string).  Clients known to handle this key: Azureus.
 330 </li><li> <b>flags</b>: a dictionary containing miscellaneous flags.  The value of the flags key is another nested dictionary, possibly containing the following:
 331 <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.
 332 </li></ul>
 333 </li></ul>
 334 <h2> <span class="mw-headline" id="Peer_wire_protocol_.28TCP.29"> Peer wire protocol (TCP) </span></h2>
 335 <h3> <span class="mw-headline" id="Overview"> Overview </span></h3>
 336 <p>The peer protocol facilitates the exchange of pieces as described in the '<i>metainfo</i> file.
 337 </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>
 338 </p><p>A client must maintain state information for each connection that it has with a remote peer:
 339 </p>
 340 <ul><li> <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.
 341 </li><li> <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.
 342 </li></ul>
 343 <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>
 344 </p>
 345 <ul><li> <b>am_choking</b>: this client is choking the peer
 346 </li><li> <b>am_interested</b>: this client is interested in the peer
 347 </li><li> <b>peer_choking</b>: peer is choking this client
 348 </li><li> <b>peer_interested</b>: peer is interested in this client
 349 </li></ul>
 350 <p>Client connections start out as "choked" and "not interested".  In other words:
 351 </p>
 352 <ul><li> <b>am_choking</b> = 1
 353 </li><li> <b>am_interested</b> = 0
 354 </li><li> <b>peer_choking</b> = 1
 355 </li><li> <b>peer_interested</b> = 0
 356 </li></ul>
 357 <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.
 358 </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).
 359 </p>
 360 <h3> <span class="mw-headline" id="Data_Types"> Data Types </span></h3>
 361 <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.
 362 </p>
 363 <h3> <span class="mw-headline" id="Message_flow"> Message flow </span></h3>
 364 <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.
 365 </p>
 366 <h3> <span class="mw-headline" id="Handshake"> Handshake </span></h3>
 367 <p>The handshake is a required message and must be the first message transmitted by the client. It is (49+len(pstr)) bytes long.
 368 </p><p><i>handshake: &lt;pstrlen&gt;&lt;pstr&gt;&lt;reserved&gt;&lt;info_hash&gt;&lt;peer_id&gt;</i>
 369 </p>
 370 <ul><li> <b>pstrlen</b>: string length of &lt;pstr&gt;, as a single raw byte
 371 </li><li> <b>pstr</b>: string identifier of the protocol
 372 </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>
 373 </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.
 374 </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).
 375 </li></ul>
 376 <p>In version 1.0 of the BitTorrent protocol, pstrlen = 19, and pstr = "BitTorrent protocol".
 377 </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 peer id will presumably be sent after the recipient sends its own handshake).  The tracker's NAT-checking feature does not send the peer_id field of the handshake.</i>
 378 </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.
 379 </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.
 380 </p>
 381 <h4> <span class="mw-headline" id="peer_id"> peer_id </span></h4>
 382 <p>The peer_id is exactly 20 bytes (characters) long.
 383 </p><p>There are mainly two conventions how to encode client and client version information into the peer_id, Azureus-style and Shadow's-style.
 384 </p><p>Azureus-style uses the following encoding:
 385 '-', two characters for client id, four ascii digits for version number, '-', followed by random numbers.
 386 </p><p>For example: '-AZ2060-'...
 387 </p><p>known clients that uses this encoding style are:
 388 </p>
 389 <ul><li> 'AG' - <a href="http://aresgalaxy.sourceforge.net/" class="external text" rel="nofollow">Ares</a>
 390 </li><li> 'A~' - <a href="http://aresgalaxy.sourceforge.net/" class="external text" rel="nofollow">Ares</a>
 391 </li><li> 'AR' - <a href="http://dev.int64.org/arctic.html" class="external text" rel="nofollow">Arctic</a>
 392 </li><li> 'AT' - <a href="http://www.cyberartemis.com" class="external text" rel="nofollow">Artemis</a>
 393 </li><li> 'AX' - <a href="http://www.analogx.com/contents/download/network/bitpump.htm" class="external text" rel="nofollow">BitPump</a>
 394 </li><li> 'AZ' - <a href="http://azureus.sf.net" class="external text" rel="nofollow">Azureus</a>
 395 </li><li> 'BB' - <a href="http://www.btvampire.com" class="external text" rel="nofollow">BitBuddy</a>
 396 </li><li> 'BC' - <a href="http://www.bitcomet.com" class="external text" rel="nofollow">BitComet</a>
 397 </li><li> 'BF' - <a href="http://bitflu.workaround.ch/" class="external text" rel="nofollow">Bitflu</a>
 398 </li><li> 'BG' - <a href="http://btg.berlios.de/" class="external text" rel="nofollow">BTG (uses Rasterbar libtorrent)</a>
 399 </li><li> 'BL' - <a href="http://www.bitblinder.com" class="external text" rel="nofollow">BitBlinder</a>
 400 </li><li> 'BP' - <a href="http://www.intelpeers.com" class="external text" rel="nofollow">BitTorrent Pro (Azureus + spyware)</a>
 401 </li><li> 'BR' - <a href="http://www.bitrocket.org" class="external text" rel="nofollow">BitRocket</a>
 402 </li><li> 'BS' - <a href="http://btslave.sourceforge.net" class="external text" rel="nofollow">BTSlave</a>
 403 </li><li> 'BW' - <a href="http://bitwombat.com" class="external text" rel="nofollow">BitWombat</a>
 404 </li><li> 'BX' - ~Bittorrent X
 405 </li><li> 'CD' - <a href="http://www.rahul.net/dholmes/ctorrent/" class="external text" rel="nofollow">Enhanced CTorrent</a>
 406 </li><li> 'CT' - <a href="http://ctorrent.sourceforge.net" class="external text" rel="nofollow">CTorrent</a>
 407 </li><li> 'DE' - <a href="http://www.deluge-torrent.org" class="external text" rel="nofollow">DelugeTorrent</a>
 408 </li><li> 'DP' - <a href="http://www.propagatedata.com/" class="external text" rel="nofollow">Propagate Data Client</a>
 409 </li><li> 'EB' - <a href="http://dywt.com.cn/" class="external text" rel="nofollow">EBit</a>
 410 </li><li> 'ES' - <a href="http://electricsheep.org" class="external text" rel="nofollow">electric sheep</a>
 411 </li><li> 'FC' - <a href="http://www.filecroc.com" class="external text" rel="nofollow">FileCroc</a>
 412 </li><li> 'FT' - <a href="http://www.foxtorrent.com" class="external text" rel="nofollow">FoxTorrent</a>
 413 </li><li> 'GS' - <a href="http://sourceforge.net/projects/gstorrent" class="external text" rel="nofollow">GSTorrent</a>
 414 </li><li> 'HK' - <a href="http://www.pps.jussieu.fr/~jch/software/hekate/" class="external text" rel="nofollow">Hekate</a>
 415 </li><li> 'HL' - <a href="http://www.binarynotions.com/halite.php" class="external text" rel="nofollow">Halite</a>
 416 </li><li> 'HN' - <a href="http://hydranode.com" class="external text" rel="nofollow">Hydranode</a>
 417 </li><li> 'KG' - <a href="http://kget.sourceforge.net" class="external text" rel="nofollow">KGet</a>
 418 </li><li> 'KT' - <a href="http://ktorrent.org" class="external text" rel="nofollow">KTorrent</a>
 419 </li><li> 'LC' - <a href="http://leechcraft.org" class="external text" rel="nofollow">LeechCraft</a>
 420 </li><li> 'LH' - <a href="http://code.google.com/p/lh-abc" class="external text" rel="nofollow">LH-ABC</a>
 421 </li><li> 'LP' - <a href="http://www.lphant.com" class="external text" rel="nofollow">Lphant</a>
 422 </li><li> 'LT' - <a href="http://libtorrent.sf.net" class="external text" rel="nofollow">libtorrent</a>
 423 </li><li> 'lt' - <a href="http://libtorrent.rakshasa.no" class="external text" rel="nofollow">libTorrent</a>
 424 </li><li> 'LW' - <a href="http://www.limewire.org" class="external text" rel="nofollow">LimeWire</a>
 425 </li><li> 'MK' - <a href="http://www.themeerkat.net/" class="external text" rel="nofollow">Meerkat</a>
 426 </li><li> 'MO' - <a href="http://monotorrent.blogspot.com/" class="external text" rel="nofollow">MonoTorrent</a>
 427 </li><li> 'MP' - <a href="http://www.moopolice.de" class="external text" rel="nofollow">MooPolice</a>
 428 </li><li> 'MR' - <a href="http://www.getmiro.com" class="external text" rel="nofollow">Miro</a>
 429 </li><li> 'MT' - <a href="http://www.moonlighttorrent.com" class="external text" rel="nofollow">MoonlightTorrent</a>
 430 </li><li> 'NX' - <a href="http://www.xi-soft.com" class="external text" rel="nofollow">Net Transport</a>
 431 </li><li> 'OS' - <a href="http://oneswarm.cs.washington.edu" class="external text" rel="nofollow">OneSwarm</a>
 432 </li><li> 'OT' - <a href="http://www.omegatorrent.com" class="external text" rel="nofollow">OmegaTorrent</a>
 433 </li><li> 'PD' - <a href="http://www.pando.com" class="external text" rel="nofollow">Pando</a>
 434 </li><li> 'PT' - <a href="http://php-tracker.org" class="external text" rel="nofollow">PHPTracker</a>
 435 </li><li> 'qB' - <a href="http://www.qbittorrent.org" class="external text" rel="nofollow">qBittorrent</a>
 436 </li><li> 'QD' - <a href="http://im.qq.com/cyclone/" class="external text" rel="nofollow">QQDownload</a>
 437 </li><li> 'QT' - Qt 4 Torrent example
 438 </li><li> 'RT' - <a href="http://www.halogenware.com/software/retriever.html" class="external text" rel="nofollow">Retriever</a>
 439 </li><li> 'RZ' - <a href="https://launchpad.net/reztorrent" class="external text" rel="nofollow">RezTorrent</a>
 440 </li><li> 'S~' - <a href="http://shareaza.sourceforge.net" class="external text" rel="nofollow">Shareaza alpha/beta</a>
 441 </li><li> 'SB' - ~Swiftbit
 442 </li><li> 'SD' - <a href="http://www.xunlei.com" class="external text" rel="nofollow">Thunder (aka XùnLéi)</a>
 443 </li><li> 'SM' - <a href="http://www.somud.com" class="external text" rel="nofollow">SoMud</a>
 444 </li><li> 'SS' - SwarmScope
 445 </li><li> 'ST' - <a href="http://symtorrent.aut.bme.hu/" class="external text" rel="nofollow">SymTorrent</a>
 446 </li><li> 'st' - <a href="http://sharktorrent.com" class="external text" rel="nofollow">sharktorrent</a>
 447 </li><li> 'SZ' - <a href="http://shareaza.sourceforge.net" class="external text" rel="nofollow">Shareaza</a>
 448 </li><li> 'TN' - TorrentDotNET
 449 </li><li> 'TR' - <a href="http://www.transmissionbt.com" class="external text" rel="nofollow">Transmission</a>
 450 </li><li> 'TS' - <a href="http://www.torrentstorm.com" class="external text" rel="nofollow">Torrentstorm</a>
 451 </li><li> 'TT' - <a href="http://www.tuotu.com" class="external text" rel="nofollow">TuoTu</a>
 452 </li><li> 'UL' - uLeecher!
 453 </li><li> 'UM' - <a href="http://mac.utorrent.com" class="external text" rel="nofollow">µTorrent for Mac</a>
 454 </li><li> 'UT' - <a href="http://www.utorrent.com" class="external text" rel="nofollow">µTorrent</a>
 455 </li><li> 'VG' - <a href="http://www.vagaa.com" class="external text" rel="nofollow">Vagaa</a>
 456 </li><li> 'WT' - <a href="http://www.bitlet.org" class="external text" rel="nofollow">BitLet</a>
 457 </li><li> 'WY' - <a href="http://www.wyzo.com/firetorrent/" class="external text" rel="nofollow">FireTorrent</a>
 458 </li><li> 'XL' - <a href="http://www.xunlei.com" class="external text" rel="nofollow">Xunlei</a>
 459 </li><li> 'XS' - XSwifter
 460 </li><li> 'XT' - <a href="http://www.xantorrent.pwp.blueyonder.co.uk/xantorrent.zip" class="external text" rel="nofollow">XanTorrent</a>
 461 </li><li> 'XX' - <a href="http://www.xtorrent.com" class="external text" rel="nofollow">Xtorrent</a>
 462 </li><li> 'ZT' - <a href="http://www.ziptorrent.com" class="external text" rel="nofollow">ZipTorrent</a>
 463 </li></ul>
 464 <p>Clients which have been seen in the wild and need to be identified:
 465 </p>
 466 <ul><li> 'BD' (example: -BD0300-)
 467 </li><li> 'NP' (example: -NP0201-)
 468 </li><li> 'wF' (example: -wF2200-)
 469 </li><li> 'hk' (example: -hk0010-) Chinese IP address, unrequestedly sends info dict in message 0xA, reconnects immediately after being disconnected, reserved bytes = 01,01,01,01,00,00,02,01
 470 </li></ul>
 471 <p>Shadow's style uses the following encoding:
 472 one ascii alphanumeric for client identification, up to five characters for version number (padded with '-' if less than five), followed by three characters (commonly '---', but not always the case), followed by random characters. Each character in the version string represents a number from 0 to 63. '0'=0, ..., '9'=9, 'A'=10, ..., 'Z'=35, 'a'=36, ..., 'z'=61, '.'=62, '-'=63.
 473 </p><p>A full explanation by Shad0w about the encoding style (including information about existing conventions on how the three characters after the version string are used) can be found <a href="http://forums.degreez.net/viewtopic.php?t=7070" class="external text" rel="nofollow">here</a>.
 474 </p><p>For example: 'S58B-----'... for Shadow's 5.8.11
 475 </p><p>known clients that uses this encoding style are:
 476 </p>
 477 <ul><li> 'A' - <a href="http://pingpong-abc.sourceforge.net/" class="external text" rel="nofollow">ABC</a>
 478 </li><li> 'O' - <a href="http://osprey.ibiblio.org/" class="external text" rel="nofollow">Osprey Permaseed</a>
 479 </li><li> 'Q' - <a href="http://btqueue.sourceforge.net/" class="external text" rel="nofollow">BTQueue</a>
 480 </li><li> 'R' - <a href="http://www.tribler.org/" class="external text" rel="nofollow">Tribler</a>
 481 </li><li> 'S' - <a href="http://bt.degreez.net/" class="external text" rel="nofollow">Shadow's client</a>
 482 </li><li> 'T' - <a href="http://bittornado.com" class="external text" rel="nofollow">BitTornado</a>
 483 </li><li> 'U' - <a href="http://aaron2003.myftp.org/upnpclient.html" class="external text" rel="nofollow">UPnP NAT Bit Torrent</a>
 484 </li></ul>
 485 <p>Bram's client now uses this style... 'M3-4-2--' or 'M4-20-8-'.
 486 </p><p><a href="http://www.bitcomet.com/" class="external text" 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" 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" 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.
 487 </p><p><a href="http://xbtt.sourceforge.net/client/" class="external text" 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.
 488 </p><p><a href="http://www.opera.com/" class="external text" rel="nofollow">Opera 8 previews and Opera 9.x releases</a> use the following peer_id scheme:
 489 The first two characters are 'OP' and the next four digits equal the build number. All following characters are random lowercase hexdecimal digits.
 490 </p><p><a href="http://mldonkey.sourceforge.net/Main_Page" class="external text" rel="nofollow">MLdonkey</a> use the following peer_id scheme:
 491 the first characters are '-ML' followed by a dotted version then a '-' followed by randomness. e.g. '-ML2.7.2-kgjjfkd'
 492 </p><p><a href="http://www.bitsonwheels.com/" class="external text" rel="nofollow">Bits on Wheels</a> uses the pattern '-BOWxxx-yyyyyyyyyyyy', where y is random (uppercase letters) and x depends on the version. Version 1.0.6 has xxx = A0C.
 493 </p><p><a href="http://queenbee.se/" class="external text" rel="nofollow">Queen Bee</a> uses Bram's new style: 'Q1-0-0--' or 'Q1-10-0-' followed by random bytes.
 494 </p><p><a href="http://bittyrant.cs.washington.edu/" class="external text" rel="nofollow">BitTyrant</a> is an Azureus fork and simply uses 'AZ2500BT' + random bytes as peer ID in its 1.1 version. Note the missing dashes.
 495 </p><p><a href="http://www.torrentopia.org/" class="external text" rel="nofollow">TorrenTopia</a> version 1.90 pretends to be or is derived from Mainline 3.4.6.
 496 Its peer ID starts with '346------'.
 497 </p><p><a href="http://www.167bt.com/intl/" class="external text" rel="nofollow">BitSpirit</a> has several modes for its peer ID. In one mode it reads the ID of its peer and reconnects using the first eight bytes as a basis for its own ID. Its real ID appears to use '\0\3BS' (C notation) as the first four bytes for version 3.x and '\0\2BS' for version 2.x. In all modes the ID may end in 'UDP0'. Since BitSpirit 3.6 the peer ID uses Azureus style with characters 'SP' but without trailing '-' (as FlashGet).
 498 </p><p><a href="http://rufus.sourceforge.net/" class="external text" rel="nofollow">Rufus</a> uses its version as decimal ASCII values for the first two bytes. The third and fourth bytes are 'RS'. What then follows is the nickname of the user and some random bytes.
 499 </p><p><a href="http://g3torrent.sourceforge.net/" class="external text" rel="nofollow">G3 Torrent</a> starts its peer ID with '-G3' and appends up to 9 characters of the nickname of the user.
 500 </p><p><a href="http://www.flashget.com/" class="external text" rel="nofollow">FlashGet</a> uses Azureus style with 'FG' but without the trailing '-'. Version 1.82.1002 still uses the version digits '0180'.
 501 </p><p><a href="http://www.btnext.com/" class="external text" rel="nofollow">BT Next Evolution</a> is derived from BitTornado but tries to mimic Azureus style. The result is that its peer ID starts with '-NE', continues with a 4 digit version number
 502 and then directly goes on with the three characters that describe the type of client in Shad0w's peer ID style.
 503 </p><p><a href="http://www.allpeers.com/" class="external text" rel="nofollow">AllPeers</a> takes the sha1 hash of a user dependent string and replaces the first few characters with "AP" + version string + "-".
 504 </p><p><a href="http://www.qvod.com/" class="external text" rel="nofollow">Qvod</a> starts its id with the four letters "QVOD" and continues with its build number in four decimal digits (currently "0054"). The remaining 12 characters are random uppercase hexdecimal digits. There appears to be a popular modified client in China that replaces the four characters in the beginning with random bytes.
 505 </p><p><a href="http://www.spywareterminator.com" class="external text" rel="nofollow">SpywareTerminator</a> uses libtorrent to share its signature updates among users. It uses Azureus style with 'CS' and version digits '2500'.
 506 </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" rel="nofollow">Bram's client</a>).
 507 </p>
 508 <h3> <span class="mw-headline" id="Messages">Messages</span></h3>
 509 <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 byte.  The payload is message dependent.
 510 </p>
 511 <h4> <span class="mw-headline" id="keep-alive:_.3Clen.3D0000.3E">keep-alive: &lt;len=0000&gt;</span></h4>
 512 <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.
 513 </p>
 514 <h4> <span class="mw-headline" id="choke:_.3Clen.3D0001.3E.3Cid.3D0.3E">choke: &lt;len=0001&gt;&lt;id=0&gt;</span></h4>
 515 <p>The <b>choke</b> message is fixed-length and has no payload.
 516 </p>
 517 <h4> <span class="mw-headline" id="unchoke:_.3Clen.3D0001.3E.3Cid.3D1.3E"> unchoke: &lt;len=0001&gt;&lt;id=1&gt; </span></h4>
 518 <p>The <b>unchoke</b> message is fixed-length and has no payload.
 519 </p>
 520 <h4> <span class="mw-headline" id="interested:_.3Clen.3D0001.3E.3Cid.3D2.3E"> interested: &lt;len=0001&gt;&lt;id=2&gt; </span></h4>
 521 <p>The <b>interested</b> message is fixed-length and has no payload.
 522 </p>
 523 <h4> <span class="mw-headline" id="not_interested:_.3Clen.3D0001.3E.3Cid.3D3.3E"> not interested: &lt;len=0001&gt;&lt;id=3&gt; </span></h4>
 524 <p>The <b>not interested</b> message is fixed-length and has no payload.
 525 </p>
 526 <h4> <span class="mw-headline" id="have:_.3Clen.3D0005.3E.3Cid.3D4.3E.3Cpiece_index.3E"> have: &lt;len=0005&gt;&lt;id=4&gt;&lt;piece index&gt; </span></h4>
 527 <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.
 528 </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 suppression" 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>
 529 </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>.
 530 </p>
 531 <h4> <span class="mw-headline" id="bitfield:_.3Clen.3D0001.2BX.3E.3Cid.3D5.3E.3Cbitfield.3E"> bitfield: &lt;len=0001+X&gt;&lt;id=5&gt;&lt;bitfield&gt; </span></h4>
 532 <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.
 533 </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.
 534 </p><p>Some clients (Deluge for example) send <b>bitfield</b> with missing pieces even if it has all data. Then it sends rest of pieces as <b>have</b> messages. They are saying this helps against ISP filtering of BitTorrent protocol. It is called <b>lazy bitfield</b>.
 535 </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>
 536 </p>
 537 <h4> <span class="mw-headline" id="request:_.3Clen.3D0013.3E.3Cid.3D6.3E.3Cindex.3E.3Cbegin.3E.3Clength.3E"> request: &lt;len=0013&gt;&lt;id=6&gt;&lt;index&gt;&lt;begin&gt;&lt;length&gt; </span></h4>
 538 <p>The <b>request</b> message is fixed length, and is used to request a block.  The payload contains the following information:
 539 </p>
 540 <ul><li> <b>index</b>: integer specifying the zero-based piece index
 541 </li><li> <b>begin</b>: integer specifying the zero-based byte offset within the piece
 542 </li><li> <b>length</b>: integer specifying the requested length.
 543 </li></ul>
 544 <p><i><b>This section is under dispute! Please use the <a href="http://wiki.theory.org/Talk:BitTorrentSpecification#Messages:_request" class="external text" rel="nofollow">discussion page</a> to resolve this!</b></i>
 545 </p><p><i><b>View #1</b></i>
 546 According to the official specification, "All current implementations use 2^15 (32KB), and close connections which request an amount greater than 2^17 (128KB)." As early as version 3 or 2004, this behavior was changed to use 2^14 (16KB) blocks. As of version 4.0 or mid-2005, the mainline disconnected on requests larger than 2^14 (16KB); and some clients have followed suit. Note that block requests are smaller than pieces (&gt;=2^18 bytes), so multiple requests will be needed to download a whole piece.
 547 </p><p><i>Strictly, the specification allows 2^15 (32KB) requests. The reality is near all clients will now use 2^14 (16KB) requests. Due to clients that enforce that size, it is recommended that implementations make requests of that size. Due to smaller requests resulting in higher overhead due to tracking a greater number of requests, implementers are advised against going below 2^14 (16KB).</i>
 548 </p><p><i>The choice of request block size limit enforcement is not nearly so clear cut. With mainline version 4 enforcing 16KB requests, most clients will use that size. At the same time 2^14 (16KB) is the </i>semi<i>-official (only </i>semi<i> because the official protocol document has not been updated) limit now, so enforcing that isn't wrong. At the same time, allowing larger requests enlarges the set of possible peers, and except on very low bandwidth connections (&lt;256kbps) multiple blocks will be downloaded in one choke-timeperiod, thus merely enforcing the old limit causes minimal performance degradation. Due to this factor, it is recommended that only the older 2^17 (128KB) maximum size limit be enforced.</i>
 549 </p><p><i><b>View #2</b></i>
 550 This section has contained falsehoods for a large portion of the time this page has existed. This is the third time I (uau) am correcting this same section for incorrect information being added, so I won't rewrite it completely since it'll probably be broken again... Current version has at least the following errors: Mainline started using 2^14 (16384) byte requests when it was still the only client in existence; only the "official specification" still talked about the obsolete 32768 byte value which was in reality neither the default size nor maximum allowed. In version 4 the request behavior did not change, but the maximum allowed size did change to equal the default size. In latest mainline versions the max has changed to 32768 (note that this is the first appearance of 32768 for either default or max size since the first ancient versions). "Most older clients use 32KB requests" is false. Discussion of larger requests fails to take latency effects into account.
 551 </p>
 552 <h4> <span class="mw-headline" id="piece:_.3Clen.3D0009.2BX.3E.3Cid.3D7.3E.3Cindex.3E.3Cbegin.3E.3Cblock.3E"> piece: &lt;len=0009+X&gt;&lt;id=7&gt;&lt;index&gt;&lt;begin&gt;&lt;block&gt; </span></h4>
 553 <p>The <b>piece</b> message is variable length, where X is the length of the block.  The payload contains the following information:
 554 </p>
 555 <ul><li> <b>index</b>: integer specifying the zero-based piece index
 556 </li><li> <b>begin</b>: integer specifying the zero-based byte offset within the piece
 557 </li><li> <b>block</b>: block of data, which is a subset of the piece specified by index.
 558 </li></ul>
 559 <h4> <span class="mw-headline" id="cancel:_.3Clen.3D0013.3E.3Cid.3D8.3E.3Cindex.3E.3Cbegin.3E.3Clength.3E"> cancel: &lt;len=0013&gt;&lt;id=8&gt;&lt;index&gt;&lt;begin&gt;&lt;length&gt; </span></h4>
 560 <p>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).
 561 </p>
 562 <h4> <span class="mw-headline" id="port:_.3Clen.3D0003.3E.3Cid.3D9.3E.3Clisten-port.3E"> port: &lt;len=0003&gt;&lt;id=9&gt;&lt;listen-port&gt; </span></h4>
 563 <p>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).
 564 </p>
 565 <h2> <span class="mw-headline" id="Algorithms"> Algorithms </span></h2>
 566 <h3> <span class="mw-headline" id="Queuing"> Queuing </span></h3>
 567 <p><i><b>This section is under dispute! Please use the <a href="http://wiki.theory.org/Talk:BitTorrentSpecification#Algorithms:_Queuing" class="external text" rel="nofollow">discussion page</a> to resolve this!</b></i>
 568 </p><p><i><b>View #1</b></i>
 569 In general peers are advised to keep a few unfullfilled requests on each connection. This is done because otherwise a full round trip is required from the download of one block to begining the download of a new block (round trip between PIECE message and next REQUEST message). On links with high BDP (bandwidth-delay-product, high latency or high bandwidth), this can result in a substantial performance loss.
 570 </p><p><i>Implementer's note: This is the <b>most crucial performance item</b>. A static queue of 10 requests is reasonable for 16KB blocks on a 5mbps link with 50ms latency. Links with greater bandwidth are becoming very common so UI designers are urged to make this readily available for changing. Notably cable modems were known for traffic policing and increasing this might of alleviated some of the problems caused by this.</i>
 571 </p><p><i><b>View #2</b></i>
 572 NOTE: much of the information in this "Queuing" section is false or misleading. I'll just note that the "defaults to 5 outstanding requests" hasn't been true for a long time, "32 KB blocks" is misleading since you normally don't use 32 KB blocks, and tuning queue length by changing it and trying to measure the effects is a bad idea.
 573 </p>
 574 <h3> <span class="mw-headline" id="Super_Seeding"> Super Seeding </span></h3>
 575 <p><i>(This was not part of the original specification)</i>
 576 </p><p><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>
 577 </p><p><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>
 578 </p><p><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>
 579 </p><p><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>
 580 </p><p><i>Super-seed mode is '</i>NOT<i> 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>
 581 </p>
 582 <pre><i>Why not rename it to e.g. "Initial Seeding Mode" or "Releaser Mode" then?</i>
 583 </pre>
 584 <h3> <span class="mw-headline" id="Piece_downloading_strategy"> Piece downloading strategy </span></h3>
 585 <p>Clients may choose to download pieces in random order.
 586 </p><p><i>A better strategy is to download pieces in </i><a href="/Availability" title="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. Note that any Rarest First strategy should include randomization among at least several of the least common pieces, as having many clients all attempting to jump on the same "least common" piece would be counter productive.</i>
 587 </p>
 588 <h3> <span class="mw-headline" id="End_Game"> End Game </span></h3>
 589 <p>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.
 590 </p><p><i>There is no documented thresholds, recommended percentages, or block counts that could be used as a guide or Recommended Best Practice here.</i>
 591 </p><p><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 href="http://hal.inria.fr/inria-00000156/en" class="external free" rel="nofollow">http://hal.inria.fr/inria-00000156/en</a>.
 592 </p>
 593 <h3> <span class="mw-headline" id="Choking_and_Optimistic_Unchoking"> Choking and Optimistic Unchoking </span></h3>
 594 <p>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.
 595 </p><p>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.
 596 </p><p>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.
 597 </p><p>The currently deployed choking algorithm avoids fibrillation by only changing choked peers once every ten seconds.
 598 </p><p>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.
 599 </p><p>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.
 600 </p><p>For optimistic unchoking, at any one time there is a single peer which is unchoked regardless of its 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.
 601 </p>
 602 <h4> <span class="mw-headline" id="Anti-snubbing"> Anti-snubbing </span></h4>
 603 <p>Occasionally a <a href="/index.php?title=BitTorrent&amp;action=edit&amp;redlink=1" class="new" title="BitTorrent (page does not exist)">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 any piece data while downloading from a peer, <a href="/index.php?title=BitTorrent&amp;action=edit&amp;redlink=1" class="new" title="BitTorrent (page does not exist)">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.
 604 </p>
 605 <h2> <span class="mw-headline" id="Official_Extensions_To_The_Protocol"> Official Extensions To The Protocol </span></h2>
 606 <p>Currently there are a few official extensions to the protocol.
 607 </p>
 608 <h4> <span class="mw-headline" id="Fast_Peers_Extensions"> Fast Peers Extensions </span></h4>
 609 <ul><li>Reserved Bit: The third least significant bit in the 8th reserved byte i.e. reserved[7] |= 0x04
 610 </li></ul>
 611 <p>These extensions serve multiple purposes. They allow a peer to more quickly bootstrap into a swarm by giving a peer a specific set of pieces which they will be allowed download regardless of choked status. They reduce message overhead by adding HaveAll and HaveNone messages and allow explicit rejection of piece requests whereas previously only implicit rejection was possible meaning that a peer might be left waiting for a piece that would never be delivered.
 612 </p><p>The specification is documented at the <a href="/index.php?title=BitTorrent&amp;action=edit&amp;redlink=1" class="new" title="BitTorrent (page does not exist)">BitTorrent</a> site here: <a href="http://bittorrent.org/beps/bep_0006.html" class="external free" rel="nofollow">http://bittorrent.org/beps/bep_0006.html</a>.
 613 </p>
 614 <h4> <span class="mw-headline" id="Distributed_Hash_Table"> Distributed Hash Table </span></h4>
 615 <ul><li> Reserved Bit: The last bit in the 8th reserved byte i.e. reserved[7] |= 0x01
 616 </li></ul>
 617 <p>This extension is to allow for the tracking of peers downloading torrents without the use of a standard tracker. A peer implementing this protocol becomes a "tracker" and stores lists of other nodes/peers which can be used to locate new peers.
 618 </p><p>The specification is documented at the <a href="/index.php?title=BitTorrent&amp;action=edit&amp;redlink=1" class="new" title="BitTorrent (page does not exist)">BitTorrent</a> site here: <a href="http://bittorrent.org/beps/bep_0005.html" class="external free" rel="nofollow">http://bittorrent.org/beps/bep_0005.html</a>.
 619 </p><p>BEP-32 extends the DHT with support for IPv6, and updates the specification in some minor ways.  <a href="http://www.pps.jussieu.fr/~jch/software/bittorrent/bep-dht-ipv6.html" class="external free" rel="nofollow">http://www.pps.jussieu.fr/~jch/software/bittorrent/bep-dht-ipv6.html</a>
 620 </p>
 621 <h4> <span class="mw-headline" id="Connection_Obfuscation"> Connection Obfuscation </span></h4>
 622 <p>This extension allows the creation of obfuscated (encrypted) connections between peers. This can be used to bypass ISPs throttling BitTorrent traffic.
 623 </p><p>The specification is documented at <a href="http://www.azureuswiki.com/index.php/Message_Stream_Encryption" class="external free" rel="nofollow">http://www.azureuswiki.com/index.php/Message_Stream_Encryption</a>.
 624 </p><p><i> The documentation is fairly complete, but ideally it would be clarified on several points including guidance on when encrypted connections should be attempted, fallback procedures to regular connections etc. </i>
 625 </p>
 626 <h2> <span class="mw-headline" id="Unofficial_Extensions_To_The_Protocol"> Unofficial Extensions To The Protocol </span></h2>
 627 <h4> <span class="mw-headline" id="Azureus_Messaging_Protocol"> Azureus Messaging Protocol </span></h4>
 628 <ul><li> Reserved Bit: 1
 629 </li></ul>
 630 <p>A protocol in its own right - if two clients indicate they support the protocol, then they should switch over to using it. It allows normal BitTorrent as well extension messages to be sent over it, and is documented <a href="http://www.azureuswiki.com/index.php/Azureus_messaging_protocol" class="external text" rel="nofollow">here</a>. Currently implemented by Azureus and Transmission.
 631 </p><p>It is not possible to use both this protocol and the LibTorrent extension protocol at the same time - if both clients indicate they support both, then they should follow the semantics defined by the <a href="http://www.azureuswiki.com/index.php/Extension_negotiation_protocol" class="external text" rel="nofollow">Extension Negotiation Protocol</a>.
 632 </p>
 633 <h4> <span class="mw-headline" id="WebSeeding"> WebSeeding </span></h4>
 634 <p>The possibility to seed a torrent via a web server is generally called WebSeeding. It allows the HTTP server to work as a peer in the BitTorrent network.
 635 </p><p>There are at least two specification for how to combine a torrent download with a HTTP download. The first standard, implemented by BitTornado is quite easy to implement in the client, but is intrusive on the HTTP in that it requires a script handling requests on the server side. i.e. A plain HTTP server that just serves plain files isn't enough. The benfits is that the script can be more abuse resistant. This specification is found here: <a href="http://bittornado.com/docs/webseed-spec.txt" class="external free" rel="nofollow">http://bittornado.com/docs/webseed-spec.txt</a>.
 636 </p><p>The second specification requires slightly more from the client, but downloads from plain HTTP servers. It is specified here: <a href="http://www.getright.com/seedtorrent.html" class="external free" rel="nofollow">http://www.getright.com/seedtorrent.html</a>. It has been implemented by GetRight, libtorrent, Mainline, BitComet, Vuze.
 637 </p>
 638 <h4> <span class="mw-headline" id="Extension_protocol"> Extension protocol </span></h4>
 639 <ul><li> Reserved Bit: 44, the fourth most significant bit in the 6th reserved byte i.e. reserved[5] |= 0x10
 640 </li></ul>
 641 <p>This is a protocol for exchanging extension information and was derived from an early version of azureus' extension protocol. It adds one message for exchanging arbitrary handshake information including defined extension messages, mapping extensions to specific message IDs. It is documented here:
 642 <a href="http://www.libtorrent.org/extension_protocol.html" class="external free" rel="nofollow">http://www.libtorrent.org/extension_protocol.html</a> and is implemented at least by libtorrent, uTorrent, Mainline, Transmission, Azureus and BitComet.
 643 </p><p>It is not possible to use both this protocol and the Azureus Messaging Protocol at the same time - if both clients indicate they support both, then they should follow the semantics defined by the <a href="http://www.azureuswiki.com/index.php/Extension_negotiation_protocol" class="external text" rel="nofollow">Extension Negotiation Protocol</a>.
 644 </p>
 645 <h4> <span class="mw-headline" id="Extension_Negotiation_Protocol"> Extension Negotiation Protocol </span></h4>
 646 <ul><li> Reserved bits: 47 and 48
 647 </li></ul>
 648 <p>These bits are used to allow two clients that support both the Azureus Messaging Protocol and LibTorrent's extension protocol to decide which of the two extensions should be used for communication, and is defined <a href="http://www.azureuswiki.com/index.php/Extension_negotiation_protocol" class="external text" rel="nofollow">here</a>.
 649 </p>
 650 <h4> <span class="mw-headline" id="BitTorrent_Location-aware_Protocol_1.0"> BitTorrent Location-aware Protocol 1.0 </span></h4>
 651 <ul><li> Reserved Bit: 21
 652 </li></ul>
 653 <p>A Protocol, considering peers location (in geographical terms) for better performance. Specification can be found <a href="http://wiki.theory.org/BitTorrent_Location-aware_Protocol_1.0_Specification" class="external text" rel="nofollow">here</a>.
 654 </p>
 655 <h4> <span class="mw-headline" id="SimpleBT_Extension_Protocol"> SimpleBT Extension Protocol </span></h4>
 656 <ul><li> Reserved Bits: fist reserved byte = 0x01, following bytes may need to be set to zero
 657 </li></ul>
 658 <p>An extension using message id 9 to add peer exchange and connection statistics exchange. The specification can be found <a href="http://web.archive.org/web/20031002201124/btfans.3322.org/simplebt/ProtocalExtension.txt" class="external text" rel="nofollow">here</a>. The extension was in use in SimpleBT 0.32 to 0.36.1. Later versions of SimpleBT were called BitComet and used the similar but incompatible BitComet Extension Protocol.
 659 </p>
 660 <h4> <span class="mw-headline" id="BitComet_Extension_Protocol"> BitComet Extension Protocol </span></h4>
 661 <ul><li> Reserved Bits: first two reserved bytes = "ex"
 662 </li></ul>
 663 <p>There appears to be no official documentation.
 664 </p><p>In this protocol a peer announces the supported extensions by sending a message &lt;len=0001+X&gt;&lt;id=0xA0&gt;&lt;extension 1&gt;...&lt;extension X&gt; where &lt;extension n&gt; is (usually) the message id of the supported extension. When an extension consists of multiple messages, all ids need to be mentioned.
 665 </p><p>Extensions currently in use (TODO: reverse engineer semantics):
 666 </p>
 667 <ul><li> 0xA0 (EXT_SUPPORT) see above, needs to be included in its parameter list
 668 </li><li> 0xA1 (EXT_PEERREQ) ask for peer exchange, used in conjunction with EXT_PEERS
 669 </li><li> 0xA2 (EXT_PEERS) in reply to EXT_PEERREQ and for updates afterwards
 670 </li><li> 0xA3 (EXT_AUTH_SEED) appeared in BitComet 0.53, used in conjunction with EXT_AUTH_CRYPTOED
 671 </li><li> 0xA4 (EXT_AUTH_CRYPTOED)
 672 </li><li> 0xA5 (EXT_CONNGRANT) appeared in BitComet 0.48, used in conjunction with EXT_CONNACCEPT
 673 </li><li> 0xA6 (EXT_CONNACCEPT)
 674 </li><li> 0x06 (?) announced by BitSpirit instead of EXT_CONNACCEPT
 675 </li><li> 0xA7 (EXT_CHAT_MESSAGE) appeared in BitComet 0.53, vanished in 0.71
 676 </li><li> 0xA9 (EXT_HASH_REQ) appeared in BitComet 0.54, vanished in 0.71, used in conjunction with EXT_HASH
 677 </li><li> 0xAA (EXT_HASH)
 678 </li><li> 0xAB (EXT_REPORT_RATE_old) appeared in BitComet 0.54, was replaced by EXT_REPORT_RATE_new in 0.57
 679 </li><li> 0xAC (EXT_REPORT_INFO) appeared in BitComet 0.54, vanished in 0.71, reappeared in 0.82
 680 </li><li> 0xAD (EXT_REPORT_RATE_new) appeared in BitComet 0.57, vanished in 0.75, reappeared in 0.82
 681 </li><li> 0xAE (EXT_BC_PASSPORT) appeared in BitComet 0.75
 682 </li><li> 0xAF (EXT_DHE_PREFERRED) appeared in BitComet 0.75
 683 </li><li> 0xB0 (?) appeared in BitComet 0.86
 684 </li><li> 0xC0 (?) does not correspond to a message id, appeared in BitComet 0.49
 685 </li></ul>
 686 <p>A minimum implementation needs only accept EXT_SUPPORT, but EXT_PEERREQ and EXT_PEERS are supported by all known implementations.
 687 </p>
 688 <h2> <span class="mw-headline" id="Reserved_Bytes"> Reserved Bytes </span></h2>
 689 <p><i>The reserved bits are numbered 1-64 in the following table for ease of identification. Bit 1 corresponds to the most significant bit of the first reserved byte. Bit 8 corresponds to the least significant bit of the first reserved byte (i.e. byte[0] |= 0x01). Bit 64 is the least significant bit of the last reserved byte i.e. byte[7] |= 0x01</i>
 690 </p><p><i> An orange bit is a known unofficial extension, a red bit is an unknown unofficial extension.</i>
 691 </p>
 692 <table border="1">
 693 <caption> Reserved Bits
 694 </caption><tr>
 695 <th> Bit </th><th> Use </th><th> Azureus </th><th> BitComet </th><th> MainLine </th><th> MonoTorrent </th><th> µTorrent </th><th> libtorrent </th><th> KTorrent </th><th> BitLord </th><th> XBT </th><th> Transmission
 696 </th></tr>
 697 <tr style="background:orange;">
 698 <td> 1 </td><td> Azureus Extended Messaging </td><td style="background: #88ff88; text-align: center;"> Yes </td><td style="text-align: center;">&nbsp;? </td><td style="text-align: center;">&nbsp;? </td><td style="text-align: center;">&nbsp;? </td><td style="text-align: center;">&nbsp;? </td><td style="text-align: center;"> No </td><td style="text-align: center;"> No </td><td style="text-align: center;"> No </td><td style="text-align: center;"> No </td><td style="background: #88ff88; text-align: center;"> Yes
 699 </td></tr>
 700 <tr style="background:orange;">
 701 <td> 1-16 </td><td> BitComet Extension protocol </td><td style="text-align: center;"> No </td><td style="background: #88ff88; text-align: center;"> Yes </td><td style="text-align: center;"> No </td><td style="text-align: center;"> No </td><td style="text-align: center;"> No </td><td style="text-align: center;"> No </td><td style="text-align: center;"> No </td><td style="background: #88ff88; text-align: center;"> Yes </td><td style="text-align: center;"> No </td><td style="text-align: center;"> No
 702 </td></tr>
 703 <tr style="background:orange;">
 704 <td> 21 </td><td> BitTorrent Location-aware Protocol 1.0 </td><td style="text-align: center;"> No </td><td style="text-align: center;"> No </td><td style="text-align: center;"> No </td><td style="text-align: center;"> No </td><td style="text-align: center;"> No </td><td style="text-align: center;"> No </td><td style="text-align: center;"> No </td><td style="text-align: center;"> No </td><td style="text-align: center;"> No </td><td style="text-align: center;"> No
 705 </td></tr>
 706 <tr style="background:orange;">
 707 <td> 44 </td><td> Extension protocol </td><td style="background: #88ff88; text-align: center;"> Yes </td><td style="background: #88ff88; text-align: center;"> Yes </td><td style="background: #88ff88; text-align: center;"> Yes </td><td style="background: #88ff88; text-align: center;"> Yes </td><td style="background: #88ff88; text-align: center;"> Yes </td><td style="background: #88ff88; text-align: center;"> Yes </td><td style="text-align: center;"> No </td><td style="text-align: center;"> No </td><td style="background: #88ff88; text-align: center;"> Yes </td><td style="background: #88ff88; text-align: center;"> Yes
 708 </td></tr>
 709 <tr style="background:orange;">
 710 <td> 47 - 48 </td><td> Extension Negotiation Protocol </td><td style="background: #88ff88; text-align: center;"> Yes </td><td style="text-align: center;"> No </td><td style="text-align: center;"> No </td><td style="text-align: center;"> No </td><td style="text-align: center;"> No </td><td style="text-align: center;"> No </td><td style="text-align: center;"> No </td><td style="text-align: center;"> No </td><td style="text-align: center;"> No </td><td style="background: #88ff88; text-align: center;"> Yes
 711 </td></tr>
 712 <tr style="background:orange;">
 713 <td> 61 </td><td> NAT Traversal </td><td style="text-align: center;"> No </td><td style="text-align: center;">&nbsp;? </td><td style="background: #88ff88; text-align: center;"> Yes </td><td style="text-align: center;">&nbsp;? </td><td style="text-align: center;">&nbsp;? </td><td style="text-align: center;"> No </td><td style="text-align: center;">&nbsp;? </td><td style="text-align: center;">&nbsp;? </td><td style="text-align: center;"> No </td><td style="text-align: center;">&nbsp;?
 714 </td></tr>
 715 <tr>
 716 <td> 62 </td><td> Fast Peers </td><td style="text-align: center;"> No </td><td style="text-align: center;">&nbsp;? </td><td style="background: #88ff88; text-align: center;"> Yes </td><td style="background: #88ff88; text-align: center;"> Yes </td><td style="text-align: center;">&nbsp;? </td><td style="background: #88ff88; text-align: center;"> Yes </td><td style="background: #88ff88; text-align: center;"> Yes </td><td style="text-align: center;"> No </td><td style="text-align: center;"> No </td><td style="text-align: center;">&nbsp;?
 717 </td></tr>
 718 <tr style="background:orange;">
 719 <td> 63 </td><td> XBT Peer Exchange </td><td style="text-align: center;"> No </td><td style="text-align: center;">&nbsp;? </td><td style="text-align: center;"> No </td><td style="text-align: center;">&nbsp;? </td><td style="text-align: center;">&nbsp;? </td><td style="text-align: center;"> No </td><td style="text-align: center;">&nbsp;? </td><td style="text-align: center;">&nbsp;? </td><td style="background: #88ff88; text-align: center;"> Yes </td><td style="text-align: center;">&nbsp;?
 720 </td></tr>
 721 <tr>
 722 <td> 64 </td><td> DHT </td><td style="text-align: center;"> No </td><td style="background: #88ff88; text-align: center;"> Yes </td><td style="background: #88ff88; text-align: center;"> Yes </td><td style="background: #88ff88; text-align: center;"> Yes </td><td style="background: #88ff88; text-align: center;"> Yes </td><td style="background: #88ff88; text-align: center;"> Yes </td><td style="background: #88ff88; text-align: center;"> Yes </td><td style="text-align: center;"> No </td><td style="text-align: center;"> No </td><td style="text-align: center;">&nbsp;?
 723 </td></tr>
 724 <tr style="background:orange;">
 725 <td> 64 </td><td> XBT Metadata Exchange </td><td style="text-align: center;"> No </td><td style="text-align: center;">&nbsp;? </td><td style="text-align: center;"> No </td><td style="text-align: center;">&nbsp;? </td><td style="text-align: center;">&nbsp;? </td><td style="text-align: center;"> No </td><td style="text-align: center;">&nbsp;? </td><td style="text-align: center;">&nbsp;? </td><td style="background: #88ff88; text-align: center;"> Yes </td><td style="text-align: center;">&nbsp;?
 726 </td></tr></table>
 727 <h2> <span class="mw-headline" id="Change_Log"> Change Log </span></h2>
 728 <p>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.
 729 </p><p>doverosx - 2011-05-30
 730 - minor: changed in notations "a block is a portion of data that the client requests from AT LEAST ONE peer" since it is not necessary to request a block from only ONE peer at a time.
 731 </p><p><a href="/index.php?title=SuprDewd&amp;action=edit&amp;redlink=1" class="new" title="SuprDewd (page does not exist)">SuprDewd</a> - 2010-07-23
 732 - Added a link to my implementation of bencoding for C#.
 733 </p><p>greywiz - 2010-01-01
 734 - Added support for Extension Protocol and DHT for BitComet in the Reserved Bytes table
 735 </p><p>SiDi - 2009-04-18
 736 - Added RezTorrent peer_id
 737 </p><p>HighInBC - 2008-02-12
 738 - Minor change. Added parsed result for final example of bencoded dictionary, added &lt;nowiki&gt; tags to top example to avoid issues.
 739 </p><p>amc1 - 2007-09-12
 740 - Azureus now supports the LibTorrent Extension Protocol (LTEP, as I refer to it).
 741 </p><p>amc1 - 2007-08-16
 742 - Added description and links to Extension Negotiation Protocol, and formatted the reserved bits table a bit.
 743 </p><p>Denial - 2007-08-13
 744 - Added description of the SimpleBT and BitComet extension protocols
 745 </p><p>amc1 - 2007-07-16
 746 - Added SymTorrent's peer ID identifier, as well as some other clients I've come across which need to be identified.
 747 </p><p>amc1 - 2007-07-14
 748 - Corrected information about Shadow's style of peer ID - existing text made incorrect assumptions.
 749 </p><p>mitchman - 2007-07-12
 750 - Clarified the Opera peed-id
 751 </p><p>roee88- 2007-06-11
 752 - Added LH-ABC peer_id
 753 </p><p>Boian V Petkantchin - April 26, 2007. Listed another unoffcial extension - BitTorrent Location-aware Protocol 1.0. Included it in the table of reserved bits.
 754 </p><p>daniel-gl at gmx.net
 755 - Corrected reserved bit numbers
 756 - Added NAT traversal and XBT extensions to table
 757 </p><p>stuge - 2006-11-20
 758 - Added Queen Bee peer_id
 759 </p><p><a href="/EHeM" title="EHeM" class="mw-redirect">EHeM</a> - 2006-10-16
 760 - Update of view #1 on <i>Message: request</i> to hopefully reflect a possible compromise position.
 761 - Trimming of changelog.
 762 </p><p><a href="/EHeM" title="EHeM" class="mw-redirect">EHeM</a> - 2006-10-11
 763 - Firmly marked the <i>Message: request</i> section as being under dispute
 764 - Firmly marked the <i>Algorithms: Queuing</i> section as being under dispute
 765 - Removed personal insults by uau, could we be reasonable humans and try to resolve disputes peacefully? Perhaps using the attached <a href="http://wiki.theory.org/Talk:BitTorrentSpecification" class="external text" rel="nofollow">talk/discussion</a> page?
 766 </p><p>Joris Guisson - 2006-09-12
 767 - Added KTorrent specific information (peer id and extension table)
 768 </p><p>Arvid - 2006-09-12
 769 - Added Extension protocol to the unofficial extensions section
 770 </p><p>Alan - 2006-09-12
 771 -Removed some older history. Update the reserved bytes section.
 772 </p><p>Alan - 2006-09-11
 773 - Added section about Extensions to Protocol
 774 </p><p>uau - 2006-08-17
 775 - Added warning about the misleading information in the Queuing and requests packet sections.
 776 </p><p><a href="/index.php?title=WikiWordsAreEllFourEmmThree&amp;action=edit&amp;redlink=1" class="new" title="WikiWordsAreEllFourEmmThree (page does not exist)">WikiWordsAreEllFourEmmThree</a> - 2006-07-08
 777 - Added <a href="/index.php?title=BitPump&amp;action=edit&amp;redlink=1" class="new" title="BitPump (page does not exist)">BitPump</a> peer_id
 778 </p><p>daniel-gl at gmx.net - 2006-04-28
 779 - Added Bits on Wheels &amp; <a href="/index.php?title=BitLord&amp;action=edit&amp;redlink=1" class="new" title="BitLord (page does not exist)">BitLord</a> peer_id.
 780 </p><p><a href="/index.php?title=DennisHolmes&amp;action=edit&amp;redlink=1" class="new" title="DennisHolmes (page does not exist)">DennisHolmes</a> - 2006-04-22
 781 - Added Enhanced CTorrent peer_id
 782 </p><p><a href="/index.php?title=WikiWordsAre&amp;action=edit&amp;redlink=1" class="new" title="WikiWordsAre (page does not exist)">WikiWordsAre</a>�berGay - 2006-04-16
 783 - Anti-snubbing '<i>is</i> part of the official protocol. Check out the paper on <a href="/index.php?title=BitTorrent&amp;action=edit&amp;redlink=1" class="new" title="BitTorrent (page does not exist)">BitTorrent</a> economics at <a href="http://www.bittorrent.org" class="external free" rel="nofollow">http://www.bittorrent.org</a>
 784 </p><p><a href="/index.php?title=JoshElsasser&amp;action=edit&amp;redlink=1" class="new" title="JoshElsasser (page does not exist)">JoshElsasser</a> - 2006-04-11
 785 - Added Transmission peer_id
 786 </p><p>daniel-gl at gmx.net - 2006-03-23
 787 - Added Tribler peer_id
 788 </p><p><a href="/index.php?title=MaSiniavine&amp;action=edit&amp;redlink=1" class="new" title="MaSiniavine (page does not exist)">MaSiniavine</a>
 789 - Corrected dictionary example
 790 </p><p>Juanjo 2006-03-10
 791 - Added Lphant peer ID
 792 </p><p><a href="/EHeM" title="EHeM" class="mw-redirect">EHeM</a> 2006-03-07
 793 - Added mention of another parameter to the baseline for queuing.
 794 - Another link adjustment.
 795 - Added exposition on request block size.
 796 - Sample link changes, the domain "example.com" is explicitly reserved for examples, as such that should be used instead of spam.com.
 797 - Added qualification to recommended number of peers.
 798 </p><p><a href="/EHeM" title="EHeM" class="mw-redirect">EHeM</a> 2006-03-01 (minor)
 799 - Link changes, the official <a href="/index.php?title=BitTorrent&amp;action=edit&amp;redlink=1" class="new" title="BitTorrent (page does not exist)">BitTorrent</a> pages are no longer on bitconjurer.org, but bittorent.com.
 800 - Removed unneeded line breaks from paragraph.
 801 - Typo fixes in changelog (yeah, I suppose do have a bit of vanity)
 802 </p><p><a href="/EHeM" title="EHeM" class="mw-redirect">EHeM</a> 2006-03-01
 803 - Restored the section on queueing, as it '<i>is</i> a highly crucial performance item. Feel free to rewrite me if you desire, uau. The developer's list, <a href="http://lists.ibiblio.org/mailman/listinfo/bittorrent" class="external free" rel="nofollow">http://lists.ibiblio.org/mailman/listinfo/bittorrent</a> is a better place for debates.
 804 - Trimmed changelog entries older than one year, the above specifies one month, but this is changing slowly so more history seems pertinent.
 805 </p><p>haylegend - 2006-01-08
 806 - Added Retriever's peer id.
 807 </p><p>uau - 2005-12-13
 808 - Fixed sizes in request message description AGAIN. They had been changed to incorrect values.
 809 - Removed "Queuing" section. 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.
 810 </p>
 811 <hr />
 812 <pre>Last edit: Tue, 12 Sep 2006 22:38:05 -0700
 813 (TresNi)
 814 Revisions: 158
 815 </pre>
 816 <h2> <span class="mw-headline" id="Related_Links">Related Links</span></h2>
 817
 818 <!--
 819 NewPP limit report
 820 Preprocessor node count: 616/1000000
 821 Post-expand include size: 3903/2097152 bytes
 822 Template argument size: 0/2097152 bytes
 823 Expensive parser function count: 0/100
 824 -->
 825
 826 <!-- Saved in parser cache with key mw_theoryorg:pcache:idhash:1427-0!1!0!!en!2!edit=0 and timestamp 20110825020102 -->
 827 <div class="printfooter">
 828 Retrieved from "<a href="http://wiki.theory.org/BitTorrentSpecification">http://wiki.theory.org/BitTorrentSpecification</a>"</div>
 829         </div>
 830 </div></div>
 831
 832 <div class="visualClear"></div>
 833 </div>
 834
 835 <!-- Served in 0.608 secs. --></body></html>