Re: Re: Tracker scrape extension proposal

Before this subject, I started out not knowing python but knew BT 
really well. Kudos for bringing it up because I learned more about BT 
and it seems python wouldn't be as difficult as I expected.

announce_interval is overwritten by a valid tracker response as is min 
interval, tracker id, etc. 'tracker id' is not used by the python 
tracker either. I would imagine implementing 'tracker id' would be just 
as easy to implement.

Rerequester.py (reference code where 'min interval' is overwritten)
     def postrequest(self, data):
         try:
             r = bdecode(data)
             check_peers(r)
             if r.has_key('failure reason'):
                 self.errorfunc('rejected by tracker - ' + r['failure 
reason'])
             else:
                 if r.has_key('warning message'):
                     self.errorfunc('warning from tracker - ' + 
r['warning message'])
                 self.announce_interval = r.get('interval', 
self.announce_interval)
                 self.interval = r.get('min interval', self.interval)
                 self.trackerid = r.get('tracker id', self.trackerid)
                 self.last = r.get('last')



Here is how to implement tracker-controlled min_interval (this would 
compliment the current tracker's support of controlling the 
announce_interval):
Alex-G5:~/bt/BitTorrent-3.4.2/BitTorrent nessence$ diff track.py 
track_mininterval.py
30a31
 >     ('min_interval', 5 * 60, 'seconds downloaders should wait between 
rerequests'),
120a122
 >         self.min_interval = config['min_interval']
399c401
<         data = {'interval': self.reannounce_interval}
---
 >         data = {'interval': self.reannounce_interval, 'min interval': 
self.min_interval}



"...though it could..." == it was not coded into the tracker, but 
supported by the client.

I tested this code and it works with the client from bittorrent.com. 
The downloading peer only contacted the tracker every 10 minutes 
instead of 5. This isn't applicable to the 2nd tracker connection. The 
second tracker connection is scheduled before the min_interval is 
overwritten by the initial event=started connection.

0) BT client makes intial tracker connection (event=started)
1) BT client connects to tracker client->min_interval seconds after 1)
n) BT client connects to tracker tracker->min_interval seconds after 2)

I'm not sure what other clients do or do not support this, but if you 
have a home-made tracker you could easily configure it to ignore 
clients which ignore the min_interval.

Just an FYI, the default min_peers value is 20, and the scheduling is 
dependent on the min_peers value. So any peer which has less than 
(20/3) peers is going to continue using the min_interval. That 
basically means that any 'default' client that has less than 7 peers on 
a torrent, whether a seeder or not, will announce at min_interval and 
not announce_interval (refer sched() function in previous email). From 
my experience, most environments have peers all using their 
min_interval and hit the tracker once every 5 mins. This equates to 0.2 
hits per min, per peer. So, one hit per min for every 5 peers or one 
hit per second for every 300 peers.

You might see why a tracker with 30k peers has problems [with python] 
handling 100 hits per second. A compiled tracker like BNBT barely 
notices the load. I honestly think it has to do with all the hash 
lookups. 100 hash lookups and peer lists per second is way faster in 
C++ than in python (or the apache+php trackers out there). Afaik, 
python uses an array and a flat dstate file whereas C++ can use 
structs, linked lists, maps, etc.

Hope I answered your questions.

-Alex
(nessence)

On Jan 18, 2005, at 5:23 PM, Olaf van der Spek wrote:

>
> Alex wrote:
>> There are two intervals, the announce - which informs tracker of the
>> status of things, and the rerequest which is based on whether the peer
>> has a connection and/or has it's peer list fulfilled. Currently, the
>> tracker doesn't set a min reqrequest interval (though it could); the
>
> How can it do that?
> And which clients respect it?
>
>> tracker only sets a default announce interval. Thus, peers by default
>> request peers (thus announcing) every 5 mins until they fulfill their
>> peers list and then resort to announcing every 30 minutes. This is 
>> only
>> how the source client works, I'm not sure how the others do but I'm
>> sure they are similar.
>>
>> By default, the announce request is 5 mins or 30, depending on how 
>> many
>> peers the client has and if it's been connected to. The majority of
>> swarms won't maintain a full peer list and will average closer to the 
>> 5
>> min interval than the 30 min interval (excepting torrents with peer
>> counts disproportional to the content's size).
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>



 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/