• Blogs
• Ajax Chat Rooms

Ajax Chat Rooms Almost Ready

01 December 2006 - 3:08 PM / by Dominic Pettifer. 2 Images for Ajax Chat Rooms Almost Ready. 1 Comment for Ajax Chat Rooms Almost Ready.

Technical Article - I'm just putting the finishing touches to my Ajax powered chat room application (see Chat Rooms link in the About section, bottom left). Still a few bugs left to deal with, but you can use it, well sort of. Though it's amazing how the XmlHttpRequest object can be harnessed to build such an application.

The Power of XmlHttpRequest

It has been a tough couple of weeks building the chat room. It's highly reliant on DHTML with JavaScript and Ajax techniques (using the XmlHttpRequest object), something I didn't know I lot about and had to study up on.

In case you don't know Ajax, it allows a webpage to use JavaScript to asynchronously call another webpage somewhere, and display the returned information on the screen (using DHML like capabilities), all without refreshing/reloading the entire page.

This is made possible with a built in browser object called the XmlHttpRequest object, supported by all major browsers. Think of it like a mini web browser inside the main web browser that can request pages by itself, and do something with the returned information.

In the chat room, an Ajax call is made at regular intervals (every second) to the web server to check for new messages, and whether any new users have logged in or left the chat room, among other things. All this uses only JavaScript and doesn't need any special plug-ins, like Java Applets, Flash or ActiveX Controls.

Server side: Background Threads

On the server, when a chat room is created, a background thread is spawned (using a Timer in .NET) that periodically checks (every second) the collection of users in the chat room. It checks for a certain period of inactivity (more than 5 seconds) for each user, by checking a polling interval property, and logs that user out of the chat room.

This needs to be done otherwise there would be no way to remove users from the chat room. The web browser doesn't send any information to the server letting it know that it has been closed, or that the user has browsed away to another web page. So every poll made by the chat room to the server resets the polling interval property for the user to the current date and time, thus keeping the user refreshed so to speak.

Problems: Server Overload and Bandwidth

It's not without its problems though. For a start the server side usage can be heavy. If 20 users are inside a chat room that's 20 http requests per second to the web server. With multiple chat rooms the number of requests served soon adds up, and could bring the server to its knees. I feared overloading the database so the chat room data is persisted in the web Cache context, instead of a database, for better performance. The Cache does get removed after a certain period of inactivity, but this doesn't matter since it's not really necessary to persist the data in a chat room anyway.

Another problem is the bandwidth. If the chat room text and users are getting resent with each polling interval, the bandwidth usage can be as high as 30/40 KB per second (with 10 users and 10 messages). That may not sound like much but its 2.4MB per minute, or 144MB an hour, 3.5GB per day etc. It soon adds up.

I have tried to solve this by setting a timestamp for each polling interval, and comparing with the timestamp for the messages, so that only new messages and sent. This helps dramatically reduce the bandwidth usage.

Also the data is sent in JSON (JavaScript Object Notation) format which is significantly more compact than XML, or sending HTML snippets. I've even gone as far using cryptic variable names like T instead of Text. All this helps to reduce the bandwidth down to 8/10 KB per second, quite a significant saving.

Bugs: Internet Explorer Woes

At the moment there are a few bugs with it. Some are solvable, others a complete mystery. For instance, Internet Explorer users keep getting logged out of the chat room at random intervals.

Sometimes this is to do with an aggressive minimum inactivity period. 5 seconds may be too short to wait to mark a user as inactive, as sometimes Ajax calls can take longer than 5 seconds on slower internet connections. Increasing this to something like 10 seconds should help solve the problem.

Other times Internet Explorer just throws a strange error and the user is logged out. The JavaScript error message is not particularly useful; it gives a line number that points to a curly bracket or method.

So far it seems fine on Firefox and Opera, still need to test on IE 7 and Safari. If you do try it and experience problems could you please send me the debug info at the bottom of the chat room, underneath the textbox, along with what browser, version, and Operating System you are using. Either email me or post a comment in this blog, thank you.

Future Article

Hopefully, if I have time I'll post a more in depth article covering how to build an Ajax chat room, complete with source code. Maybe even post it on the Code Project.