Google Wave Protocols: Clearing the Confusion

wavelogoToday is the long-awaited day when 100,000 lucky individuals receive access to an early, but working, version of Google Wave. I hope I am in those ranks! Like many people, I have been reading about Wave, but have not been able to experience it hands-on.

Wave has been a hot topic since it was first shown outside of Google last May. Yet it continues to be quite misunderstood, most likely because it is such an early stage effort and most interested people have not been able to lay hands on the technology.

The confusion surrounding Wave was highlighted for me yesterday in a Twitter exchange on the topic. It all started innocently enough, when Andy McAfee asked:

Andy1

To which I replied:

Larry1

That statement elicited the following comment from Jevon MacDonald of the Dachis Group:

Jevon1

I am not a technologist. I seek to understand technology well enough that I can explain it in layman’s terms to business people, so they understand how technology can help them achieve their business goals. So I generally avoid getting into deep technical discussions. This time, however, I was pretty sure that I was on solid ground, so the conversation between me and Jevon continued:

Larry2

Larry3

Jevon2

Larry4

Now, here we are, at the promised blog post. But, how can Jevon and I both be correct? Simple. Google Wave encompasses not one, but several protocols for communication between system components, as illustrated in the figure below.

wave_protocols

Figure 1: Google Wave Protocols (Source: J. Aaron Farr, http://www.cubiclemuses.com/cm/articles/2009/08/09/waves-web-of-protocols/)

The most discussed of these is the Google Wave Federation protocol, which is an extension of the Extensible Messaging and Presence Protocol (XMPP). However, Wave also requires protocols for client-server and robot server- (Web service) Wave server communication. It is also possible, but probably not desirable, for Wave to utilize a client-client protocol.

Jevon was absolutely correct about the XMPP protocol enabling server-server communication in the Google Wave Federation Protocol. The Draft Protocol Specification for the Google Wave Federation Protocol lays out the technical details, which I will not explore here. XMPP provides a reliable mechanism for server-server communication and is a logical choice for that function in Google Wave, because XMPP was originally designed to transmit instant message and presence data.

It turns out that the Google Wave team has not defined a specific protocol to be used in client-server communication. A Google whitepaper entitled Google Wave Data Model and Client-Server Protocol does not mention a specific protocol. The absence of a required or recommended protocol is also confirmed by this blog post. While the Google implementation of Wave does employ HTTP as the client-server protocol, as Jevon stated, it is possible to use XMPP as the basis for client-server communication, as I maintained. ProcessOne demonstrates this use of XMPP in this blog post and demo.

Finally, there is no technical reason that XMPP could not be used to route communications directly from one client to another. However, it would not be desirable to communicate between more than two clients via XMPP. Without a server somewhere in the implementation, Wave would be unable to coordinate message state between multiple clients. In plain English, the Wave clients most likely would not be synchronized, so each would display a different point in the conversation encapsulated in the Wave.

To summarize, Google Wave employs the following protocols:

  • XMPP for server-server communication
  • HTTP for client-server communication in the current Google implementation; XMPP is possible, as demonstrated by ProcessOne
  • HTTP (JSON RPC) for robot server-Wave server communication in the current Google implementation
  • Client-client protocol is not defined, as this mode of communication is most likely not usable in a Wave

I hope this post clarifies the protocols used in the current architecture of Google Wave for you. More importantly, I hope that it highlights just how much additional architectural definition needs to take place before Wave is ready for use by the masses. If I had a second chance to address Andy McAfee’s question, I would unequivocally state that Google Wave is a “concept car” at this point in time.

Postscript: The heretofore mentioned possibilities around XMPP as a client-client protocol are truly revolutionary. The use of XMPP as the primary communication protocol for the Internet, instead of the currently used HTTP protocol, would create a next generation Internet in which centralized servers would no longer serve as intermediaries between users. Web application architectures, even business models, would be changed. See this post for a more detailed explanation of this vision, which requires each user to run a personal server on their computing device.

Advertisements

4 responses to “Google Wave Protocols: Clearing the Confusion

  1. Pingback: Twitter Trackbacks for Google Wave Protocols: Clearing the Confusion « Together, We Can! [lehawes.wordpress.com] on Topsy.com

  2. I’m not sure to understand the problem with more than 2 XMPP clients. In principle, XMPP uses a client-server model where communications between two clients happen like this :

    XMPP client –c2s–> XMPP server –s2s–> XMPP server –c2s–> XMPP client.

    There exists a P2P XMPP communcation mechanism called E2E (end-to-end) but still requires S2S for the intial P2P negotiation.

    Wave uses S2S communication with Pubsub , so items are published to a node and then broadcasted to all the node subscribers by passing through the respective servers. Pubsub allows hence to maintain a synchronized state between all clients.

  3. Hi Larry,

    It is true that XMPP is a Peer-To-Peer technology, and as such allows any server to connect with anyone else in the cloud. However, using a transport layer (as in the OSI model) that is P2P do not guarantee that the Wave resolution function can. That is a pretty important difference.

    From the published details on the protocol, you can see that the Operational Transformation framework uses an IT (inclusive transformation) function only. That means that peers can only include messages in its resolution queue. That is a pretty important concept, because the protocol cannot exclude the effect of out of order operations; something that it is pretty important for serverless scenarios.

    Furthermore, on May I have published a blog post explaining what Google Wave was all about (http://www.corvalius.com/blog/index.php/technology/dissecting-googles-wave-technology/). At the time, I left open the question and Soren Lassen from the Wave team was kind enough to sheed some light over it (see the comments).

    Soren is the engineer that is working on the Federation protocol (http://www.youtube.com/watch?v=CRZbHpYhZrA). His response was very clear: “The federation case works just like the single server case because, for a given wavelet, a single designated “authoritative” server (identified by the domain part of the wavelet id) hosts the wavelet and operates as server. All the other servers act as dumb proxies, they just forward the operations between their clients and the authoritative server”.

    Technically speaking, everything is possible. But, you have to resort to convert one of your clients into a server itself to act as an “authoritative” host to enable OT Enabled communication paths between clients.

    Greetings
    Federico
    twitter: @federicolois

  4. Pingback: links for 2009-10-01 | Don't mind Rick

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s