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:
- 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.
- Chat: It is very easy to implement a chat application using SignalR, either it could be one-to one or a group chat.
- 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.