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?
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.
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.
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?
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.
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/
