On Wednesday 01 April 2009 19:40:37 Martin Langhoff wrote: > 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.
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. _______________________________________________ Server-devel mailing list [email protected] http://lists.laptop.org/listinfo/server-devel
