Creating a Simple Echo Server

You can demonstrate that ease of use by creating a simple echo server. Once it is running, the server will send back whatever data you send it. For the server side of things, you will be using Python. It was chosen because the server-side code is concise and easy to understand. To begin, you will need to have Python (http://python.org) installed on your machine. You will be using the Python web framework Tornado because of its great WebSocket support.

If you don’t already have Tornado installed, you can do so with the following command, run from any directory:

sudo easy_install tornado

Start the server by executing python tornado-demo.py in the same directory as the file; navigate to http://localhost:8888 to see it in action. You do not have to understand fully the Python in Listing 11-4 to see that it closely mirrors the JavaScript WebSocket API. You do some setup when the socket is opened, send a message immediately back to the client when you receive it, and close the connection when the client requests it.

Listing 11-4. Python Example: Open Socket, Send Message, Close Connection

class WebSocketHandler(tornado.websocket.WebSocketHandler):
    def open(self, *args):
        self.id = self.get_argument("Id")
        self.stream.set_nodelay(True)
        clients[self.id] = {"id": self.id, "object": self}
 
    def on_message(self, message):
        # Print to console when message received
        # Write same message to client
        print "Client %s sent a message : %s" % (self.id, message)
        self.write_message(message)
         
    def on_close(self):
        if self.id in clients:
            del clients[self.id]

On the client, you begin by instantiating a WebSocket connection. The universally unique identifier (UUID) allows each client to have his or her own ID and to receive only the messages targeted to the client. Other libraries, which you will investigate later in the chapter, do this bookkeeping for you. After the WebSocket object is created, you define the handlers that respond to events, as shown in Listing 11-5 and Figure 11-2.

Listing 11-5. Create the WebSocket Object, Define Event Handlers

var ws = new WebSocket("ws://localhost:8888/ws?Id="+Math.uuid());
 
ws.onopen = function() {
    messageContainer.innerHTML += "Preparing to send message";
    ws.send("The time is now "+ new Date());
    messageContainer.innerHTML += "Sent message."
};
 
ws.onmessage = function (evt) {
    var received_msg = evt.data;
    messageContainer.innerHTML += "Message received: "+received_msg;
};
 
ws.onclose = function() {
    messageContainer.innerHTML += "Connection is closed...";
};

Getting Started

Provided that you already have a Node.js install on your machine (for more information, see http://nodejs.org), you can install Socket.IO with node-packaged modules (npm), using the following command:

npm install socket.io

Echo Server

Let’s revisit the echo server example that you completed earlier in the chapter, but this time reimplemented, using Socket.IO. As you can see in Listing 11-8, the Socket.IO code on the client is strikingly similar to that of your previous, raw WebSocket example.

Listing 11-8. Socket.IO Client Code

var socket = io.connect('http://0.0.0.0:3000'),
socket.on('connect', function() {
    messageContainer.innerHTML += "Socket connected to server<br/>";
         
});
socket.on('message', function (msg) {
    messageContainer.innerHTML +=  "Message received: " + msg +"<br/>";
});
socket.on('disconnect', function() {
    messageContainer.innerHTML = "Connection is closed...";
});
     
var sendSocketMessage = function() {
    socket.send("The time is now "+ new Date());
    messageContainer.innerHTML += "Sent message.<br/>";
}

Instead of instantiating a WebSocket object directly, you are getting a Socket.IO instance with the io.connect command. The names of the events that are triggered when a socket is opened or closed have changed to connect and disconnect. In sendSocketMessage, you send a message on the socket with code that is almost indistinguishable from that of the earlier WebSocket example.

The full app.js file for setting up an echo server is in Listing 11-9.

Listing 11-9. The Full app.js File

var app = require('http').createServer(handler)
  , io = require('socket.io').listen(app)
  , fs = require('fs')
 
app.listen(3000);
 
function handler (req, res) {
  fs.readFile(__dirname + '/public/index.html',
  function (err, data) {
    if (err) {
      res.writeHead(500);
      return res.end('Error loading index.html'),
    }
 
    res.writeHead(200);
    res.end(data);
  });
}
 
io.sockets.on('connection', function (socket) {
  socket.on('message', function (data) {
    socket.send(data);
  });
});

After being bound to an application (app) instance to listen for new connections, the io object attaches a function to any inbound socket to echo back received input. You may have noticed that the form

socket.on ('<name of event>', function(args) { })

is present in both your front-end and back-end code. It also doesn’t require a confusing ws:// or wss:// protocol. Fewer APIs to learn makes for happier developers.

You can run the Node.js example by executing this code:

npm install
node app

Using Events

In the previous section, I briefly covered events, mostly adhering to the general WebSocket API. In this section, you will work with events further in the completion of a full-fledged application. In this example, we want something that is both easy to code and not obscured by a bunch of Canvas or Web Graphics Library (WebGL) code, so you will use a simple quiz game, with an associated chat box.

When the user navigates to the app, you establish a socket connection and register events for your app to handle. Three custom events, question, answer, and chat, receive questions, send and receive answers, and send and receive chat messages, respectively. The code resides in the app.js file, in the examples/socket.io/quizgame directory. Each event has its own handler function, as shown in Listings 11-10 and 11-11.

Listing 11-10. The Custom Events’ Handler Functions

App.prototype.setupClient = function() {
  this.socket = io.connect();
  this.socket.on('message', this.handleMessage);
  this.socket.on('question', this.displayQuestion);
  this.socket.on('answer', this.displayAnswer);
  this.socket.on('chat', this.displayChatMessage);
   $('#sendMessage').click(this.sendChatMessage);
  this.time = new Date().getTime();
}

The code for sending a chat message is shown in Listing 11-11.

Listing 11-11. Sending a chat Message

App.prototype.sendChatMessage = function() {
  var text = $('#message').get(0).value;
  if (text == "") return;
  $('#message').get(0).value=""
  app.socket.emit('chat', {message: text});
  app.displayChatMessage({message: text});
}

When the server receives an answer message, it determines a result and then adjusts the score accordingly. For the score, you can use the get and set functions on the socket, as shown in Listing 11-12; these let you store arbitrary data that you want to retain for the lifetime of the socket.

Listing 11-12. The get and set Functions

socket.on('answer', function(msg) {
    // Score answer
    var currentScore;
    var result = scoreAnswer(msg);
    socket.get('score', function(err, score) {
      currentScore = score;
    });
    // Emit message only to this client.
    socket.emit('answer', {
        message:result.message,
        score:(currentScore + result.points)
    });
    socket.set('score', currentScore + result.points);
  });

Finally, you have a bit of code for retrieving a question at random, masking its answer, and sending it to all connected sockets, as shown in Listing 11-13. The quiz game start screen is displayed in Figure 11-3.

Listing 11-13. Sending a Random Question to All Connected Sockets

var sendQuestion = function (questionId) {
   var q = _.clone(findQuestionById(questionId))
   q.correctAnswer = -1;
 
   io.sockets.emit('question', q);
}
setInterval(function() {
    sendQuestion(getRandomQuestion());
}, 10000);

For this quiz game, you used a single URL to address events for question, answer, and chat messages and general messages, but you could easily have used a separate socket for each event type. There are several other tweaks and enhancements that are beyond the scope of this chapter and whose investigation will remain a follow-up exercise for the reader (for more details, see http://socket.io).

Reducing the Size of Data Transmitted

In the previous examples, you used either raw text or JSON to transmit data. JSON is great because it is humanly readable, relatively lightweight, and natively supported by JavaScript. However, for a highly connected online game, JSON may not be lightweight enough. The general premise is that the less data transmitted, the faster they transmit and decode. BSON and MessagePack seek to improve transmission rates by discarding one of JSON’s key features: readability.

Intelligently Processing and Distributing Packets

Reducing the amount of data transmitted by sending it in a more efficient data exchange format is one way to increase data processing. An equally effective alternative is simply to send less data. In the following sections, I will discuss several ways to send fewer packets over the wire.

Autonomous Clients/Echo Server

This kind of setup, in which the clients do everything locally and report their changes to the server, is by far the easiest client-server combination with which to start. However, it is the one that is the most prone to cheating. When you hear about cheating in an online game, it is likely that a client was able to change something maliciously and have that state blindly pushed by the server to all the other clients. This also increases the load on the server, because all actions have to be received and sent to all the clients by it. Assuming that each client sends one update per second, then as the number of clients increases, so, too, does the number of updates, and by a large margin, as seen in Table 11-2.

That update rate is very close to being n^2. Combine this with the ever-present threat of cheating and variable network latency, and chaos is sure to ensue.

Dumb Clients/Authoritative Server

An alternative to having the server dutifully serve whatever the clients report without question is to have an authoritative server with “dumb” clients. This approach makes cheating less of a problem, while reducing network traffic. Clients receive routine updates from the server, indicating game state. Player commands are issued as requests to the server. If it deems a request possible, the server updates its state and sends it to the clients. If a request is impossible or invalid—for instance, holding down the spacebar to send “rapid-fire” events—the server will drop it. The server will also combine updates so that it can send out fewer of them.

Its parameters similar to those in Table 11-2, , Table 11-3 demonstrates how an authoritative server dramatically reduces load.

In the two examples presented here, I talked about the two extremes and chose to view them through the lens of network load. There are many intermediate variants that take into account the individual needs of the game being designed. A good place to start is the still relevant Valve paper “Source Multiplayer Networking” (https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking). Also of interest would be anything on multiplayer networking from the Association for Computing Machinery Digital Library (ACM DL) or the Institute of Electrical and Electronics Engineers (IEEE).

GRITS

GRITS is a multiplayer, top-down battle game designed by Google engineers to act as an example implementation of an HTML5-based game leveraging best-of-breed HTML5 technology, such as Canvas, WebSockets, Google App Engine, and Google+ integration.

GRITS employs one of the concepts introduced earlier, the authoritative server (see the section “Dumb Clients/Authoritative Server”). Here, clients send requests for specific actions to the server, the server pushes its state tothe clients, and the clients see this as the source of truth, overriding any local data. Listing 11-14 displays the setup of GRITS’s socket for handling directional input when using an Android device.

Listing 11-14. GRITS’s Directional Input Socket for Android

var controller_endpoint = '/'+game_id+'!'+id;
console.log('STARTING TO LISTEN ON WASD CHANNEL', controller_endpoint);
io.of(controller_endpoint).on('connection', function(wasdSocket) {
  ref = {};
  console.log('CONTROLLER CONNECTED TO WASD CHANNEL', controller_endpoint);
  wasdSocket.on('disconnect', function(msg) {
    console.log('RECEIVED DISCONNECT FOR WASD CHANNEL', controller_endpoint);
  });
  wasdSocket.on('message', function(msg) {
    // console.log('GOT WASD CONTROLLER MESSAGE', msg,
    //        'ON WASD CHANNEL', controller_endpoint);
    wasdSocket.send('ack ' + msg);
    if (msg.slice(0,4) == 'init') {
      ref = JSON.parse(msg.slice(4));
      return;
    }
    if (!ref['player_name']) {
      console.log('disconnecting', controller_endpoint,
      'wasd controller; received msg', msg, 'while ref has no player_name:', ref);
      wasdSocket.disconnect();
      return;
    }
    W = (msg[0] == 'Y'),
    A = (msg[1] == 'Y'),
    S = (msg[2] == 'Y'),
    D = (msg[3] == 'Y'),
    socket.q_wasd({from: ref['player_name'].slice(1), W: W, A: A, S: S, D: D});
  });
});

Readers are encouraged to watch the Google IO talk by Colt McAnlis on GRITS at https://developers.google.com/events/io/2012/sessions/gooio2012/210. The previous snippet comes from https://code.google.com/p/gritsgame/source/browse/src/games-server/main.js.

Rawkets

Rawkets is a proof-of-concept, online, multiplayer game developed by Rob Hawkes, the head of developer relations at Pusher and former technical evangelist at Mozilla. The game explores HTML5 Canvas, WebGL, and WebSockets. Rawkets is reminiscent of the classic arcade game Asteroids. A simple line-art ship represents the players; they can move about the world and shoot at other players.

You can peruse the Rawkets code at https://github.com/robhawkes/rawkets. Rawkets uses PHP for some of its code. PHP is outside the scope of this chapter, so I will leave it as an exercise for the reader to work out how to install a LAMP (Linux, Apache, MySQL, PHP [or Perl]) server and get the code running.

Rawkets uses many of the techniques described earlier in this chapter. The interesting portions of code lie in the main.js file at https://github.com/robhawkes/rawkets/blob/422026f0fcd31db7645281568cf5b6d1d7668932/server/main.js.

Listing 11-15 provides all the specific message types in Rawkets. A unit of data for a Rawkets game takes this general form.

Listing 11-15. All Message Types in Rawkets, in the File main.js

{type: <MESSAGE TYPE ID>, arg1: value1, arg2: value2, ...}
 
/**
 * Message protocols
 */
var MESSAGE_TYPE_PING = 1;
var MESSAGE_TYPE_UPDATE_PING = 2;
var MESSAGE_TYPE_NEW_PLAYER = 3;
var MESSAGE_TYPE_SET_COLOUR = 4;
var MESSAGE_TYPE_UPDATE_PLAYER = 5;
var MESSAGE_TYPE_REMOVE_PLAYER = 6;
var MESSAGE_TYPE_AUTHENTICATION_PASSED = 7;
var MESSAGE_TYPE_AUTHENTICATION_FAILED = 8;
var MESSAGE_TYPE_AUTHENTICATE = 9;
var MESSAGE_TYPE_ERROR = 10;
var MESSAGE_TYPE_ADD_BULLET = 11;
var MESSAGE_TYPE_UPDATE_BULLET = 12;
var MESSAGE_TYPE_REMOVE_BULLET = 13;
var MESSAGE_TYPE_KILL_PLAYER = 14;
var MESSAGE_TYPE_UPDATE_KILLS = 15;
var MESSAGE_TYPE_REVIVE_PLAYER = 16;
 
socket = ws.createServer();
serverStart = new Date().getTime();
         
players = [];
bullets = [];
         
// On incoming connection from client
socket.on("connection", function(client) {
 
    socket.broadcast(formatMessage(MESSAGE_TYPE_REMOVE_BULLET, {i: bulletId}));
    socket.broadcast(formatMessage(MESSAGE_TYPE_KILL_PLAYER, {i: player.id}));
    socket.broadcast(formatMessage(MESSAGE_TYPE_UPDATE_KILLS, {i: bulletPlayer.id, k: bulletPlayer.killCount}));
    socket.broadcast(formatMessage(MESSAGE_TYPE_UPDATE_BULLET, {i: bullet.id, x: bullet.x, y: bullet.y}));
 
    // omitted code
});

The helper function formatMessage converts the arguments into a JavaScript object and binary encodes it before passing it to the socket to broadcast to other clients:

function formatMessage(type, args) {
        var msg = {type: type};
 
        for (var arg in args) {
                // Don't overwrite the message type
                if (arg != "type")
                        msg[arg] = args[arg];
        };
        
        //return JSON.stringify(msg);
        return BISON.encode(msg);
};

BiSON is similar in many respects to BSON and MessagePack; BiSON is more lightweight than JSON and can more efficiently store types. However, BiSON lacks the mindshare of BSON and MessagePack. You can read more about BiSON on its project page at https://github.com/BonsaiDen/BiSON.js.

Firebase

Firebase (www.firebase.com) provides a real-time API for syncing and accessing data. Firebase has client libraries and bindings for most mobile and web platforms, while offering the option of a Representational state transfer (REST) API if your favorite language or framework is not supported. Firebase is somewhat like WebSockets plus a data store wrapped up in the same package.

Firebase stores data in a JSON-like format, and it allows you to access the data through one of several options:

• A client library
• Vanilla REST calls
• A browser

Everything that you store is addressable by its object path. For instance, consider a player object stored at the root http://MyGame.firebaseIO-demo.com and represented by the following code:

ud7h3if: {
    name: 'John',
    vitals: {
        health: 80,
        attack: 20,
        weapons: ['pistol', 'rifle', 'machete']
    }
}

You could display the object by navigating to http://MyGame.firebaseIO-demo.com/ud7h3if, or perhaps only the vitals or weapons by going to http://MyGame.firebaseIO-demo.com/ud7h3if/vitals or http://MyGame.firebaseIO-demo.com/ud7h3if/vitals/weapons, respectively.

Unlike WebSockets, in which you listen for message and connectivity events, Firebase events all deal with the underlying object model. They are

1. value
2. child added
3. child changed
4. child removed
5. child moved

Because each property is individually addressable, on http://MyGame.firebaseIO-demo.com/ud7h3if/vitals/weapons, you could trigger the child added or child removed handler functions when the player picks up or drops a weapon or to monitor changes in health. All Firebase clients maintain a copy of the data and fire any attached callbacks locally before the data are synced to the other clients. This system of eventual consistency means that some clients may be in a transitional state for some time until all the data have been propagated. Firebase will merge updates from clients as needed.

As a result, Firebase is great for turn-based games or even some light real-time games, but it doesn’t offer enough control for games such as GRITS or Rawkets.

Pusher

Pusher is a software as a service (SaaS) provider of a hosted WebSocket API. Pusher includes fallbacks for noncompliant browsers and libraries (both client and server) in many languages to give the developer a single API to learn. Letting someone else deal with the WebSocket code frees you to offload those responsibilities to Pusher and just work on integration. Many programming languages do have some sort of WebSocket API, but they generally aren’t as mature as Socket.io. If your application is not written in Node.js, you have to worry about finding a library or server that supports even a fraction of what Socket.io does. Pusher gives you the best of both worlds: a mature and fully featured solution and no responsibility to maintain a separate socket server.

Kaazing

Kaazing’s commercial WebSocket platform offers the infrastructure and protocol libraries that make it easier to build real-time, in-game experiences, such as peer-to-peer, chat, virtual-goods shopping, auctions, and game-state notifications for players who are away from the game. Kaazing also provides hosted, cloud-based WebSocket servers to take the hassle out of deployment. You can read more about Kaazing and gaming at http://kaazing.com/industries/online-gaming.