Simple Ajax Chat for TheBroth

We have recently added chat to TheBroth. Yay! Interestingly, all the females we asked about whether they’d like to have chat at TheBroth excitedly agreed, whereas males wouldn’t respond as favorably.

As some visitors commented, TheBroth really is just like one big sociology study - anyone ready to write a PhD on this? ;-)

Well be that as it may, TheBroth now has chat in every room and we’re ready to share with the world how we did it. In an associated tutorial article we’ll demonstrate how you can easily add Ajax-powered chat to your own site!

Let’s explain the vocabulary first

We use a client/server setup to coordinate the data flow between each visitor and everyone else who is currently looking at the same page.

The engine is the php script on the server that does all the heavy lifting. This script accepts the user input that is sent along with the XmlHttpRequest, then does a whole bunch of somewhat protracted MySql queries, and then sends new data back to the client.

The client is the JavaScript portion of the page that you load when you access a mosaic page. Of course this page is also created dynamically in php, but it is the JavaScript that does all the work when things are running.

In logical terms, you can also think of the visitor that looks at the web page as a client, but technically it’s of course this person’s browser that is engaged here.

Piggybacking the chat code

Since the updating of a client with new tile information is done by polling the server, we simply added the chat message of each user to the data that’s already being sent to each client with each request.

This repeated polling is nothing else but the periodic XmlHttpRequest associated with our one Ajax object. Yep that’s right, there’s only one Ajax object for everything the mosaic does.

All user input, including the chat messages, are being pooled until the next request is being sent to the server. This will occur when the previous request has returned, asynchronously.

So, all we needed to do to add chat to TheBroth was to add the user’s input to the information that is sent to the server. At the server, the messages are inserted into a chat messages table. When the engine selects messages to be sent to each client, it simply includes all messages that are younger than when it last looked. Sounds trivial, right?

The secret lies in the request counter

So how does the engine know which messages of which user to report back to each client? Well, here we use the same trick that is responsible for the z-index synchronization of the tiles, an algorithm and associated data structures that ensure that all clients get to see the exact same thing.

The magical request counter is a single, site-wide “global” value that counts up whenever the engine script is called by any client. Tile data and chat messages are stored along with the request counter value at that time. In addition, in the table that stores all clients, we store the request counter from the time when this client last requested data.

When the engine selects which tiles and which messages to send to each client, it simply takes all the data (moved tiles and messages) that have a request counter associated with it that’s higher than the request counter from when this client looked last time.

This simple setup ensures that everyone gets to see everything, and nobody ever gets data twice. Wonderful - and infinitely useful for any multiplayer or one-to-many real time application you can think of!

Cleaning up

Now that we can add and distribute chat messages, we have to get rid of them again. When do we know that everyone has seen everything so that we can delete old messages from the chat messages table?

In fact, we actually don’t know whether or when everyone has seen everything. We don’t have a backscroll buffer, and we don’t keep track of who’s seen what, like other multi-user chat implementations do, most noteably Internet Relay Chat, IRC.

What we do is much much simpler - any message older than let’s say, 60 seconds, is being deleted from the system!

Because our update rate is so much faster than this timeout period, we can be pretty sure that everyone got to see all messages. Clients that didn’t get an update in the last 60 seconds certainly can’t use the mosaic (or any chat of any kind) anyway.

Scrolling of the chat messages, client-side

From a certain number of messages onwards, the client has to begin to scroll the incoming messages. Once again, we’re using JavaScript and a little bit of DHTML to make that happen.

The underlying data structure is a simple JavaScript array. When a new message comes in, we take off the first element of the array, and then push a new element onto it.

To be quite precise, we’re using two arrays, one for the message, and one for the player name.

The event of an incoming message occurs when the Ajax request returns. At that time, we update the messages array, create the HTML markup based on the data contained in the array, and update the chat container div with that HTML. Done!

Free Ajax chat on your site

Read on how you can implement a free, super simple and robust Ajax/Php/Mysql chat facility on your own site!

Bedtime - will post the chat tutorial tomorrow :-)