incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex North <a...@alexn.id.au>
Subject Re: Wave OT / CC Call for Help
Date Tue, 10 Jan 2012 00:17:16 GMT
On Mon, Jan 9, 2012 at 1:12 PM, David Hearnden <hearnden@google.com> wrote:

>
> On Wed, Dec 28, 2011 at 3:24 AM, Michael MacFadden <
> michael.macfadden@gmail.com> wrote:
> > 4) How exactly are the hashed versions designed?  There seems to be a
> > monotonic scalar version number and a hash?  I want to make sure I
> > understand how both are generated and how both are used.
> >
>
> I'll defer this to Alex.


Each wavelet has a version number which is a monotonic scalar. The version
number counts the number of wave ops which have been applied to that
wavelet. The version number isn't necessarily observed to be contiguous
though: version numbers are available only at the boundaries between
deltas. Deltas are atomic at the server so at the protocol level wavelets
are only observed after the complete application of each delta. IIRC, even
in clients, during application of a delta an observer will see the wavelet
state change with each operation, then the version number increase once at
the end.

A hash is calculated after each delta boundary. This hash serves two
purposes: one in federation and another in the c/s protocol, and I'm only
talking about the latter. From the c/s protocols point of view, how the
hash is calculated is irrelevant: it's just securely random number attached
to the version of a wavelet (and remember versions are all on delta
boundaries). So a hashed version is a (version, hash) pair.

The server responds with a hashed version after each successful delta
submission. A client must provide a target hashed version with each submit
delta request and the server checks this as a basic protocol correctness
check: if the client's hash doesn't match the server's for a given version,
the protocol has broken down somewhere. The same goes for opening a wavelet
channel or requesting a snapshot. Providing a matching hashed version
certifies that the client has correctly followed the protocol, at least as
far as counting ops.

The hashed version also has some extra uses in access control, particularly
with removed participants. In brief, a client's knowledge of a hashed
version of some wavelet is a certificate that it observed the wavelet at
that version. The protocol allows a removed participant to continue to
access the wavelet up to the version at which is was removed, and in
particular to fetch a snapshot or open a stream at such a version that it
actually observed.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message