mldonkey-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Goswin Brederlow
Subject: Re: [Mldonkey-users] feature suggestion: forward error correction
Date: 05 Sep 2002 05:19:06 +0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Honest Recruiter)

Christian Brandt <address@hidden> writes:

> Am Mittwoch, 4. September 2002 13:20 schrieben Sie:
> 
> > So why would we want to do this? We have checksums per block and can
> > detect errors and redownload the block. So FEC isn't realy needed you
> > might think.
> 
>  This idea sounds interesting, but why would this be helpfull?
> 
>  Uncompletable Files are uncompletable because there is no longer a 
> complete Copy of the file available. You can't remove that fact by using 
> FEC, you would rather need an upload-technique which speeds up sending of 
> rare chunks. But even then you couldn't avoid incomplete files.

Why are files incomplete?

1. The file was never uploaded 100%. Nothing you can do there.

2. The file was uploaded but all the persons having a certain chunk
are offline now or most of the time.

Now consider the second case. Assuming the file has 4 chunks and we
have 4 users (a,b,c,d).

A sends out 6 chunks to b, c and d. But then A and B go offline.

        1 4
      A-----B
      |\     
     2| \3   
     1|  \2  
      |   \  
      |    \ 
      D     C

C and D are still online but they can only exchange chunk 1 and 3:

   12 D-----C 23   ===>   123 D------C 123

The file stays incomplete.

Now the same with FEC: A sends out 6 chunks to b, c and d. But then A
and B go offline. Chunks 5 and 6 are FEC chunks

        1 4
      A-----B
      |\     
     2| \3   
     5|  \6  
      |   \  
      |    \ 
      D     C

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.


Also note that even if A and B stay online but have a slow connection
it might be much faster for C and D to trade chunks instead of asking
A or B.

>  To implement an "everything is complete" one must force the operator of a 
> client to keep data on his drive. But drivespace is a limited resource and 
> I think its not a donkeys mission to occupie other people resources based 
> on complicated assumptions which haven't to do much with "the real thing": 
> Bandwidth-Utilization.

Drivespace is limited. So to best utilise the space you would want
information on the drive that is most valuable. A chunk that everyone
has is not realy valuable. There are many places to get that
chunk. The most valuable is a chunk that only you have. Anyone
intrested in that file would want that chunk.

With FEC there are more chunks for a file (but not more chunks needed
to restore the file) so less people have each chunk. The chunks become
more valuable.


With FEC its bad to send out a chunk twice if it can be avoided.
Because you send out a chunk already someone else has it so you don't
have to provide it again. If the person deleted that chunk or is
offline it doesn't hurt, because no single chunk is strictly
neccessary.

FEC increases the redundancy of a file. It has no single point of
failure as a missing chunk has now.

> But then I am just a happy user and not Swamp or mldonkey ;-)

I'm not quite happy. Encouraged, satisfied but not quite happy.
It could still be better. :)

MfG
        Goswin




reply via email to

[Prev in Thread] Current Thread [Next in Thread]