XMPP rings

Words are words, and their understanding varies amongst those reading them. I thought I had set the context of my previous post on some the limitations of XMPP server to server communication arising from its dependency on DNS for more than address resolution. I was wrong, and Jason's follow up made this very clear.

The point I was trying to make was not related to DNS itself being a weak point in a highly distributed XMPP architecture, but rather on XMPP relying on DNS for more than just address resolution for server-to-server communication. DNS has sufficiently proven it can handle its task of name resolution.

I believe part of the evolution for the future web is in the emergence and spread of communication overlay networks serving the interest of various overlapping communities of interest. This is neither a new idea nor a new technology. The premises of this kind of organization are already at work in many GRID experiments, for example. I also believe the natural evolution for XMPP is in enabling part of this future evolution. What strikes me though is the limited number of experiments trying to use XMPP in this role. There have been several intents in the last two to three years at building some sort of XMPP based grid communications. But, to my knowledge they have not been brought to fruition.

As represented in the drawing, these architectures, that I would call XMPP rings, are made up of several nodes communication between themselves in a peer-to-peer fashion. These nodes may be either application nodes or routing nodes. Every XMPP ring domain possesses its own private addressing spaces, and communicates with the outside world through well identified edge nodes. Possible use of these XMPP ring would be large PubSub brokers' networks, distributed MUCs, or some kind of XMPP distributed hash tables.

I believe the current state of the protocol does not allow building these kinds of XMPP rings because of the way server-to-server communication works today.  In particular, it would not be possible to build XMPP routers. XMPP rings routers task would be to direct traffic to a given destination using only the private ring addressing spaces. Today, the recipient of a server-to-server connection must be an end point. According to the specification, it can only receive traffic for a single DNS domain it is supposed to handle on each connection. It cannot route the received traffic to another destination because, doing so, it would not be the originating source and the destination node would have to deny the connection. This is in my opinion a limitation of the current protocol version.

Obviously the kind of architecture I am describing here was not considered in the initial standardization effort. But I would appreciate if the next revision of the standard could lift these limitations. And as a matter of fact, I believe the current servers behaviors are only specific cases of the more generic XMPP rings, which would ensure backward protocol compatibility.

Technorati Tags: XMPP, Jabber, Conversation spaces, Addressing, XMPP ring, Antecipate