Still Not Perfect

The past couple of months I’ve been pondering an idea. It isn’t a new one, or anywhere close to groundbreaking, but I don’t think anyone has accomplished anything quite like it before. I want to write an IM/chat system that is as responsive and real-time as native IM/chat programs, and that operates solely over HTTP, with vanilla browsers – no Java applets, no ActiveX plug-ins, just Javascript that all modern browsers support. The advantage of such a system is that it could traverse firewalls and proxies traditionally used to block users from using IM/chat, and that users would never be prompted to install applets or plug-ins that many users distrust (for good reason too).

So, why hasn’t it been done before? When I first had the idea I thought surely there would be at least 10 similar projects already. I found several attempts, but none seemed to fit the bill – some communicated entirely over HTTP but required Java applets, some didn’t use any applets or plug-ins on the client but weren’t responsive or real-time (updates were polled for ever 2 secs or so). Looking at the current field of attempts there seemed to be a couple of challenges that I would have to find a way around.

• HTTP/1.1 supports keep-alive connections, but they don’t work well for 2-way communication. The client still must initiate every exchange, so the server can’t send messages to the client on demand.
• A client repeatedly polling a server for messages (even when there are none for it) puts a lot of unnecessary load on the server, and generally results in a poor user experience. The programs I looked at that used this model often felt very laggy and sluggish – they certainly didn’t feel like native applications.

So, what’s the solution? I don’t know for sure, but I think I’ve got a start. Basically the client uses XMLHttpRequest calls to open up a connection to the server in the background (so no page reloads are required). The server accepts the connection and just sleeps until it has a message to send the client. By setting the script timeout to be very long or infinite on the server the connection never times out, even if the client has to wait hours for a message because nobody wants to talk to the user (as long as the network between client and server stays healthy, but that is assumed). Once the server does have a message to send back to the client (such as a message from another user, or notification that a buddy has signed on) it simply sends it back on the connection the client initiated. Now, once the client has received the message and processed it accordingly it immediately calls XMLHttpRequest again to start another request to the server, and so it starts just waiting for the server’s next message to it.

Not quite ideal as far as IM/chat protocols go, but it fits within the confines of HTTP, has less overhead than a system where the clients are constantly polling the server (instead of basically sleeping until responded to), and allows for a responsive native feeling application (because all connections and updates can be done without reloading the page). My proof of concept experiment seems to have been a success (at least for Mozilla browsers). It seems to mostly work in IE as well, just IE doesn’t handle pre tags like I expected it should. When I get time I’ll be working on developing the idea. Hopefully soon you will see a more comprehensive example of my idea here.

This entry was posted on Friday, August 12th, 2005 at 8/12/2005 7:43 pm and is filed under Computing, Software Engineering, Web. 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.