[Http-crcsync] crccache ready for some testing I think

[Alex Wulms]

Hi,

The updated code is in the git repository. I have also, as an experiment, 
changed from 20 blocks to 40 blocks. In practice this seems to give better 
results when there are small changes spread over several places in the page 
(e.g. some advertisement links in newssites like slashdot). The penalty of 
such small changes is now less severe.

Though, the Block-Hashes header in the request now has a length of 219 
characters (including the header field name). Don't know if that could pose a 
problem for intermediate proxies in future when rsync aware browsers are 
talking with rsync aware origin servers. In theory, it should be fine. As far 
as I know the HTTP specification does not put a limitation on the header 
length but in practice I'm pretty sure that proxies and servers do impose 
some limits but I don't know how low they are.


Cheers,
Alex



Op dinsdag 7 april 2009, schreef WULMS Alexander:
> Oops. You are right on the max tail size. I have to brush up my math a
> little bit. And fix the calculation of the tail-size in crccache-client and
> crccache-server... Will do that this evening.
>
>
> --------
> Alex WULMS
> Lead Developer/Systems Engineer
>
> Tel: +32 2 655 3931
> Information Systems - SWIFT.COM Development
> S.W.I.F.T. SCRL
>
> >-----Original Message-----
> >From: http-crcsync-bounces at lists.laptop.org
> > [mailto:http-crcsync-bounces at lists.laptop.org] On Behalf Of Rusty Russell
> >Sent: Tuesday, April 07, 2009 6:43 AM
> >To: Alex Wulms
> >Cc: Toby Collett; http-crcsync at lists.laptop.org
> >Subject: Re: [Http-crcsync] crccache ready for some testing I think
> >
> >On Monday 06 April 2009 01:23:52 Alex Wulms wrote:
> >> Op zondag 5 april 2009, schreef Rusty Russell:
> >> > On Sunday 05 April 2009 07:33:06 Alex Wulms wrote:
> >> >
> >> > I think Toby's draft, which suggested just leaving the trailing block
> >> > as a literal, is an interesting possibility.  Worst case, it's 19
> >> > bytes.
> >>
> >> Actually, in worst case scenario it is (blocksize-1) = (pagesize/20 -
> >> 1).
> >
> >Hmm, we select blocksize to encode the N byte original file in 20
> > equal-size parts, no?  So worst case is 19 bytes?
> >
> >eg. original file is 999999 bytes.  We choose block size of
> >999999 / 20 = 49999 bytes.  20 x 49999 = 999980, so if file is unchanged
> >server will answer:
> >	C00000000C00000001C00000002...C00000019L<last 19 bytes of file>
> >
> >Tridge argues that we shouldn't nail the number of csums, I'm not so sure.