[Http-crcsync] General comments on crcsync document

Alex Wulms alex.wulms at scarlet.be
Thu Jul 9 17:31:31 EDT 2009


Hi Patrick,

Sorry, I just realise I got my formula's mixed-up. I was starting from the 
situation that we know the filesize and the blocksize but in reality we know 
the filesize and the number of blocks, including the trailing block.

The current implementation is based on having 40 full-blocks and an optional 
non-0-size trailing block. The dynamic number-of-block stuff is not yet 
implemented.

I must think about how to specify this mathematically but I'm too tired now. 
But in your example, 3x15 and no trailer (or a zero-size trailer) would be 
the right one.

Cheers,
Alex


Op donderdag 9 juli 2009, schreef Alex Wulms:
> Hi,
>
> I'll specify it as following in the spec:
>
> number-of-full-blocks = filesize/blocksize
> trailing-block-size = filesize%blocksize
> trailing-block only exists if trailing-block-size != 0
>
> All operations in integer logic, using C conventions (e.g. / is integer
> division, % is modulo)
>
> Cheers,
> Alex
>
> Op donderdag 9 juli 2009, schreef Patrick McManus:
> > > Regarding trailing block and file-size header: we specify the file-size
> > > and we (plan to) specify the number of blocks (though, it could indeed
> > > be implicitly derived from the blocks-header-size like somebody
> > > mentioned).
> >
> > so number of blocks is the missing information, not block-size?
> >
> > Doesn't that still make the block size ambiguous?
> >
> > e.g. file-size = 45, number of blocks = 3 ..
> > wouldn't (3x15 + a trailer of 0) and (2x20 + a trailer of 5) both be
> > legitimate?
> >
> > maybe I'm just missing something, but the block size would seem to be
> > something the server would need to compute hashes when looking for a
> > matched block.
> >
> > I've also got this inkling that you ought to at least put some SHOULDs
> > around various recommended block sizes.. In the cases where the server
> > is not creating the resource completely on the fly this would allow it
> > to cache some important meta information and save itself some runtime
> > computations if it at least had a reasonable expectation about what
> > block size the next request would use...
>
> _______________________________________________
> Http-crcsync mailing list
> Http-crcsync at lists.laptop.org
> http://lists.laptop.org/listinfo/http-crcsync




More information about the Http-crcsync mailing list