Using HTML5 WebSockets
Friday 11 November 2011
In previous blog posts I wrote about using Server-Sent Events so send data from the server to the browser. This works but has the drawback that it is a one way messaging from the server to the browser. There is nothing preventing you from doing ajax style calls back to the server but basically you are using 2 connection. The big plus for Server-Sent Events is that is use standard HTTP connections so the infrastructure is no problem.
Sometimes you want more flexibility of duplex communication and this is where WebSockets come in. Opening a connection from the browser is simply a question of instantiating a WebSocket object and passing in the required URL. The difference is this time we are not using HTTP but the WS scheme so the connection URL looks something like ws://api.myserver.com/chatService. Sounds simple enough but as WebSockets are relatively new you do run a very real risk that some of the infrastructure that works fine with HTTP request will not work with WS requests. But for a demo on a local machine that is no problem
The client code
The code on the client is actually quite simple. First we new up the WebSocket and we start listening for onmessage events. There are a few more events that are interesting:
- The onopen event fires when the connection is opened
- The onclose event fires when the connection is closed
- The onerror event that fires when something goes wrong.
To send data you use the send() method that takes a single string to send to the server. Hint: Use JSON.stringify() to turn you rich object into a string.
I wrote a very simple chat client to demonstrate how to work with WebSockets.
Not bad right
One thing to note is the way I create the WebSocket object:
I am using the expression WebSocket || MozWebSocket because support for WebSockets is still very experimental and FireFox still uses the Moz prefix. See CanIUse.com for more details about browser support.
The server part.
With Server-Sent Events the server part was easy and standard web stuff because we are just using HTTP. With WebSockets this is no longer the case as we are using a socket style connection using the WS scheme. So we need some extra support on the server. As I am doing .NET I want a .NET 4 solution on the server, there are several other non .NET solutions as well. If we search NuGet we see there are thee different WebSocket packages. One is part of WCF 4.5 and an other, SignalR.WebSockets, that is build on top of it. Now SignalR is an awesome product but as this requires .NET 4.5 and this isn’t released yet I am going with the third option, Fleck, which does run on .NET 4 as is.
Fleck is pretty easy to use, just new up an WebSocketServer with the URL to start listening and it has pretty much the same interface as the WebSocket on the client. Whenever a client connects the OnOpen is called and when a message is received the OnMessage callback fires. My ASP.NET MVC home controller looks like this:
Again pretty simple to use
Of course real life isn’t quite as simple as this demo. For one you are now using a direct connection between the browser and one of your servers so any form of load balancing is out of the question here. And as this is real new its quite likely that you will run into routers, proxy severs or the like that don’t support WebSockets. If you really need this functionality now looking at a package as SignalR which makes all of this a lot more reliable makes sense. And the standard SignalR package will work just fine on existing .NET 4