A playful look at WebSockets – with the help of the XSockets library

What’s the best way to spend a friday night to saturday afternoon, in the city of Sundsvall, Sweden? What about coding some WebSockets together with others like minded (+ having one or two sponsored beers)? In the end of september team XSockets and XLent hosted such an event and I was happy to be able to join.

For me it was the first real experience of WebSockets coding, and in this blog post I’ll write a few words about it (so there – my usual “I’m a noob-disclaimer”).

WebSockets (and the WebSockets API) is currently in an evolving phase, and as such it has varying support in the different web browsers. It’s quite a lot of work to use it directly with cross-browser support for real time applications. Therefore many look for helping libraries, actively maintained by people following the ongoing development of WebSockets and with fallback support for non-websockets-supporting browsers. XSockets is such a library. It is under active development, has support for several WebSockets protocol versions and it has fallback support that works in most browsers, with the help of Flash or Silverlight plugins.

Setting up an XSockets Visual Studio solution is easy with the help of the XSockets Nuget package. The recommended way to start playing [link to video]see also this walkthrough is to 1) create an empty MVC3-application, then 2) type Install-package XSockets in the package manager. The Nuget installs a XSockets server project, a custom handler project, and a samples web project with a few samples. To have a go – 3) right click the server and run it. Then 4) open a Sample project html page also by right clicking, and browse open the file – preferrably in Chrome.

The parts of an XSockets solution

For a XSockets solution to run you will need the following.

  • A websockets server. A .Net Windows command line application or a service. Configured to serve websockets communication on a specified port (for example 4502). The easiest way to get a server up and running is simply by installing the Nuget (se above).
  • Client side code. For example js code using the jxsockets client side libray – best if they are running on WebSockets enabled browsers like Chrome, or Safari.

The clients all communicate with the server, there’s no direct peer-to-peer communication. However, the server can of course maintain a communication between two individual clients.

Here is an example of how an XSockets (and WebSockets) communication sequence can look like:

1. Client A creates a jXSockets instance, responsible to handle WebSockets communication with a running XSockets server.

var ws = jXSockets.xWebSocket('http://myserver.com:4502/XSockets.Core.Handlers.Generic, jXSockets.WEBSOCKET);

2. The server establishes and opens the connection and the event “open” is triggered. The client can now start listen to and trigger own events.

ws.bind("open", function() { $('#status').text('<p>Connection open</p>');} );

3. Client B does the same. Now the server has two open connections. Each client is represented by a guid on serverside, and messages (as events) can easily be sent to all clients or a selection of clients.

4. Client A triggers a “OnChatMessage” event with the data “Hello WebSockets” and “John Doe”.

// Create a WebSocketMessage 
var myMessage = new $$.WebSocketMessage("OnChatMessage");
myMessage.AddJson({Text: "Hello WebSockets",UserName:"John Doe");
//  Send the message using the .trigger(WebSocketMessage) method 

5. The server’s generic event handler is configured to listen to all events and broadcasts the event directly to all other clients.

6. If Client B has a binding to the “OnChatMessage” event it will get the “Hello World!” data and can for example display it on a web page.

// Event handler for the WebSocket event named OnChatMessage, where the WebSocket instance is named ws
ws.bind("OnChatMessage",function(message) {
 $('#message').append('<p>' + message.Text + ' from ' + message.UserName + '</p>');

7. More messages is being sent between the clients and the server.

8. The connections stays open until they are actively closed. This means that the need for overhead is minimal, which in turn means it’s very efficient to send a lot of data back and forth compared to the traditional http request / response method which has a lot of overhead.

We can also bind to the close event if we like

ws.bind("close", function() { $('#status').text('<p>Connection closed</p>');} );

More server side

The generic handler is best for demo usage, and not really (?) meant for real applications. But it’s very easy to build a custom handler which can be setup to handle the communication however you like.


A really fun part – and the part that was given the most time – of the CodeCamp was where we participants was given the task to code real XSockets applications, which should be demo’ed at the end of the camp. It resulted in really cool apps, most of which had a entertainment/game theme, but there were also real business/industry ‘real-time-dashboard’ like applications.

Here’s a short video of my contribution.

In all, the CodeCamp proved to me that WebSockets is a technique that has an important place in the modern web, and XSockets is a well engineered and easy-to-use library for WebSockets solutions.

2 thoughts on “A playful look at WebSockets – with the help of the XSockets library

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s