SignalR: What is happening under the hood (Part 1)

SignalR provides us the possibility of real time, two way communication between the browser (or any other client) and our server. There are many possibilities on what can you do with this technology, many advantages that you can use, I don’t want to be too wide in one article so I plan to write three of them starting with this one. Here I want to write more about SignalR, what is happening under the hood  and describe some of the main components when building a system on top of it. But what is theory without practice?


That is why, in the second article, I’m going to make sample demo on how to implement SingnalR in your Web API 2 server and also make sample client that will communicate with that server.
In the third part I plan to demonstrate how you can use SignalR on a self hosted server using the OWIN/Katana middle wear, the plan is to use the same client.

Before going deeper on what SignalR is, how to set up and how to use it, first we must understand Web Sockets and how they work, because Web Sockets are the backbone (when available) to SignalR.

What are Web Sockets and how to use them

In the classic web communication everything is based on request and response. If we want something we send the appropriate request and get back the response with the results. With using Web Sockets we can establish two way, TCP connection between the client and the server. So the client can send data to the server and the server can send data to the client.

The messages don’t contain headers and extra data as the classic request would do, so the communication is fast and lightweight. Some examples on where is appropriate to use web sockets is a chat application, stocks application or any other application that requires real time data.

Creating a web socket communication is very simple, this is basic example how using Web Sockets could look like:


Note that the web socket server uri starts with ws.

Why do we need SignalR when we have Web Sockets

Using Web Sockets has it own downsides when operating at low level. They are not supported by all web browsers, so you need to handle that somehow


Also you need to take care of serializing/deserializing the data that you send and receive, you need to manage the socket connections etc.

So here is where SignalR comes in play, with SignalR you don’t need to take care of older browsers support – that is automatically handled and you don’t need to care about connection management and serialization.

How is SignalR handling connections

Web Sockets are the most efficient way of communication in terms of overhead of memory and CPU consumption. But as we said, Web Sockets are not always supported by the client or/and by the server. If that is the case SignalR can try to sent information via Server Sent Events (SSE) which is HTML5 API that allows the server to push data to the client via HTTP request. This is not efficient as Web Sockets but out system will work in environments where Web Sockets are not supported. If SSE is also not supported, SignalR can try to establish the communication with Forever Frame, this means that the client will create hidden iFrame in the browser and hold the communication open.
So what if that is not an option as well, again SignalR has another card in it sleeve and this time is Long Polling which means that additional request will be sent to the server for retrieving the data.


If you are using IIS have in mind that Web Sockets are supported in version IIS 8 and above and also that support applies to IIS Express.

How the communication is set up between the client and the server

Before going into details and show you how to implement these, let’s see how the communication is build on the server and on the client side. First think you need to do is to add this nuget package to your project

Install-Package Microsoft.AspNet.SignalR

On the server side you’ll have one or more hubs, where Hub is a class provided by SignalR to abstract the underline connections. On the client side you’ll connect to the server using a SignalR plugin for jQuery.

After the connection is established, the server can invoke methods that are mapped to java script methods on the client, and the client can send messages to the server by invoking methods from the client API that are mapped to methods on the server.

This is brief introduction on SignalR and how it’s working, in the next two articles you’ll get more familiar with the actual building of SignalR based systems by using it in your Web API server or run it on self hosted application.

Until then – Happy Coding,



2 thoughts on “SignalR: What is happening under the hood (Part 1)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

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

Google photo

You are commenting using your Google 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 )

Connecting to %s