Re: [Libbt-devel] Re: Features request

[Dakidd <da...@so...>]

>>From: Diego Casorran <di...@us...>
>> On 20-05-2005 (08:34:57), you wrote:
>>
>> > you can always make a script in which you run btget in a while loop, so,
>> > if it  dies, it restarts...
>> >
>> yeah, but my intention was to avoid the current downloaded torrent being
>> re-seeded for ok pieces every loop.
>
>All BT clients do this.

I agree with Diego that this is a Bad Thing, despite being vital.

I understand *WHY* it happens, and recognize the need to do it - How else
is the client supposed to decide that a file is or isn't complete, without
storing extraneous cruft in either the .torrent file, one or more of the
"target" files, or even worse, some kind of "cookie-jar" file? There seems
to be no real good answer, and it's something that has to be done.

But the amount of time it takes to accomplish can be *VERY* discouraging,
particularly to "newcomers" to BitTorrent. Depending on the client (and the
exact SHA1 implementation being used by that particular client) and the
size of the file(s) involved, doing the "pre-check" on a freshly
(re)started .torrent can take anywhere from several minutes to more than an
hour. (potentially *MUCH* longer)

Case in point: A 265 meg file I've got that takes well over an hour and a
half to be checked by the "official" Python-based client. Same file, using
my partially-hacked-into-operationality LibBT (more accurately, btList and
btCheck - I'm still hacking on networking capability so I can get btGet up
and running) and a standalone SHA1 implementation (Note 1) checks in a
little more than 75 seconds. In the Python-based client, that delay is
absolutely maddening - I can fire up to seed the file I mention, and it'll
be close to two hours before the leechers that flock to it get the first
byte of it from me.

I've been chasing some ideas about how to handle this problem around in my
head. I've got a few thoughts, but with all of them, I'm worried that if
they were put into wide practice, trackers would start getting hammered
into the ground by the traffic of the frequent "re-registers" that would be
needed during the time a particular client using them is "firing up".

(Note 1) ReidSHA, if anyone is interested. Explicitly in the public domain,
small footprint in the library, and QUICK. Be aware that I'm coming at
things from another angle than most everybody else who's hacking on this
thing, since I'm trying to port the library over to Pre-OSX Macintosh
systems - "Canned" goodies like LibCURL, the OpenSSL libraries, etc, just
aren't "there" for me and my platform, so I'm having to "invent the
technology on the fly" - This has lead me to finding various substitutes
and workarounds, and discovery of what I believe to be better ways for
doing some things. ReidSHA is one definite Good Thing.


Don Bruder -  da...@so...      <--- Preferred Email - unmunged
I will choose a path that's clear: I will choose Free Will! - N. Peart