On Wed, Apr 1, 2009 at 8:29 AM, Rusty Russell <[email protected]> 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... -- [email protected] [email protected] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff _______________________________________________ Server-devel mailing list [email protected] http://lists.laptop.org/listinfo/server-devel
