marcus welz

HTML5 Game - Connecting to the server

I'm prototyping a multiplayer HTML5 game. The client is the HTML5 concoction of JavaScript, CSS, and whatever one might lump into the "HTML5" technology stack, while the server is the "concurrency oriented" Erlang and mochiweb stack.

The browser will then communicate with the web server using AJAX calls. Eventually this could all be done using WebSockets, but we're not there yet. WebSockets have just experienced a set back due to a problem with the protocol.

With simple AJAX calls (which aren't really AJAX anyway, since JSON is so much nicer to work with) there are two ways to get data from the server.

One is polling. Often. Every second or so. This is rather wasteful, but it's easy to implement. In PHP, for instance, polling often is pretty much the only option since the connection to the server ties up an Apache child process. The PHP portions needs to be as quickly as possible in order to free up the resources for the next person to be able to bang away at the server.

The other option is long-polling (AKA COMET). In this case the browser connects to the server, which then holds onto that connection until data is ready to be sent back. This eats the socket, and whatever additional resources are required by the webserver. And since Erlang appears to be really good at this, I'll do that.

So for the purpose of communicating with the server, I'll use two types of connections. One is the "event listener", waiting for data coming from the web server, that's my long-polling COMET call. Whenever there's data the server wants me to have, it'll send it and then close the connection. On the client side I'll process it, and then immediately fire off the next COMET call, waiting for more data. Mochiweb actually comes with an example of long-polling.

The other connection type is the "action connection". It'll fire for every command that the client is sending to the server. So when I click something in the browser, that'll result in an action call to the server. For that I'll use the regular jQuery .ajax() call.

So essentially to receive data from the server I have my listener AJAX call, and to send data to the server I use my action AJAX call.

Erlang Processes

I'll need an Erlang process that represents my client. It stores my session data, but a bit more than that, actually. I'll basically store all relevant client view state and interact with the rest of the server on the browser's behalf.

So for each client there's a session process. This process gets created when the client makes a login call:

Once this Session process exists, the listener will connect to the server. The server will hold onto the connection, until data is available. The data is then returned to the browser:

Finally, the action AJAX call. It just fires off an action and closes the connection. The Listener Pid here is the hibernating mochiweb process from the previous sequence diagram:

It's rather quick, too. The first feature I implemented was the "ping". JavaScript sends a ping command, along with the current time.

metapoly.net =
{
    action: function(action, params) {
        $.post('/action/' + action, params);
    },
};

metapoly.net.action("ping", {time: (new Date()).getTime()});

The AJAX call will connect to the mochiweb server, which creates a new process to handle the request. The process will then look up which "client view" process is responsible for handling the web browser commands, this is stored in ets. The "client view" process is then sent the ping message. The client view process pattern matches it, and tries to send a response "pong" to the listener process, which is the COMET connection.

% actions such as mouse clicks, text events, etc.
handle_action(Payload, State) ->
    case Payload of
        {"ping", Params} ->
            Pong = {struct, [{'_t', mpu:now()}, {"c", "pong"}|Params]},
            io:format("received ping, queueing pong reply: ~p ~p~n", [Params, Pong]),
            NewState = State#state{messages = [Pong | State#state.messages]}
    end,
    ?MODULE:loop(NewState).

As soon as the listener has the command, it'll return it to the client. The JavaScript client will invoke the callback, get the new current time, do a diff with the time the ping was sent and displays the results in a div tag.

metapoly.net.e('pong', function(msg) {
    var diff = (new Date()).getTime() - msg.time;
    $('#ms').text(diff + "ms lag");
});

On localhost, and using Chrome, the fastest I've seen was a 6ms response time. If I hammer the button, it'll come back somewhere between 8 - 20ms. On Firefox, with Firebug open, it'll bounce around between 30ms and 150ms.

With that, the consider the first conversation with the server successful.