Hi Chiang,
I posted a couple of entries on my blog a while back on server
acknowledgement and TP2 that you can find here:
http://www.thinkbottomup.com.au/site/taxonomy/term/45
They might help answer some of your questions.
Cheers,
Dan
On Apr 13, 5:38 pm, chiang <[email protected]> wrote:
> Hi John,
>
> Thank you first of all for the detail explanations. Your explanations
> did help me confirm my understandings. Think I had some
> misunderstandings between TP1 and TP2 properties, e.g. on the number
> of sites exchanging operations, and when do we get two different
> document states.
>
> Think I'm a lot clearer now, but allow me think out loud and see if
> these are correct:
> 1) There are two types of application acknowledgements, one between
> client and server, and another in the form of commit-notice, which is
> used when a server "agrees" that the changes should be persisted
> (presumably the master server will decide when to start propagating
> the commit-notice), even though the changes have already been applied.
> 2) Operations are exchanged between only two sites - client and
> server, or server (slave) and server (master). TP2 on the other hand
> allows all peers to exchange operations with one another and the final
> state of the document will still converge.
>
> cheers,
>
> Chiang
>
> On Apr 13, 5:20 am, John Barstow <[email protected]> wrote:
>
>
>
> > On Thu, Apr 8, 2010 at 8:45 PM, chiang <[email protected]> wrote:
>
> > > The reason I'm seeking clarification is if an operation can be applied
> > > at the FedOne server without requiring acknowledgement from the master
> > > wavesandbox, then operations can be applied in different orders, and
> > > potentially from more than 3 sites. But this does not sound right also
> > > as I think I have been told that this cannot be done with current
> > > Google Wave's OT implementation. Or am I missing something huge?!
>
> > You are missing something important.
> > The while point of the OT algorithm is that any number of sites can
> > apply the operations in different orders and still end up in the same
> > final state.
>
> > So things look like this:
>
> > Server M (the master server) has a list of operations it knows about
> > [a,b,c,d,e,f]
> > Server A has a list of operations it knows about [a,b,c,d,e]
> > Client A knows about [a,b,c,d] and has new operations [g,h]
> > Client B knows about [a,b,c,d,e,f] and has new operations[k,l]
>
> > Client A sends [g,h] to Server A.
> > Server A runs the OT algorithm, applies the resulting [g', h'] and
> > returns [e'] to Client A.
> > Server A sends [g', h'] to Server M.
> > Server M runs the OT algorithm, applies the resulting [g", h"] and
> > returns [f'] to Server A.
> > Client B sends [k, l] to Server M.
> > Server M runs the OT algorithm, applies the resulting [k', l'] and
> > returns [g3, h3] to Client B.
>
> > Server M sends [k', l'] to Server A. Server A has no outstanding
> > operations so just applies them directly.
> > Server A sends [f', k', l'] to Client A.
>
> > At the end of this exchange, all 4 participants have converged on the
> > same state, but they followed a different set of operations.
>
> > Server M = [a, b, c, d, e, f, g", h", k', l']
> > Server A = [a, b, c, d, e, g', h', f', k', l']
> > Client A = [a, b, c, d, g, h, e', f', k', l']
> > Client B = [a, b, c, d, e, f, k, l, g3, h3]
>
> > Having the client wait for an acknowledgment is really a way of
> > simplifying the algorithm. I find it helpful to think of a version
> > control system merging between branches - if you allow branches to
> > diverge too much, merging can become really difficult. But if you
> > rebase (or merge from the parent branch back to the child branch)
> > periodically it greatly simplifies things. Applying the server
> > response before sending more operations is like rebasing before
> > pushing another set of commits.
>
> > So a real client (like the Web interface) actually acts quite a lot
> > like a server; it maintains a list of operations it knows about and
> > runs the OT algorithm when the server tells it about new operations.
> > However the FedOne client is pretty pitiful; it's more like hacking
> > directly on the server list of operations, so it obscures much of what
> > is actually going on. This is potentially where the misunderstanding
> > creeps in for many people, because they look at the code and think it
> > represents what an actual client should be doing instead of seeing it
> > as the hacking tool it actually is.
--
You received this message because you are subscribed to the Google Groups "Wave
Protocol" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.
