ASP.Net SignalR library builds apps that can communicate in real-time

SignalR is an open source library written in .Net that can provide “real-time” functionality to your Web applications. It simplifies the exchange of data between a Web browser and a Web server using WebSockets as a communication protocol, and it supports broadcasting functionality and can be used to build Web applications that can communicate with the connected clients. SignalR contains an ASP.Net server library and also a JavaScript client library that can be used to push notifications and updates to the clients.

SignalR doesn’t leverage the request-response model to establish communications between the server and the client. Rather, it makes use of Remote Procedure Call (RPC) to enable the server-side application to notify the Web browser at the client side with updates and notifications. Note that you don’t necessarily need ASP.Net to host SignalR — it can be self-hosted or hosted using Open Web Interface for .Net (OWIN).

Why SignalR?

In real time applications, the client needs to send a request to receive updates. In such a typical request – response model, the client isn’t aware of these updates unless a request is sent to the server. Although you can use continuous polling, long polling, etc., these would incur a lot of overhead on the server as the load on the Web server would increase. Hence, these methodologies are not recommended. The alternate approach that you can adopt to enable the server notify the connected clients with the updates is in using a mechanism in which the server can broadcast messages to the connected clients.

To achieve this, you can leverage either Web Sockets or Server Sent Events (SSE). Web sockets provide support for asynchronous full duplex communication using the HTTP protocol. However, both of these technologies have their downsides — they work only on browsers that have support for HTML5. A Web socket is a TCP socket connection between the client and the server over a network. Essentially, a Web socket is a two-ay full duplex communication between the client and the server over a network. Note that not all browsers support web sockets. Here is where SignalR comes in — it uses HTML5 if the target browser is compatible with HTML5. If the target browser doesn’t support HTML5, it uses other techniques. The ASP.Net SignalR framework uses Web sockets internally to connect to the server if IIS and the Web browser have support for Web sockets; it switches to a long polling strategy otherwise. The SignalR API provides support for “server push” or “broadcasting functionality” and handles connection management automatically.

Unlike Web sockets, when you are using SignalR you need not be concerned about serialization and deserialization of data, connection management, processing of the messages, etc. — most of the underlying complexity is abstracted from you. This makes working with SignalR easy and comfortable.

SignalR components

SignalR is just an abstraction over a TCP connection and its two major components: hubs and persistent connections. This abstraction over the underlying communication protocol and support for both Web sockets and long polling are some of its great features.

The built-in transports in SignalR include the following:

1. WebSockets
2. ServerSent Events
3. Forever Frame
4. Long Polling

Note that SignalR is designed so that it can select the best connection supported by the server and the client and use it accordingly.

The Hubs API in SignalR facilitates Remote Procedure Calls (RPC) seamlessly. It helps you to make RPC calls from the server to the clients that are connected to it. All you need to do is define methods in the server that the clients can invoke. In the client side you should also define methods that can be invoked by the server. The internal intricacies and client-to-server plumbing would be taken care of by the SignalR framework. In computer networking, a hub is defined as a networking device that can be used to connect multiple Ethernet devices together. In SignalR a hub provides support for multicast functionaly over a Web socket connection. When a connected client sends a message to the hub, this message in turn gets broadcasted to all the clients connected to the hub.

Although the Hubs API is preferred over PersistentConnections, you can use PersistentConnections when you need to work with SignalR at a low level — if you need more control over the connection in SignalR. Unlike PersistentConnections, the Hubs API enables you to pass strongly typed paramaters to methods when using SignalR. Also, the Hubs API in SignalR provides a high level abstraction for managing connection.