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

Rusty Russell rusty at rustcorp.com.au
Wed Apr 1 20:27:14 EDT 2009


On Wednesday 01 April 2009 19:40:37 Martin Langhoff wrote:
> 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.

Yep, any hash can have collisions.

It's not one or two hashes, it's the number of bits.

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

Yes, but it changes the balance; I assumed that 1 in 1000 was a fair failure
rate.  If we want one in a million, we need more hash bits :)

If the cache just blows away the cached base page it was using when one of
these errors occurs, that should Do The Right Thing even without seed.

A more radical approach is to use a random seed, but don't have a total-content
hash: say "meh, it's unreliable, but unlikely to fail", though I don't think
the world is ready to accept such engineered-in-failure.

Cheers,
Rusty.


More information about the Http-crcsync mailing list