[Http-crcsync] Apache proxy CRCsync & mozilla gsoc project?

[WULMS Alexander]

If we go for the 'fail in case of mismatch' approach, we can keep streaming. We simply have to make sure that we close the
connection before we have streamed the last block if we discover the global checksum mismatch. And that is just a matter of putting
the global checksum validation before the 'stream last block back to client' in the decoder logic.


--------
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: Martin Langhoff [mailto:martin.langhoff at gmail.com]
>Sent: Wednesday, April 01, 2009 11:11 AM
>To: Rusty Russell
>Cc: Toby Collett; Gervase Markham; Alex Wulms; XS Devel; WULMS Alexander; tridge at samba.org; angxia Huang;
>jg at freedesktop.org; http-crcsync at lists.laptop.org
>Subject: Re: Apache proxy CRCsync & mozilla gsoc project?
>
>On Wed, Apr 1, 2009 at 8:29 AM, Rusty Russell <rusty at rustcorp.com.au> wrote:
>> Yes, we need to chunk, because we can't hand the data on to the client until
>> we've verified it, at least in a serious implementation.
>
>Hmmm. If I understand you right, the concern is that the rolling hash
>matches in locations that aren't a true match.
>
>Can we do anything that is still efficient and retains the ability to
>stream? Maybe the client can send 2 hashes in the header, same block
>size but seeded differently?
>
>Or is the problem with the delta blocks we send?... (doesn't seem
>likely to prevent a streaming implementation, but maybe I'm missing
>something)
>
>> Since we're going to error out on the fail case, I'll switch the code to do
>> 64-bit checksums (not right now, but soon: what we have is good enough for
>> testing).
>
>Does 2 hashes make the error condition so unlikely that we can assume
>it won't happen normally? Also - delivery of HTTP payloads is not
>guaranteed. As Tridge said, non-cacheable GETs may be non-idempotent,
>but they sometimes fail to complete for any of many reasons, and the
>user has a big fat Refresh button right there in the webbrowser.
>
>IOWs, a blind, unchecked "delete-last-user" action in a webapp is a
>bug in the webapp. It is ok to fail, as long as the retry will use a
>different seed...
>
>cheers,
>
>
>
>m
>ps: cc'd the http-crcsync list, which is more appropriate...
>--
> martin.langhoff at gmail.com
> martin at laptop.org -- School Server Architect
> - ask interesting questions
> - don't get distracted with shiny stuff  - working code first
> - http://wiki.laptop.org/go/User:Martinlanghoff
-------------- 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/20090401/bb1d50d6/attachment.bin