Use of Ajax for the mosaic

The following article explains how we use Ajax to implement the mosaic of TheBroth as a near-realtime, synchronized server-multi-client application. As you can imagine, things are somewhat complicated and the description below may appear like rather dry material for some. If you’re not fully versed in Ajax yet, you may want to have a quick look at Wikipedia’s entry on Ajax.

And now straight to the meat…

The client/server data exchange required to update TheBroth’s mosaic game area is handled using the Ajax web application model. A player’s moves and Karma votes are communicated to the server via the JavaScript XmlHttpRequest object, and similarly, data regarding other players’ moves and Karma votes are returned to each browser via this XmlHttpRequest object.

Tile position data passed to the XmlHttpRequest object triggers a JavaScript function which causes each tile moved to ‘fly’ to its new position in the mosaic game area.

Each XmlHttpRequest object is fully synchronized with the server, and there is therefore no loss of data even when there are many players active in TheBroth’s rooms.

How it works

TheBroth uses a time-dependent implementation of Ajax to give the appearance of being real-time. Each browser client is scheduled to interact with the server every second to:

1. Transfer new position data regarding tiles the player has moved; and
2. Receive new position data for tiles other players have moved.

This means, we only use a single XmlHttpRequest object. This request to the server invokes a server-side script (we call it the “engine“) that processes the incoming data, and returns whatever has changed in the server’s database tables back to the client.

This request returns asynchronously. Upon return of the new data, the client now updates its own data structures, namely the tile positions and the information about the room occupants, ie the players. Then another request is being sent, including data about of what the player has moved in the meantime, and so on and so on.

Pooling of player moves

Instead of sending a request to the server every time a tile is moved, we pool the data of each tile movement and then send all the new positions in the same request:

Between the periodic updates, a player’s moves are added to a client side stack. When the periodic update takes place, the contents of this stack is written to a buffer to be sent to the server. The request is identified by a timestamp and the player’s name.

Description of each Ajax write/read cycle

At each periodic update, the following steps are performed, by making an XmlHttpRequest to the server:

1. Data regarding the player’s moves and new tile positions (if there are any) are posted to the server.
2. The server-side script that is being called by this request looks up its output buffer to see whether response data for this request have already been generated or if it is a new request.
3. Once it has been determined that the request is a new one, the server updates the database to reflect the player’s moves.
4. The server then gathers data regarding what has changed since the player’s last periodic interaction.
5. These data are returned to the client in a custom format, along with the original request’s timestamp for identification purposes.

Request timeouts

If an Ajax request is not returned to the client within 5 seconds, the original request is aborted and a new one is sent.

Here’s the JavaScript code that aborts a pending request by calling the abort() function, deleting the object, and initializing a new one:

ajaxOb.abort();
delete ajaxOb;
ajaxOb=initxmlhttp();

Data exchange format

Data is exchanged between the client and server as delimited strings. This option was chosen over XML in order to save bandwidth and parsing overhead.

Data sent from the client to the server contains the following information:

• Room name: the name of the room from which the data have been sent.
• Timestamp: a 13-digit integer denoting the time in milliseconds.
• Square data: delimited data concerning new positions of moved squares. These data are made up of the following fields:
  • Slot number: the number of the tile that has been moved.
  • X: the x position of the new tile.
  • Y: the y position of the new tile.

If no tiles have been moved, then no square data are included when the XmlHttpRequest to the server is made.

What the server-side script returns to each browser

Data returned from the server to the client, as a response to the XmlHttpRequest sent to the server, contains three parts:

1. Player hash
2. Square data
3. Player data

The player hash is always sent, regardless of whether there are accompanying square and player data to be sent. The square data again details which tiles have been moved and their new x, y positions. Including the player hash allows other players to see which player last moved a tile.

The player data details whether something about the player - his room karma or player name - has changed since the last update.

Want more detail? Read more about exactly what is being sent back and forth between client and server here, where we discuss the player synchronisation.