Home Web Development Adding Real-time Functionality Using Socket.io

Adding Real-time Functionality Using Socket.io

September 22, 2014 - 12:00 am

9178

17 min read

In this article by Amos Q. Haviv, the author of MEAN Web Development, decribes how Socket.io enables Node.js developers to support real-time communication using WebSockets in modern browsers and legacy fallback protocols in older browsers.

(For more resources related to this topic, see here.)

Introducing WebSockets

Modern web applications such as Facebook, Twitter, or Gmail are incorporating real-time capabilities, which enable the application to continuously present the user with recently updated information. Unlike traditional applications, in real-time applications the common roles of browser and server can be reversed since the server needs to update the browser with new data, regardless of the browser request state. This means that unlike the common HTTP behavior, the server won’t wait for the browser’s requests. Instead, it will send new data to the browser whenever this data becomes available.

This reverse approach is often called Comet, a term coined by a web developer named Alex Russel back in 2006 (the term was a word play on the AJAX term; both Comet and AJAX are common household cleaners in the US). In the past, there were several ways to implement a Comet functionality using the HTTP protocol.

The first and easiest way is XHR polling. In XHR polling, the browser makes periodic requests to the server. The server then returns an empty response unless it has new data to send back. Upon a new event, the server will return the new event data to the next polling request. While this works quite well for most browsers, this method has two problems. The most obvious one is that using this method generates a large number of requests that hit the server with no particular reason, since a lot of requests are returning empty. The second problem is that the update time depends on the request period. This means that new data will only get pushed to the browser on the next request, causing delays in updating the client state. To solve these issues, a better approach was introduced: XHR long polling.

In XHR long polling, the browser makes an XHR request to the server, but a response is not sent back unless the server has a new data. Upon an event, the server responds with the event data and the browser makes a new long polling request. This cycle enables a better management of requests, since there is only a single request per session. Furthermore, the server can update the browser immediately with new information, without having to wait for the browser’s next request. Because of its stability and usability, XHR long polling has become the standard approach for real-time applications and was implemented in various ways, including Forever iFrame, multipart XHR, JSONP long polling using script tags (for cross-domain, real-time support), and the common long-living XHR.

However, all these approaches were actually hacks using the HTTP and XHR protocols in a way they were not meant to be used. With the rapid development of modern browsers and the increased adoption of the new HTML5 specifications, a new protocol emerged for implementing real-time communication: the full duplex WebSockets.

In browsers that support the WebSockets protocol, the initial connection between the server and browser is made over HTTP and is called an HTTP handshake. Once the initial connection is made, the browser and server open a single ongoing communication channel over a TCP socket. Once the socket connection is established, it enables bidirectional communication between the browser and server. This enables both parties to send and retrieve messages over a single communication channel. This also helps to lower server load, decrease message latency, and unify PUSH communication using a standalone connection.

However, WebSockets still suffer from two major problems. First and foremost is browser compatibility. The WebSockets specification is fairly new, so older browsers don’t support it, and though most modern browsers now implement the protocol, a large group of users are still using these older browsers. The second problem is HTTP proxies, firewalls, and hosting providers. Since WebSockets use a different communication protocol than HTTP, a lot of these intermediaries don’t support it yet and block any socket communication. As it has always been with the Web, developers are left with a fragmentation problem, which can only be solved using an abstraction library that optimizes usability by switching between protocols according to the available resources. Fortunately, a popular library called Socket.io was already developed for this purpose, and it is freely available for the Node.js developer community.

Introducing Socket.io

Created in 2010 by JavaScript developer, Guillermo Rauch, Socket.io aimed to abstract Node.js’ real-time application development. Since then, it has evolved dramatically, released in nine major versions before being broken in its latest version into two different modules: Engine.io and Socket.io.

Previous versions of Socket.io were criticized for being unstable, since they first tried to establish the most advanced connection mechanisms and then fallback to more primitive protocols. This caused serious issues with using Socket.io in production environments and posed a threat to the adoption of Socket.io as a real-time library. To solve this, the Socket.io team redesigned it and wrapped the core functionality in a base module called Engine.io.

