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.

I still find it surprising that the “classical” messaging network operators don’t support the native (“Wireless Village”) mobile clients shipped with almost every phone nowadays, and they rather prefer to write their own proprietary clients. Besides the development and distribution costs associated, being locked to a proprietary network limits the user’s freedom. In contrast, the native clients are based on a standard specification optimized for mobile networks and mobile phones:

• Standards based means freedom for the user. You can chose between service providers, like Yamigo.
• Optimized for mobile networks means supporting maintaining a session across multiple connections, perhaps even with different IPs. Imagine entering a tunnel, loosing your connection and being able to reestablish the connection and your conversations seamlessly.
• Optimized for mobile phones means things like not draining your batteries by using operator infrastructure like WAP Push or even UDP datagrams.

When thinking Wireless Village, I am really looking at Yamigo, the largest free mobile chat service. Yamigo started in Finland in 2003, developed an OMA IMPS CSP server, formerly known as Wireless Village, and provided a gateway to the mainstream instant messaging networks: Yahoo! messenger, AIM, MSN, and ICQ. Yamigo grew to reach its first 100,000 users in 2006. Since then, there has been little to no development. Even without development and support, Yamigo currently has grown to over 135,000 users.

I strongly think the world needs a service like Yamigo. Personally, I believe we’ll look back at 2008 as the year when mobile IM finally kicked off. Unlike in the past, most operators are now open, and phones ship with better native WV IM clients installed. While some operators still remove the default IM client shipped by the manufacturer, this is becoming less of a norm. In other words, Wireless Village is silently ubiquitous, at least now that Yamigo has been dead for over a year.

It’s to time to wake up! And so I have started the onesoup service, in order to bring a WV service back live. I want the service to be useful and really simple, even if that means only partially supporting the specs. For example, at least initially, onesoup will just be a gateway to the existing networks, and there won’t be any “onesoup network”, meaning no groups, no search, etc.

My goal is to make the experience of using instant messaging on your mobile phone as easy and streamlined as possible. Onesoup will provide automatic registration, and you will be able to access your instant messaging network seamlessly without requiring downloads or complex setups.

I am just starting coding and setting up this blog as I walk through the implementation. I’ll be setting up a mailing list for folks that might be interested in this service, e.g. as private beta testers (since we’ll need to test with a lot of phones!).

Comments or suggestions are highly welcome.