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

Eric Cestari - cstar - February 10, 2009

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.



Categories: Blogs  Eric Cestari  

Comments

No comments so far, you could be the first.

Add comment

Name:

Email:

URL:

Smileys

Remember my personal information

Notify me of follow-up comments?