libbt-devel — C Library for Bittorrent Developers

[Libbt-devel] $B$Q$s$A$e$N>e$+$i8TFl(B

[<in...@sk...>]

$B!!!|!|!|!|!|!|!|!|!|!|!|!|!|!|!|!|!|!|!|!|!|!|!|!|!|!|!|!|(B
$B!!!!!!!!!!!!!!!!!!!!!!!!!T40A4L5NA!U(B

$B!!!!!!!!!!!!!!!!!Z!!=w;R9;@8!!$rE0DlD465!*!*![(B

$B!!!!!!Gr%V%?!!!!!!!!JQBV%a%9%V%?(B12$BL>EPO?!!!!!!!!9u%V%?(B
$B!!!|!|!|!|!|!|!|!|!;!|!!!!!!!!!!!!!!!!!|!;!|!|!|!|!|!|!|!|(B
$B!!!!!!%V%9!*%V%9!*%V%9!*2<J"$K%Q%s%A!*!*!*$*$^$($O9u$$!*!*(B
$B!!!!!!<j[H(B!$B8T3d$j!*!*87=E$K1n7%!*!!@Z$C$A$c$C$?!*!*!*(B
$B!!(B
$B!!!!!!!!!!!!(Bhttp://awg.webchu.com/gyakuten/?buta
$B!!!|!|!|!|!|!|!|!|!|!|!|!|!|!|!|!|!|!|!|!|!|!|!|!|!|!|!|!|!!(B
$B!!!!(B100$B!s9-9p<}F~!!!!40A4L5NA!!!!5U1g%5%$%H!!!!#S#M(B
$B!!!NCm!OD465NA$OE[Nl$+$iD>@\D:$$$F$/$@$5$$!*(B












I don't veceive yourmail
gya...@ya... 
$B%a!<%k<u?.5qH](B
gya...@ya... 
$B!!(B
$B!!!!!!!!(B
$B!!(B

[Libbt-devel] $B%;%l%V$N7hDjHG!*(B?$BVq%g%;(B2d$Bw?%h(B

[<in...@tt...>]

$B!g!g!g!g!y!g!g!g!g!g!y!g!g!g!g!g!g!g!g!g!y!g!g!g!g!g!y!g!g!g!g!g(B
$B!c(BNO.I don't veceive your mail$B!d"M!!(Bsw...@ya...
$B!c:#8e!"<u?.$r5qH]$9$k>l9g$O!d"M!!(Bsw...@ya...
$B!g!g!g!g!y!g!g!g!g!g!y!g!g!g!g!g!g!g!g!g!y!g!g!g!g!g!y!g!g!g!g!g(B

[Libbt-devel] $B%;%l%V$N7hDjHG!*(B?$BVq%g%;(B2d$Bw?%h(B

[<in...@tt...>]

$B!g!g!g!g!y!g!g!g!g!g!y!g!g!g!g!g!g!g!g!g!y!g!g!g!g!g!y!g!g!g!g!g(B
$B!c(BNO.I don't veceive your mail$B!d"M!!(Bsw...@ya...
$B!c:#8e!"<u?.$r5qH]$9$k>l9g$O!d"M!!(Bsw...@ya...
$B!g!g!g!g!y!g!g!g!g!g!y!g!g!g!g!g!g!g!g!g!y!g!g!g!g!g!y!g!g!g!g!g(B

Re: [Libbt-devel] Segmentation faults.

[oliver <ol...@ar...>]

I should have mentioned the release i'm using: libbt-1.04 on gentoo 2005.1.

Tell me how to backtrace, and I'll backtrace : )

Also I was wondering, btget creates files when it receives packets for
them, and assigns a certain amount of space for them. However that space
isn't actually allocated (on reiserfs anyhow). Wouldn't it be wiser to
actually physically allocated the space when a blok is received for a file?

Anyway, hope this helps further.



Alien wrote:

>is this the releases or CVS HEAD?
>
>CVS HEAD is under constant development on amd64, if it wasn't to work, you'd 
>better tell me, so i can correct it. (backtrace is nice)
>
>Op zondag 4 september 2005 01:31, schreef oliver:
>  
>
>>Hi all,
>>
>>I've just wanted to know wether others have experienced a reasonably
>>high amount of segmentation faults on quite a few torrents. For example:
>>http://tracker.kedora.net/file?info_hash=D%B2%19%3FH%F3%07%8E%F7%60g0%E9%B1
>>%B9%89%C5%B4%DAx
>>
>>(welcometotehscene.com's episode 6 torrent)
>>
>>I've noticed this a lot on several torrents.
>>
>>oliver
>>
>>
>>-------------------------------------------------------
>>SF.Net email is Sponsored by the Better Software Conference & EXPO
>>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
>>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
>>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
>>_______________________________________________
>>Libbt-devel mailing list
>>Lib...@li...
>>https://lists.sourceforge.net/lists/listinfo/libbt-deve
>>
>l
>  
>

Re: [Libbt-devel] Segmentation faults.

[Alien <ali...@us...>]

is this the releases or CVS HEAD?

CVS HEAD is under constant development on amd64, if it wasn't to work, you'=
d=20
better tell me, so i can correct it. (backtrace is nice)

Op zondag 4 september 2005 01:31, schreef oliver:
> Hi all,
>
> I've just wanted to know wether others have experienced a reasonably
> high amount of segmentation faults on quite a few torrents. For example:
> http://tracker.kedora.net/file?info_hash=3DD%B2%19%3FH%F3%07%8E%F7%60g0%E=
9%B1
>%B9%89%C5%B4%DAx
>
> (welcometotehscene.com's episode 6 torrent)
>
> I've noticed this a lot on several torrents.
>
> oliver
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic=
es
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Libbt-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libbt-devel

[Libbt-devel] Segmentation faults.

[oliver <ol...@ar...>]

Hi all,

I've just wanted to know wether others have experienced a reasonably
high amount of segmentation faults on quite a few torrents. For example:
http://tracker.kedora.net/file?info_hash=D%B2%19%3FH%F3%07%8E%F7%60g0%E9%B1%B9%89%C5%B4%DAx

(welcometotehscene.com's episode 6 torrent)

I've noticed this a lot on several torrents.

oliver

Re: [Libbt-devel] [Feature Request] UDP Tracker Extension Support

[Ian <ia...@pe...>]

On Fri, 15 Jul 2005 11:25:54 +0200 (CEST)
"Maarten Vanraes" <maa...@te...> wrote:

> > Hi , developers:
> >
> > I am wondering if it's possible to add UDP support in the future
> > version ?
> > Is this in the Todo List ?
> 
> normally by design it uses TCP, will someone benefit from having UDP?
> I do not think so...
> 

  In the east asia, there are many torrents made by BitComet or
  somewhat else use both TCP and UDP.

  so, Yes, I think there are people will benefit from having UDP support
  in libbt , like me.  :p

> > does anyone have the interest to write that codes ?
> 
> I donno about the release, but the restructured CVS HEAD version has
> more pressing matters
> 

  I will check it out.
  Thanks for your response.

Re: [Libbt-devel] [Feature Request] UDP Tracker Extension Support

[Maarten V. <maa...@te...>]

> Hi , developers:
>
> I am wondering if it's possible to add UDP support in the future
> version ?
> Is this in the Todo List ?

normally by design it uses TCP, will someone benefit from having UDP? I do
not think so...

> does anyone have the interest to write that codes ?

I donno about the release, but the restructured CVS HEAD version has more
pressing matters

> Thank for your answering!
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Libbt-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libbt-devel
>
>

[Libbt-devel] [Feature Request] UDP Tracker Extension Support

[Ian <ia...@pe...>]

Hi , developers:

I am wondering if it's possible to add UDP support in the future
version ? 
Is this in the Todo List ?

does anyone have the interest to write that codes ?

Thank for your answering!

Re: [Libbt-devel] Fix for the cvs version

[Alien <ali...@us...>]

Op vrijdag 1 juli 2005 13:55, schreef Fotis Loukos:
> I recently checked out from cvs and found some errors so i'm sending a fix.
> The errors corrected are:
> 1) wrong default id, should be 20 chars instead of 22.
> 2) wrong assertions at default_config function, should not add 1 to the
> length of each string.
> 3) memory should be allocated for the default values at the beginning.
> 4) fixed an assertion that that stops the program if memory was allocated.
> It should stop it if it wasn't allocated.
> I've tried btlist and it works fine. I'm checking btget right now.
>
> Fotis

thanks

committed

[Libbt-devel] UPnP support

[Fotis L. <fo...@in...>]

I would be nice if UPnP support was added as an optional feature. Many peop=
le=20
are using nat and using UPnP they won't have to setup port forwarding by=20
hand.

=46otis

=2D-=20
Q: How many Pentium designers does it take to screw in a light bulb?
A: 1.99904274017, but that's close enough for non-technical people.

[Libbt-devel] Fix for the cvs version

[Fotis L. <fo...@in...>]

I recently checked out from cvs and found some errors so i'm sending a fix. 
The errors corrected are:
1) wrong default id, should be 20 chars instead of 22.
2) wrong assertions at default_config function, should not add 1 to the length 
of each string.
3) memory should be allocated for the default values at the beginning.
4) fixed an assertion that that stops the program if memory was allocated. It 
should stop it if it wasn't allocated.
I've tried btlist and it works fine. I'm checking btget right now.

Fotis

-- 
Are you tired of being a crash test dummy for Microsoft? Discover Linux. 

   -- Gareth Barnard

Re: [Libbt-devel] Re: Features request

[Alien <ali...@us...>]

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

Re: [Libbt-devel] Re: Features request

[Peter S. <stu...@cd...>]

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

Re: [Libbt-devel] Re: Features request

[Peter S. <stu...@cd...>]

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

Re: [Libbt-devel] Re: Features request

[Alien <ali...@us...>]

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???

Re: [Libbt-devel] Re: Features request

[Alien <ali...@us...>]

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

Re: [Libbt-devel] Re: Features request

[Alien <ali...@us...>]

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

Re: [Libbt-devel] Re: Features request

[Peter S. <stu...@cd...>]

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

Re: [Libbt-devel] Re: Features request

[Peter S. <stu...@cd...>]

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

[Libbt-devel] Re: Features request

[Diego C. <di...@us...>]

 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

[Libbt-devel] Re: Features request

[Diego C. <di...@us...>]

 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

[Libbt-devel] Re: Features request

[Diego C. <di...@us...>]

 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.

Re: [Libbt-devel] Re: Features request

[Alien <ali...@us...>]

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

Re: [Libbt-devel] Re: Features request

[Alien <ali...@us...>]

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