all services are back to normal now. we only had 60 minutes of downtime, basically for the DNS records to take over. thank you for patience.

heads up guys. we have a new server. the service will be down for the next 2 hours, while we move the service.

today we’ve had a couple of network issues around noon GMT with a faulty router. it’s now fixed and up and running. this is the kind of thing you get with hosting on DSL. but hopefully we’ll move to a new colocation facility within the next few days, where we’ll have redundant kit. for now, please bear with me. thank you guys for your support!

following along the lines of our previous gtalk release, we are now adding support for aim and icq. you can now chat using the embedded chat client in most Nokia, Sony-Ericsson, Siemens or BenQ phones.

behind the scenes in this release, we are also reducing the payload by a factor of 3 for most phones, and a few more phones should be supported now. additionally, not only gtalk, but any jabber account should be supported right now (e.g. myjid@jabber.mobi).

chat client setup instructions here.

again, please give us feedback through the forum.

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’d have loved to get this out earlier but, finally, here it is. drumroll!! a wireless village server for the embedded chat client in most modern nokia, sony-ericsson, siemens and benq phones. i’ve been working hard to make it as mobile-network friendly as possible, looking at things from transfer volumes, to battery life. but foremost, usability.

if you have a supported phone, you can get gtalk on your cell phone by simply pointing to our IMPS servers as described in the gtalk connection page. you will need to already have a working packet data connection (EDGE/GPRS/3G/UMTS/…). note that not everything you would expect works just yet, but at least you will be able to login, fetch your gtalk/gmail contacts, chat, change your presence and get status updates from your buddies.

on thing that i have tried to keep very visible is the traffic volumes involved. you can see what to expect in our help page. i am also working to provide a simple web interface where you will be able to see your access history, connection time, and transferred data volumes.

now, be friendly to the service. it’s just out of alpha. expect a few interruptions as i build up the infrastructure and get new servers. i’ll blog about it anyway to let you guys know about any upcoming support window.

but, for now, enjoy gtalk on your cell phone, and let others know what your experiences are at the forum.