Matthew Toseland <toad at amphibian.dyndns.org> writes: > 0.5.1 will be out soon. Main features being ARKs, working splitfiles and > lots of bug fixes. > I look forward to this release greatly.
> 0.5.2 focuses will be initially: > overhaul of splitfile user interface > some sort of request pool so that we can allocate decent numbers of > threads to a splitfile download/upload without overloading the node > I just hope we do a good job of building splitfile support into fred so that future users aren't burdened with a poor interface > other splitfile improvements > specifically: can we stream FEC splitfiles? it is certainly > possible to stream non-FEC splitfiles, (although we still > have to wait for the first block), but if it is FEC... > it might take a large number of randomly chosen blocks to > generate the first output block. So how do we do this? Any > constructive suggestion would be appreciated... I'll give three answers to your question; one for FEC in general, one for the FEC that's being used at the moment and one for xor-based FEC. There's nothing inherent in FEC that prevents using FEC on streaming data and coming out with a nice datastream after FEC recovery. One big use of FEC is in multicast streaming. Onionnetworks' FEC is going to be tough to stream with. Basically you can only get the first byte of the file at the same time as you get the rest of the first slice of the file. (iirc, slices are 32MB) The scheme used divides the whole file into slices, and then does FEC on each slice, so that you can guarantee recovery of that slice when the threshold number of chunks (from that slice) are recieved. If we made slices smaller, they could be recovered with less latency, but increasing the number of chunks decreases the number of error patterns recoverable. XOR-based FEC has much smaller granularity in recovery; the file is not sliced before being chunked, and individual chunks of the file can be recovered as the necessary pieces of data are recieved. Normally in FEC, the model is set up so that the reciever has no control over what data it gets, but in freenet, the reciever has the choice of what blocks to request, and there's just a chance that each block isn't found. Because of the much smaller granularity and the way that the recipe for decoding is given beforehand, it's pretty easy to list which blocks can be downloaded to recover the first chunk of data, and then the second, and pretty quickly the FEC has already recovered blocks further down the line from the extra blocks used in reconstructing early data. Thelema -- E-mail: thelema314 at swbell.net Raabu and Piisu GPG 1024D/36352AAB fpr:756D F615 B4F3 BFFC 02C7 84B7 D8D7 6ECE 3635 2AAB _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
