Thread: [Libbt-devel] Features request
Brought to you by:
ksmathers
From: Diego C. <di...@us...> - 2005-05-20 05:14:46
|
Hello!, First of all, Im new on the list, and using BitTorrent therefore a big thanks to Kevin and the people involved in creating the libbt software package. I wonder if it is possible to implement the following features/improvements: it is possible to add an option to limit the bandwidth (downstream/upstream) usage? sometimes could be so hateful I can't browse the web nicely because btget is using all bandwidth. what about the trackers which request a user&password to access to it? and the most important to me: btget frecuently (well, could be depending the torrent and/or his peers, dunno for sure) dies itself due a Map Synch error, when this happens there is a 'peer_connect failed:' with the errors messages: "No route to host" and/or "can't assign requested address" :( is there any way to avoid safely that DIE_UNLESS( ctx->statmap[cs] == i); and just restart btget automatically when this assertion is false? thats all, thanks again. Kind Regards. ps: sorry for my bad english.. |
From: Alien <ali...@us...> - 2005-05-20 08:35:15
|
you can always make a script in which you run btget in a while loop, so, if= it=20 dies, it restarts... i thought the release did have bandwidth limitations an assertion is there to tell us that there is a bug in programming, it's n= ot=20 it's job to restart btget. Since I'm not involved in the release, i cannot answer the rest of your=20 questions and i cannot direct your concerns... btw: i never heard about trackers that request user/passwd, can you send us= =20 one? what is your OS and libbt version AL13N Op vrijdag 20 mei 2005 07:11, schreef Diego Casorran: > Hello!, > > First of all, Im new on the list, and using BitTorrent therefore a big > thanks to Kevin and the people involved in creating the libbt software > package. > > I wonder if it is possible to implement the following > features/improvements: > > it is possible to add an option to limit the bandwidth > (downstream/upstream) usage? sometimes could be so hateful I can't browse > the web nicely because btget is using all bandwidth. > > what about the trackers which request a user&password to access to it? > > and the most important to me: btget frecuently (well, could be depending > the torrent and/or his peers, dunno for sure) dies itself due a Map Synch > error, when this happens there is a 'peer_connect failed:' with the errors > messages: "No route to host" and/or "can't assign requested address" :( > > is there any way to avoid safely that DIE_UNLESS( ctx->statmap[cs] =3D=3D= i); > and just restart btget automatically when this assertion is false? > > thats all, thanks again. > > Kind Regards. > > ps: sorry for my bad english.. > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_id=3D7412&alloc_id=3D16344&op=3Dclick > _______________________________________________ > Libbt-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libbt-devel |
From: Diego C. <di...@us...> - 2005-05-21 12:50:54
|
Hello Alien 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. > i thought the release did have bandwidth limitations > hmm, how I setup/configure it?.. > an assertion is there to tell us that there is a bug in programming, > it's not it's job to restart btget. > > Since I'm not involved in the release, i cannot answer the rest of your > questions and i cannot direct your concerns... > > btw: i never heard about trackers that request user/passwd, can you send > us one? > its attached, seems that all torrents from www.pctorrent.com needs a user&pass to connect to his tracker, however not a great problem, later or sonner they will be available from somewhere else.. > what is your OS and libbt version > AmigaOS.. and 1.04 NEWS: About the 'no route to host' problem, it is trying to connect to 127.1.1.1, whats this?... some other kind of local loopback address? never see it myself here, and how to work with it? I need to set it up on my computer or it is supposed to point the tracker/some badly configured peer?... anyhow, seems Ive fixed it just adding a check on context.c, basically: if( 0x7f010101 != ... p = peer_add( ... however, not sure if is only my impression or now the active peers are lower, (some secondary effect, dunno), is this "hack" corrent?... Also, the 'cant assign requested address' indicates the kernel's dbtable size is full, right? then, not tested yet but this should work now after changing MAXCONN to 60-64 instead the default value 100 I think, need to check more carefully my kernel docs about that matter however. btw, whats the purpose of the "snub detection"? I can't see a tip on the protocol specs. Thanks for your time. Kind Regards |
From: Elliott M. <eh...@m5...> - 2005-05-21 21:20:32
|
>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. > > an assertion is there to tell us that there is a bug in programming, > > it's not it's job to restart btget. > > > > Since I'm not involved in the release, i cannot answer the rest of your > > questions and i cannot direct your concerns... > > > > btw: i never heard about trackers that request user/passwd, can you send > > us one? > > > its attached, seems that all torrents from www.pctorrent.com needs a user&pass > to connect to his tracker, however not a great problem, later or sonner they > will be available from somewhere else.. This might be a case of it gives you a modified URL which you use to connect to the tracker. Along the lines of <trackerurl>&&user=<foo>&&pass=<bar> and you're supposed to connect to a central webserver to get those two values. If so, this isn't something for the BT client, just how you get the .torrent file. BTW one of the anti-viral things out there ate the file (not that I'm worried about Linux getting hit, but something did eat it). > > what is your OS and libbt version > > > AmigaOS.. and 1.04 IT STILL LIVES!!! Sigh. :'-( I wonder if v4 is ever going to happen. > About the 'no route to host' problem, it is trying to connect to 127.1.1.1, > whats this?... some other kind of local loopback address? never see it myself > here, and how to work with it? I need to set it up on my computer or it is > supposed to point the tracker/some badly configured peer?... You have a wacky tracker? Or wacky torrent? 127.1.1.1 should never be seen anywhere. I've got no idea how it could possibly be generated inside libbt. If that is somehow appearing, there might be something scribbling on memory, otherwise the fault is *definitely* in some other piece of software. At which point perhaps we document that said piece of software is badly broken, but it is likely to induce bugs of our own to handle. -- (\___(\___(\______ --=> 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\_|_/___/ |
From: Dakidd <da...@so...> - 2005-05-21 22:19:29
|
>>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 |
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\_|_/___/ |
From: Diego C. <di...@us...> - 2005-05-25 06:08:49
|
Hello Elliott On 21-05-2005 (23:14:17), you wrote: >> 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, >> ...... snip. ... > 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! > erm... on my Classic Amiga I have a 68060 overclocked at 66Mhz. . . . .. . tested just now and it takes about 2 minutes to write a 262 Mb file, however thats depends on the IDE controller, Im using the A1200's default controller with transfer data of about 2.5Mb/s (Im talking of a 1992's computer :) hmm, no more laughts folks! ;-D > 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) > right now Im using btget, also running my browser, my emailer (ofcourse, Im writing this ;), a filemanager, Apache, samba, and some other daemons.. can you deduce my current CPU Usage? I can guarante you 20-30%! :) The only "problem" I have with btget is due lseek()... since AmigaOS's seek functions lacks of auto-expand feature I needed to implement that thing.. just allocating a chunk of mem of ~10mb and filling the file with zeros until the offset desired, and Im almost sure the big problem here is my lseek() implementation which isn't properly optimized... however that isn't a great problem for me, since the 700Mb files I download aren't fillied in one step (except when I restart btget after few mb downloaded..), honestly I can't see big problems right now, Im so happy to be able to downloaded torrents for first time on my Amiga :-).. Kind Regards |
From: Dakidd <da...@so...> - 2005-05-22 16:47:52
|
>>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?! I'm using a PowerMac 7500, G4@450. In terms of "raw power", it compares favorably to a mid-range P2 or P3 - when the code it's running is worth anything... Python here in Mac-land doesn't qualify as "worth anything". In a nutshell, Python on a Mac *SUCKS*. Not just a little, but HIDEOUSLY. It'll take the chrome off a bumper at 50 paces, and still have power left over to pull a golf ball through a garden hose. Apps written in Python running on a Mac suck even harder. >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) My tests of the parts of LibBT that I've got ported and operational are giving me every indication that BitTorrent will run just fine - If it ever arrives as an actual compiled app, rather than the godforsaken clusterfsk that is the "official" client written in Python. >> 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? Well, the method I keep coming back to, then discarding, then coming back to, then discarding again (lather-rinse-repeat) would involve checking a block at a time and updating the tracker after each block, rather than doing the checking as a "monolithic" action and talking to the tracker only once. It's hard for me to put it into words - perhaps I ought to sit down and concentrate on the algorithm for a bit... Later... For now, I'd be happy just getting this beast to WORK, let alone wrok WELL, or "The way I think it ought to". >> (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. Disagree all you like. ReidSHA passes all of the NIST test data with no problems, which is a fairly good indication that it's correct. It's basically a speed optimization of the NIST code, unrolling loops, stomping out unneccesary redundancy, and otherwise reorganizing to achieve better speed. >OpenSSL is very common. Show me the port for Macs running pre-MacOS X systems, and I'll show you the code that never existed. Maybe in Windows-Land it's very common. Here in "Mac-world", it plain doesn't exist - Period. (And save your breath - I'm *NOT* going to be the person who ports it across - I've already got plenty on my plate already, thank you very much!) >This means they've got the >eyeballs to look at code and make sure it is correct and fast. By all information I can find, that's already been dealt with in ReidSHA. >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. Actually, it's not a library - Just some code that I'm rolling directly into LibBT. Once I get things cranked up (if I ever manage to find enough time to do so) there will be no need to "go hunting" for anything - I intend to make LibBT for the Mac be a truly "standalone" library, not dependent on anything except the standard C library (and as little of that as I can possibly get away with - I'm still debating whether it ought to have part of the functionality of "string.h" rolled directly in so that I can get away from depending on even that much external support code) and OS-supplied services. For my nickel, the "ideal" LibBT port to Mac will have *NO* dependencies other than OS-supplied stuff (Primarily networking and disk-access, although a couple other minor things will also be needed - "print to the screen", "read the keyboard", etc) rather than needing umpty-seven libraries (several of which just plain don't exist for Macs) worth of support code. That's the target I'm aiming at - Truly a standalone library. Quite frankly, the concept of needing to drag half a dozen "foreign" libraries into the linkage so that the library that's being built can run offends my sensibilities in a big and ugly fashion. And that doesn't apply only to LibBT - That goes for *ANY* library code. If it can't be written to be standalone, requiring no support other than OS-level primitives for I/O and networking, then it doesn't qualify as a "proper" library by my standards. >For crypto is an >extremely bad idea as it is difficult to get right. All reviews I've stumbled across give ReidSHA high marks for both correctness and execution speed. Likewise, my own testing, limited though it may be due to not having a "master cryptologist" degree, seems to indicate that it has no significant flaws. It appears it's been "got right". Don Bruder - da...@so... <--- Preferred Email - unmunged I will choose a path that's clear: I will choose Free Will! - N. Peart |
From: Alien <ali...@us...> - 2005-05-23 08:47:15
|
the CVS version has as dependencies: =2D maybe libuuid (not really required) =2D ssl (for SHA checking) =2D curl (for fetching) =2D m (for math) =2D pthread (not really required) these are widely spread; if not so for MacOS, i intend to find good=20 replacements for those. lemme know which ones don't work and possible replacements for each of=20 those... AL13N PS: I will think about these things, but I won't change it until i got btge= t=20 running good, myself... Op zondag 22 mei 2005 18:46, schreef Dakidd: > >>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 c= an > >> 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?! > > I'm using a PowerMac 7500, G4@450. In terms of "raw power", it compares > favorably to a mid-range P2 or P3 - when the code it's running is worth > anything... Python here in Mac-land doesn't qualify as "worth anything". > > In a nutshell, Python on a Mac *SUCKS*. Not just a little, but HIDEOUSLY. > It'll take the chrome off a bumper at 50 paces, and still have power left > over to pull a golf ball through a garden hose. Apps written in Python > running on a Mac suck even harder. > > >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) > > My tests of the parts of LibBT that I've got ported and operational are > giving me every indication that BitTorrent will run just fine - If it ever > arrives as an actual compiled app, rather than the godforsaken clusterfsk > that is the "official" client written in Python. > > >> 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 th= at > >> 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? > > Well, the method I keep coming back to, then discarding, then coming back > to, then discarding again (lather-rinse-repeat) would involve checking a > block at a time and updating the tracker after each block, rather than > doing the checking as a "monolithic" action and talking to the tracker on= ly > once. > It's hard for me to put it into words - perhaps I ought to sit down and > concentrate on the algorithm for a bit... Later... For now, I'd be happy > just getting this beast to WORK, let alone wrok WELL, or "The way I think > it ought to". > > >> (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 defini= te > >> Good Thing. > > > >I strongly disagree. > > Disagree all you like. ReidSHA passes all of the NIST test data with no > problems, which is a fairly good indication that it's correct. It's > basically a speed optimization of the NIST code, unrolling loops, stomping > out unneccesary redundancy, and otherwise reorganizing to achieve better > speed. > > >OpenSSL is very common. > > Show me the port for Macs running pre-MacOS X systems, and I'll show you > the code that never existed. Maybe in Windows-Land it's very common. Here > in "Mac-world", it plain doesn't exist - Period. (And save your breath - > I'm *NOT* going to be the person who ports it across - I've already got > plenty on my plate already, thank you very much!) > > >This means they've got the > >eyeballs to look at code and make sure it is correct and fast. > > By all information I can find, that's already been dealt with in ReidSHA. > > >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. > > Actually, it's not a library - Just some code that I'm rolling directly > into LibBT. Once I get things cranked up (if I ever manage to find enough > time to do so) there will be no need to "go hunting" for anything - I > intend to make LibBT for the Mac be a truly "standalone" library, not > dependent on anything except the standard C library (and as little of that > as I can possibly get away with - I'm still debating whether it ought to > have part of the functionality of "string.h" rolled directly in so that I > can get away from depending on even that much external support code) and > OS-supplied services. > > For my nickel, the "ideal" LibBT port to Mac will have *NO* dependencies > other than OS-supplied stuff (Primarily networking and disk-access, > although a couple other minor things will also be needed - "print to the > screen", "read the keyboard", etc) rather than needing umpty-seven > libraries (several of which just plain don't exist for Macs) worth of > support code. That's the target I'm aiming at - Truly a standalone librar= y. > Quite frankly, the concept of needing to drag half a dozen "foreign" > libraries into the linkage so that the library that's being built can run > offends my sensibilities in a big and ugly fashion. And that doesn't apply > only to LibBT - That goes for *ANY* library code. If it can't be written = to > be standalone, requiring no support other than OS-level primitives for I/O > and networking, then it doesn't qualify as a "proper" library by my > standards. > > >For crypto is an > >extremely bad idea as it is difficult to get right. > > All reviews I've stumbled across give ReidSHA high marks for both > correctness and execution speed. Likewise, my own testing, limited though > it may be due to not having a "master cryptologist" degree, seems to > indicate that it has no significant flaws. It appears it's been "got > right". > > > > Don Bruder - da...@so... <--- Preferred Email - unmunged > I will choose a path that's clear: I will choose Free Will! - N. Peart > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_id=3D7412&alloc_id=3D16344&op=3Dclick > _______________________________________________ > Libbt-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libbt-devel |
From: Diego C. <di...@us...> - 2005-05-25 06:08:33
|
Hello Dakidd On 21-05-2005 (22:19:34), you wrote: >>> 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. > thats not what I wanted to express, as I told on my previous mail, however it could be a good idea if there is any reliable method to perform it. > 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. > I think an easy way should be just using a plain text file (like some others p2p systems) containing the offsets of pieces downloaded (and his hash(?)), and later, when the file goes 100% complete, perform a full hash check. I have some basic C knowlement, but I can try to implement this if I manage to understand how this works.. however if that improvement is added as an optional behavior there shouldn't be any problem to do it IMHO, what all you do think, ...Kevin? > Pre-OSX Macintosh systems - "Canned" goodies like LibCURL, the OpenSSL > libraries, etc, just aren't "there" for me and my platform, so I'm surprising, whats the reason why you do not have those packages ported to MacOS ?? AmigaOS and MacOS: both systems are big-endian: the classic models used the Motorola 680x0 chipsets, and the next-gen models a PowerPC, in few works they are 100% compatibles (in architecture words ;) I haven't too much idea about Mac internals.. but it is surprissing for me the fact they aren't available for MacOS when they are working just fine (and natively) on AmigaOS. Kind Regards |
From: Alien <ali...@us...> - 2005-05-25 07:16:47
|
Op woensdag 25 mei 2005 08:00, schreef Diego Casorran: > Hello Dakidd > > On 21-05-2005 (22:19:34), you wrote: > >>> 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. > > thats not what I wanted to express, as I told on my previous mail, however > it could be a good idea if there is any reliable method to perform it. > > > 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. > > I think an easy way should be just using a plain text file (like some > others p2p systems) containing the offsets of pieces downloaded (and his > hash(?)), and later, when the file goes 100% complete, perform a full hash > check. > > I have some basic C knowlement, but I can try to implement this if I mana= ge > to understand how this works.. however if that improvement is added as an > optional behavior there shouldn't be any problem to do it IMHO, what all > you do think, ...Kevin? if I understand you correctly, then you are talking bullshit. I'm not kevin= ,=20 but the BitTorrent whole idea is based upon an amount of pieces completing,= =20 so one can upload the pieces that are finished, hash checking _has_ to be=20 done upon completing a piece (for that piece only), and thank god for that,= =20 otherwise our downloads would've been so slow, that we'd never use=20 BitTorrent. There is no use to make a totally incompatible client and let people leech= =20 away without doing something for the others, I am strongly against such=20 variations of BitTorrent protocols, there is a max_rate for that purpose. AL13N |
From: Diego C. <di...@us...> - 2005-05-25 10:51:06
|
Hello Alien On 25-05-2005 (07:16:30), you wrote: >> I think an easy way should be just using a plain text file (like some >> others p2p systems) containing the offsets of pieces downloaded (and >> his hash(?)), and later, when the file goes 100% complete, perform a >> full hash check. >> >> I have some basic C knowlement, but I can try to implement this if I >> manage to understand how this works.. however if that improvement is >> added as an optional behavior there shouldn't be any problem to do it >> IMHO, what all you do think, ...Kevin? > > if I understand you correctly, then you are talking bullshit. I'm not > kevin, but the BitTorrent whole idea is based upon an amount of pieces > completing, so one can upload the pieces that are finished, hash > checking _has_ to be done upon completing a piece (for that piece > only), and thank god for that, otherwise our downloads would've been so > slow, that we'd never use BitTorrent. > no no no, ofcourse, I do not mean that, hash check ofcourse *must* be performed. just I mean: when a piece is completed and the hash checked, in addition to save that info on memory write it to a text file, therefore on next btget run, the file being downloaded shouldn't be necessarily checked for completed pieces because that data was previously stored on that text file. "shouldn't be necessarily checked" I mean that adding a new command line option, (so the user will decide if perform the whole hash check or use the data saved on the text file), will be just fine for everybody, imho. hope now is clear, and sorry for my bad english again... Kind Regards |
From: Peter S. <stu...@cd...> - 2005-05-25 11:25:26
|
On Wed, May 25, 2005 at 12:42:43PM +0200, Diego Casorran wrote: > just I mean: > > when a piece is completed and the hash checked, in addition to save > that info on memory write it to a text file, therefore on next > btget run, the file being downloaded shouldn't be necessarily > checked for completed pieces because that data was previously > stored on that text file. This isn't a bad idea, it is certainly relevant for some cases. But I don't think libbt should go about creating lots of data bases on it's own, I instead suggest that libbt hands the information up to the calling application, which can then save it any way it likes to. Also, on initializing a torrent with libbt, an optional map of good pieces could be sent by the application, and libbt would then assume marked pieces are actually correct. //Peter |
From: Alien <ali...@us...> - 2005-05-25 12:12:57
|
Op woensdag 25 mei 2005 13:25, schreef Peter Stuge: > On Wed, May 25, 2005 at 12:42:43PM +0200, Diego Casorran wrote: > > just I mean: > > > > when a piece is completed and the hash checked, in addition to save > > that info on memory write it to a text file, therefore on next > > btget run, the file being downloaded shouldn't be necessarily > > checked for completed pieces because that data was previously > > stored on that text file. > > This isn't a bad idea, it is certainly relevant for some cases. > > But I don't think libbt should go about creating lots of data bases > on it's own, I instead suggest that libbt hands the information up to > the calling application, which can then save it any way it likes to. the status of everything is available to the calling application, it can=20 deduce stuff from itself, i don't think piecemanagement is a good idea, fro= m=20 the progress, it can see if some files are completely done, so... > Also, on initializing a torrent with libbt, an optional map of good > pieces could be sent by the application, and libbt would then assume > marked pieces are actually correct. i don't really believe in this... applications shouldn't have anything to d= o,=20 and we cannot assume pieces, uploads could go wrong and stuff. at start, the reading of the file isn't really that slow, and won't interfe= re=20 with down/uploading or system performance anyway... I'd advise against these things... |
From: Peter S. <stu...@cd...> - 2005-05-25 12:43:29
|
On Wed, May 25, 2005 at 02:12:42PM +0200, Alien wrote: > > But I don't think libbt should go about creating lots of data > > bases on it's own, I instead suggest that libbt hands the > > information up to the calling application, which can then save it > > any way it likes to. > > the status of everything is available to the calling application, > it can deduce stuff from itself, i don't think piecemanagement is a > good idea, from the progress, it can see if some files are > completely done, so... Well, that depends on the design goal of libbt, I guess. Either simple to use for applications that want to add BT support. Or feature-complete and means for micro management. Or perhaps we can have both? I think curl is a good example of both, although I do admit I've only used it a few times. > > Also, on initializing a torrent with libbt, an optional map of > > good pieces could be sent by the application, and libbt would > > then assume marked pieces are actually correct. > > i don't really believe in this... applications shouldn't have > anything to do, Unless it's sole purpose is to do BT and do it extremely well. > and we cannot assume pieces, uploads could go wrong and stuff. Yes, but then peers will hate you and stop talking to you, which makes the problem a non-issue. This should of course be a user decision with a sensible default. (Ie. no correct pieces.) > at start, the reading of the file isn't really that slow, and won't > interfere with down/uploading or system performance anyway... It sure interferes with the performance of my system, but otoh I'm on a P3 laptop with a 5k4 RPM disk. :) > I'd advise against these things... They all need good default values and settings, but ultimately I don't think libbt should devise a method to save state between invocations. The calling application will probably already have some way to save state, I'm guessing different ones for each application, and I think it makes more sense to store libbt state at the same place, since it's certainly only relevant information within the scope of the application. //Peter |
From: Alien <ali...@us...> - 2005-05-25 13:05:35
|
Op woensdag 25 mei 2005 14:43, schreef Peter Stuge: > On Wed, May 25, 2005 at 02:12:42PM +0200, Alien wrote: > > > But I don't think libbt should go about creating lots of data > > > bases on it's own, I instead suggest that libbt hands the > > > information up to the calling application, which can then save it > > > any way it likes to. > > > > the status of everything is available to the calling application, > > it can deduce stuff from itself, i don't think piecemanagement is a > > good idea, from the progress, it can see if some files are > > completely done, so... > > Well, that depends on the design goal of libbt, I guess. > > Either simple to use for applications that want to add BT support. > Or feature-complete and means for micro management. > > Or perhaps we can have both? I think curl is a good example of both, > although I do admit I've only used it a few times. I wanna have both curl has some shortcomings... > > > Also, on initializing a torrent with libbt, an optional map of > > > good pieces could be sent by the application, and libbt would > > > then assume marked pieces are actually correct. > > > > i don't really believe in this... applications shouldn't have > > anything to do, > > Unless it's sole purpose is to do BT and do it extremely well. it doesn't matter, they should not fiddle with the background of libbt; libbt sole purpose is to do only libbt and do it well, not the application,= =20 it's goal is to make calls and display progress, and manage more or less=20 torrents or whatever... > > and we cannot assume pieces, uploads could go wrong and stuff. > > Yes, but then peers will hate you and stop talking to you, which > makes the problem a non-issue. This should of course be a user > decision with a sensible default. (Ie. no correct pieces.) with lost networking, and other people being angry that there are clients o= ut=20 there that allow broken pieces to be uploaded... no, this is not going to=20 happen, strictly for security reasons and networking reasons only... you wa= nt=20 fast downloads? you check the pieces. > > at start, the reading of the file isn't really that slow, and won't > > interfere with down/uploading or system performance anyway... > > It sure interferes with the performance of my system, but otoh I'm on > a P3 laptop with a 5k4 RPM disk. :) we'll make it a seperate thread and let you nice it to your likings, ok? > > I'd advise against these things... > > They all need good default values and settings, but ultimately I > don't think libbt should devise a method to save state between > invocations. The calling application will probably already have some > way to save state, I'm guessing different ones for each application, > and I think it makes more sense to store libbt state at the same > place, since it's certainly only relevant information within the > scope of the application. i don't think that has anything to do with it... if you don't want it to ru= n=20 and you want it to run later with the same settings, just pause the damn=20 thing... problem solved... AL13N |
From: Kevin S. <ke...@an...> - 2005-05-25 06:01:34
|
Elliott Mitchell wrote: >>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. > > > >>>an assertion is there to tell us that there is a bug in programming, >>>it's not it's job to restart btget. >>> >>>Since I'm not involved in the release, i cannot answer the rest of your >>>questions and i cannot direct your concerns... >>> >>>btw: i never heard about trackers that request user/passwd, can you send >>>us one? >>> >>> >>> >>its attached, seems that all torrents from www.pctorrent.com needs a user&pass >>to connect to his tracker, however not a great problem, later or sonner they >>will be available from somewhere else.. >> >> > >This might be a case of it gives you a modified URL which you use to >connect to the tracker. Along the lines of ><trackerurl>&&user=<foo>&&pass=<bar> and you're supposed to connect to >a central webserver to get those two values. If so, this isn't something >for the BT client, just how you get the .torrent file. > >BTW one of the anti-viral things out there ate the file (not that I'm >worried about Linux getting hit, but something did eat it). > > > >>>what is your OS and libbt version >>> >>> >>> >>AmigaOS.. and 1.04 >> >> > >IT STILL LIVES!!! Sigh. :'-( I wonder if v4 is ever going to happen. > > > >>About the 'no route to host' problem, it is trying to connect to 127.1.1.1, >>whats this?... some other kind of local loopback address? never see it myself >>here, and how to work with it? I need to set it up on my computer or it is >>supposed to point the tracker/some badly configured peer?... >> >> > >You have a wacky tracker? Or wacky torrent? 127.1.1.1 should never be >seen anywhere. I've got no idea how it could possibly be generated inside >libbt. If that is somehow appearing, there might be something scribbling >on memory, otherwise the fault is *definitely* in some other piece of >software. At which point perhaps we document that said piece of software >is badly broken, but it is likely to induce bugs of our own to handle. > > > > 127.*.*.*/8 are all loopback devices. Your tracker shouldn't be returning anything in that range, but I've fixed some of the error handling when a connect fails immediately, so the synch error should go away. Test the latest release branch and let me know if it works for you. |
From: Diego C. <di...@us...> - 2005-05-25 10:50:52
|
Hello Kevin = On mi=E9rcoles (25-05-2005), you wrote: > 127.*.*.*/8 are all loopback devices. Your tracker shouldn't be = > returning anything in that range, but I've fixed some of the error = > handling when a connect fails immediately, so the synch error should go = > away. Test the latest release branch and let me know if it works for > you. > nice, thanks, will check. Kind Regards. |
From: Diego C. <di...@us...> - 2005-05-25 06:07:02
|
Hello Elliott On 21-05-2005 (21:20:12), you wrote: > All BT clients do this. > thats ok, ofcourse, what I mean (and afaik) on the program run all pieces are hashed (even if lseek() must expand the file), those which match are saved/remembered on memory, if there is some new piece before btget dies (in case of) they are stored on memory as well, when btget dies I wanted to just restart it without exit since all ok pieces are already stored on memory, and shouldn't be really needed to exit if you really do not want to exit (with a option, for example..), atleast when the mentioned assertion fails, I think. >> AmigaOS.. and 1.04 > > IT STILL LIVES!!! Sigh. :'-( I wonder if v4 is ever going to happen. > yeah, ofcourse.. :-) what? you wonder if AmigaOS v4.0 is going to happen? then I have great news to you.. it is a reallity! it is currently/still being developed and already available and distributed with the new Amiga models (PowerPC G3/G4), dont hesitate to let me know if you need more info/specs/urls :) btw, that ":'-(" smiley means you melancolic? ...or? >> About the 'no route to host' problem, it is trying to connect to >> 127.1.1.1, whats this?... some other kind of local loopback address? >> never see it myself here, and how to work with it? I need to set it up >> on my computer or it is supposed to point the tracker/some badly >> configured peer?... > > You have a wacky tracker? Or wacky torrent? 127.1.1.1 should never be > seen anywhere. I've got no idea how it could possibly be generated > inside libbt. If that is somehow appearing, there might be something > scribbling on memory, otherwise the fault is *definitely* in some other > piece of software. At which point perhaps we document that said piece of > software is badly broken, but it is likely to induce bugs of our own to > handle. > > well, I dunno whats up here.. but for now I got that problem only fetching the attached torrent (however until todays Ive downloaded 4-5 torrents only), try and see it for yourself if you want, may you can discover whats wrong. Kind Regards |
From: Alien <ali...@us...> - 2005-05-25 07:21:47
|
Op woensdag 25 mei 2005 07:59, schreef Diego Casorran: > Hello Elliott > > On 21-05-2005 (21:20:12), you wrote: > > All BT clients do this. > > thats ok, ofcourse, what I mean (and afaik) on the program run all pieces > are hashed (even if lseek() must expand the file), those which match are > saved/remembered on memory, if there is some new piece before btget dies > (in case of) they are stored on memory as well, when btget dies I wanted = to > just restart it without exit since all ok pieces are already stored on > memory, and shouldn't be really needed to exit if you really do not want = to > exit (with a option, for example..), atleast when the mentioned assertion > fails, I think. I have worked out a solution for this on the CVS version, files aren't=20 increased in size by lseek anymore when checking them at the start. > >> AmigaOS.. and 1.04 > > > > IT STILL LIVES!!! Sigh. :'-( I wonder if v4 is ever going to happen. > > yeah, ofcourse.. :-) > > what? you wonder if AmigaOS v4.0 is going to happen? then I have great ne= ws > to you.. it is a reallity! it is currently/still being developed and > already available and distributed with the new Amiga models (PowerPC > G3/G4), dont hesitate to let me know if you need more info/specs/urls :) > > btw, that ":'-(" smiley means you melancolic? ...or? > > >> About the 'no route to host' problem, it is trying to connect to > >> 127.1.1.1, whats this?... some other kind of local loopback address? > >> never see it myself here, and how to work with it? I need to set it up > >> on my computer or it is supposed to point the tracker/some badly > >> configured peer?... > > > > You have a wacky tracker? Or wacky torrent? 127.1.1.1 should never be > > seen anywhere. I've got no idea how it could possibly be generated > > inside libbt. If that is somehow appearing, there might be something > > scribbling on memory, otherwise the fault is *definitely* in some other > > piece of software. At which point perhaps we document that said piece of > > software is badly broken, but it is likely to induce bugs of our own to > > handle. > > well, I dunno whats up here.. but for now I got that problem only fetching > the attached torrent (however until todays Ive downloaded 4-5 torrents > only), try and see it for yourself if you want, may you can discover whats > wrong. maybe someone on the tracker itself is down/up-loading and he gave the wron= g=20 IP, or someone is using totally different routing in his LAN... the=20 specifications should tell us that 127.0.0.1/8 is routed to itself, and !no= t!=20 127.0.0.1/24 or something... i guess we'll have to put in an additional check to see if it's a valid IP.= =2E. AL13N |
From: Diego C. <di...@us...> - 2005-05-25 10:51:17
Attachments:
context.c.patch
|
Hello Alien On 25-05-2005 (07:21:36), you wrote: >> pieces are hashed (even if lseek() must expand the file), those which > > I have worked out a solution for this on the CVS version, files aren't > increased in size by lseek anymore when checking them at the start. > Thanks!, will download asap >> > maybe someone on the tracker itself is down/up-loading and he gave the > wrong IP, or someone is using totally different routing in his LAN... > the specifications should tell us that 127.0.0.1/8 is routed to itself, > and !not! 127.0.0.1/24 or something... > > i guess we'll have to put in an additional check to see if it's a valid > IP... Ive created a quick function to do this job, is attached, let me know if it is ok. Kind Regards |
From: Peter S. <stu...@cd...> - 2005-05-25 11:29:08
|
On Wed, May 25, 2005 at 12:46:15PM +0200, Diego Casorran wrote: > > i guess we'll have to put in an additional check to see if it's a > > valid IP... > > Ive created a quick function to do this job, is attached, let me > know if it is ok. IMHO this is a very very bad idea. Private IP networks is a matter of politics, not technology, and as such it shouldn't be special-cased in software. I might want to do IP tricks to find a tracker or peers, please don't cripple libbt like this. //Peter |
From: Alien <ali...@us...> - 2005-05-25 12:14:30
|
Op woensdag 25 mei 2005 13:29, schreef Peter Stuge: > On Wed, May 25, 2005 at 12:46:15PM +0200, Diego Casorran wrote: > > > i guess we'll have to put in an additional check to see if it's a > > > valid IP... > > > > Ive created a quick function to do this job, is attached, let me > > know if it is ok. > > IMHO this is a very very bad idea. Private IP networks is a matter of > politics, not technology, and as such it shouldn't be special-cased > in software. > > I might want to do IP tricks to find a tracker or peers, please don't > cripple libbt like this. it is not the purpose of libbt to check for such stuff... but, proper error handling is to be implemented... |
From: Peter S. <stu...@cd...> - 2005-05-25 12:43:48
|
On Wed, May 25, 2005 at 02:14:15PM +0200, Alien wrote: > > IMHO this is a very very bad idea. Private IP networks is a matter of > > politics, not technology, and as such it shouldn't be special-cased > > in software. > > > > I might want to do IP tricks to find a tracker or peers, please don't > > cripple libbt like this. > > it is not the purpose of libbt to check for such stuff... I agree. > but, proper error handling is to be implemented... Indeed! :) //Peter |
From: Alien <ali...@us...> - 2005-05-25 12:15:28
|
Op woensdag 25 mei 2005 12:46, schreef Diego Casorran: > Hello Alien > > On 25-05-2005 (07:21:36), you wrote: > >> pieces are hashed (even if lseek() must expand the file), those which > > > > I have worked out a solution for this on the CVS version, files aren't > > increased in size by lseek anymore when checking them at the start. > > Thanks!, will download asap you miss the point, it's only on CVS fixed ( and the cvs version doesn't do= wn=20 or upload yet)... there is no download of that yet... i'm trying to finish CVS libbt as fast as i can, ok??? |