> I'm still going to discourage people from using onionnetworks' FEC
> because of inherent weaknesses of only being able to encode small
> numbers of chunks.
Note that this behavior is true for Vandermonde-based FEC codes in
general, and not just the Onion Networks implementation. Of course, the
(patented) Tornado codes don't have this limitation, but at the cost of
having 5.5% overhead in your download.
In practice, I don't think this limitation is a problem at all. I
usually use a source symbol count of 32, which for a 100MB file would
give you 3MB chunks, which should be quite manageable.
The most important thing in content delivery is to have a large
expansion factor so that there are a large number of possible blocks
that can be used in the decoding. So I think having a large N value is
more important than the K. And indeed, the Onion Networks library
supports an N value up to 2^16, though I recommend 2^8 for performance
reasons.
If you do find an unencumbered code that has better than the Vandermonde
codes, please let me know and we'll implement it in our library right away.
Thanks,
--
Justin Chapweske, Onion Networks
http://onionnetworks.com/
_______________________________________________
devl mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
