Ajax chat polling bandwidth efficiency.

Question

I've written a small web application which is basically a JQuery powered chat client within the browser, to get the posts I'm polling the server with an AJAX request and then appending any new replies, I'm worried about making this as efficient as possible while not losing the realtime feel.

http://darklightweb.co.uk/RealTime/

I can't see any way that interrupts are possible so I am polling a page every 5 seconds that returns nothing if no new posts are available to keep data-transfer down if it's idle, if it does have a message the top message in the queue is sent out and I'm checking again as soon as the Ajax request has finished until the message queue is empty.

Any other tips on making this as low-bandwidth as possible or possible alternate implementations?

Answer 1

I think for a chat application you can use

Reverse Ajax

Reverse Ajax refers to an Ajax design pattern that uses long-lived HTTP connections to enable low-latency communication between a web server and a browser. Basically it is a way of sending data from client to server and a mechanism for pushing server data back to the browser.1

This server–client communication takes one of two forms:

* Client polling, the client repetitively queries (polls) the

server and waits for an answer. * Server pushing, a connection between a server and client is kept open, the server sends data when available.

Reverse Ajax describes the implementation of either of these models, or a combination of both. The design pattern is also known as Ajax Push, Full Duplex Ajax and Streaming Ajax.

and

moo-comet

Request.Comet is a simple javascript class to create cross browser Comet(Reverse Ajax) applications easily. It provides realtime data transfers between client and server and can be used with any server-sided language.

Answer 2

Polling might not be the best solution for implementing a chat - I'd suggest taking a look at JQuery's implementation of COMET which keeps an open connection to the client and pushes updates from the server 'down' and is also quite scalable.

Answer 3

I've written almost EXACTLY the same application to facilitate communication between friends at work when various employers use draconian web filtering.

I found that the the amount of data transfered for these polling requests is minimal and rarely approaches 1kb/s per logged on user, usually way less since you're only polling ever 5s.

Is bandwidth really an issue or are you prematurely optimizing?

Answer 4

To go along with msparer's response, here is a a blog post on Comet message rates and benchmarking such a technique for a chat application:

http://cometdaily.com/2008/10/30/comet-apps-will-not-scale-equally/

Answer 5

If you decide not to go with the COMET approach, then I would do the same as you do, except if the queue contains several messages then they are sent all at once. This way you only poll exactly every 5 seconds and no more (and no less). Of course, with 100 people connected this still results in 20 requests per second, so you should try and optimize the server side in such a way that each request takes as little server resources (CPU/RAM/time) as possible. Caching is your friend here.

I wouldn't worry about bandwidth though because chat messages are usually very short and your requests would be tiny anyway.