Re: [Mldonkey-users] feature suggestion: forward error correction

[Goswin Brederlow]

Christian Brandt <address@hidden> writes:

> On Thu, Sep 05, 2002 at 05:19:06AM +0200, Goswin Brederlow wrote:
> 
> > C and D are still online and together they have 4 different chunks:
> > 
> >    25 D-----C 36   ===>   2356 D------C 2356
> > 
> > Using FEC both can now restore the original file.
 
>  Ok, this may work out. But you also increase traffic: A FEC which
>  is only able to reconstruct one part out of five or 2 out of 15
>  increases Bandwidth by 15-20%, make this 2 out of 7 or something
>  like that and you quickly need 40 or 50% more bandwidth. Those
>  numbers are educated guesses, hamming code & Co have faded out of
>  my view after a decade or so.

I'm thinking about 30 out of 65536. The 9 MB blocks are kept as it is
and each file is extended with FEC to have 65536 blocks.

Why should that increase bandwith? Now you need X blocks for a
file. With FEC you still need X blocks for a file. The only thing that
grows is the block list each client has. That should be runlength
encoded or gziped or something since its usually very sparse. As you
can see with my example above each client downloads 4 blocks of 4
needed for the file. No bandwith wasted.

Even with FEC you could just request the original chunks and would
have the current behaviour.

> My 2cent: Bandwidth is too expensive to be wasted this way as
> incomplete files are an rare exception, not the general case. But
> still its an ugly exception ;-) Also this would make the
> Donkeyprotocol too complex for Joe Average to understand. Hey, most
> even do not understand "for 1-3kb/s I get 3-9kB, for 4-9kb/s I get
> 12-45kb/s and for 10kb/s I get limitless bandwidth". Most would
> start to think of donkey beeing an user-annoying-tool and not a
> p2p-software.

FEC would be quite transparent to the user.

MfG
        Goswin