The idea behind Engine.io was to create a more stable real-time module, which first opens a long-polling XHR communication and then tries to upgrade the connection to a WebSockets channel. The new version of Socket.io uses the Engine.io module and provides the developer with various features such as events, rooms, and automatic connection recovery, which you would otherwise implement by yourself. In this article’s examples, we will use the new Socket.io 1.0, which is the first version to use the Engine.io module.

Older versions of Socket.io prior to Version 1.0 are not using the new Engine.io module and therefore are much less stable in production environments.

When you include the Socket.io module, it provides you with two objects: a socket server object that is responsible for the server functionality and a socket client object that handles the browser’s functionality. We’ll begin by examining the server object.

The Socket.io server object

The Socket.io server object is where it all begins. You start by requiring the Socket.io module, and then use it to create a new Socket.io server instance that will interact with socket clients. The server object supports both a standalone implementation and the ability to use it in conjunction with the Express framework. The server instance then exposes a set of methods that allow you to manage the Socket.io server operations. Once the server object is initialized, it will also be responsible for serving the socket client JavaScript file for the browser.

A simple implementation of the standalone Socket.io server will look as follows:

var io = require('socket.io')();
io.on('connection', function(socket){ /* ... */ });
io.listen(3000);

This will open a Socket.io over the 3000 port and serve the socket client file at the URL http://localhost:3000/socket.io/socket.io.js. Implementing the Socket.io server in conjunction with an Express application will be a bit different:

var app = require('express')();
var server = require('http').Server(app);
var io = require('socket.io')(server);
io.on('connection', function(socket){ /* ... */ });
server.listen(3000);

This time, you first use the http module of Node.js to create a server and wrap the Express application. The server object is then passed to the Socket.io module and serves both the Express application and the Socket.io server. Once the server is running, it will be available for socket clients to connect. A client trying to establish a connection with the Socket.io server will start by initiating the handshaking process.

Socket.io handshaking

When a client wants to connect the Socket.io server, it will first send a handshake HTTP request. The server will then analyze the request to gather the necessary information for ongoing communication. It will then look for configuration middleware that is registered with the server and execute it before firing the connection event. When the client is successfully connected to the server, the connection event listener is executed, exposing a new socket instance.

Once the handshaking process is over, the client is connected to the server and all communication with it is handled through the socket instance object. For example, handling a client’s disconnection event will be as follows:

var app = require('express')();
var server = require('http').Server(app);
var io = require('socket.io')(server);
io.on('connection', function(socket){
socket.on('disconnect', function() {
   console.log('user has disconnected');
});
});
server.listen(3000);

Notice how the socket.on() method adds an event handler to the disconnection event. Although the disconnection event is a predefined event, this approach works the same for custom events as well, as you will see in the following sections.

While the handshake mechanism is fully automatic, Socket.io does provide you with a way to intercept the handshake process using a configuration middleware.

The Socket.io configuration middleware

Although the Socket.io configuration middleware existed in previous versions, in the new version it is even simpler and allows you to manipulate socket communication before the handshake actually occurs. To create a configuration middleware, you will need to use the server’s use() method, which is very similar to the Express application’s use() method:

var app = require('express')();
var server = require('http').Server(app);
var io = require('socket.io')(server);

io.use(function(socket, next) {
/* ... */
next(null, true);
});

io.on('connection', function(socket){
socket.on('disconnect', function() {
   console.log('user has disconnected');
});
});

server.listen(3000);

As you can see, the io.use() method callback accepts two arguments: the socket object and a next callback. The socket object is the same socket object that will be used for the connection and it holds some connection properties. One important property is the socket.request property, which represents the handshake HTTP request. In the following sections, you will use the handshake request to incorporate the Passport session with the Socket.io connection.

The next argument is a callback method that accepts two arguments: an error object and Boolean value. The next callback tells Socket.io whether or not to proceed with the handshake process, so if you pass an error object or a false value to the next method, Socket.io will not initiate the socket connection. Now that you have a basic understanding of how handshaking works, it is time to discuss the Socket.io client object.

