[BitTorrent] Re: Tracker scrape extension proposal

Alex bittorrent at networkessence.net
Tue Jan 18 12:18:34 EST 2005


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 
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).

download.py
     ('rerequest_interval', 5 * 60,
         'time to wait between requesting more peers'),
     rerequest = Rerequester(response['announce'], 
config['rerequest_interval']...)

Rerequest.py (announce/rerequest interval code [summarized]):
class Rerequester:
     def __init__(self, url, interval, sched, howmany, minpeers,
             connect, externalsched, amount_left, up, down,
             port, ip, myid, infohash, timeout, errorfunc, maxpeers, 
doneflag,
             upratefunc, downratefunc, ever_got_incoming):

         self.interval = interval
         self.announce_interval = 30 * 60

     def c(self):
         self.sched(self.c, self.interval)
         if self.ever_got_incoming():
             getmore = self.howmany() <= self.minpeers / 3
         else:
             getmore = self.howmany() < self.minpeers
         if getmore or time() - self.last_time > self.announce_interval:
             self.announce()

     def announce(self, event = None):
         Thread(target = self.rerequest, args = [s, set]).start()

     def rerequest(self, url, set):
                     self.postrequest(r)

     def postrequest(self, data):
             r = bdecode(data)
                 self.interval = r.get('min interval', self.interval)
                 self.trackerid = r.get('tracker id', self.trackerid)



Alex

On Jan 18, 2005, at 7:10 AM, Harold Feit - Depthstrike.com 
Administrator wrote:

>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> BitTorrent doesn't have a default announce cycle of 5 minutes. It has
> a default announce cycle of 30.
>
> Clients SHOULDN'T report keep-alive capability for announces anyway,
> since the connections are typically so short and so far spaced. This
> would permit a webserver to run BitTorrent trackers without
> Keep-alives.
>
> - -----Original Message-----
> From: dropnessence [mailto:bittorrent at networkessence.net]
> Sent: Monday, January 17, 2005 12:12 PM
> To: BitTorrent at yahoogroups.com
> Subject: [BitTorrent] Re: Tracker scrape extension proposal
>
>
>
>
> Keep-alive is a bad system to use with a bittorrent tracker. By
> default clients are set to only hit the server every 5 mins. If you
> keep a thread/socket alive for 5 minutes just for that client, and
> you
> have a swarm of clients then you will be keeping thousands of
> threads/sockets open for keep-alive. Keep-alive is useful for webpage
> where somebody is clicking on something every 3-60 seconds. BT
> happens
> every 300 seconds. If the BT tracker (announce) is implemented by a
> web-server (eg, PHP), then keep-alive should be disabled.
>
> - --- In BitTorrent at yahoogroups.com, "Roger Pate" <roger at q...> wrote:
>> On Mon, 17 Jan 2005 00:19:42 +0100, Olaf van der Spek
>> <OvdSpek at L...>
> wrote:
>>
>>>> from the tracker, individual requests aren't particularaly
>>>> efficient, but nor is fetching everything. I'd still rather
>>>> fetch everything
> than
>>>> hit the tracker with 100 HTTP requests, though. This is why I
> think it'd
>>>
>>> Why?
>>> 100 single-torrent requests consume far less than 3 mb.
>>
>> Each HTTP request consumes server resources, even if the data
> transferred is small. One hundred requests is significant.
>>
>> How trackers support keep-alive? That would help, but not
>> eliminate,
> this problem.
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
> - --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 265.6.13 - Release Date: 1/16/2005
>
>
> - --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 265.7.0 - Release Date: 1/17/2005
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 8.0.3
>
> iQEVAwUBQe0Kul8nceBm0DUaAQK+4QgAyPUtRlVsbpRgTm4cgE+v8Rk/SRTLNGYf
> Ssaaaj91dwd0Dhw7Ev+lwf9mafoqVLzK+CMyBPkC1ad6v9GGtpTdBZI0sNcouy88
> e0eDWoR0TnWcIraa7/j95Glop5qBIKFeMu+wBsbq32xCEnF5XKvZ7ppSO5MQr20N
> ZSsMrJmIGkL6jkPI1YR8rtrMSRcBhvElFa0zZq/3nRskwOCvXiuwQGe38Os4oZRS
> tIvMW9HILDwQ29OxGLre46w2IWAKY5D8Gslxfsov7Ol8dRPV/QYCrn2Il9i56Ar0
> OJKzS/bFCfH8N+hObGxedNFWjb3aWL01KLXHKvup+n+rc13BLHAlUg==
> =8PDG
> -----END PGP SIGNATURE-----
>
>
>
>
>
> 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:
    BitTorrent-unsubscribe at yahoogroups.com

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





More information about the BitTorrent mailing list