Edgar Friendly <thelema at cs-mercury.truman.edu> writes: > Having check blocks smaller than data blocks means that to correct one > missing key, you're going to have to retrieve more than one check > block. And if the check blocks are bigger... well, I guess you lose > most of the advantages of splitfiles; might as well just make all the > blocks bigger.
I'd really like to see a FEC algorithm that uses differently-sized checkblocks, and the benefits that this algorithm actually buys us. Until then I'm going to believe that this is just an overgeneralisation. > The next best solution (that still allows variable block sizes) is > to have an optional field that gives the size of blocks when they're > the same size, and to just have clients "deal with it" when it's not > known. Sounds good. Please don't deprecate BlockSize, just make it optional (IIRC it already is at the moment). Users of Vandermonde/OnionNetworks FEC should always insert with this field. > I think that having multiple algorithms is going to result in either > noone using FEC or clients implementing their own FEC that's only > compatible with other copies of that same client. I don't think so. If the codec is available in source in an accessible language (C preferred), under a liberal license, it will be incorporated into all maintained clients. > actually, it's worth quite a lot in terms of future growth; as better > methods of deciding how to XOR data blocks together to produce check > blocks are discovered, they can be used without requiring all client > authors to rewrite their code. That's true. But I'm not envisioning changes in FEC technology as frequent as you seem to. -- Robbe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.ng Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20020917/98e8b13a/attachment.pgp>
