Show
Ignore:
Timestamp:
02/14/2008 01:38:02 PM (11 months ago)
Author:
dave
Message:

regenerated to reflect previous changes to bep_0008.rst

Files:
1 modified

Legend:

Unmodified
Added
Removed

  • dotorg/trunk_fixed/html/beps/bep_0008.html

    r10598 r10763  
    3838<tr class="field"><th class="field-name">Title:</th><td class="field-body">Tracker Peer Obfuscation</td> 
    3939</tr> 
    40 <tr class="field"><th class="field-name">Version:</th><td class="field-body">10597</td> 
    41 </tr> 
    42 <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_0008.rst">2008-02-07 17:08:03 -0800 (Thu, 07 Feb 2008)</a></td> 
     40<tr class="field"><th class="field-name">Version:</th><td class="field-body">10762</td> 
     41</tr> 
     42<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_0008.rst">2008-02-14 13:37:25 -0800 (Thu, 14 Feb 2008)</a></td> 
    4343</tr> 
    4444<tr class="field"><th class="field-name">Author:</th><td class="field-body">David Harrison &lt;dave&#32;&#97;t&#32;bittorrent.com&gt;, Anthony Ciani &lt;tony&#32;&#97;t&#32;ciani.phy.uic.edu&gt;, Arvid Norberg &lt;arvid&#32;&#97;t&#32;bittorrent.com&gt;, Greg Hazel &lt;greg&#32;&#97;t&#32;bittorrent.com&gt;</td> 
    … …  
    107107<p>We distinguish between the <em>tracker peer list</em> and the <em>returned peer 
    108108list</em>.  The <em>tracker peer list</em> contains the ip-port pairs of all 
    109 peers that have reported to the tracker that they are downloading or 
    110 seeding a given file with a given infohash.  The tracker may store 
    111 this peer list however it wishes.  The <em>returned peer list</em> contains a 
    112 packed array of ip-port pairs conforming to the BitTorrent protocol 
    113 specification.  If the swarm is sufficiently large then the returned 
    114 ip-port pairs constitute a subset of the ip-port pairs in the 
    115 <em>tracker peer list</em>.</p> 
     109known peers in a given torrent, i.e., those peers that have reported to 
     110the tracker that they are downloading or seeding a given file with a 
     111given infohash.  The tracker may store this peer list however it 
     112wishes.  The <em>returned peer list</em> contains a packed array of ip-port 
     113pairs conforming to the BitTorrent protocol specification.  If the 
     114swarm is sufficiently large then the returned ip-port pairs constitute 
     115a subset of the ip-port pairs in the <em>tracker peer list</em>.</p> 
    116116<p>The returned peer list is encrypted using RC4-drop768 encryption using 
    117 the infohash as a shared secret and optionally an initialization 
    118 vector.</p> 
     117the infohash as a shared secret and optionally employing an 
     118initialization vector.</p> 
    119119<p>For the remainder of this document RC4 refers to RC4-drop768.  In the 
    120120process of encryption, RC4 generates a pseudorandom string that is 
    … …  
    174174<p>The tracker MAY also cache the encrypted tracker peer list.  To 
    175175support this the tracker MUST pass two additional keys <em>i</em> and <em>n</em> 
    176 each with 32-bit integer values ,except the tracker MAY omit <em>i</em> and 
    177 <em>n</em> when <em>i=0</em> and the returned peer list is the entire tracker peer 
    178 list.  Whether the tracker returns <em>i</em> and <em>n</em>, the first 8 bytes of 
     176each with 32-bit integer values, except the tracker MAY omit <em>i</em> and 
     177<em>n</em> when <em>i=0</em> and the <em>returned peer list</em> is the entire <em>tracker peer 
     178list</em>.  Whether the tracker returns <em>i</em> and <em>n</em>, the first 8 bytes of 
    179179the RC4 psuedorandom string are reserved for obscuring <em>i</em> and <em>n</em>. 
    180180We come back to this momentarily.  Decryption starts by XORing from 
    … …  
    183183encrypted the tracker peer list starting from the first byte after the 
    184184discarded and reserved bytes in the pseudorandom string then <em>i</em> also 
    185 corresponds to the <em>ith</em> ip-port pair in the tracker peer list and the 
    186 starting point of the copy into the returned request.</p> 
     185corresponds to the <em>ith</em> ip-port pair in the tracker peer list.</p> 
    187186<p>So that the client and the tracker do not have to generate an 
    188187arbitrarily long pseudorandom string to support large swarms, we 
    … …  
    209208list consisting of 3 ip-port pairs, and using an RC4 pseudorandom string 
    210209of length <em>n=2</em>. <em>n</em> is small for purposes of illustration.  Also, for the 
    211 purpose of illustration, the tracker returns only 3 peers at a time.</p> 
     210purpose of illustration, the tracker returns only 2 peers at a time.</p> 
    212211<pre class="literal-block"> 
    213212Given the following peer list 
    … …  
    229228<p>Because the RC4 pseudorandom string is shorter than the tracker 
    230229peer list, we wrap to the beginning of the pseudorandom string.</p> 
    231 <p>In the first response, the tracker would return:</p> 
     230<p>A tracker returning the first two peers would return the bencoded 
     231equivalent of:</p> 
    232232<pre class="literal-block"> 
    233233peers=74de24afa2df5201bedb15d7, i=0, n=2 
    234234</pre> 
    235 <p>In the second response, the tracker would return:</p> 
     235<p>A tracker returning the second and third peer would return the 
     236bencoded equivalent of:</p> 
    236237<pre class="literal-block"> 
    237238peers=5201bedb15d72443e3f1a2df, i=1, n=2 
    238239</pre> 
     240<p>In each response the tracker includes additional keys such as the 
     241rerequest <tt class="docutils literal"><span class="pre">interval</span></tt> and the initialization vector <tt class="docutils literal"><span class="pre">iv</span></tt>.</p> 
    239242<p>The tracker response MUST remain a valid bencoded message.</p> 
    240243</div> 
    … …  
    269272plaintext as the next twenty bytes, hence also defeating the purpose 
    270273of the shared secret.</p> 
    271 <p>If the tracker does not know enough peers that support MSE to return 
    272 the desired number of peers then it MAY include peers that are not 
    273 assumed to support MSE.  If a peer closes a connection in response to 
    274 an encrypted header then the initiating peer should try other peers in 
    275 the peer list returning to the peer that closed the connection only 
     274<p>If the tracker does not know enough peers assumed to support MSE to 
     275return the desired number of peers then it MAY include peers that are 
     276not assumed to support MSE.  If a peer closes a connection in response 
     277to an encrypted header then the initiating peer SHOULD try other peers 
     278in the peer list returning to the peer that closed the connection only 
    276279when all other peers known or not yet known to support MSE have been 
    277280tried and have failed to provide &quot;adequate performance.&quot;  We