Changeset 10505

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

Further work conforming standards documents to the BEP process.

Location:
dotorg/trunk/html/beps
Files:
8 removed
6 modified
1 moved

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> 

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

    r10416 r10505  
    33Version: 2 
    44Last-Modified: 11-Jan-2008 
    5 Author:  Bram Cohen 
     5Author:  Bram Cohen <bram@bittorrent.com> 
    66Status:  Final 
    77Type:    Standard 

  • dotorg/trunk/html/beps/bep_0004.rst

    r10504 r10505  
    33Version: 2 
    44Last-Modified: 11-Jan-2008 
    5 Author:  Andrew Loewenstern  
    6 Status:  Final 
    7 Type:    Standard 
     5Author:  Andrew Loewenstern <drue@bittorrent.com> 
     6Status:  Accepted 
     7Type:    Standards Track 
    88Created: 31-Jan-2008 
    99Post-History: 
    1010 
    11 ------------ 
    12 DHT Protocol 
    13 <p>BitTorrent uses a "distributed sloppy hash table" (DHT) for storing peer contact information for "trackerless" torrents. In effect, each peer becomes a tracker. The protocol is based on Kademila and is implemented over UDP.</p> 
    14 <p>Please note the terminology used in this document to avoid confusion. A "peer" is a client/server listening on a TCP port that implements the BitTorrent protocol. A "node" is a client/server listening on a UDP port implementing the distributed hash table protocol. The DHT is composed of nodes and stores the location of peers. BitTorrent clients include a DHT node, which is used to contact other nodes in the DHT to get the location of peers to download from using the BitTorrent protocol.</p> 
    15 <h3>Contents</h3> 
    16 <ul> 
    17 <li><a href="#Overview">1 Overview</a></li> 
    18 <li><a href="#Routing_Table">2 Routing Table</a></li> 
    19 <li><a href="#BitTorrent_Protocol_Extension">3 BitTorrent Protocol Extension</a></li> 
    20 <li><a href="#Torrent_File_Extensions">4 Torrent File Extensions</a></li> 
    21 <li><a href="#KRPC_Protocol">5 KRPC Protocol</a> 
    22 <ul> 
    23 <li><a href="#Contact_Encoding">5.1 Contact Encoding</a></li> 
    24 <li><a href="#Queries">5.2 Queries</a></li> 
    25 <li><a href="#Responses">5.3 Responses</a></li> 
    26 <li><a href="#Errors">5.4 Errors</a> 
    27 <ul> 
    28 <li><a href="#Example_Error_Packets">5.4.1 Example Error Packets</a></li> 
    29 </ul> 
    30 </li> 
    31 </ul> 
    32 </li> 
    33 <li><a href="#DHT_Queries">6 DHT Queries</a> 
    34 <ul> 
    35 <li><a href="#ping">6.1 ping</a> 
    36 <ul> 
    37 <li><a href="#example_packets">6.1.1 Example Packets</a></li> 
    38 </ul> 
    39 </li> 
    40 <li><a href="#find_node">6.2 find_node</a> 
    41 <ul> 
    42 <li><a href="#example_packets_2">6.2.1 Example Packets</a></li> 
    43 </ul> 
    44 </li> 
    45 <li><a href="#get_peers">6.3 get_peers</a> 
    46 <ul> 
    47 <li><a href="#example_packets_3">6.3.1 Example Packets</a></li> 
    48 </ul> 
    49 </li> 
    50 <li><a href="#announce_peer">6.4 announce_peer</a> 
    51 <ul> 
    52 <li><a href="#example_packets_4">6.4.1 Example Packets</a></li> 
    53 </ul> 
    54 </li> 
    55 </ul> 
    56 </li> 
    57 <li><a href="#Footnotes">7 Footnotes</a></li> 
    58 </ul> 
    59 <a name="Overview"></a> 
    60 <h3>Overview</h3> 
    61 <p>Each node has a globally unique identifier known as the "node ID." 
     11BitTorrent uses a "distributed sloppy hash table" (DHT) for storing 
     12peer contact information for "trackerless" torrents. In effect, each 
     13peer becomes a tracker. The protocol is based on Kademila[Kademlia]_ and is 
     14implemented over UDP. 
     15 
     16Please note the terminology used in this document to avoid 
     17confusion. A "peer" is a client/server listening on a TCP port that 
     18implements the BitTorrent protocol. A "node" is a client/server 
     19listening on a UDP port implementing the distributed hash table 
     20protocol. The DHT is composed of nodes and stores the location of 
     21peers. BitTorrent clients include a DHT node, which is used to contact 
     22other nodes in the DHT to get the location of peers to download from 
     23using the BitTorrent protocol. 
     24 
     25Overview 
     26-------- 
     27 
     28Each node has a globally unique identifier known as the "node ID." 
    6229Node IDs are chosen at random from the same 160-bit space as BitTorrent 
    63 infohashes.  A "distance metric" is used to compare two node IDs or a node  
     30infohashes [#entropy]_.  A "distance metric" is used to compare two node IDs or a node  
    6431ID and an infohash for "closeness." Nodes must maintain a routing table 
    6532containing the contact information for a small number of other nodes. 
    … …  
    6734own ID. Nodes know about many other nodes in the DHT that have IDs that 
    6835are "close" to their own but have only a handful of contacts with IDs 
    69 that are very far away from their own.</p> 
    70 <p>In Kademlia, the distance metric is XOR and the result is 
    71 interpreted as an unsigned integer. distance(A,B) = |A ⊗ B| Smaller 
    72 values are closer.</p> 
    73 <p>When a node wants to find peers for a torrent, it uses the 
    74 distance metric to compare the infohash of the torrent with the IDs of 
    75 the nodes in its own routing table. It then contacts the nodes it knows 
     36that are very far away from their own. 
     37 
     38In Kademlia, the distance metric is XOR and the result is interpreted 
     39as an unsigned integer. ``distance(A,B) = |A xor B|`` Smaller values 
     40are closer. 
     41 
     42When a node wants to find peers for a torrent, it uses the distance 
     43metric to compare the infohash of the torrent with the IDs of the 
     44nodes in its own routing table. It then contacts the nodes it knows 
    7645about with IDs closest to the infohash and asks them for the contact 
    7746information of peers currently downloading the torrent. If a contacted 
    78 node knows about peers for the torrent, the peer contact information is 
    79 returned with the response. Otherwise, the contacted node must respond 
    80 with the contact information of the nodes in its routing table that are 
    81 closest to the infohash of the torrent. The original node iteratively 
    82 queries nodes that are closer to the target infohash until it cannot 
    83 find any closer nodes. After the search is exhausted, the client then 
    84 inserts the peer contact information for itself onto the responding 
    85 nodes with IDs closest to the infohash of the torrent.</p> 
    86 <p>The return value for a query for peers includes an opaque value 
    87 known as the "token." For a node to announce that its controlling peer 
    88 is downloading a torrent, it must present the token received from the 
     47node knows about peers for the torrent, the peer contact information 
     48is returned with the response. Otherwise, the contacted node must 
     49respond with the contact information of the nodes in its routing table 
     50that are closest to the infohash of the torrent. The original node 
     51iteratively queries nodes that are closer to the target infohash until 
     52it cannot find any closer nodes. After the search is exhausted, the 
     53client then inserts the peer contact information for itself onto the 
     54responding nodes with IDs closest to the infohash of the torrent. 
     55 
     56The return value for a query for peers includes an opaque value known 
     57as the "token." For a node to announce that its controlling peer is 
     58downloading a torrent, it must present the token received from the 
    8959same queried node in a recent query for peers. When a node attempts to 
    9060"announce" a torrent, the queried node checks the token against the 
    9161querying node's IP address. This is to prevent malicious hosts from 
    92 signing up other hosts for torrents. Since the token is merely returned 
    93 by the querying node to the same node it received the token from, the 
    94 implementation is not defined. Tokens must be accepted for a reasonable 
    95 amount of time after they have been distributed. The BitTorrent 
    96 implementation uses the SHA1 hash of the IP address concatenated onto a 
    97 secret that changes every five minutes and tokens up to ten minutes old 
    98 are accepted.</p> 
    99 <a name="Routing_Table"></a> 
    100 <h3>Routing Table</h3> 
    101 <p>Every node maintains a routing table of known good nodes. The nodes 
    102 in the routing table are used as starting points for queries in the 
     62signing up other hosts for torrents. Since the token is merely 
     63returned by the querying node to the same node it received the token 
     64from, the implementation is not defined. Tokens must be accepted for a 
     65reasonable amount of time after they have been distributed. The 
     66BitTorrent implementation uses the SHA1 hash of the IP address 
     67concatenated onto a secret that changes every five minutes and tokens 
     68up to ten minutes old are accepted. 
     69 
     70 
     71Routing Table 
     72------------- 
     73 
     74Every node maintains a routing table of known good nodes. The nodes in 
     75the routing table are used as starting points for queries in the 
    10376DHT. Nodes from the routing table are returned in response to queries 
    104 from other nodes.</p> 
    105 <p>Not all nodes that we learn about are equal. Some are "good" 
    106 and some are not. Many nodes using the DHT are able to send queries and 
    107 receive responses, but are not able to respond to queries from other 
    108 nodes. It is important that each node's routing table must contain only 
    109 known good nodes. A good node is a node has responded to one of our 
    110 queries within the last 15 minutes. A node is also good if it has ever 
    111 responded to one of our queries and has sent us a query within the last 
    112 15 minutes. After 15 minutes of inactivity, a node becomes 
     77from other nodes. 
     78 
     79Not all nodes that we learn about are equal. Some are "good" and some 
     80are not. Many nodes using the DHT are able to send queries and receive 
     81responses, but are not able to respond to queries from other nodes. It 
     82is important that each node's routing table must contain only known 
     83good nodes. A good node is a node has responded to one of our queries 
     84within the last 15 minutes. A node is also good if it has ever 
     85responded to one of our queries and has sent us a query within the 
     86last 15 minutes. After 15 minutes of inactivity, a node becomes 
    11387questionable. Nodes become bad when they fail to respond to multiple 
    11488queries in a row. Nodes that we know are good are given priority over 
    115 nodes with unknown status.</p> 
    116 <p>The routing table covers the entire node ID space from 0 to 2<sup>160</sup>. 
    117 The routing table is subdivided into "buckets" that each cover a 
    118 portion of the space. An empty table has one bucket with an ID space 
    119 range of min=0, max=2<sup>160</sup>. When a node with ID "N" is 
    120 inserted into the table, it is placed within the bucket that has min 
    121 &lt;= N &lt; max. An empty table has only one bucket so any node must 
    122 fit within it. Each bucket can only hold K nodes, currently eight, 
    123 before becoming "full." When a bucket is full of known good nodes, no 
    124 more nodes may be added unless our own node ID falls within the range 
    125 of the bucket. In that case, the bucket is replaced by two new buckets 
    126 each with half the range of the old bucket and the nodes from the old 
    127 bucket are distributed among the two new ones. For a new table with 
    128 only one bucket, the full bucket is always split into two new buckets 
    129 covering the ranges 0..2<sup>159</sup> and 2<sup>159</sup>..2<sup>160</sup>.</p> 
    130 <p>When the bucket is full of good nodes, the new node is simply 
     89nodes with unknown status. 
     90 
     91The routing table covers the entire node ID space from 0 to 
     922\ :sup:`160`\ .  The routing table is subdivided into "buckets" that 
     93each cover a portion of the space. An empty table has one bucket with 
     94an ID space range of min=0, max=2\ :sup:`160`\ . When a node with ID 
     95"N" is inserted into the table, it is placed within the bucket that 
     96has min &lt;= N &lt; max. An empty table has only one bucket so any 
     97node must fit within it. Each bucket can only hold K nodes, currently 
     98eight, before becoming "full." When a bucket is full of known good 
     99nodes, no more nodes may be added unless our own node ID falls within 
     100the range of the bucket. In that case, the bucket is replaced by two 
     101new buckets each with half the range of the old bucket and the nodes 
     102from the old bucket are distributed among the two new ones. For a new 
     103table with only one bucket, the full bucket is always split into two 
     104new buckets covering the ranges 0..2\ :sup:`159`\  and 
     1052\ :sup:`159`\ ..2\ :sup:`160`\ . 
     106 
     107When the bucket is full of good nodes, the new node is simply 
    131108discarded. If any nodes in the bucket are known to have become bad, 
    132109then one is replaced by the new node. If there are any questionable 
    … …  
    138115suggested to try once more before discarding the node and replacing it 
    139116with a new good node. In this way, the table fills with stable long 
    140 running nodes.</p> 
    141 <p>Each bucket should maintain a "last changed" property to 
     117running nodes. 
     118 
     119Each bucket should maintain a "last changed" property to 
    142120indicate how "fresh" the contents are. When a node in a bucket is 
    143121pinged and it responds, or a node is added to a bucket, or a node in a 
    … …  
    150128from other nodes usually will need to refresh all buckets periodically 
    151129to ensure there are good nodes in their table when the DHT is needed. 
    152 </p><p>Upon inserting the first node into its routing table and when 
    153 starting up thereafter, the node should attempt to find the closest 
    154 nodes in the DHT to itself. It does this by issuing find_node messages 
    155 to closer and closer nodes until it cannot find any closer. The routing 
    156 table should be saved between invocations of the client software.</p> 
    157 <a name="BitTorrent_Protocol_Extension"></a> 
    158 <h3>BitTorrent Protocol Extension</h3> 
    159 <p>The BitTorrent protocol has been extended to exchange node UDP port 
     130 
     131Upon inserting the first node into its routing table and when starting 
     132up thereafter, the node should attempt to find the closest nodes in 
     133the DHT to itself. It does this by issuing find_node messages to 
     134closer and closer nodes until it cannot find any closer. The routing 
     135table should be saved between invocations of the client software. 
     136 
     137 
     138BitTorrent Protocol Extension 
     139----------------------------- 
     140 
     141The BitTorrent protocol has been extended to exchange node UDP port 
    160142numbers between peers that are introduced by a tracker. In this way, 
    161143clients can get their routing tables seeded automatically through the 
    162144download of regular torrents. Newly installed clients who attempt to 
    163 download a trackerless torrent on the first try will not have any nodes 
    164 in their routing table and will need the contacts included in the 
    165 torrent file.</p> 
    166 <p>Peers supporting the DHT set the last bit of the 8-byte 
    167 reserved flags exchanged in the BitTorrent protocol handshake. Peer 
    168 receiving a handshake indicating the remote peer supports the DHT 
    169 should send a PORT message. It begins with byte 0x09 and has a two byte 
    170 payload containing the UDP port of the DHT node in network byte order. 
    171 Peers that receive this message should attempt to ping the node on the 
     145download a trackerless torrent on the first try will not have any 
     146nodes in their routing table and will need the contacts included in 
     147the torrent file. 
     148 
     149Peers supporting the DHT set the last bit of the 8-byte reserved flags 
     150exchanged in the BitTorrent protocol handshake. Peer receiving a 
     151handshake indicating the remote peer supports the DHT should send a 
     152PORT message. It begins with byte 0x09 and has a two byte payload 
     153containing the UDP port of the DHT node in network byte order.  Peers 
     154that receive this message should attempt to ping the node on the 
    172155received port and IP address of the remote peer. If a response to the 
    173156ping is recieved, the node should attempt to insert the new contact 
    174 information into their routing table according to the usual rules.</p> 
    175 <a name="Torrent_File_Extensions"></a> 
    176 <h3>Torrent File Extensions</h3> 
    177 <p>A trackerless torrent dictionary does not have an "announce" key. 
     157information into their routing table according to the usual rules. 
     158 
     159 
     160Torrent File Extensions 
     161----------------------- 
     162 
     163A trackerless torrent dictionary does not have an "announce" key. 
    178164Instead, a trackerless torrent has a "nodes" key. This key should be 
    179165set to the K closest nodes in the torrent generating client's routing 
    180 table. Alternatively, the key could be set to a known good node such as 
    181 one operated by the person generating the torrent. Please do not 
     166table. Alternatively, the key could be set to a known good node such 
     167as one operated by the person generating the torrent. Please do not 
    182168automatically add "router.bittorrent.com" to torrent files or 
    183 automatically add this node to clients routing tables.</p> 
    184 <p><code>nodes = [["<i>&lt;host&gt;</i>", <i>&lt;port&gt;</i>], ["<i>&lt;host&gt;</i>", <i>&lt;port&gt;</i>], ...] 
    185 nodes = [["127.0.0.1", 6881], ["your.router.node", 4804]]</code></p> 
    186 <a name="KRPC_Protocol"></a> 
    187 <h3>KRPC Protocol</h3> 
    188 <p>The KRPC protocol is a simple RPC mechanism consisting of bencoded 
     169automatically add this node to clients routing tables. 
     170 
     171:: 
     172 
     173  nodes = [["<host>", <port>], ["<host>", <port>], ...] 
     174  nodes = [["127.0.0.1", 6881], ["your.router.node", 4804]] 
     175 
     176   
     177 
     178KRPC Protocol 
     179------------- 
     180 
     181The KRPC protocol is a simple RPC mechanism consisting of bencoded 
    189182dictionaries sent over UDP. A single query packet is sent out and a 
    190183single packet is sent in response. There is no retry. There are three 
    191184message types: query, response, and error. For the DHT protocol, there 
    192 are four queries: ping, find_node, get_peers, and announce_peer.</p> 
    193 <p>A KRPC message is a single dictionary with two keys common to 
     185are four queries: ping, find_node, get_peers, and announce_peer. 
     186 
     187A KRPC message is a single dictionary with two keys common to 
    194188every message and additional keys depending on the type of message. 
    195189Every message has a key "t" with a string value representing a transaction 
    … …  
    201195with a single character value describing the type of message. The value 
    202196of the "y" key is one of "q" for query, "r" for response, or "e" for 
    203 error.</p> 
    204 <a name="Contact_Encoding"></a> 
    205 <h4>Contact Encoding</h4> 
    206 <p>Contact information for peers is encoded as a 6-byte string. Also 
    207 known as "Compact IP-address/port info" the 4-byte IP address is in 
    208 network byte order with the 2 byte port in network byte order 
    209 concatenated onto the end.</p> 
    210 <p>Contact information for nodes is encoded as a 26-byte string. 
    211 Also known as "Compact node info" the 20-byte Node ID in network byte 
    212 order has the compact IP-address/port info concatenated to the end.</p> 
    213 <a name="Queries"></a> 
    214 <h4>Queries</h4> 
    215 <p>Queries, or KRPC message dictionaries with a "y" value of "q", 
    216 contain two additional keys; "q" and "a". Key "q" has a string value 
    217 containing the method name of the query. Key "a" has a dictionary value 
    218 containing named arguments to the query.</p> 
    219 <a name="Responses"></a> 
    220 <h4>Responses</h4> 
    221 <p>Responses, or KRPC message dictionaries with a "y" value of "r", 
    222 contain one additional key "r". The value of "r" is a dictionary 
    223 containing named return values. Response messages are sent upon 
    224 successful completion of a query.</p> 
    225 <a name="Errors"></a> 
    226 <h4>Errors</h4> 
    227 <p>Errors, or KRPC message dictionaries with a "y" value of "e", 
    228 contain one additional key "e". The value of "e" is a list. The first 
    229 element is an integer representing the error code. The second element 
    230 is a string containing the error message. Errors are sent when a query 
    231 cannot be fulfilled. The following table describes the possible error 
    232 codes:</p> 
    233 <table> 
    234 <tr> 
    235 <td class="shade">201</td><td class="shade">Generic Error</td> 
    236 </tr> 
    237 <tr> 
    238 <td>202</td><td>Server Error</td> 
    239 </tr> 
    240 <tr> 
    241 <td class="shade">203</td><td class="shade">Protocol Error, such as a malformed packet,<br />invalid arguments, or bad token</td> 
    242 </tr> 
    243 <tr> 
    244 <td>204</td><td>Method Unknown</td> 
    245 </tr> 
    246 </table> 
    247 <a name="Example_Error_Packets"></a> 
    248 <h5>Example Error Packets</h5> 
    249 <p><code>generic error = {"t":"aa", "y":"e", "e":[201, "A Generic Error Ocurred"]} 
    250 bencoded = d1:eli201e23:A Generic Error Ocurrede1:t2:aa1:y1:ee</code></p> 
    251 <a name="DHT_Queries"></a> 
    252 <h3>DHT Queries</h3> 
    253 <p>All queries have an "id" key and value containing the node ID of the 
     197error. 
     198 
     199Contact Encoding 
     200  Contact information for peers is encoded as a 6-byte string. Also 
     201  known as "Compact IP-address/port info" the 4-byte IP address is in 
     202  network byte order with the 2 byte port in network byte order 
     203  concatenated onto the end. 
     204 
     205  Contact information for nodes is encoded as a 26-byte string. 
     206  Also known as "Compact node info" the 20-byte Node ID in network byte 
     207  order has the compact IP-address/port info concatenated to the end. 
     208 
     209Queries 
     210  Queries, or KRPC message dictionaries with a "y" value of "q", 
     211  contain two additional keys; "q" and "a". Key "q" has a string value 
     212  containing the method name of the query. Key "a" has a dictionary value 
     213  containing named arguments to the query. 
     214 
     215Responses 
     216  Responses, or KRPC message dictionaries with a "y" value of "r", 
     217  contain one additional key "r". The value of "r" is a dictionary 
     218  containing named return values. Response messages are sent upon 
     219  successful completion of a query. 
     220 
     221Errors 
     222  Errors, or KRPC message dictionaries with a "y" value of "e", 
     223  contain one additional key "e". The value of "e" is a list. The first 
     224  element is an integer representing the error code. The second element 
     225  is a string containing the error message. Errors are sent when a query 
     226  cannot be fulfilled. The following table describes the possible error 
     227  codes: 
     228 
     229+----------+------------------------------------------+ 
     230|  Code    | Description                              | 
     231+----------+------------------------------------------+ 
     232|  201     |   Generic Error                          | 
     233+----------+------------------------------------------+ 
     234|  202     |   Server Error                           | 
     235+----------+------------------------------------------+ 
     236|  203     | Protocol Error, such as a malformed      | 
     237|          | packet, invalid arguments, or bad token  | 
     238+----------+------------------------------------------+ 
     239|  204     |   Method Unknown                         | 
     240+----------+------------------------------------------+ 
     241 
     242Example Error Packets: 
     243 
     244:: 
     245 
     246  generic error = {"t":"aa", "y":"e", "e":[201, "A Generic Error Ocurred"]} 
     247  bencoded = d1:eli201e23:A Generic Error Ocurrede1:t2:aa1:y1:ee 
     248 
     249   
     250DHT Queries 
     251----------- 
     252 
     253All queries have an "id" key and value containing the node ID of the 
    254254querying node. All responses have an "id" key and value containing the 
    255 node ID of the responding node.</p> 
    256 <a name="ping"></a> 
    257 <h4>ping</h4> 
    258 <p>The most basic query is a ping. "q" = "ping" A ping query has a 
    259 single argument, "id" the value is a 20-byte string containing the 
    260 senders node ID in network byte order. The appropriate response to a 
    261 ping has a single key "id" containing the node ID of the responding 
    262 node.</p> 
    263 <code><p>arguments:  {"id"&nbsp;: "<i>&lt;querying nodes id&gt;</i>"}</p> 
    264 <p>response: {"id"&nbsp;: "<i>&lt;queried nodes id&gt;</i>"}</p></code> 
    265 <a name="example_packets"></a> 
    266 <h5>Example Packets</h5> 
    267 <p><code>ping Query = {"t":"aa", "y":"q", "q":"ping", "a":{"id":"abcdefghij0123456789"}} 
    268  bencoded = d1:ad2:id20:abcdefghij0123456789e1:q4:ping1:t2:aa1:y1:qe</code></p> 
    269 <p><code> Response = {"t":"aa", "y":"r", "r": {"id":"mnopqrstuvwxyz123456"}} 
    270  bencoded = d1:rd2:id20:mnopqrstuvwxyz123456e1:t2:aa1:y1:re</code></p> 
    271 <a name="find_node"></a> 
    272 <h4>find_node</h4> 
    273 <p>Find node is used to find the contact information for a node given 
    274 its ID. "q" == "find_node" A find_node query has two arguments, "id" 
    275 containing the node ID of the querying node, and "target" containing 
    276 the ID of the node sought by the queryer. When a node receives a 
    277 find_node query, it should respond with a key "nodes" and value of a 
    278 string containing the compact node info for the target node or the K 
    279 (8) closest good nodes in its own routing table.</p> 
    280 <code><p>arguments:  {"id"&nbsp;: "<i>&lt;querying nodes id&gt;</i>", "target"&nbsp;: "<i>&lt;id of target node&gt;</i>"}</p> 
    281 <p>response: {"id"&nbsp;: "<i>&lt;queried nodes id&gt;</i>", "nodes"&nbsp;: "<i>&lt;compact node info&gt;</i>"}</p></code> 
    282 <a name="example_packets_2"></a> 
    283 <h5>Example Packets</h5> 
    284 <p><code>find_node Query = {"t":"aa", "y":"q", "q":"find_node", "a": {"id":"abcdefghij0123456789", "target":"mnopqrstuvwxyz123456"}} 
    285 bencoded = d1:ad2:id20:abcdefghij01234567896:target20:mnopqrstuvwxyz123456e1:q9:find_node1:t2:aa1:y1:qe</code></p> 
    286 <p><code>Response = {"t":"aa", "y":"r", "r": {"id":"0123456789abcdefghij", "nodes": "def456..."}} 
    287 bencoded = d1:rd2:id20:0123456789abcdefghij5:nodes9:def456...e1:t2:aa1:y1:re</code></p> 
    288 <a name="get_peers"></a> 
    289 <h4>get_peers</h4> 
    290 <p>Get peers associated with a torrent infohash. "q" = "get_peers" A 
    291 get_peers query has two arguments, "id" containing the node ID of the 
    292 querying node, and "info_hash" containing the infohash of the torrent. 
    293 If the queried node has peers for the infohash, they are returned in a 
    294 key "values" as a list of strings. Each string containing "compact" format 
    295 peer information for a single peer. If the queried node has no 
    296 peers for the infohash, a key "nodes" is returned containing the K 
    297 nodes in the queried nodes routing table closest to the infohash 
    298 supplied in the query. In either case a "token" key is also included in 
    299 the return value. The token value is a required argument for a future 
    300 announce_peer query. The token value should be a short binary string.</p> 
    301 <code><p>arguments:  {"id"&nbsp;: "<i>&lt;querying nodes id&gt;</i>", "info_hash"&nbsp;: "<i>&lt;20-byte infohash of target torrent&gt;</i>"}</p> 
    302 <p>response: {"id"&nbsp;: "<i>&lt;queried nodes id&gt;</i>", "token"&nbsp;:"<i>&lt;opaque write token&gt;</i>", "values"&nbsp;: ["<i>&lt;peer 1 info string&gt;</i>", "<i>&lt;peer 2 info string&gt;</i>"]}</p> 
    303 <p>or: {"id"&nbsp;: "<i>&lt;queried nodes id&gt;</i>", "token"&nbsp;:"<i>&lt;opaque write token&gt;</i>", "nodes"&nbsp;: "<i>&lt;compact node info&gt;</i>"}</p></code> 
    304 <a name="example_packets_3"></a> 
    305 <h5>Example Packets</h5> 
    306 <p><code>get_peers Query = {"t":"aa", "y":"q", "q":"get_peers", "a": {"id":"abcdefghij0123456789", "info_hash":"mnopqrstuvwxyz123456"}} 
    307 bencoded = d1:ad2:id20:abcdefghij01234567899:info_hash20:mnopqrstuvwxyz123456e1:q9:get_peers1:t2:aa1:y1:qe</code></p> 
    308 <p><code>Response with peers = {"t":"aa", "y":"r", "r": {"id":"abcdefghij0123456789", "token":"aoeusnth", "values": ["axje.u", "idhtnm"]}} 
    309 bencoded = d1:rd2:id20:abcdefghij01234567895:token8:aoeusnth6:valuesl6:axje.u6:idhtnmee1:t2:aa1:y1:re</code></p> 
    310 <p><code>Response with closest nodes = {"t":"aa", "y":"r", "r": {"id":"abcdefghij0123456789", "token":"aoeusnth", "nodes": "def456..."}} 
    311 bencoded = d1:rd2:id20:abcdefghij01234567895:nodes9:def456...5:token8:aoeusnthe1:t2:aa1:y1:re</code></p> 
    312 <a name="announce_peer"></a> 
    313 <h4>announce_peer</h4>  
    314 <p>Announce that the peer, controlling the querying node, is downloading 
    315 a torrent on a port. announce_peer has four arguments: "id" containing the node ID of the 
    316 querying node, "info_hash" containing the infohash of the torrent, 
    317 "port" containing the port as an integer, and the "token" received in 
    318 response to a previous get_peers query. The queried node must verify 
    319 that the token was previously sent to the same IP address as the 
    320 querying node. Then the queried node should store the IP address of the 
    321 querying node and the supplied port number under the infohash in its 
    322 store of peer contact information.</p> 
    323 <code><p>arguments:  {"id"&nbsp;: "<i>&lt;querying nodes id&gt;</i>", "info_hash"&nbsp;: "<i>&lt;20-byte infohash of target torrent&gt;</i>", "port"&nbsp;: <i>&lt;port number&gt;</i>, "token"&nbsp;: "<i>&lt;opaque token&gt;</i>"}</p> 
    324 <p>response: {"id"&nbsp;: "<i>&lt;queried nodes id&gt;</i>"}</p></code> 
    325 <a name="example_packets_4"></a> 
    326 <h5>Example Packets</h5> 
    327 <p><code>announce_peers Query = {"t":"aa", "y":"q", "q":"announce_peer", "a": {"id":"abcdefghij0123456789", "info_hash":"mnopqrstuvwxyz123456", "port": 6881, "token": "aoeusnth"}} 
    328 bencoded = d1:ad2:id20:abcdefghij01234567899:info_hash20:<br /> 
    329 mnopqrstuvwxyz1234564:porti6881e5:token8:aoeusnthe1:q13:announce_peer1:t2:aa1:y1:qe</code></p> 
    330 <p><code>Response = {"t":"aa", "y":"r", "r": {"id":"mnopqrstuvwxyz123456"}} 
    331 bencoded = d1:rd2:id20:mnopqrstuvwxyz123456e1:t2:aa1:y1:re</code></p> 
    332 <p>Send questions, comments and corrections to editor@bittorrent.org</p> 
    333 <a name="Footnotes"></a> 
    334 <h3>Footnotes</h3> 
    335 <ol> 
    336 <li><a href="http://www.cs.rice.edu/Conferences/IPTPS02/109.pdf" class="external text" title="http://www.cs.rice.edu/Conferences/IPTPS02/109.pdf" rel="nofollow">"Kademlia: A Peer-to-peer Information System Based on the XOR Metric"</a>,<br />Petar Maymounkov and David Mazieres, 
    337 </li> 
    338 <li>Use SHA1 and plenty of entropy to ensure a unique ID</li> 
    339 </ol> 
    340 </div> 
    341  
    342 <div class="section"> 
    343  <h2><a id="authors" name="authors">authors</a></h2> 
    344  <div class="line-block"> 
    345    <div class="line"><a class="reference" href="mailto:drue&#37;&#52;&#48;bittorrent&#46;com">Andrew Loewenstern</a></div> 
    346    <div class="line"><a class="reference" href="mailto:bram&#37;&#52;&#48;bittorrent&#46;com">Bram Cohen</a></div> 
    347  </div> 
    348 </div> 
    349 <!-- ### End Content ### --> 
    350 </div> 
    351 </div> 
    352 <div id="footer"> 
    353 <hr /> 
    354 <p>Copyright © 2008 BitTorrent.org</p> 
    355 </div> 
    356 </body> 
    357 </html> 
     255node ID of the responding node. 
     256 
     257ping 
     258  The most basic query is a ping. "q" = "ping" A ping query has a 
     259  single argument, "id" the value is a 20-byte string containing the 
     260  senders node ID in network byte order. The appropriate response to a 
     261  ping has a single key "id" containing the node ID of the responding 
     262  node. 
     263 
     264:: 
     265 
     266  arguments:  {"id"&nbsp;: "<querying nodes id>"} 
     267   
     268  response: {"id"&nbsp;: "<queried nodes id>"} 
     269 
     270 
     271Example Packets 
     272:: 
     273 
     274  ping Query = {"t":"aa", "y":"q", "q":"ping", "a":{"id":"abcdefghij0123456789"}} 
     275  bencoded = d1:ad2:id20:abcdefghij0123456789e1:q4:ping1:t2:aa1:y1:qe 
     276 
     277 
     278:: 
     279 
     280  Response = {"t":"aa", "y":"r", "r": {"id":"mnopqrstuvwxyz123456"}} 
     281  bencoded = d1:rd2:id20:mnopqrstuvwxyz123456e1:t2:aa1:y1:re 
     282 
     283 
     284find_node 
     285  Find node is used to find the contact information for a node given 
     286  its ID. "q" == "find_node" A find_node query has two arguments, "id" 
     287  containing the node ID of the querying node, and "target" containing 
     288  the ID of the node sought by the queryer. When a node receives a 
     289  find_node query, it should respond with a key "nodes" and value of a 
     290  string containing the compact node info for the target node or the K 
     291  (8) closest good nodes in its own routing table. 
     292 
     293:: 
     294 
     295  arguments:  {"id"&nbsp;: "<querying nodes id>", "target"&nbsp;: "<id of target node>"} 
     296 
     297  response: {"id"&nbsp;: "<queried nodes id>", "nodes"&nbsp;: "<compact node info>"} 
     298 
     299 
     300Example Packets 
     301:: 
     302 
     303  find_node Query = {"t":"aa", "y":"q", "q":"find_node", "a": {"id":"abcdefghij0123456789", "target":"mnopqrstuvwxyz123456"}} 
     304  bencoded = d1:ad2:id20:abcdefghij01234567896:target20:mnopqrstuvwxyz123456e1:q9:find_node1:t2:aa1:y1:qe 
     305 
     306 
     307:: 
     308 
     309  Response = {"t":"aa", "y":"r", "r": {"id":"0123456789abcdefghij", "nodes": "def456..."}} 
     310  bencoded = d1:rd2:id20:0123456789abcdefghij5:nodes9:def456...e1:t2:aa1:y1:re 
     311 
     312 
     313get_peers 
     314  Get peers associated with a torrent infohash. "q" = "get_peers" A 
     315  get_peers query has two arguments, "id" containing the node ID of the 
     316  querying node, and "info_hash" containing the infohash of the torrent. 
     317  If the queried node has peers for the infohash, they are returned in a 
     318  key "values" as a list of strings. Each string containing "compact" format 
     319  peer information for a single peer. If the queried node has no 
     320  peers for the infohash, a key "nodes" is returned containing the K 
     321  nodes in the queried nodes routing table closest to the infohash 
     322  supplied in the query. In either case a "token" key is also included in 
     323  the return value. The token value is a required argument for a future 
     324  announce_peer query. The token value should be a short binary string. 
     325 
     326:: 
     327 
     328  arguments:  {"id"&nbsp;: "<querying nodes id>", "info_hash"&nbsp;: "<20-byte infohash of target torrent>"} 
     329 
     330  response: {"id"&nbsp;: "<queried nodes id>", "token"&nbsp;:"<opaque write token>", "values"&nbsp;: ["<peer 1 info string>", "<peer 2 info string>"]} 
     331 
     332  or: {"id"&nbsp;: "<queried nodes id>", "token"&nbsp;:"<opaque write token>", "nodes"&nbsp;: "<compact node info>"} 
     333 
     334 
     335Example Packets: 
     336:: 
     337 
     338  get_peers Query = {"t":"aa", "y":"q", "q":"get_peers", "a": {"id":"abcdefghij0123456789", "info_hash":"mnopqrstuvwxyz123456"}} 
     339  bencoded = d1:ad2:id20:abcdefghij01234567899:info_hash20:mnopqrstuvwxyz123456e1:q9:get_peers1:t2:aa1:y1:qe 
     340   
     341 
     342:: 
     343 
     344  Response with peers = {"t":"aa", "y":"r", "r": {"id":"abcdefghij0123456789", "token":"aoeusnth", "values": ["axje.u", "idhtnm"]}} 
     345  bencoded = d1:rd2:id20:abcdefghij01234567895:token8:aoeusnth6:valuesl6:axje.u6:idhtnmee1:t2:aa1:y1:re 
     346 
     347 
     348:: 
     349 
     350  Response with closest nodes = {"t":"aa", "y":"r", "r": {"id":"abcdefghij0123456789", "token":"aoeusnth", "nodes": "def456..."}} 
     351  bencoded = d1:rd2:id20:abcdefghij01234567895:nodes9:def456...5:token8:aoeusnthe1:t2:aa1:y1:re 
     352 
     353 
     354announce_peer 
     355  Announce that the peer, controlling the querying node, is downloading 
     356  a torrent on a port. announce_peer has four arguments: "id" containing the node ID of the 
     357  querying node, "info_hash" containing the infohash of the torrent, 
     358  "port" containing the port as an integer, and the "token" received in 
     359  response to a previous get_peers query. The queried node must verify 
     360  that the token was previously sent to the same IP address as the 
     361  querying node. Then the queried node should store the IP address of the 
     362  querying node and the supplied port number under the infohash in its 
     363  store of peer contact information. 
     364 
     365:: 
     366 
     367  arguments:  {"id" : "<querying nodes id>", "info_hash" : "<20-byte infohash of target torrent>", "port" : <port number>, "token" : "<opaque token>"} 
     368   
     369  response: {"id" : "<queried nodes id>"} 
     370   
     371 
     372Example Packets: 
     373:: 
     374 
     375  announce_peers Query = {"t":"aa", "y":"q", "q":"announce_peer", "a": {"id":"abcdefghij0123456789", "info_hash":"mnopqrstuvwxyz123456", "port": 6881, "token": "aoeusnth"}} 
     376  bencoded = d1:ad2:id20:abcdefghij01234567899:info_hash20:<br /> 
     377  mnopqrstuvwxyz1234564:porti6881e5:token8:aoeusnthe1:q13:announce_peer1:t2:aa1:y1:qe 
     378 
     379 
     380:: 
     381 
     382  Response = {"t":"aa", "y":"r", "r": {"id":"mnopqrstuvwxyz123456"}} 
     383  bencoded = d1:rd2:id20:mnopqrstuvwxyz123456e1:t2:aa1:y1:re 
     384 
     385 
     386Send questions, comments and corrections to editor@bittorrent.org 
     387 
     388 
     389.. [Kademlia] Peter Maymounkov, David Mazieres, "`Kademlia: A Peer-to-peer Information System Based on the XOR Metric`_", IPTPS 2002. 
     390 
     391.. _`Kademlia: A Peer-to-peer Information System Based on the XOR Metric`: http://www.cs.rice.edu/Conferences/IPTPS02/109.pdf 
     392 
     393.. [#entropy] Use SHA1 and plenty of entropy to ensure a unique ID. 
     394 

  • dotorg/trunk/html/beps/bep_0006.rst

    r10416 r10505  
     1BEP: 4 
     2Title: IPv6 Tracker Extension 
     3Version: 2 
     4Last-Modified: 11-Jan-2008 
     5Author:  Greg Hazel <greg@bittorrent.com>, Arvid Norberg <arvid@bittorrent.com> 
     6Status:  Draft 
     7Type:    Standards Track 
     8Created: 31-Jan-2008 
     9Post-History: 
     10 
    111IPv6 tracker extension 
    212====================== 
    … …  
    8999current response, using the same encoding. 
    90100 
    91 authors 
    92 ------- 
    93101 
    94 | `Greg Hazel`__ 
    95 | `Arvid Norberg`__ 
    96102 
    97 .. __: mailto:greg@bittorrent.com 
    98 .. __: mailto:arvid@bittorrent.com 
    99  

  • dotorg/trunk/html/beps/bep_0007.rst

    r10491 r10505  
    1 tracker peer obfuscation extension 
    2 ================================== 
     1BEP: 4 
     2Title: Tracker Peer Obfuscation 
     3Version: 3 
     4Last-Modified: 02-Feb-2008 
     5Author:  David Harrison <dave@bittorrent.com>, Anthony Ciani <tony@ciani.phy.uic.edu>, Arvid Norberg <arvid@bittorrent.com>, Greg Hazel <greg@bittorrent.com>  
     6Status:  Draft 
     7Type:    Standards Track 
     8Created: 31-Jan-2008 
     9Post-History: 
    310 
    411This extends the tracker protocol to support simple obfuscation of the 
    … …  
    327334 
    328335 
    329 authors 
    330 ------- 
    331  
    332 | `David Harrison`__ 
    333 | `Arvid Norberg`__ 
    334 | `Greg Hazel`__ 
    335 | `Anthony Ciani`__ 
    336  
    337 .. __: mailto:dave@bittorrent.com 
    338 .. __: mailto:arvid@bittorrent.com 
    339 .. __: mailto:greg@bittorrent.com 
    340 .. __: mailto:tony@ciani.phy.uic.edu  
    341336.. _`RFC 2119`: http://tools.ietf.org/html/rfc2119 
    342337.. _`BitTorrent Protocol Encryption`: http://www.bittorrent.org/beps/bep_0013.html 

  • dotorg/trunk/html/beps/bep_1000_requested_standard_track.rst

    r10492 r10505  
    1 :BEP: 0 
    2 :Title: Index of BitTorrent Enhancement Proposals  
    3 :Version: 1 
    4 :Last-Modified: 11-Jan-2008 
    5 :Author:  David Harrison 
    6 :Status:  Active 
    7 :Type:    Process 
    8 :Created: 10-Jan-2008 
    9 :Post-History: 
     1BEP: 1000 
     2Title: Request for Standards Track Documents 
     3Version: 1 
     4Last-Modified: 02-Feb-2008 
     5Author:  David Harrison <dave@bittorrent.com> 
     6Status:  Active 
     7Type:    Process 
     8Created: 10-Jan-2008 
     9Post-History: 
    1010 
    11 The following have known implementations but no standards documents. 
    12 We are requesting people to write up documents for standardization. 
     11This documents lists BitTorrent extensions with known implementations 
     12that have been assinged BEP numbers, and are awaiting submission of 
     13the formal standards track document. 
    1314 
    1415 
    … …  
    202112_    Protocol Encryption 
    212213_    Local Service Discovery 
     2314_    UDP Tracker Protocol 
     2415_    Super-seeding 
    2225=====  =========================================  
    2326 
    2427 
    25 .. [#python] http://www.python.org/dev/peps/ 
    26 .. [#svn] http://svn.bittorrent.org 
    2728.. _10: bep_0010.html 
    2829.. _11: bep_0011.html 
    2930.. _12: bep_0012.html 
    3031.. _13: bep_0013.html 
     32.. _14: bep_0014.html 
     33.. _15: bep_0015.html 

  • dotorg/trunk/html/beps/makefile

    r10465 r10505  
    33        bep_0000.html \ 
    44        bep_0002.html \ 
     5        bep_0003.html \ 
     6        bep_0004.html \ 
    57        bep_0006.html \ 
    68        bep_0007.html \ 
    … …  
    1113 
    1214%.html:%.rst 
    13         ~/docutils/tools/rstpep2html.py --template=../template.txt --cloak-email-addresses --link-stylesheet --stylesheet=../css/screen.css --no-toc-backlinks $? >$@ --traceback 
     15        rstpep2html.py --template=../template.txt --cloak-email-addresses --link-stylesheet --stylesheet=../css/screen.css --no-toc-backlinks $? >$@ --traceback 
    1416 
    1517        #~/docutils/tools/rst2html.py --template=../template.txt --cloak-email-addresses --link-stylesheet --stylesheet=../css/screen.css --no-doc-title --no-toc-backlinks $? >$@