An increasing number of software out there namely web sites and web applications today offer or need to offer real-time data, they want to have up-to-date data delivered to any device and to any application over any network and any connection. Whether application is based on a browser and a website or a web application, or whether that's just a WPF or Silverlight, or a Windows store application, it doesn't matter a lot. An increasing number of collaborative apps and collaboration solutions running in the web browser but also running on mobile devices as well. So to cater these needs a robust framework is needed.
There are various approaches for realizing this with HTTP. The most well-knowns are maybe the polling approaches so whether it's Periodic Polling which means every 10 seconds, this gets tedious and it's quite heavy as it uses up a lot of resources especially on the server-side.
Long Polling, also known as HTTP Streaming. Long Polling is a little bit more intelligent. The client opens up a connection to the server polls but the server doesn't respond until there is some real data. Usually, you have a default time-out and based on the default time-out, the server waits or the connection is kept open until some data or some event happens on the server-side, inside of the Push Service and that it does send over back on the HTTP response to the client/clients. It's still using a lot of connections and a lot of resources like threads on the server.
Forever Frame approach. The Forever Frame approach has been in place for quite some time. A hidden iFrame in your web page keeps the connection alive for communication. So as the name suggest the iFrame lasts forever.
SSE or Server Sent Event Technology is a part of HTML5 Specification. SSE is actually has its own protocol and standard of pushing data based on HTTP connection, so it's still all based on the original HTTP but with some more background work on Server or Client side.
Web Sockets is the way to go, it’s so easy to do but it turns out that, if you do it in the real world, there may be some issues and some obstacles like which server-side framework or server-side platform can be used to offer Web Sockets. Within the Microsoft family Web Socket support is only available beginning with Windows 8 or Server 2012, together with IIS and the new HTTP assist. Another issue may be some network obstacles and considerations that you have to make when it comes to proxy servers or to firewalls or any other intermediaries in the way between the clients and the server that may just block Web Sockets communication. Web Sockets is actually a socket. So the protocol of Web Sockets says that it is extending HTTP.
If we need to have the ability to try out Web Sockets and if it does not work then fallback on Server-Sent Events, and if that is also not supported then use Forever Frame. If forever frame is also not supported then fallback and use Long Polling, it would be very nice to have such framework.
SignalR is such a framework for building real-time applications in .net. SignalR takes advantage of Web Socket and all above based approaches based on the support. SignalR takes advantage of several transports, automatically selecting the best available transport given the client's and server's best available transport.
It is an HTML5 API that enables bi-directional communication between the browser and server. SignalR uses WebSockets based on its availability, if it is not available on particular client it goes on to other techniques and technologies without the developer modifying the code. It can be hosted inside an asp.net application on IIS. Also we can just host it in and use it and expose it in any arbitrary .net process. It can be used to push real time or near real-time data from the server, to push data from the back end into the end user's applications and the end user's devices.
ASP.Net and SignalR -- Demo
Let us create a simple ASP.NET MVC Chat Application to see SignalR in action.
To add SignalR to the project, we need to launch the package manager console and install package, Microsoft.aspnet.signalr. And that will bring in a number of dependencies. It also opens up a readme file in the editor and we can see that in order for SignalR for to run we need some OWIN middleware. So we can simply call the method from a simple Start up class of the project.
Here is the code :
public class Startup
public void Configuration(IAppBuilder app)
Once SignalR NuGet package is added, both server and client-side components there to use. On the server side we need to create one or more hubs where hub is a class provided by SignalR to abstract away the underlying connections. To add a hub class we need to select the "SignalR Hub Class" template from Visual Studio, Add New Item Dialog.
Here is the code for the same:
public class ChatHub : Hub
public void Send(string message)
Context.User.Identity.Name + " says " + message
On the client side, we connect to a hub, using a SignalR plugin for jQuery, so jQuery is required. To use SignalR in the view we need to use the jquery.signalr script reference. Here is the code:
Now let us see the code for the View. Here is how the view file will look.