From: "Scott G. Miller" <[email protected]>
> >
> > > By file splitting, we meant that there would be a mandatory chunk
sizes
> > > for files such as 16k, 32k, 64k, 128k, and 256k or perhaps higher.
Files
> > > would be padded so that they fit a given chunk size.  Your proposal
would
> > > have some might have some routing problems too, I think.
> >
> > Having a fixed chunk-size worries me as it imposes an arbitrary
> > restriction - why a fixed size, why not just leave it up to the client
> > (it would be in the client's interest not to make it too big as then it
> > might not get stored anywhere)?
> The fixed size restriction meant that you had to pick one size out of a
> set of possible chunk sizes.  This is partially to defeat file-size
> matching attacks.
Well there will always be a last uneved size block, unless all blocks are
forced to a size of 2^N, this restriction can be applied by either including
padding or by recursively splitting until all blocks are of size 2^N.
Padding wouldnt hurt as much as it sounds first; it would force file
splitting to reasonable size, as otherwise the padding might be unnescesary
large in proportion to the total size. For example if I have a file of size
1025k, I could split it into 9x 128k blocks thereby leaving only 127k to be
padded, or splitting it into 17x 64k blocks and leaving 65k to be padded.

--typo




_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev

Reply via email to