With the advent of the WebSocket protocol, we can finally push data from the server to the browser. I went over the fine details of the protocol in my last blog so I won’t go over them again here. To sum up, the protocol allows a browser to maintain a secure bi-directional connection with the server so they can talk back and forth without initiating new requests and passing new headers. This is great! Let’s go ahead and use WebSockets to send a message to a browser.
Two (big) problems:
1. This is going to take a lot of dev time to implement. Sure, browsers can support the protocol, but now we have to code the server side. This is somewhat low level stuff that involves making the initial handshake according to the protocol, managing the multiple socket connections, accepting incoming messages, sending outgoing messages, closing connections, etc. This can be a hard sell to get dev time for as it’s not necessarily a top priority.
2. Not all browsers support it. More importantly, even when the latest browsers do all support it, we really can’t tell all our users to upgrade just so we can take advantage of this cool new technology.
ASP.NET 4.5 WebSocket Support
The NuGet Microsoft.WebSockets library, sitting on top of System.Net.WebSockets, takes care of all the work required to manage WebSocket connections server side! There is a class called WebSocketHandler which you can inherit and easily override methods like OnOpen, OnClose, and OnMessage to handle requests. Clients are stored in a WebSocketCollection and completely managed. You need to do little more than inherit this class. Also, you do need to run .NET 4.5 on IIS8 with the WebSocket feature enabled. I am not including sample code for this because there are already a few excellent articles out there. You can learn all about it by watching Paul Batum’s wonderfully informative presentation and following his step by step instructions here:
So problem # 1 is solved as soon as we upgrade to Windows 8. But what about problem #2, our users on old browsers that don’t support the protocol. And what if we’re not on Windows 8 yet. In terms of old browsers, generally the approach is to fallback to long polling when WebSockets are not supported. OK, we can long poll. But now we need to write a whole bunch of code to manage this.
This is how you do it:
Taking it further with WebHooks
To take this a step further, the browser can respond to something that happens on a remote system by being a consumer of a WebHook. A WebHook provider is some system that will post data to a callback url you supply when something happens that you want to know about. As a WebHook consumer, upon receiving this data on your server, you can use SignalR to let the browser know.
In my sample app, there are two web applications called “RemoteServer” and “MySocketApp”. The “RemoteServer” application acts as a WebHook provider. When something happens on this server, it will tell all of the subscribed WebHook clients by sending an HTTP post request to the callback urls supplied by the these clients. “MySocketApp” acts as a client and has a WCF service which serves as a callback url to listen for any data sent by the “RemoteServer” app. When this service receives some data, it will use SignalR to alert the browser of the new data it received. So now the browser gets a message when something happened on some remote server. I will not go into details about the WebHook implementation as it is discussed in detail here.
I created a poor quality screen cast so you know it works without opening the sln. Sorry, it is much more fun to play with the actual app and I will try to put one online. The video demonstrates FireFox, IE, and Chrome all responding to an event from a “RemoteServer” by showing an alert on the screen. http://vimeo.com/39857434.
The solution contains two web projects, RemoteServer and MySocketApp.
To run the projects, run MySocketApp’s default.html in a browser. Then run RemoteServer’s CreateEvent.html in a browser. Enter some text into the form on this CreateEvent page. The text you enter will be posted to a callback url on MySocketApp. The callback url will use SignalR to then send this data to the browser and display it on the screen. You will see your text appear in the browser running MySocketApp’s default.html.
Note: This sample does not rely on Microsoft.WebSockets and can be ran in older versions of Windows. For it to use Microsoft.WebSockets on Windows 8, we need to install SignalR.WebSockets and we can not use Express IIS. More Info
The issues of performance, server load, and how well signalR will scale are critical to consider when implementing WebSockets.
SignalR Hubs QuickStart ( Basically sums up my entire article )
Performance Tuning SignalR
Paul Batum’s Samples and Presentation