Re: Support for "announce-list"

"Harold Feit - Depthstrike.com Administrator" wrote:
> - -----From the site-----
> If that tracker fails, we shuffle the tracker list in "announce-list"
> and try every tracker in it, looking for anyone alive.
> 
> If all trackers are unavailable, we keep trying all of them, just
> like the standard client.
> - -----------------------
> That's all well and good, but if there's a specific order in which
> the tracker administrators wanted their trackers accessed you just
> ignored it. You also didn't specify how many of the list to try at a
> time. If it tries more than one in a tier at a time, it is abusive
> and should not be used.

I do a single try for every announce period. That is, if the period is
30 minutes, I try a new tracker every 30 minutes. A bit slow to ramp up
but gently to the trackers. If you have ten trackers and nine are
offline, you could be idle for nearly five hourse, in the worse case.

I've invested the last hour studying the client to tracker code in
standard BitTorrent, and to implement "announce-list" properly would
require a massive neurosurgery in the code. Currently BT tries to
connect using a separate thread with no support for timeouts. The code
simply tries to connect until the OS gives up, basically.

I could "inject" a modified socket class (with proper timeouts) into the
HTTP library, taking in count do not disturb the other BT threads. Ugly
and fragile.

In fact I always thought that FTP/URL/HTTP/SMTP/etc libs in python
should accept an optional parameter for the connection contructor in
order to be flexible and don't assume that sockets are the only thing
under the Sun. It could be nice, for example, to use HTTPLIB via FIFOs,
for example.

That is, instead of doing "s=socket.socket()" deep inside the lib, it
could do s="self.conn_constructor()", where the caller could especify
arbitrary constructors.

But current code is very hostile to the "official" "announce-list"
behaviour.

I guess I will keep my current code for a while :-(

PS: Another posibility could be to set sockets timeouts to 60 seconds by
default, and to alter BT code to change it later, case by case. That is,
instead of hacking the ins of the lib to implement "localiced" timeouts,
I could configure timeouts as general rule and escape it case by case in
BT code.

Ugly and complex, also. Not a nice foundation to future BT 3.5 :-(. But
seems to be only three code paths to consider, doing a "coarse" "grep"
searching.

PPS: Another, last, option could be to simply rip the standard libs and
modify them as we wish. Another hack, and we need to keep in sync with
future lib improvements in the standard "branch".

-- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
[email protected] http://www.argo.es/~jcea/ _/_/    _/_/  _/_/    _/_/  _/_/
                                      _/_/    _/_/          _/_/_/_/_/
PGP Key Available at KeyServ   _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz


------------------------ Yahoo! Groups Sponsor --------------------~--> 
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/dkFolB/TM
--------------------------------------------------------------------~-> 

 
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/