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