[flud-devel] Short-term plans

[Alen Peacock]

On 9/28/07, Chinmay Kulkarni <chinmay007 at gmail.com> wrote:
> Hi.
>
> New to this mail group.

Welcome!  These are excellent points you bring up.


> Why aren't LT codes being considered? Also, if I haven't forgotten; RS codes
> cannot generate packets independently of the packets generated so far. This
> could be a problem if a host goes offline, and we simply have to create one
> more packet to maintain the desired redundancy.

I'd love to use LT codes (or even some other fountain code), but my
understanding is that they are seriously patent-encumbered, and thus a
non-starter for a free/open project like flud.

You are right about packet generation dependency for RS.  This is not
such a big issue for backup, though, where we are only storing a
secondary remote copy, i.e., we can always regenerate missing blocks
locally because we have the full input data locally.  In the rarer
case where we've lost the local copy, we would need to download enough
blocks from remaining hosts to reconstruct the file entirely, and then
re-upload the missing blocks.


> Is the variance high enough that we can't cover it using our redundancy
> criteria?

I initially thought so, but I have not been able to find a method for
reducing the variance using ldpc, at least not for the relatively
small number of blocks we'd like to produce.  If some method exists,
I'd love to know about it, since ldpc encode times are at least 5x
faster than the fastest rs encoders I've been able to test.

Alen