Ignore:
Timestamp:
02/02/08 02:56:00 (2 years ago)
Author:
dave
Message:

Further work conforming standards documents to the BEP process.

File:
1 edited

Legend:

Unmodified
Added
Removed

  • dotorg/trunk/html/beps/bep_0002.html

    r10492 r10505  
    1 <?xml version="1.0" encoding="utf-8" ?> 
    2 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> 
    3 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> 
    4 <!-- 
    5 This HTML is auto-generated.  DO NOT EDIT THIS FILE!  If you are writing a new 
    6 BEP, see http://www.bittorrent.org/beps/bep_0001.html for instructions and links 
    7 to templates.  DO NOT USE THIS HTML FILE AS YOUR TEMPLATE! 
    8 --> 
    9 <head> 
    10   <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 
    11   <meta name="generator" content="Docutils 0.5: http://docutils.sourceforge.net/" /> 
    12   <title>BEP 2 -- The BitTorrent Protocol Specification</title> 
    13   <style type="text/css"> 
    14  
    15 /* 
    16 :Author: David Goodger 
    17 :Contact: goodger@python.org 
    18 :date: $Date: 2006-05-21 22:44:42 +0200 (Sun, 21 May 2006) $ 
    19 :version: $Revision: 4564 $ 
    20 :copyright: This stylesheet has been placed in the public domain. 
    21  
    22 Default cascading style sheet for the BEP HTML output of Docutils. 
    23 */ 
    24  
    25 /* "! important" is used here to override other ``margin-top`` and 
    26    ``margin-bottom`` styles that are later in the stylesheet or  
    27    more specific.  See http://www.w3.org/TR/CSS1#the-cascade */ 
    28 .first { 
    29   margin-top: 0 ! important } 
    30  
    31 .last, .with-subtitle { 
    32   margin-bottom: 0 ! important } 
    33  
    34 .hidden { 
    35   display: none } 
    36  
    37 .navigation { 
    38   width: 100% ; 
    39   background: #99ccff ; 
    40   margin-top: 0px ; 
    41   margin-bottom: 0px } 
    42  
    43 .navigation .navicon { 
    44   width: 150px ; 
    45   height: 35px } 
    46  
    47 .navigation .textlinks { 
    48   padding-left: 1em ; 
    49   text-align: left } 
    50  
    51 .navigation td, .navigation th { 
    52   padding-left: 0em ; 
    53   padding-right: 0em ; 
    54   vertical-align: middle } 
    55  
    56 .rfc2822 { 
    57   margin-top: 0.5em ; 
    58   margin-left: 0.5em ; 
    59   margin-right: 0.5em ; 
    60   margin-bottom: 0em } 
    61  
    62 .rfc2822 td { 
    63   text-align: left } 
    64  
    65 .rfc2822 th.field-name { 
    66   text-align: right ; 
    67   font-family: sans-serif ; 
    68   padding-right: 0.5em ; 
    69   font-weight: bold ; 
    70   margin-bottom: 0em } 
    71  
    72 a.toc-backref { 
    73   text-decoration: none ; 
    74   color: black } 
    75  
    76 blockquote.epigraph { 
    77   margin: 2em 5em ; } 
    78  
    79 body { 
    80   margin: 0px ; 
    81   margin-bottom: 1em ; 
    82   padding: 0px } 
    83  
    84 dl.docutils dd { 
    85   margin-bottom: 0.5em } 
    86  
    87 div.section { 
    88   margin-left: 1em ; 
    89   margin-right: 1em ; 
    90   margin-bottom: 1.5em } 
    91  
    92 div.section div.section { 
    93   margin-left: 0em ; 
    94   margin-right: 0em ; 
    95   margin-top: 1.5em } 
    96  
    97 div.abstract { 
    98   margin: 2em 5em } 
    99  
    100 div.abstract p.topic-title { 
    101   font-weight: bold ; 
    102   text-align: center } 
    103  
    104 div.admonition, div.attention, div.caution, div.danger, div.error, 
    105 div.hint, div.important, div.note, div.tip, div.warning { 
    106   margin: 2em ; 
    107   border: medium outset ; 
    108   padding: 1em } 
    109  
    110 div.admonition p.admonition-title, div.hint p.admonition-title, 
    111 div.important p.admonition-title, div.note p.admonition-title, 
    112 div.tip p.admonition-title { 
    113   font-weight: bold ; 
    114   font-family: sans-serif } 
    115  
    116 div.attention p.admonition-title, div.caution p.admonition-title, 
    117 div.danger p.admonition-title, div.error p.admonition-title, 
    118 div.warning p.admonition-title { 
    119   color: red ; 
    120   font-weight: bold ; 
    121   font-family: sans-serif } 
    122  
    123 /* Uncomment (and remove this text!) to get reduced vertical space in 
    124    compound paragraphs. 
    125 div.compound .compound-first, div.compound .compound-middle { 
    126   margin-bottom: 0.5em } 
    127  
    128 div.compound .compound-last, div.compound .compound-middle { 
    129   margin-top: 0.5em } 
    130 */ 
    131  
    132 div.dedication { 
    133   margin: 2em 5em ; 
    134   text-align: center ; 
    135   font-style: italic } 
    136  
    137 div.dedication p.topic-title { 
    138   font-weight: bold ; 
    139   font-style: normal } 
    140  
    141 div.figure { 
    142   margin-left: 2em ; 
    143   margin-right: 2em } 
    144  
    145 div.footer, div.header { 
    146   clear: both; 
    147   font-size: smaller } 
    148  
    149 div.footer { 
    150   margin-left: 1em ; 
    151   margin-right: 1em } 
    152  
    153 div.line-block { 
    154   display: block ; 
    155   margin-top: 1em ; 
    156   margin-bottom: 1em } 
    157  
    158 div.line-block div.line-block { 
    159   margin-top: 0 ; 
    160   margin-bottom: 0 ; 
    161   margin-left: 1.5em } 
    162  
    163 div.sidebar { 
    164   margin-left: 1em ; 
    165   border: medium outset ; 
    166   padding: 1em ; 
    167   background-color: #ffffee ; 
    168   width: 40% ; 
    169   float: right ; 
    170   clear: right } 
    171  
    172 div.sidebar p.rubric { 
    173   font-family: sans-serif ; 
    174   font-size: medium } 
    175  
    176 div.system-messages { 
    177   margin: 5em } 
    178  
    179 div.system-messages h1 { 
    180   color: red } 
    181  
    182 div.system-message { 
    183   border: medium outset ; 
    184   padding: 1em } 
    185  
    186 div.system-message p.system-message-title { 
    187   color: red ; 
    188   font-weight: bold } 
    189  
    190 div.topic { 
    191   margin: 2em } 
    192  
    193 h1.section-subtitle, h2.section-subtitle, h3.section-subtitle, 
    194 h4.section-subtitle, h5.section-subtitle, h6.section-subtitle { 
    195   margin-top: 0.4em } 
    196  
    197 h1 { 
    198   font-family: sans-serif ; 
    199   font-size: large } 
    200  
    201 h2 { 
    202   font-family: sans-serif ; 
    203   font-size: medium } 
    204  
    205 h3 { 
    206   font-family: sans-serif ; 
    207   font-size: small } 
    208  
    209 h4 { 
    210   font-family: sans-serif ; 
    211   font-style: italic ; 
    212   font-size: small } 
    213  
    214 h5 { 
    215   font-family: sans-serif; 
    216   font-size: x-small } 
    217  
    218 h6 { 
    219   font-family: sans-serif; 
    220   font-style: italic ; 
    221   font-size: x-small } 
    222  
    223 hr.docutils { 
    224   width: 75% } 
    225  
    226 img.align-left { 
    227   clear: left } 
    228  
    229 img.align-right { 
    230   clear: right } 
    231  
    232 img.borderless { 
    233   border: 0 } 
    234  
    235 ol.simple, ul.simple { 
    236   margin-bottom: 1em } 
    237  
    238 ol.arabic { 
    239   list-style: decimal } 
    240  
    241 ol.loweralpha { 
    242   list-style: lower-alpha } 
    243  
    244 ol.upperalpha { 
    245   list-style: upper-alpha } 
    246  
    247 ol.lowerroman { 
    248   list-style: lower-roman } 
    249  
    250 ol.upperroman { 
    251   list-style: upper-roman } 
    252  
    253 p.attribution { 
    254   text-align: right ; 
    255   margin-left: 50% } 
    256  
    257 p.caption { 
    258   font-style: italic } 
    259  
    260 p.credits { 
    261   font-style: italic ; 
    262   font-size: smaller } 
    263  
    264 p.label { 
    265   white-space: nowrap } 
    266  
    267 p.rubric { 
    268   font-weight: bold ; 
    269   font-size: larger ; 
    270   color: maroon ; 
    271   text-align: center } 
    272  
    273 p.sidebar-title { 
    274   font-family: sans-serif ; 
    275   font-weight: bold ; 
    276   font-size: larger } 
    277  
    278 p.sidebar-subtitle { 
    279   font-family: sans-serif ; 
    280   font-weight: bold } 
    281  
    282 p.topic-title { 
    283   font-family: sans-serif ; 
    284   font-weight: bold } 
    285  
    286 pre.address { 
    287   margin-bottom: 0 ; 
    288   margin-top: 0 ; 
    289   font-family: serif ; 
    290   font-size: 100% } 
    291  
    292 pre.literal-block, pre.doctest-block { 
    293   margin-left: 2em ; 
    294   margin-right: 2em } 
    295  
    296 span.classifier { 
    297   font-family: sans-serif ; 
    298   font-style: oblique } 
    299  
    300 span.classifier-delimiter { 
    301   font-family: sans-serif ; 
    302   font-weight: bold } 
    303  
    304 span.interpreted { 
    305   font-family: sans-serif } 
    306  
    307 span.option { 
    308   white-space: nowrap } 
    309  
    310 span.option-argument { 
    311   font-style: italic } 
    312  
    313 span.pre { 
    314   white-space: pre } 
    315  
    316 span.problematic { 
    317   color: red } 
    318  
    319 span.section-subtitle { 
    320   /* font-size relative to parent (h1..h6 element) */ 
    321   font-size: 80% } 
    322  
    323 table.citation { 
    324   border-left: solid 1px gray; 
    325   margin-left: 1px } 
    326  
    327 table.docinfo { 
    328   margin: 2em 4em } 
    329  
    330 table.docutils { 
    331   margin-top: 0.5em ; 
    332   margin-bottom: 0.5em } 
    333  
    334 table.footnote { 
    335   border-left: solid 1px black; 
    336   margin-left: 1px } 
    337  
    338 table.docutils td, table.docutils th, 
    339 table.docinfo td, table.docinfo th { 
    340   padding-left: 0.5em ; 
    341   padding-right: 0.5em ; 
    342   vertical-align: top } 
    343  
    344 td.num { 
    345   text-align: right } 
    346  
    347 th.field-name { 
    348   font-weight: bold ; 
    349   text-align: left ; 
    350   white-space: nowrap ; 
    351   padding-left: 0 } 
    352  
    353 h1 tt.docutils, h2 tt.docutils, h3 tt.docutils, 
    354 h4 tt.docutils, h5 tt.docutils, h6 tt.docutils { 
    355   font-size: 100% } 
    356  
    357 ul.auto-toc { 
    358   list-style-type: none } 
    359  
    360 </style> 
    361 </head> 
    362 <body bgcolor="white"> 
    363 <table class="navigation" cellpadding="0" cellspacing="0" 
    364        width="100%" border="0"> 
    365 <tr><td class="navicon" width="150" height="35"> 
    366 <!--<a href="http://www.python.org/" title="Python Home Page"> 
    367 <img src="http://www.python.org/pics/PyBanner037.gif" alt="[Python]" 
    368  border="0" width="150" height="35" /></a></td> 
    369 <td class="textlinks" align="left"> 
    370 [<b><a href="http://www.bittorrent.org/">bittorrent.org</a></b>]--> 
    371 [<b><a href="http://www.bittorrent.org/beps/">BEP Index</a></b>] 
    372 [<b><a href="./bep-0002.txt">BEP Source</a></b>] 
    373 </td></tr></table> 
    374 <div class="document"> 
    375 <table class="rfc2822 docutils field-list" frame="void" rules="none"> 
    376 <col class="field-name" /> 
    377 <col class="field-body" /> 
    378 <tbody valign="top"> 
    379 <tr class="field"><th class="field-name">BEP:</th><td class="field-body">2</td> 
    380 </tr> 
    381 <tr class="field"><th class="field-name">Title:</th><td class="field-body">The BitTorrent Protocol Specification</td> 
    382 </tr> 
    383 <tr class="field"><th class="field-name">Version:</th><td class="field-body">2</td> 
    384 </tr> 
    385 <tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference external" href="https://svn.bittorrent.com/trac.cgi/browser/dotorg/trunk/html/beps/bep_0002.rst">11-Jan-2008</a></td> 
    386 </tr> 
    387 <tr class="field"><th class="field-name">Author:</th><td class="field-body">Bram Cohen</td> 
    388 </tr> 
    389 <tr class="field"><th class="field-name">Status:</th><td class="field-body">Final</td> 
    390 </tr> 
    391 <tr class="field"><th class="field-name">Type:</th><td class="field-body">Standard</td> 
    392 </tr> 
    393 <tr class="field"><th class="field-name">Created:</th><td class="field-body">10-Jan-2008</td> 
    394 </tr> 
    395 <tr class="field"><th class="field-name">Post-History:</th><td class="field-body"></td> 
    396 </tr> 
    397 </tbody> 
    398 </table> 
    399 <hr /> 
    400 <div class="contents topic" id="contents"> 
    401 <p class="topic-title first">Contents</p> 
    402 <ul class="simple"> 
    403 <li><a class="reference internal" href="#a-bittorrent-file-distribution-consists-of-these-entities" id="id2">A BitTorrent file distribution consists of these entities:</a></li> 
    404 <li><a class="reference internal" href="#to-start-serving-a-host-goes-through-the-following-steps" id="id3">To start serving, a host goes through the following steps:</a></li> 
    405 <li><a class="reference internal" href="#to-start-downloading-a-user-does-the-following" id="id4">To start downloading, a user does the following:</a></li> 
    406 <li><a class="reference internal" href="#the-connectivity-is-as-follows" id="id5">The connectivity is as follows:</a></li> 
    407 <li><a class="reference internal" href="#metainfo-files-are-bencoded-dictionaries-with-the-following-keys" id="id6">Metainfo files are bencoded dictionaries with the following keys:</a></li> 
    408 <li><a class="reference internal" href="#tracker-get-requests-have-the-following-keys" id="id7">Tracker GET requests have the following keys:</a></li> 
    409 <li><a class="reference internal" href="#all-non-keepalive-messages-start-with-a-single-byte-which-gives-their-type" id="id8">All non-keepalive messages start with a single byte which gives their type.</a></li> 
    410 <li><a class="reference internal" href="#the-possible-values-are" id="id9">The possible values are:</a></li> 
    411 </ul> 
    412 </div> 
    413 <p>BitTorrent is a protocol for distributing files. It identifies content 
    414 by URL and is designed to integrate seamlessly with the web. Its 
    415 advantage over plain HTTP is that when multiple downloads of the same 
    416 file happen concurrently, the downloaders upload to each other, making 
    417 it possible for the file source to support very large numbers of 
    418 downloaders with only a modest increase in its load.</p> 
    419 <div class="section" id="a-bittorrent-file-distribution-consists-of-these-entities"> 
    420 <h1><a class="toc-backref" href="#id2">A BitTorrent file distribution consists of these entities:</a></h1> 
    421 <ul class="simple"> 
    422 <li>An ordinary web server</li> 
    423 <li>A static 'metainfo' file</li> 
    424 <li>A BitTorrent tracker</li> 
    425 <li>An 'original' downloader</li> 
    426 <li>The end user web browsers</li> 
    427 <li>The end user downloaders</li> 
    428 </ul> 
    429 <p>There are ideally many end users for a single file.</p> 
    430 </div> 
    431 <div class="section" id="to-start-serving-a-host-goes-through-the-following-steps"> 
    432 <h1><a class="toc-backref" href="#id3">To start serving, a host goes through the following steps:</a></h1> 
    433 <ol class="arabic simple"> 
    434 <li>Start running a tracker (or, more likely, have one running already).</li> 
    435 <li>Start running an ordinary web server, such as apache, or have one already.</li> 
    436 <li>Associate the extension .torrent with mimetype application/x-bittorrent on their web server (or have done so already).</li> 
    437 <li>Generate a metainfo (.torrent) file using the complete file to be served and the URL of the tracker.</li> 
    438 <li>Put the metainfo file on the web server.</li> 
    439 <li>Link to the metainfo (.torrent) file from some other web page.</li> 
    440 <li>Start a downloader which already has the complete file (the 'origin').</li> 
    441 </ol> 
    442 </div> 
    443 <div class="section" id="to-start-downloading-a-user-does-the-following"> 
    444 <h1><a class="toc-backref" href="#id4">To start downloading, a user does the following:</a></h1> 
    445 <ol class="arabic simple"> 
    446 <li>Install BitTorrent (or have done so already).</li> 
    447 <li>Surf the web.</li> 
    448 <li>Click on a link to a .torrent file.</li> 
    449 <li>Select where to save the file locally, or select a partial download to resume.</li> 
    450 <li>Wait for download to complete.</li> 
    451 <li>Tell downloader to exit (it keeps uploading until this happens).</li> 
    452 </ol> 
    453 </div> 
    454 <div class="section" id="the-connectivity-is-as-follows"> 
    455 <h1><a class="toc-backref" href="#id5">The connectivity is as follows:</a></h1> 
    456 <ul class="simple"> 
    457 <li>Strings are length-prefixed base ten followed by a colon and the string. For example &lt;code&gt;4:spam&lt;/code&gt; corresponds to 'spam'.</li> 
    458 <li>Integers are represented by an 'i' followed by the number in base 10 
    459 followed by an 'e'. For example &lt;code&gt;i3e&lt;/code&gt; corresponds to 3 and 
    460 &lt;code&gt;i-3e &lt;/code&gt;corresponds to -3. Integers have no size 
    461 limitation. &lt;code&gt;i-0e&lt;/code&gt; is invalid. All encodings with a leading 
    462 zero, such as &lt;code&gt;i03e&lt;/code&gt;, are invalid, other than 
    463 &lt;code&gt;i0e&lt;/code&gt;, which of course corresponds to 0.</li> 
    464 <li>Lists are encoded as an 'l' followed by their elements (also 
    465 bencoded) followed by an 'e'. For example &lt;code&gt;l4:spam4:eggse&lt;/code&gt; 
    466 corresponds to ['spam', 'eggs'].</li> 
    467 <li>Dictionaries are encoded as a 'd' followed by a list of alternating 
    468 keys and their corresponding values followed by an 'e'. For example, 
    469 &lt;code&gt;d3:cow3:moo4:spam4:eggse&lt;/code&gt; corresponds to {'cow': 'moo', 
    470 'spam': 'eggs'} and &lt;code&gt;d4:spaml1:a1:bee&lt;/code&gt; corresponds to 
    471 {'spam': ['a', 'b']}. Keys must be strings and appear in sorted order 
    472 (sorted as raw strings, not alphanumerics).</li> 
    473 </ul> 
    474 </div> 
    475 <div class="section" id="metainfo-files-are-bencoded-dictionaries-with-the-following-keys"> 
    476 <h1><a class="toc-backref" href="#id6">Metainfo files are bencoded dictionaries with the following keys:</a></h1> 
    477 <dl class="docutils"> 
    478 <dt>announce</dt> 
    479 <dd>The URL of the tracker.</dd> 
    480 <dt>info</dt> 
    481 <dd><p class="first">This maps to a dictionary, with keys described below.</p> 
    482 <p>The &lt;code&gt;name&lt;/code&gt; key maps to a string which is the suggested name 
    483 to save the file (or directory) as. It is purely advisory.</p> 
    484 <p>&lt;code&gt;piece length&lt;/code&gt; maps to the number of bytes in each piece 
    485 the file is split into. For the purposes of transfer, files are 
    486 split into fixed-size pieces which are all the same length except for 
    487 possibly the last one which may be truncated. &lt;code&gt;piece 
    488 length&lt;/code&gt; is almost always a power of two, most commonly 2 18 = 
    489 256 K (BitTorrent prior to version 3.2 uses 2 20 = 1 M as 
    490 default).</p> 
    491 <p>&lt;code&gt;pieces&lt;/code&gt; maps to a string whose length is a multiple of 
    492 20. It is to be subdivided into strings of length 20, each of which is 
    493 the SHA1 hash of the piece at the corresponding index.</p> 
    494 <p>There is also a key &lt;code&gt;length&lt;/code&gt; or a key &lt;code&gt;files&lt;/code&gt;, 
    495 but not both or neither. If &lt;code&gt;length&lt;/code&gt; is present then the 
    496 download represents a single file, otherwise it represents a set of 
    497 files which go in a directory structure.</p> 
    498 <p>In the single file case, &lt;code&gt;length&lt;/code&gt; maps to the length of 
    499 the file in bytes.</p> 
    500 <p>For the purposes of the other keys, the multi-file case is treated as 
    501 only having a single file by concatenating the files in the order they 
    502 appear in the files list. The files list is the value 
    503 &lt;code&gt;files&lt;/code&gt; maps to, and is a list of dictionaries containing 
    504 the following keys:</p> 
    505 <p>&lt;code&gt;length&lt;/code&gt; - The length of the file, in bytes.</p> 
    506 <p>&lt;code&gt;path&lt;/code&gt; - A list of strings corresponding to subdirectory 
    507 names, the last of which is the actual file name (a zero length list 
    508 is an error case).</p> 
    509 <p class="last">In the single file case, the name key is the name of a file, in the 
    510 muliple file case, it's the name of a directory.</p> 
    511 </dd> 
    512 </dl> 
    513 </div> 
    514 <div class="section" id="tracker-get-requests-have-the-following-keys"> 
    515 <h1><a class="toc-backref" href="#id7">Tracker GET requests have the following keys:</a></h1> 
    516 <dl class="docutils"> 
    517 <dt>info_hash</dt> 
    518 <dd>The 20 byte sha1 hash of the bencoded form of the info value from the 
    519 metainfo file. Note that this is a substring of the metainfo 
    520 file. This value will almost certainly have to be escaped.</dd> 
    521 <dt>peer_id</dt> 
    522 <dd>A string of length 20 which this downloader uses as its id. Each 
    523 downloader generates its own id at random at the start of a new 
    524 download. This value will also almost certainly have to be escaped.</dd> 
    525 <dt>ip</dt> 
    526 <dd>An optional parameter giving the IP (or dns name) which this peer is 
    527 at. Generally used for the origin if it's on the same machine as the 
    528 tracker.</dd> 
    529 <dt>port</dt> 
    530 <dd>The port number this peer is listening on. Common behavior is for a 
    531 downloader to try to listen on port 6881 and if that port is taken try 
    532 6882, then 6883, etc. and give up after 6889.</dd> 
    533 <dt>uploaded</dt> 
    534 <dd>The total amount uploaded so far, encoded in base ten ascii.</dd> 
    535 <dt>downloaded</dt> 
    536 <dd>The total amount downloaded so far, encoded in base ten ascii.</dd> 
    537 <dt>left</dt> 
    538 <dd>The number of bytes this peer still has to download, encoded in 
    539 base ten ascii. Note that this can't be computed from downloaded and 
    540 the file length since it might be a resume, and there's a chance that 
    541 some of the downloaded data failed an integrity check and had to be 
    542 re-downloaded.</dd> 
    543 <dt>event</dt> 
    544 <dd>This is an optional key which maps to &lt;code&gt;started&lt;/code&gt;, 
    545 &lt;code&gt;completed&lt;/code&gt;, or &lt;code&gt;stopped&lt;/code&gt; (or 
    546 &lt;code&gt;empty&lt;/code&gt;, which is the same as not being present). If not 
    547 present, this is one of the announcements done at regular 
    548 intervals. An announcement using &lt;code&gt;started&lt;/code&gt; is sent when a 
    549 download first begins, and one using &lt;code&gt;completed&lt;/code&gt; is sent 
    550 when the download is complete. No &lt;code&gt;completed&lt;/code&gt; is sent if 
    551 the file was complete when started. Downloaders send an announcement 
    552 using &lt;code&gt;stopped&lt;/code&gt; when they cease downloading.</dd> 
    553 </dl> 
    554 <p>Tracker responses are bencoded dictionaries. If a tracker response 
    555 has a key &lt;code&gt;failure reason&lt;/code&gt;, then that maps to a human 
    556 readable string which explains why the query failed, and no other keys 
    557 are required. Otherwise, it must have two keys: &lt;code&gt;interval&lt;/code&gt;, 
    558 which maps to the number of seconds the downloader should wait between 
    559 regular rerequests, and &lt;code&gt;peers&lt;/code&gt;. &lt;code&gt;peers&lt;/code&gt; maps to 
    560 a list of dictionaries corresponding to &lt;code&gt;peers&lt;/code&gt;, each of 
    561 which contains the keys &lt;code&gt;peer id&lt;/code&gt;, &lt;code&gt;ip&lt;/code&gt;, and 
    562 &lt;code&gt;port&lt;/code&gt;, which map to the peer's self-selected ID, IP 
    563 address or dns name as a string, and port number, respectively. Note 
    564 that downloaders may rerequest on nonscheduled times if an event 
    565 happens or they need more peers.</p> 
    566 <p>If you want to make any extensions to metainfo files or tracker 
    567 queries, please coordinate with Bram Cohen to make sure that all 
    568 extensions are done compatibly.</p> 
    569 <p>BitTorrent's peer protocol operates over TCP. It performs efficiently 
    570 without setting any socket options.</p> 
    571 <p>Peer connections are symmetrical. Messages sent in both directions 
    572 look the same, and data can flow in either direction.</p> 
    573 <p>The peer protocol refers to pieces of the file by index as 
    574 described in the metainfo file, starting at zero. When a peer finishes 
    575 downloading a piece and checks that the hash matches, it announces 
    576 that it has that piece to all of its peers.</p> 
    577 <p>Connections contain two bits of state on either end: choked or not, 
    578 and interested or not. Choking is a notification that no data will be 
    579 sent until unchoking happens. The reasoning and common techniques 
    580 behind choking are explained later in this document.</p> 
    581 <p>Data transfer takes place whenever one side is interested and the 
    582 other side is not choking. Interest state must be kept up to date at 
    583 all times - whenever a downloader doesn't have something they 
    584 currently would ask a peer for in unchoked, they must express lack of 
    585 interest, despite being choked. Implementing this properly is tricky, 
    586 but makes it possible for downloaders to know which peers will start 
    587 downloading immediately if unchoked.</p> 
    588 <p>Connections start out choked and not interested.</p> 
    589 <p>When data is being transferred, downloaders should keep several 
    590 piece requests queued up at once in order to get good TCP performance 
    591 (this is called 'pipelining'.) On the other side, requests which can't 
    592 be written out to the TCP buffer immediately should be queued up in 
    593 memory rather than kept in an application-level network buffer, so 
    594 they can all be thrown out when a choke happens.</p> 
    595 <p>The peer wire protocol consists of a handshake followed by a 
    596 never-ending stream of length-prefixed messages. The handshake starts 
    597 with character ninteen (decimal) followed by the string 'BitTorrent 
    598 protocol'. The leading character is a length prefix, put there in the 
    599 hope that other new protocols may do the same and thus be trivially 
    600 distinguishable from each other.</p> 
    601 <p>All later integers sent in the protocol are encoded as four bytes 
    602 big-endian.</p> 
    603 <p>After the fixed headers come eight reserved bytes, which are all 
    604 zero in all current implementations. If you wish to extend the 
    605 protocol using these bytes, please coordinate with Bram Cohen to make 
    606 sure all extensions are done compatibly.</p> 
    607 <p>Next comes the 20 byte sha1 hash of the bencoded form of the info 
    608 value from the metainfo file. (This is the same value which is 
    609 announced as &lt;code&gt;info_hash&lt;/code&gt; to the tracker, only here it's raw 
    610 instead of quoted here). If both sides don't send the same value, they 
    611 sever the connection. The one possible exception is if a downloader 
    612 wants to do multiple downloads over a single port, they may wait for 
    613 incoming connections to give a download hash first, and respond with 
    614 the same one if it's in their list.</p> 
    615 <p>After the download hash comes the 20-byte peer id which is reported 
    616 in tracker requests and contained in peer lists in tracker 
    617 responses. If the receiving side's peer id doesn't match the one the 
    618 initiating side expects, it severs the connection.</p> 
    619 <p>That's it for handshaking, next comes an alternating stream of 
    620 length prefixes and messages. Messages of length zero are keepalives, 
    621 and ignored. Keepalives are generally sent once every two minutes, but 
    622 note that timeouts can be done much more quickly when data is 
    623 expected.</p> 
    624 </div> 
    625 <div class="section" id="all-non-keepalive-messages-start-with-a-single-byte-which-gives-their-type"> 
    626 <h1><a class="toc-backref" href="#id8">All non-keepalive messages start with a single byte which gives their type.</a></h1> 
    627 </div> 
    628 <div class="section" id="the-possible-values-are"> 
    629 <h1><a class="toc-backref" href="#id9">The possible values are:</a></h1> 
    630 <ul class="simple"> 
    631 <li>0 - choke</li> 
    632 <li>1 - unchoke</li> 
    633 <li>2 - interested</li> 
    634 <li>3 - not interested</li> 
    635 <li>4 - have</li> 
    636 <li>5 - bitfield</li> 
    637 <li>6 - request</li> 
    638 <li>7 - piece</li> 
    639 <li>8 - cancel</li> 
    640 </ul> 
    641 <p>'choke', 'unchoke', 'interested', and 'not interested' have no payload.</p> 
    642 <p>'bitfield' is only ever sent as the first message. Its payload is a 
    643 bitfield with each index that downloader has sent set to one and the 
    644 rest set to zero. Downloaders which don't have anything yet may skip 
    645 the 'bitfield' message. The first byte of the bitfield corresponds to 
    646 indices 0 - 7 from high bit to low bit, respectively. The next one 
    647 8-15, etc. Spare bits at the end are set to zero.</p> 
    648 <p>The 'have' message's payload is a single number, the index which 
    649 that downloader just completed and checked the hash of.</p> 
    650 <p>'request' messages contain an index, begin, and length. The last 
    651 two are byte offsets. Length is generally a power of two unless it 
    652 gets truncated by the end of the file. All current implementations use 
    653 2 15 , and close connections which request an amount greater than 2 
    654 17.</p> 
    655 <p>'cancel' messages have the same payload as request messages. They 
    656 are generally only sent towards the end of a download, during what's 
    657 called 'endgame mode'. When a download is almost complete, there's a 
    658 tendency for the last few pieces to all be downloaded off a single 
    659 hosed modem line, taking a very long time. To make sure the last few 
    660 pieces come in quickly, once requests for all pieces a given 
    661 downloader doesn't have yet are currently pending, it sends requests 
    662 for everything to everyone it's downloading from. To keep this from 
    663 becoming horribly inefficient, it sends cancels to everyone else every 
    664 time a piece arrives.</p> 
    665 <p>'piece' messages contain an index, begin, and piece. Note that they 
    666 are correlated with request messages implicitly. It's possible for an 
    667 unexpected piece to arrive if choke and unchoke messages are sent in 
    668 quick succession and/or transfer is going very slowly.</p> 
    669 <p>Downloaders generally download pieces in random order, which does a 
    670 reasonably good job of keeping them from having a strict subset or 
    671 superset of the pieces of any of their peers.</p> 
    672 <p>Choking is done for several reasons. TCP congestion control behaves 
    673 very poorly when sending over many connections at once. Also, choking 
    674 lets each peer use a tit-for-tat-ish algorithm to ensure that they get 
    675 a consistent download rate.</p> 
    676 <p>The choking algorithm described below is the currently deployed 
    677 one. It is very important that all new algorithms work well both in a 
    678 network consisting entirely of themselves and in a network consisting 
    679 mostly of this one.</p> 
    680 <p>There are several criteria a good choking algorithm should meet. It 
    681 should cap the number of simultaneous uploads for good TCP 
    682 performance. It should avoid choking and unchoking quickly, known as 
    683 'fibrillation'. It should reciprocate to peers who let it 
    684 download. Finally, it should try out unused connections once in a 
    685 while to find out if they might be better than the currently used 
    686 ones, known as optimistic unchoking.</p> 
    687 <p>The currently deployed choking algorithm avoids fibrillation by 
    688 only changing who's choked once every ten seconds. It does 
    689 reciprocation and number of uploads capping by unchoking the four 
    690 peers which it has the best download rates from and are 
    691 interested. Peers which have a better upload rate but aren't 
    692 interested get unchoked and if they become interested the worst 
    693 uploader gets choked. If a downloader has a complete file, it uses its 
    694 upload rate rather than its download rate to decide who to 
    695 unchoke.</p> 
    696 <p>For optimistic unchoking, at any one time there is a single peer 
    697 which is unchoked regardless of it's upload rate (if interested, it 
    698 counts as one of the four allowed downloaders.) Which peer is 
    699 optimistically unchoked rotates every 30 seconds. To give them a 
    700 decent chance of getting a complete piece to upload, new connections 
    701 are three times as likely to start as the current optimistic unchoke 
    702 as anywhere else in the rotation.</p> 
    703 </div> 
    704  
    705 </div> 
    706 </body> 
    707 </html> 
Note: See TracChangeset for help on using the changeset viewer.