Demonic Angelicism Blending dreams with reality

Mesh Chat Box

I recently had (or rather, wanted) to make a chat box. I had no idea of how to do this before, so I had to work with what I knew already about chat boxes, which ended up being almost nothing. You type things into a box, and they magically appear in an upper box, where things from other people appear as well — just like magic.

Magic — now how do I do magic?

I had to break down the chat box problem into something more manageable. The simplest form of chat box that exists would be like a message board, or the comments of a blog post. I knew how those work — simply take the thing someone types in and store it to the database, then load them from the database and display them on the page. Because it’s all loaded when you load the page, you would have to refresh to see the new messages. I realized I could use a similar solution for a chat window. All I had to do was to change all server interactions from normal page loads to AJAX.

AJAX, or Asynchronous JavaScript and XML, is much less complicated than it sounds. One thing that really scared me when I first decided to look at it was the first word, Asynchronous. Just look at it — it’s huge! (And do you know how to pronounce it? ) I would say that initially, dictionaries actually scared me, defining the word as “Not synchronous; occurring at different times.” (Wiktionary) After I finally crawled out of my hole, I learned that AJAX is “simple”: it’s basically telling JavaScript to pretend you loaded a page. The page content would be basically in a JavaScript variable. Of course, there are cross-browser standardization issues, but they’re all removed when you use a library like Prototype or jQuery.

Anyway, adding a chat message to the database was easy, simply send the form with AJAX to a page which would add it to the database. The processing page could work just like the guestbook would: Take the input, clean it for the database, add on an id, time, sender info, and channel (you want more than one chat box on the site, right?). The JavaScript would basically be a line in jQuery:

$.post('processing.php', $('#chatform').serialize());

In retrospect, it’s actually quite amazing I decided to do the sending code last while I was making the chat.

The code for displaying the code was a bit more difficult. Strangely, it wasn’t because getting the content was hard, jQuery even has a function specifically for a purpose like this. To load getchats.php into the #chatmessages <div> you would only have to do this:

$('#chatmessages').load('getchats.php');

The hard part of making a chat window is figuring out how to actually pick out chats to put into the window. You can go several ways here: You can decide to load the last five chat messages into the chat messages area. That way, you can also cheat by avoiding the “how should I stay scrolled to the bottom of the chat box” problem: if everything except the last five messages isn’t there, you wouldn’t even need to scroll.

As always, as great as this solution sounds, there are a few problems with it — there is no chat history for anyone to look at, and what if more than five messages are sent in that one second between chat fetches? (You can’t have it fetch continuously because that would bog down the server, so you have to do it at an interval.)

Okay, so that wouldn’t work. I considered storing the time of the last chat received, and then telling the server to fetch everything that was received after that time. I could then ask jQuery to append the code. Append is easy — one line in Prototype, three with my style in jQuery:

$.get('new-getchats.php', {lasttime: aVarWithTheLastTime}, function(data) {
    $('#chatmessages').append(data);
}, 'html');

It works well, but theres still one problem left. Imagine that two different people send messages at the same second, right as one other person is fetching messages. There is a very slim chance that one of the messages can be missed.

    Time            Action
1248513790 User C sends "All in favor say aye"
1248513791 User C requests list of messages, stores time 1248513791.
1248513792 User A sends "aye"
1248513792 User C requests list of messages, stores time 1248513792.
1248513792 User B sends "nay"
1248513793 User C requests list of messages, stores time 1248513793.
1248513794 User C sends "So we all agree"

What happened here? User C just happened to request the messages before user B’s message got stuffed into the server. The message never appears to user C because the time 1248513792 was stored, which means “I already got messages for the time 1248513792. Next time I check, I only need to get messages starting from time 1248513793.” The message was dropped.

The solution is actually simple. Just use ids instead of times. There is no chance of messages being dropped with ids, as long as you keep them in order. If you fetched chat message number 324, a new chat message numbered 321 isn’t going to pop up (well, actually, depends on how you coded it, but ideally it doesn’t). Problem solved.