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

[Alex Wulms]

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).
But that is not the main reason the code had to be adapted. Main reason is 
that the automatic tail detection in the previous version of crcsync library 
did give complications with keeping track of what was already written back to 
the client and what was still pending (especially when read_block returned 
a 'result==0'  response), which had led to a subtle bug in crccache. That is 
the problem I wanted to get fixed, which is meanwhile done. The fact that the 
tailblock is now also encoded is just a nice added bonus of a problem 
investigation and it's associated bug fix :-)

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

>
> 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.

Kind regards,
Alex