The Socket.io client object

The Socket.io client object is responsible for the implementation of the browser socket communication with the Socket.io server. You start by including the Socket.io client JavaScript file, which is served by the Socket.io server. The Socket.io JavaScript file exposes an io() method that connects to the Socket.io server and creates the client socket object. A simple implementation of the socket client will be as follows:

<script src="/socket.io/socket.io.js"></script>

<script>
var socket = io();
socket.on('connect', function() {
   /* ... */
});
</script>

Notice the default URL for the Socket.io client object. Although this can be altered, you can usually leave it like this and just include the file from the default Socket.io path. Another thing you should notice is that the io() method will automatically try to connect to the default base path when executed with no arguments; however, you can also pass a different server URL as an argument.

As you can see, the socket client is much easier to implement, so we can move on to discuss how Socket.io handles real-time communication using events.

Socket.io events

To handle the communication between the client and the server, Socket.io uses a structure that mimics the WebSockets protocol and fires events messages across the server and client objects. There are two types of events: system events, which indicate the socket connection status, and custom events, which you’ll use to implement your business logic.

The system events on the socket server are as follows:

io.on(‘connection’, …): This is emitted when a new socket is connected
socket.on(‘message’, …): This is emitted when a message is sent using the socket.send() method
socket.on(‘disconnect’, …): This is emitted when the socket is disconnected

The system events on the client are as follows:

socket.io.on(‘open’, …): This is emitted when the socket client opens a connection with the server
socket.io.on(‘connect’, …): This is emitted when the socket client is connected to the server
socket.io.on(‘connect_timeout’, …): This is emitted when the socket client connection with the server is timed out
socket.io.on(‘connect_error’, …): This is emitted when the socket client fails to connect with the server
socket.io.on(‘reconnect_attempt’, …): This is emitted when the socket client tries to reconnect with the server
socket.io.on(‘reconnect’, …): This is emitted when the socket client is reconnected to the server
socket.io.on(‘reconnect_error’, …): This is emitted when the socket client fails to reconnect with the server
socket.io.on(‘reconnect_failed’, …): This is emitted when the socket client fails to reconnect with the server
socket.io.on(‘close’, …): This is emitted when the socket client closes the connection with the server

Handling events

While system events are helping us with connection management, the real magic of Socket.io relies on using custom events. In order to do so, Socket.io exposes two methods, both on the client and server objects. The first method is the on() method, which binds event handlers with events and the second method is the emit() method, which is used to fire events between the server and client objects.

An implementation of the on() method on the socket server is very simple:

var app = require('express')();
var server = require('http').Server(app);
var io = require('socket.io')(server);

io.on('connection', function(socket){
socket.on('customEvent', function(customEventData) {
   /* ... */
});
});

server.listen(3000);

In the preceding code, you bound an event listener to the customEvent event. The event handler is being called when the socket client object emits the customEvent event. Notice how the event handler accepts the customEventData argument that is passed to the event handler from the socket client object.

An implementation of the on() method on the socket client is also straightforward:

<script src="/socket.io/socket.io.js"></script>

<script>
var socket = io();
socket.on('customEvent', function(customEventData) {
   /* ... */
});
</script>

This time the event handler is being called when the socket server emits the customEvent event that sends customEventData to the socket client event handler.

Once you set your event handlers, you can use the emit() method to send events from the socket server to the socket client and vice versa.

Emitting events

On the socket server, the emit() method is used to send events to a single socket client or a group of connected socket clients. The emit() method can be called from the connected socket object, which will send the event to a single socket client, as follows:

io.on('connection', function(socket){
socket.emit('customEvent', customEventData);
});

The emit() method can also be called from the io object, which will send the event to all connected socket clients, as follows:

io.on('connection', function(socket){
io.emit('customEvent', customEventData);
});

Another option is to send the event to all connected socket clients except from the sender using the broadcast property, as shown in the following lines of code:

io.on('connection', function(socket){
socket.broadcast.emit('customEvent', customEventData);
});

