Hi Dan, We're happy so see that there are eager developers out there working on this. We have not yet published our client/server protocol because we have prioritized our efforts at standardization on the federation protocol as this is critical in making it viable for other people to run wave servers that talk to ours. Our production client/server protocol is in flux as we continue development of our client. We are limited in the amount of work we can do - we're juggling many balls and are keenly focused on delivering a cool and stable product. A crappy Wave architecture will not help Wave get adopted any faster. For example, we only have a very small number of people (think ~3) to hammer out complex protocol details, write production quality servers, integrate with other backends, support our own servers in production, keep on top of a fast moving architecture in Wave-land, work on the open source code to name a few tasks.
Indeed, we have not published the details of our c/s protocol, but once we manage to disentangle our implementation from Google architecture and have ironed out the bits that we've not nailed down yet, we will contribute it as an option for people to use as they see fit. In the mean time, for what it's worth, the FedOne client/server protocol is a functional client/server protocol that can be extended if you so choose. There are interesting problems that need to be solved, and other developers have implemented their own client/server protocols successfully (e.g. see Novell Pulse). FWIW, we wrote a high level outline our recovery algorithm (see http://www.waveprotocol.org/whitepapers/internal-client-server-protocol), but did not address the particular problem of connections dropping and dealing with a client getting it's own deltas back. In brief: we've tried both inserting unique client-side generated ID's as well as comparing deltas held in the client (until the server notifies us that they are committed by the server) against incoming deltas. Because during recovery, unacknowledged deltas are continually transformed by the client against applied deltas coming in from the server, the client's unacknowledged delta should match any delta (using a deep comparison function) that it previously submitted but did not receive an ACK for. (Note that under normal conditions we don't echo the entire delta back to the client in order to cut down the amount of data on the network). This is the approach we currently take (as opposed to the unique ID approach), but there is a corner case problem as pointed out here earlier, that two clients where the same user has logged on submit changes at exactly the same place at the same time when a connection drops. There is a call to be made about intention-preservation when resolving conflicts under OT, and in this case we felt if the same user does exactly the same action in two clients in the time window of a submit RTT, and the TCP connection fails, he/she most likely will be satisfied that the action is performed only once (referring to the earlier example, "hellohello" is probably less desirable than "hello", unless the user deliberately wants to test recovery of concurrency control ;). There are different possible solutions and I'm not saying this is the best, but it's one we're currently using. As you can see, the debate on this thread has come up with the same solutions as us, and similarly trade-offs need to be made in this debate. We hope our solution, when we find enough time to open source it, will be helpful. If you can propose a much better solution in to the problem discussed above, or any other, the open sourced protocol we contribute could benefit from it (particularly if there is a working implementation). Hope that helps, Jochen Software Engineer, Google Wave On Thu, Jan 21, 2010 at 1:10 PM, Daniel Paull <[email protected]> wrote: > That is well understood James. The problem is that what has been > published by Google is an incomplete cient/server implementation and > some terse documentation that does not, in my opinion, provide enough > detail to actually implement a Wave client and server from the ground > up. > > Dan > > On Jan 21, 3:37 am, James Purser <[email protected]> wrote: >> On Wed, 2010-01-20 at 07:08 -0800, Daniel Paull wrote: >> > My answer to the original question is >> > "implement server acknowledgements as documented in the Google OT >> > whitepaper and the problem no longer exists." >> >> Okay, I'd just like to point out something. FedOne is open source. The >> FedOne project is accepting patches for review and inclusion from >> outside Google. If you believe there is a deficiency and can fix it, >> please send it in. Improving FedOne can only be a good thing. >> >> Thanks >> -- >> James Purserhttp://wavingtheshiny.collaborynth.com.au >> Wave Addresses: >> [email protected] (wave.google.com) >> [email protected] (wavesandbox.com) >> [email protected] (collaborynth.com.au FedOne Server) >> Skype: purserj1977 >> GTalk: [email protected] > > -- > 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. > > > >
-- 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.
