one of the key virtues of wireless village (aka IMPS) is that it does not require setting up and keeping a TCP/IP connection open throughout a session. IMPS data channel is enabled through HTTP, and as such it does not require to keep the connection open. this is particular important for IM clients running on constraint environments, such as mobile. this is even more important if the server is outside of the fenced operator network.

the issue however is that HTTP is a client-initiated synchronous model, and the only way to ensure responsiveness is to continuously have the client poll for new messages that may be sitting for delivery at the server. with polling comes an implementation trade-off, either the client polls frequently, to ensure quick delivery of messages, which consumes bandwidth, or the client polls less frequently, which saves bandwidth, but delays the delivery of messages (no more “instant” messaging).

the way IMPS solves the issue is by adding a client initiation request (CIR) channel, in addition to the data channel based on HTTP. with the CIR channel, the server notifies the client that it must poll through HTTP for a message. unfortunately, the methods specified within the CIR channel are not really very useful outside of an operator’s network. they are either based on TCP/IP (which defeats the benefit of HTTP) or UDP (standalone or WAP). there is also SMS available, which is clearly only an option for operators, if nothing else, based on cost reasons.

so, in most cases, if the IMPS service access provider for the IM service is outside of the operator’s network it’s very likely that CIR / push will not be available and the client forced to poll regularly. so much for not keeping sockets open …

now, on the IMPS 1.3 specification, still in draft status, OMA adds another CIR transport, based on polling using HTTP. unfortunately the specification draft, not wanting to talk about implementation, misses the real benefit, and keeps talking about polling, which is a pity since i believe this could completely make the TCP/IP transport irrelevant. in reality what OMA has just done is adding Comet or more precisely the BOSH technique of XMPP to IMPS.

the idea is simple: have the client make an HTTP request and have the server hold the request on the queue until there is a message to push. if the TCP/IP connection is lost or times-out, the client will make a new HTTP request, and the delay will only be the round trip time for a request/response pair. the specification unfortunately only talks about the request, and does not mention anything about holding the request. quite the opposite, the specification keeps talking about polling, which is simply wrong and does not solve anything.

this model effectively requires two TCP/IP connections for HTTP, client to server, though none permanent and hence mobile friendly (and also, RFC 2616 recommends only 2 connections to be open at any point in time). one connection is used by the client to send or request information to the server. the other connection is effectively used by the server to push to the client a CIR, where the client will then use the other channel to poll and get the messages

this model requires less bandwidth than polling, provides immediate notifications, and it’s mobile network friendly. there is a trade-off in maintaining the HTTP requests pending on the server side since that consumes server resources, but nothing that can’t be fixed with a separate HTTP server forcing network queueing for the CIR channel. and given that this mechanism is always available, it even makes me wonder whether UDP would be useful any longer, at least considering that it is not reliable.

unfortunately, this is all currently useless for IMPS, since there are barely any 1.3 clients. besides IMPS is now considered by OMA as a legacy messaging protocol, alongside SMS and MMS

anyway, beyond IMPS, this is in all cases a good technique for environments where sockets cannot be open or ensured to be kept open. it also makes server implementation much more simple, since you are now only talking about plain HTTP and there is nothing about having your own daemon running. i very much like the idea and might use it to implement an iPhone client.