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.langh...@gmail.com] >Sent: Wednesday, April 01, 2009 11:11 AM >To: Rusty Russell >Cc: Toby Collett; Gervase Markham; Alex Wulms; XS Devel; WULMS Alexander; >tri...@samba.org; angxia Huang; >j...@freedesktop.org; http-crcs...@lists.laptop.org >Subject: Re: Apache proxy CRCsync & mozilla gsoc project? > >On Wed, Apr 1, 2009 at 8:29 AM, Rusty Russell <ru...@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.langh...@gmail.com > mar...@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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
