Microsoft’s latest technology for creating Web Services–SignalR–addresses an interesting problem in creating modern applications: two-way communication. The whole point of Web Services is that the server “knows” something that the client does not. To get that information the client calls the service to get that information. However, in a volatile environment (where data on the server frequently changes) with a long running client (where the client stays connected to the server while that volatile data changes) and critical information (the client wants to stay up-to-date with the server’s changes) it may be necessary for the client to be updated as data changes on the server. With the original design of Web Services that was only possible through “long polling”: the client keeps calling the service to ask “Has anything changed?” That’s terrifically inefficient in two ways: Either the client waits a long time between checking so that, when the client does get the information, the data is stale and/or out-of-date; The client checks frequently so that the server is battered with requests when, most time, nothing has changed. The right answer is to have the server call the client when something changes. The trick is to find an interoperable, industry standard way to do that.
There are a couple of HTML5 solutions to this problem that stay interoperable: using server-side events or WebSockets, for instance. But the problem with HTML5 is that not all modern browsers support all of the various HTML5 specs…and, anyway, not all users are using modern browsers. SignalR provides a single interface for letting the server call the client and does that by concealing from the developer how this magic is achieved: SignalR will use WebSockets if the browser supports it but (in the absence of WebSockets) will revert to other technologies, including long polling if necessary.
And, before I go any further, I should point out that SignalR is still only in “release candidate” mode. It’s possible that Microsoft might never release a final version of this technology (as happened with Upshot) or, better yet, might roll this into some other technology (the ASP.NET Web API would be my choice, as covered in Learning Tree’s 2601 course, Introduction to WCF and Web API Services).
The first step is to use NuGet to add the SignalR package to your project. Since this is pre-release software you’ll need, in the NuGet Manager dialog, to set the top-left dropdown list to “Include Prerelease.” After adding the “Microsoft ASP.NET SignalR” package, you’ll also need to add the JSON2 package. Since SignalR is implemented as a jQuery add-in you’ll need ensure that you have some version of the jQuery library in your project.
The following code defines a method (which I’ve called ReceiveMessage) in a hub (called MessageHub) that clients can call to send a message to all other clients. The method then calls a function (called acceptMessage) on all the all connected clients (since this method name is one you define, you won’t get any IntelliSense support when you type the function name in):
Imports System Imports System.Web Imports Microsoft.AspNet.SignalR Public Class MessageHub Inherits Hub Public Sub ReceiveMessage(Message As String) Me.Clients.All.acceptMessage(Message) End Sub End Class
To get messages routed to the hubs in your application, you need to register your hubs with SignalR. That requires a single line in your Application_Start method in your Global.asax file (for ASP.NET) or wherever you define your routing rules (in ASP.NET MVC). You’ll need to add an imports statement for System.Web.Routing to make this code work:
Sub Application_Start(ByVal sender As Object, ByVal e As EventArgs) RouteTable.Routes.MapHubs() End Sub