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

WULMS Alexander Alex.WULMS at swift.com
Tue Apr 7 03:38:17 EDT 2009


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.
>
>> > 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.
>_______________________________________________
>Http-crcsync mailing list
>Http-crcsync at lists.laptop.org
>http://lists.laptop.org/listinfo/http-crcsync
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5020 bytes
Desc: not available
Url : http://lists.laptop.org/pipermail/http-crcsync/attachments/20090407/79ed6776/attachment.bin 


More information about the Http-crcsync mailing list