Re: [Libbt-devel] Re: Features request
Brought to you by:
ksmathers
From: Elliott M. <eh...@m5...> - 2005-05-21 23:14:30
|
>From: Dakidd <da...@so...> > 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. What the heck kind of system do you have?! On a 233MHz P2 system I can run 256MB of data (/dev/zero since it is handy) through in 18 seconds! By this measure I'd guess you had less than a 66MHz system! If this is so, do you seriously expect such a system to be able to handle downloading and processing such a torrent? (during download you'll be clobbering your I/O system grabbing pieces, when looking at the file(s) you'll merely peg your processor) > 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". Hammering a tracker is a concern, but how would this scenario manage to cause that? > (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. I strongly disagree. OpenSSL is very common. This means they've got the eyeballs to look at code and make sure it is correct and fast. Using an uncommon library is bad because you force people to go hunting to obtain it, and they may choose to go elsewhere and no bother. For crypto is an extremely bad idea as it is difficult to get right. -- (\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/) \BS ( | EH...@gr... PGP 8881EF59 | ) / \_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/ \___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/ |