[freenet-dev] rateless codes

2003-11-15 Thread Zlatin Balevsky
This idea may be rather unpopular, but too bad... :))


Rateless codes are like FEC except that they support infinite number of 
checkblocks, and the file becomes a stream.  Simple implementation is 
just to wrap the checkblocks from fec in a repeating sequence and insert 
them in a channel like frost boards, etc.  More sophisticated 
implementations don't exist afaik, the theory is at

http://www.scs.cs.nyu.edu/~petar/oncodes.pdf
http://www.scs.cs.nyu.edu/~petar/msdtalk.pdf
and if you have postscript,
http://www.scs.cs.nyu.edu/~petar/msd.ps


I believe this will provide a better performance than fec for large 
files than the current FEC algorithm as it will ensure that as long as 
someone is inserting the file stream it will be retrievable and 
reconstructable.  Of course mass adoption may have disastrous effects on 
the network (but then again the same has been said for the polling 
mechanism frost uses).  It has different uses than the standard FEC, 
most notably a large rare file that is not going to be very popular. 
When the file-stream stops being requested the inserter will effectively 
become a ddos-er, but freenet can handle that ;)  It may be integrated 
with the frost feedback mechanism (i.e. turn the source off when x 
succesful downloads complete)

As soon as I hear back from the author of the paper I will start 
implementing a client which does that.  Forward all hatemail to 
/dev/null :-pp


pgp0.pgp
Description: PGP signature
___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] rateless codes

2003-11-15 Thread Toad
On Sat, Nov 15, 2003 at 09:52:33AM -0500, Zlatin Balevsky wrote:
 This idea may be rather unpopular, but too bad... :))
 
 
 Rateless codes are like FEC except that they support infinite number of 
 checkblocks, and the file becomes a stream.  Simple implementation is 
 just to wrap the checkblocks from fec in a repeating sequence and insert 
 them in a channel like frost boards, etc.  More sophisticated 
 implementations don't exist afaik, the theory is at
 
 http://www.scs.cs.nyu.edu/~petar/oncodes.pdf
 http://www.scs.cs.nyu.edu/~petar/msdtalk.pdf
 
 and if you have postscript,
 http://www.scs.cs.nyu.edu/~petar/msd.ps
 
 
 
 I believe this will provide a better performance than fec for large 
 files than the current FEC algorithm as it will ensure that as long as 
 someone is inserting the file stream it will be retrievable and 
 reconstructable.  Of course mass adoption may have disastrous effects on 
 the network (but then again the same has been said for the polling 
 mechanism frost uses).  It has different uses than the standard FEC, 
 most notably a large rare file that is not going to be very popular. 
 When the file-stream stops being requested the inserter will effectively 
 become a ddos-er, but freenet can handle that ;)  It may be integrated 
 with the frost feedback mechanism (i.e. turn the source off when x 
 succesful downloads complete)

Why is it better to insert an infinite number of different blocks than
to insert the original N blocks? If they cease to be reachable, reinsert
them with skipDS, or pull them through with skipDS, or pull them from
another node with skipDS. I don't see the advantage.
 
 As soon as I hear back from the author of the paper I will start 
 implementing a client which does that.  Forward all hatemail to 
 /dev/null :-pp

Hehe, we haven't got to that stage yet, first we have to argue about
it, then it degenerates into hatemail. :)
-- 
Matthew J Toseland - [EMAIL PROTECTED]
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.


signature.asc
Description: Digital signature
___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl