Understanding SignalR

I need my data and I need it now !!! Isn't it what you think while on any web site or any application these days. Everyone working with some sort of IT system being a Website/Application/ConsoleApp, they all demand real time updates on their data. With modern mobile platforms and Push services, applications are becoming almost real time and more engaging. Instead of users asking for the data, data gets delivered to them as soon as back end services receive them. But but.. what about our old friends web sites and web applications ? How do they keep up with this demand of real time updates ?

Being a web programmer so long, the first thing that crosses your mind is "AJAX". You say it's easy, what are you talking about. Just setup a JavaScript function that polls server every 2 seconds and gets the update. I agree, that's easy but at what cost ?

• Every request takes up some CPU cycles from client's machine and from Server.

• Imagine this being done by 10,000 users at the same time and only 2000 of them had any real updates. Those 8000 calls are a waste.

• Imagine the network traffic being generated by these requests. On top of those whatever session management information you are passing back and forth(e.g. cookie) with every request and response.

• And the top of all, if client needs the update he has to earn it by making an explicit request to the server. There is no way for server to pass information to the client as soon it has it.

And that is why SignalR was created. SignalR will solve the problems listed above and provide a robust infrastructure of near-real time communication.

What was before SignalR

Before we jump into details of SignalR, let's see what web developers have been using for near-real time communication prior to SignalR.

• AJAX Long polling
• Forever Frames (IE Only)
• Server Sent Events (SSE)
• WebSocket

AJAX Long polling As the name suggests, client creates an AJAX request which stays open until server responds. After that client creates next brand new request which stays open until the response is received.

Forever Frames The idea is to create a hidden IFrame which makes requests to server endpoint. This request does not complete and so server keeps sending chunk of JavaScript snippet to the client. Again this is a one way communication from Server to client.

Next two options are features introduced as part of HTML5 specifications.

Server Sent Events In this protocol the web page receives updates automatically. You can explore this more at W3Schools. This was possible before too, but clients had to explicitly ask for the data.

WebSocket If the server and client both are capable of communicating over this protocol, this is the most persistent two way full duplex communication channel between client and server in web applications. Again, this is pretty new and only the latest versions of all browsers supports this.

Okey, so these are different options you have as a web developer when you have been tasked to implement real-time communication in your web application. now imagine that you have to implement such real-time communication feature in your application. In order to make that application cross browser compatible you will have to consider all of the above options and fallback on one after the other if a specific feature is not supported by a specific client.

This is exactly where SignalR saves you a ton of time. You can think of SignalR as a wrapper around all of these different protocols. So as a developer you will not have to handle fallback scenarios on your own. You just create a simple SignalR HUB, and it will do the rest. While your application is running, it will negotiate a suitable protocol with the client automatically.

To demonstrate the negotiation, I have captured few screen shots of a simple Chant SignalR hub (We will be building this in the next blog post).

First latest version of Firefox tried connecting to the HUB and following was the negotiation sequence.

The full details of the second request which actually establishes a WebSocket connection is as following.

Now, let's try connecting the IE 9 to the same SignalR HUB and you will see that the protocol IE9 and Hub negotiated is foreverFrame.

In the future blog posts we will see how to create these types of SignlaR Hub in a step by step process.