Why choose (XMPP versus HTTP or HTTP versus XMPP) ?

Morning reading

With the aftermath of the XMPP Summit, I’ve seen a few posts about XMPP as a potential replacement for HTTP.

HTTP

I love HTTP. That protocol has so many great features, I wouldn’t know where to start.

And it’s only a couple of years that the world (and me) really understood what this HTTP thing was really about. (Before that, it was only inside the brain of Roy Fielding and a few others) – I thank DHH for raising awareness and Richardsson and Ruby for writing that great O’Reilly book.

The bits and pieces one describes as REST (the VERBS, mime-types, caching strategies) build a very clever and stable architecture.

Yet it’s polling based and every 30 minutes my feed reader polls a load of feed, most of them returning 304 Not Modified.

XMPP

XMPP is a decade old, it’s only becoming very popular recently. But it still has that “new frontier” smell I like. Still a lot of work to do. And I hope I can be part of that.

It’s a place where a lot of work has been done, but that protocol is still working to expand itself beyond instant messaging.

Enters PubSub. The solution to polling endlessly Atom feeds. Machines sending events to machines in a distributed, decentralized way. Bandwidth saved.

Yet XMPP has limits :

  • message size : Sending more than a few kilobytes of data per stanza can fill up your server queues (especially when you have thousand of messages to route)

  • binary transfer : encode your data in base64, split it up in approprietly sized stanzas, send it over. It’s slow as hell (but reliable).

  • connected socket : one connects usually on an XMPP server on TCP port 5222. Loose the socket, loose the connection. Hence on iPhone, task switching means loosing the connection. And each time I chat from the iPhone, I have the need to switch between OneTeam XMPP client and my calendar or mail.

There are other nitpicks I have : discovery is cool, but without paging and caching your bandwidth and CPU bills will go through the roof. I started implementing paging in ejabberd’s MUC, SHIM – for caching – is an itch I may scratch one day.

Overcoming those limits

Every time HTTP has a solution for “fixing” XMPP.

The first two limits can be fixed by running a WebDAV server. Upload to the WebDAV server, share the link. That’s a solution everyone can do without XMPP client support. Of course, having a way to do that transparently with client and server support, with signed URLs (à la S3) would greatly improve the process.

For the connected socket problem, there’s BOSH. That’s basically running XMPP over HTTP. With the added bonus of having the server retaining the “connection” for a couple of minutes – that fixes my iPhone problem. Once I relaunch the client in the two minutes window, all the pending messages are delivered.

There’s also a nice side effect : HTTP tools (load balancers, proxys) can be used in front of the server.

XMPP and HTTP are here to stay.

In my opinion XMPP needs more HTTP than HTTP needs XMPP.

I wouldn’t mind if my XMPP avatar was accessed by clients through the HTTP component of the XMPP server (they all have one embedded, that’s a sign, right ?), as opposed to fetching the VCard base64 encoded database stored version of it through XMPP.

I wouldn’t mind if my filetransfers never fail because the binary files are uploaded first on my XMPP server via HTTP, itself notifying the receiving client I am sending the file to that the payload is ready.

As a final note, writing my Atompub-PubSub bridge was quite gratifying, I could leverage MarsEdit to publish on my pubsub nodes.

5 comments so far

  1. Nolan Eakins on

    Just wanted to comment about XMPP’s connection “problem”. Most servers *do* support offline messages, so any messages will get piled up at the server, in order. On the flip side, your presence is tied to the connection which signals to others to stop sending messages. I’m sure it’s possible to have your presence stick around for a minute on a dirty break. And there’s also that second and third client I run which need to tweak their priorities to not cause problems.

  2. cstar on

    @Nolan : absolutely right, we have solutions. But re-connecting is not instantaneous (DNS SRV + TLS + Roster ….)

    And I do actually feel that BOSH is maybe bending HTTP a bit too far though, but it’s the best standard solution we have currently.

    And there’s work being done : http://twitpic.com/1eis2

  3. laurent lathieyre on

    “connected socket” : the way you put it, looks like it’s more like an iPhone problem (feature ?) rather than a xmpp limitation 😉

    sockets are pretty robust these days

  4. cstar on

    @laurent : of course it is an iPhone problem : no apps running in the background. Though mobile network loss is also a possible cause.

    By connected socket, (sorry if I was unclear) I meant that a disconnect implies reopening the connection (DNS SRV + TLS + Roster + presence broadcast).

    If there was a fast reconnect mode (and I think that’s what the paperboard link in my comment explains) for the next 120 second of connectivity loss, that would be great. BOSH makes that possible (just send the last tid, sid, rid the server sent you)

  5. cstar on

    As a coworker just told me bittorrent has a use too, especially for that fabled muc room file sharing😉


Comments are closed.

%d bloggers like this: