On Wed, Feb 3, 2010 at 11:19 PM, Daniel Paull <[email protected]> wrote:
> hi John, > > That's an excellent description of what goes on between clients and > servers when there are concurrent edits. It's a great starting point > for forming a picture in your mind. > > There are probably a few details that aren't quite right - but that > may be because there is no standard way that the client and server > communicate and e are all confused because of this! For example, you > said, "Client A sends an empty delta to ping the server ([...@v8) and > gets a response of [B1',B2',B3',B4',B5'], now at v10)." This is not > how it should work. The server is able to send updates to the clients > at any time rather than clients polling the server for updates. The > OT whitepaper talks about a broadcast of transformed operations to > clients. This broadcast must happen before the acknowledgement is > sent back to the originating client. > > Dan, If the client in question is a web client, and we aren't using WebSocket or a hack like long polling, then no, the server can't send updates to the clients when ever it feels like it. This is especially true when dealing with a back end system like AppEngine... brett > Cheer, > > Dan > > On Feb 3, 6:37 pm, John Barstow <[email protected]> wrote: > > On Wed, Feb 3, 2010 at 4:44 PM, Turner <[email protected]> wrote: > > > Hi John, > > > > > Is that correct? If so, I'm a little confused about how the clients > > > deal with this. For example, client A has applied A1, A2 and A3, and > > > gets back streamA' from the server (right?). But it can't just apply > > > B1-3', can it? I haven't worked it out, but I don't believe that that > > > would work. Does client A hold off on "committing" its changes to its > > > own content until it gets the up-to-date version from the server > > > (whether compressed by the Composer or not)? > > > > Here's how I explain it; note that I'm working off memory at the > > moment so someone might have to correct me. > > > > At startup, clients A and B get the latest version from the server. > > Let's be arbitrary and say we start at v7. So the server and both > > clients are synced at v7. > > > > Key point 1: The "last known version" is how the server knows what > > needs to be transformed! It's sent as part of every delta. > > > > Client A generates some operations. Let's say [A1, A2, A3]. It sends a > > delta to the server containing the operations and the last version it > > knows about. ([A1,A2,a...@v7) > > > > Server sees the delta from client A, sees that it's still at v7, so > > just commits the delta as v8. It sends back a response that > > essentially says (no changes, now at v8). > > > > Client A has no outstanding edits, so it just bumps the "last known > > version" variable internally. > > > > Client B generates [B1, B2, B3] and sends a delta ([B1, B2, b...@v7). > > While waiting for a response, it generates [B4, B5]. > > > > Key point 2: Any operations generated while waiting for a server > > response need to be tracked, because they might get transformed! > > > > Server sees the delta from client B, and that there is a newer > > version. So it takes all the operations committed since v7 and > > transforms them. > > > > [A1, A2, A3] x [B1, B2, B3] = [A1', A2', A3'], [B1', B2', B3'] > > > > The B' operations get saved as v9. The server generates a response > > saying ([A1',A2', A3'], now at v9). > > > > Client B now needs to apply the changes returned by the server, but it > > has some pending operations. That means it needs to apply a transform. > > > > [A1', A2', A3'] x [B4, B5] = [A1", A2", A3"], [B4', B5']. Client B > > applies the A" operations and bumps the "last known version" to v9. > > The [B4', B5'] can now be sent to the server as a delta ([B4', > > B5']...@v9). > > > > Since v9 is that latest version, the server applies the delta as v10. > > The response says (no changes, now at v10). Client B has no more > > pending operations, so it just bumps the "last known version" to v10. > > > > Client A sends an empty delta to ping the server ([...@v8) and gets a > > response of ([B1',B2',B3',B4',B5'], now at v10). > > > > Since Client A has no pending operations, it applies the delta as-is > > and bumps the "last known version" to v10. > > > > We're done, now the server and both clients are synced at v10, even > > though all three applied different sets of operations! > > > > Anyplace you have a sequence of operations bundled up - anywhere I've > > used [ ] brackets - you can optionally do a compose to reduce the > > length of the sequence. > > > > I hope that makes sense! Tracing that out was the main thing I did to > > get my head around the algorithm. > > -- > 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]<wave-protocol%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. > > -- Brett Morgan http://domesticmouse.livejournal.com/ -- 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.
