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

[Rusty Russell]

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.

> > I also think we should go to 60-bit csums (but needs new CRC algo).
> I agree that that would indeed be better.

OK, I'll try to get some time to code that up.

> > Finally, I think the strong hash sent in request in Toby's draft is not
> > useful as the block signature + size can be used for caching in exactly the
> > same way.
> I was already wondering about the value of the strong hash in the request in 
> Toby's draft.
> What kind of scenario could that be used for? Would the purpose be that the 
> server caches complete pages? Can't that be handled with the 
> classical 'last-modified/modified-since/304-not-modified' protocol? The 
> purpose of crccache/crcsync is to cache the 'static' part of dynamic pages. 
> So I do not directly see the added value to use a strong hash or a 
> block-signature+size to detect 'unmodified' pages at the server level, when a 
> simpler and faster protocol already exists.

Assume:
1) CRCCache-Takes-Over-The-World (TM),
2) You serve a news website which changes with time, but not on every serve,

You will have lots of requests coming in with the Block-Hashes: from before
your last change.  You can cache that and the response to it (including the
new literals) which is even cheaper than running the crccache algo.

Hope that clarifies,
Rusty.