Edgar Friendly 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
Robert Bihlmeyer writes:
> 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.
>
I agree with you that it's not needed.
> Sounds
Edgar Friendly [EMAIL PROTECTED] 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
Robert Bihlmeyer [EMAIL PROTECTED] writes:
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.
I agree with you that it's not needed.
On 13 Sep 2002, Edgar Friendly wrote:
> > The Metadata spec should probably list the known values for this
> > field, and give links to further documentation. A genuine registry for
> > these may be needed, but I doubt that there will be more than 3
> > algorithms used in general ...
> >
> I
fish writes:
> Not to be blunt, but last I checked, and correct me if I'm wrong, freenet
> is written in java, and therefore platforms on which you cannot either
> compile java source, or execute java bytecode, are already orphaned.
>
clients don't have to run on the same architectures the
Robert Bihlmeyer writes:
> Gianni Johansson writes:
>
> > C. Within a segment all data blocks must be the same size and all
> > check blocks must be the same size. The check block and data block
> > sizes are not required to be the same however. Smaller trailing
> > blocks must be zero
On Thu, 12 Sep 2002, Gianni Johansson wrote:
> It's good to make the distinction because if you manage to get all the data
> blocks you don't need to decode at all.
bob the angry flower says "wrong,m wrong, wrong ,wrong, where did you
learn that??! wrong!!!" :-p. Seriously, this is a very
Gianni Johansson writes:
> C. Within a segment all data blocks must be the same size and all
> check blocks must be the same size. The check block and data block
> sizes are not required to be the same however. Smaller trailing
> blocks must be zero padded to the required length.
Ugh, do we
Gianni Johansson writes:
> It's good to make the distinction because if you manage to get all the data
> blocks you don't need to decode at all.
Prefering data blocks to check blocks will restrict the usefulness of
FEC, as it will make the check blocks less popular, thus less
fetchable, in
Most of this sounds pretty good.
Firstly, a stupid question - is there any reason to seperate "data blocks"
and "check blocks"? As far as the FEC encoder/decoder knows, they're just
blocks, right? I mean, that's the whole *point* of it (you need any k
blocks of n in order to decode a file).
On Thu, Sep 12, 2002 at 07:37:32PM +1000, fish wrote:
>
> Most of this sounds pretty good.
>
> Firstly, a stupid question - is there any reason to seperate "data blocks"
> and "check blocks"? As far as the FEC encoder/decoder knows, they're just
> blocks, right? I mean, that's the whole
On Thursday 12 September 2002 08:40, you wrote:
> > Anyhow, the other point I wished to make, is that from looking at your
> > information, it seems like it would be far more convinent still to just
> > call the onionnetworks library direclty - okay, yeah, I see the
> > usefulness of this for
On Thursday 12 September 2002 05:37, you wrote:
> Most of this sounds pretty good.
>
> Firstly, a stupid question - is there any reason to seperate "data blocks"
> and "check blocks"? As far as the FEC encoder/decoder knows, they're just
> blocks, right? I mean, that's the whole *point* of it
FCP FEC Proposal rev. 1.0
giannijohansson at attbi.com 20020912
I. INTRODUCTION:
This proposal presents a set of new FCP commands that can be used to
encode and decode files using forward error correction (FEC).
FEC is a way of encoding packetized data files with extra error
recovery
Most of this sounds pretty good.
Firstly, a stupid question - is there any reason to seperate data blocks
and check blocks? As far as the FEC encoder/decoder knows, they're just
blocks, right? I mean, that's the whole *point* of it (you need any k
blocks of n in order to decode a file).
On Thu, Sep 12, 2002 at 07:37:32PM +1000, fish wrote:
Most of this sounds pretty good.
Firstly, a stupid question - is there any reason to seperate data blocks
and check blocks? As far as the FEC encoder/decoder knows, they're just
blocks, right? I mean, that's the whole *point* of it
On Thursday 12 September 2002 05:37, you wrote:
Most of this sounds pretty good.
Firstly, a stupid question - is there any reason to seperate data blocks
and check blocks? As far as the FEC encoder/decoder knows, they're just
blocks, right? I mean, that's the whole *point* of it (you need
On Thursday 12 September 2002 08:40, you wrote:
Anyhow, the other point I wished to make, is that from looking at your
information, it seems like it would be far more convinent still to just
call the onionnetworks library direclty - okay, yeah, I see the
usefulness of this for providing
Gianni Johansson [EMAIL PROTECTED] writes:
It's good to make the distinction because if you manage to get all the data
blocks you don't need to decode at all.
Prefering data blocks to check blocks will restrict the usefulness of
FEC, as it will make the check blocks less popular, thus less
On Thu, 12 Sep 2002, Gianni Johansson wrote:
It's good to make the distinction because if you manage to get all the data
blocks you don't need to decode at all.
bob the angry flower says wrong,m wrong, wrong ,wrong, where did you
learn that??! wrong!!! :-p. Seriously, this is a very bad
FCP FEC Proposal rev. 1.0
[EMAIL PROTECTED] 20020912
I. INTRODUCTION:
This proposal presents a set of new FCP commands that can be used to
encode and decode files using forward error correction (FEC).
FEC is a way of encoding packetized data files with extra error
recovery information which
22 matches
Mail list logo
