I blogged a few weeks ago that IMPS was dead, and that I would be embracing XMPP. Since then I have received many, many, emails from folks asking me to keep the service. I honestly appreciate the support and interest.

I stand by my original posting that IMPS is a failed specification. It is true though that the original arguments for Onesoup, namely being native to the phone and the ability to run on the background, still hold true, and as such, an IMPS service still makes sense.

The issue is that technically IMPS has failed and I am not willing to invest much more time to support a specification that I consider to be broken. I’d much rather spend my time building a mobile IM service on XMPP. But until the manufacturers stop shipping a built-in IMPS client that barely anybody uses, rather than an XMPP client, there is a point in supporting IMPS.

This is the dilemma where I stand:  IMPS is a failed specification yet a widely-spread technology without a short-term viable replacement. My requirement has therefore transformed to providing mobile IM through XMPP, and having the ability to additionally support IMPS at almost no additional cost. The current Onesoup is fully articulated around IMPS, not XMPP, and I need to move away from there.

The current architecture consists of a very light weight Tomcat server implementing the IMPS Data and Client Initiation Request channels. This is fronted by a custom load-balancer written in PHP that examines the XML payload and distributes the request to a particular node based on the session token identifier. Right now there is only one node, but the intent was to be able to scale to multiple nodes this way. The sticky session is unfortunately required to support the CIR STCP (standalone TCP binding), and since the Tomcat server maintains TCP connections to the 3rd party IM services (e.g. AOL, Yahoo, etc.).

In contrast, the proposed architecture is based around the HTTP BOSH binding to XMPP, which avoids having to open bare TCP server sockets. Note that I am selecting ejabberd as a server, which has a built-in http-bind module, but I could use any dedicated BOSH Connection Manager, such as punjab. I’ll decide on this detail as I move further. Also, I am sticking to Apache as web server for now, although for most of the needs it would be more interesting to use nginx as a load balancer, and push the PHP processing to an Apache backend, either through proxy, or a fastcgi processor.

In the proposed architecture, the IMPS data channel support is provided by a stateless IMPS to XMPP BOSH adapter in PHP. The tricky bit is however the CIR channel, which requires the notion of session.

In order to understand how to best support CIR, I decided to scan through the logs looking for CIR usage, and I realized that all devices that support STCP also support SUDP. Unless proven otherwise when I start coding this, I will be dropping support for the STCP binding.

The challenge of moving to XMPP for Onesoup really comes down to implementing a BOSH client in PHP. I’d had loved the device client to help here, but the IMPS specification uses a data channel (HTTP) and a notification channel (TCP, UDP, WAP, SMS) rather than using only long-lived blocking HTTP requests. To adapt IMPS to BOSH, I need then to handle the original IMPS request, and then continue the processing by issuing an asynchronous CURL to the http-bind backend. Since Apache kills long running processes (a good thing), I’ll need some way to catch this and re-launch the request. I’ll also have to avoid holding more than one TCP connection to the http-bind endpoint per client.

I feel this is a step in the right direction. There is certainly further thinking required in terms to solve the CIR. But this architecture would be much easier to adapt going forward into supporting new clients and new applications beyond basic IM.

This entry was posted on Saturday, December 13th, 2008 at 11:09 pm and is filed under onesoup. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.