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

correct some errors.

Files:
1 modified

Legend:

Unmodified
Added
Removed

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

    r10597 r10762  
    5959We distinguish between the *tracker peer list* and the *returned peer 
    6060list*.  The *tracker peer list* contains the ip-port pairs of all 
    61 peers that have reported to the tracker that they are downloading or 
    62 seeding a given file with a given infohash.  The tracker may store 
    63 this peer list however it wishes.  The *returned peer list* contains a 
    64 packed array of ip-port pairs conforming to the BitTorrent protocol 
    65 specification.  If the swarm is sufficiently large then the returned 
    66 ip-port pairs constitute a subset of the ip-port pairs in the 
    67 *tracker peer list*. 
     61known peers in a given torrent, i.e., those peers that have reported to 
     62the tracker that they are downloading or seeding a given file with a 
     63given infohash.  The tracker may store this peer list however it 
     64wishes.  The *returned peer list* contains a packed array of ip-port 
     65pairs conforming to the BitTorrent protocol specification.  If the 
     66swarm is sufficiently large then the returned ip-port pairs constitute 
     67a subset of the ip-port pairs in the *tracker peer list*. 
    6868 
    6969The returned peer list is encrypted using RC4-drop768 encryption using 
    70 the infohash as a shared secret and optionally an initialization 
    71 vector.   
     70the infohash as a shared secret and optionally employing an 
     71initialization vector. 
    7272 
    7373For the remainder of this document RC4 refers to RC4-drop768.  In the 
    … …  
    141141The tracker MAY also cache the encrypted tracker peer list.  To 
    142142support this the tracker MUST pass two additional keys *i* and *n* 
    143 each with 32-bit integer values ,except the tracker MAY omit *i* and 
    144 *n* when *i=0* and the returned peer list is the entire tracker peer 
    145 list.  Whether the tracker returns *i* and *n*, the first 8 bytes of 
     143each with 32-bit integer values, except the tracker MAY omit *i* and 
     144*n* when *i=0* and the *returned peer list* is the entire *tracker peer 
     145list*.  Whether the tracker returns *i* and *n*, the first 8 bytes of 
    146146the RC4 psuedorandom string are reserved for obscuring *i* and *n*. 
    147147We come back to this momentarily.  Decryption starts by XORing from 
    … …  
    150150encrypted the tracker peer list starting from the first byte after the 
    151151discarded and reserved bytes in the pseudorandom string then *i* also 
    152 corresponds to the *ith* ip-port pair in the tracker peer list and the 
    153 starting point of the copy into the returned request. 
     152corresponds to the *ith* ip-port pair in the tracker peer list. 
    154153 
    155154So that the client and the tracker do not have to generate an 
    … …  
    179178list consisting of 3 ip-port pairs, and using an RC4 pseudorandom string  
    180179of length *n=2*. *n* is small for purposes of illustration.  Also, for the  
    181 purpose of illustration, the tracker returns only 3 peers at a time. 
     180purpose of illustration, the tracker returns only 2 peers at a time. 
    182181 
    183182:: 
    … …  
    202201peer list, we wrap to the beginning of the pseudorandom string. 
    203202 
    204 In the first response, the tracker would return:: 
     203A tracker returning the first two peers would return the bencoded 
     204equivalent of:: 
    205205 
    206206  peers=74de24afa2df5201bedb15d7, i=0, n=2 
    207207 
    208 In the second response, the tracker would return:: 
     208A tracker returning the second and third peer would return the 
     209bencoded equivalent of:: 
    209210 
    210211  peers=5201bedb15d72443e3f1a2df, i=1, n=2 
     212 
     213In each response the tracker includes additional keys such as the 
     214rerequest ``interval`` and the initialization vector ``iv``. 
    211215 
    212216The tracker response MUST remain a valid bencoded message. 
    … …  
    250254of the shared secret. 
    251255 
    252 If the tracker does not know enough peers that support MSE to return 
    253 the desired number of peers then it MAY include peers that are not 
    254 assumed to support MSE.  If a peer closes a connection in response to 
    255 an encrypted header then the initiating peer should try other peers in 
    256 the peer list returning to the peer that closed the connection only 
     256If the tracker does not know enough peers assumed to support MSE to 
     257return the desired number of peers then it MAY include peers that are 
     258not assumed to support MSE.  If a peer closes a connection in response 
     259to an encrypted header then the initiating peer SHOULD try other peers 
     260in the peer list returning to the peer that closed the connection only 
    257261when all other peers known or not yet known to support MSE have been 
    258262tried and have failed to provide "adequate performance."  We