What, Why and How About SignalR

What is SignalR

We know very well how a client sends data to a server so now it's time to understand how a server pushes data to a client in a HTTP connection. SignalR is an open source library to add real-time web functionality in your ASP.Net web application. So what does real-time functionality mean? Just use as an example when more than 1 user is working on the same document in Google Documents When a user is making changes and at the same time another user can see the changes without reloading the page. So real-time web functionality is the ability to have server code to push content to connected clients. In the HTTP request response model we know each time we need to send a new request to communicate with the server but SignalR provides a persistent connection between the client and server.

It can be easily scaled out via SQL Server, Redis or a service bus (scale out means adding more servers to handle the load). There is no need to worry about this scale out term, in my next article I will explain it in detail because SignalR provides good scale out features. SignalR uses Web socket technology to send data. WebSocket is a new HTML5 API that enables bidirectional communication between the browser and server but if it is not available then SignalR can use other technologies like long polling.

SignalR transfers data in non-compressed JSON text or plain text so if you want to send data in compressed JSON then you need to write your own logic on the server side and the same logic on the client side also. SingnalR makes extensive use of asynchronous techniques to achieve immediate and maximum performance.

Modes of communication

SignalR provides two models for communicate between clients and severs.

1. Persistent Connections

Persistent Connections provide direct access to a low-level communication protocol that signalR provides. Each client connection to a server is identified by a connectionID. So in your application if you need more control over a connection, in SingnalR you can use this model. This midel can be used where you want to work with a messaging and dispatching model rather than remote invocation or in any existing application using a message model and you want to port to signalR.

2. Hubs

Hubs provide a High level API for the client and server to call each other's method. It will be very familiar to those developers who have worked on remote invocation APIs. If you have multiple types of messages that you want to send between a server and a client then it is recommended to use Hubs so you don't need to do your own dispatching. You can create an application either using Hubs or a Persistent connection; the only concern is, with Hubs it will be easy to implement.





So now we have an idea of what SignalR is so now it's time to proceed to "why".

WHY use SignalR

Using SignalR we can create web applications that require high frequency updates from the server. For examle, a dashboard, games and chat applications. SignalR uses Web Sockets and the HTML5 API that helps in bidirectional communication. It also provides an API for server-to-client Remote Procedure Calls (RPC) call, it may be something new for you because most of the time we use a request and response model.

SignalR includes automatic connection management, it provides the facility to broadcast messages to all connected clients or to a specific client. The connection between the client and server is persistent while in HTTP it isn't persistent.

So now where to use SignalR:

1. Notification: If you want to notify 1 client or all clients then we can use SignalR. Notification can be like some alerts, a reminder, feedback or comments and so on.
    
2. Chat: It is very easy to implement a chat application using SignalR, either it could be one-to one or a group chat.
    
3. Gaming: SignalR helps to create a Gaming application that requires frequently pushing from a server and so on.

HOW use SignalR

Here I am not going to directly jump into code. I will first explain how a Remote Procedure Call (RPC) happens.

Let's assume that on the server side we have a method named MyServerFunction() so if we want to call that method from a client you can call it using "$.connection.myHub.server.MyServerFunction()" and suppose we have a JavaScript function named "myClientFunction()" and we want to call that method from the server so we can call that using "Client.Client(id). myClientFunction()".

I know many of you are thinking, what are this connection, hub and server keywords. So please be patient, very shortly I will explain all these when I will explain both modes (persistent and hubs) in details.

See the following diagram for a better understanding.




As you can see, during the RPC using SignalR the hub will be at the server side and the client will have a hub proxy. When the proxy object wants to call a real method of the server, the object implements Ajax style calls to the real method. Whereas when the server wants to invoke the client method , it is resolved using dynamic types and a special protocol that packages these calls to the server.

When an application has a SignalR connection and it wants to send some data to the server, the data is not sent in a raw form, SignalR wraps that data in JSON with other information and wraps it all on the JOSON payload before sending to the server.

I think we have explained many concepts about SignalR. I know many of you are feeling bored but don't worry, in my next article I will have with all the coding and implementation about SignalR. I wrote this article because I didn't find any article on SignalR that can explain all concepts and how SignalR works. Thanks for reading and be ready for the next article.