> 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.
Each block must be of a selected size, so the last block would be the
smallest block-size larger than the bytes remaining, then
padded. Performance-impact would be negligable.
Scott
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20000727/71f22ba8/attachment.pgp>