On the socket client, things are much simpler. Since the socket client is only connected to the socket server, the emit() method will only send the event to the socket server:

var socket = io();
socket.emit('customEvent', customEventData);

Although these methods allow you to switch between personal and global events, they still lack the ability to send events to a group of connected socket clients. Socket.io offers two options to group sockets together: namespaces and rooms.

Socket.io namespaces

In order to easily control socket management, Socket.io allow developers to split socket connections according to their purpose using namespaces. So instead of creating different socket servers for different connections, you can just use the same server to create different connection endpoints. This means that socket communication can be divided into groups, which will then be handled separately.

Socket.io server namespaces

To create a socket server namespace, you will need to use the socket server of() method that returns a socket namespace. Once you retain the socket namespace, you can just use it the same way you use the socket server object:

var app = require('express')();
var server = require('http').Server(app);
var io = require('socket.io')(server);

io.of('/someNamespace').on('connection', function(socket){
socket.on('customEvent', function(customEventData) {
   /* ... */
});
});

io.of('/someOtherNamespace').on('connection', function(socket){
socket.on('customEvent', function(customEventData) {
   /* ... */
});
});

server.listen(3000);

In fact, when you use the io object, Socket.io actually uses a default empty namespace as follows:

io.on('connection', function(socket){
/* ... */
});

The preceding lines of code are actually equivalent to this:

io.of('').on('connection', function(socket){
/* ... */
});

Socket.io client namespaces

On the socket client, the implementation is a little different:

<script src="/socket.io/socket.io.js"></script>

<script>
var someSocket = io('/someNamespace');
someSocket.on('customEvent', function(customEventData) {
   /* ... */
});

var someOtherSocket = io('/someOtherNamespace');
someOtherSocket.on('customEvent', function(customEventData) {
   /* ... */
});
</script>

As you can see, you can use multiple namespaces on the same application without much effort. However, once sockets are connected to different namespaces, you will not be able to send an event to all these namespaces at once. This means that namespaces are not very good for a more dynamic grouping logic. For this purpose, Socket.io offers a different feature called rooms.

Socket.io rooms

Socket.io rooms allow you to partition connected sockets into different groups in a dynamic way. Connected sockets can join and leave rooms, and Socket.io provides you with a clean interface to manage rooms and emit events to the subset of sockets in a room. The rooms functionality is handled solely on the socket server but can easily be exposed to the socket client.

Joining and leaving rooms

Joining a room is handled using the socket join() method, while leaving a room is handled using the leave() method. So, a simple subscription mechanism can be implemented as follows:

io.on('connection', function(socket) {
   socket.on('join', function(roomData) {
       socket.join(roomData.roomName);
   })

   socket.on('leave', function(roomData) {
       socket.leave(roomData.roomName);
   })
});

Notice that the join() and leave() methods both take the room name as the first argument.

Emitting events to rooms

To emit events to all the sockets in a room, you will need to use the in() method. So, emitting an event to all socket clients who joined a room is quite simple and can be achieved with the help of the following code snippets:

io.on('connection', function(socket){
   io.in('someRoom').emit('customEvent', customEventData);
});

Another option is to send the event to all connected socket clients in a room except the sender by using the broadcast property and the to() method:

io.on('connection', function(socket){
   socket.broadcast.to('someRoom').emit('customEvent', customEventData);
});

This pretty much covers the simple yet powerful room functionality of Socket.io. In the next section, you will learn how implement Socket.io in your MEAN application, and more importantly, how to use the Passport session to identify users in the Socket.io session.

While we covered most of Socket.io features, you can learn more about Socket.io by visiting the official project page at https://socket.io.

Summary

In this article, you learned how the Socket.io module works. You went over the key features of Socket.io and learned how the server and client communicate. You configured your Socket.io server and learned how to integrate it with your Express application. You also used the Socket.io handshake configuration to integrate the Passport session. In the end, you built a fully functional chat example and learned how to wrap the Socket.io client with an AngularJS service.

Resources for Article:

Further resources on this subject: