Building asynchronous real time apps with bidirectional communication has traditionally been a very difficult thing to do. HTTP was originally designed to speak in terms of requests and responses, long before concepts of rich media, social integration, and real time communication were considered staples of modern web development. Over the years, various solutions have been hacked together to solve this problem. You can use plugins like flash or silverlight to make a true socket connection on your behalf - but not all clients support plugins. You can use long polling to manage multiple connections via HTTP - but this can be tricky to implement, and can eat up system resources. The Web Socket standard promises to give web developers a first class socket connection, but browser support is spotty and inconsistent.
Various tools across multiple stacks have been release to solve this problem, but in this post I would like to talk about the first real asynchronous client/server package for ASP.NET: SignalR. SignalR allows .NET developers to change the way we think about client/server messaging: instead of worrying about implementation details of web sockets, we can focus on the way communication flows across the various components of our applications.
This sounds familiar: socket.io with node.js
Node.js and socket.io paved the way for a series of new tools and frameworks across multiple stacks that enable developers to have a first class client/server messaging experience. Node.js and socket.io are wonderful tools - but let’s get back to focusing on SignalR.
Two ways to build apps with SignalR
There are two ways you can go about setting up the server for SignalR. If you want a low level experience, you can add a ‘PersistentConnection’ class along with a custom route. This will give you basic messaging capabilities, suitable for many apps. Straight from the SignalR github, here is an example:
This works well if you’re dealing with simple messaging - the other model SignalR supports is the ‘hub’ model. This is where things start to get interesting. Using hubs, you can invoke client side functions from the server, and server side functions from the client. Here’s another example from the documentation:
Here is the server:
And the client:
I chose the high level API, because well… it’s just cool. For a wonderful break down of the differences between these two methods, check out Scott Hanselman’s post on the topic.
Lets build something!
One of the common examples of using these frameworks is a chat room: it has all of the touch points that are otherwise difficult to implement. How do we know when someone joins the room? What about sending a message? What if I want to send a message to multiple people? This is a perfect example of how client/server messaging over the web can make our lives easier. The SignalR folks have a live sample of this application running on their demo site. With the chat idea done, I decided to combine two tools into one project: a user map. I want to maintain a map that uses a pushpin for every user on the page. As users come, a new pushpin will be added in their location in real time. As they leave, the pushpin will be removed. Before we dive into the code, check out the demo at http://signalrmap.apphb.com/. If no one is in the room, you can slightly randomize your position by using the “random flag” at http://signalrmap.apphb.com/?random=true. This will allow you to use multiple browser windows and watch the system add location push pins.
Building the client
After including our scripts, connecting to a hub is crazy awesome easy:
There are a few things going on here. First, we reference our connection to the hub created on the server (note: the connection has not been established yet). Notice the mapHub.addClient method - this method will be exposed in a way such that it can be invoked from the server. scratches head - this is a neat concept. After defining methods which can be invoked from the server, we start the connection to the hub. Once the connection is established, we get the browser’s current location, and send that location back to the server. That’s about it. Remember how simple it was to use socket.io? Here we have the same experience. There’s a little more client script here to handle managing the map component. For the full client source for the application, check out my github.
Server side code
As mentioned above, I chose to take the ‘hubs’ route for my application. One of the nice things about using a hub is that it doesn’t require any custom routing - just create a class that extends ‘Hub’, and you’re set. In this example, I’m storing a persistent list of the clients connected to the application (obviously, this method will only work with a single web server). As users show up at the site, they send their current position to the server. The new MapClient is broadcasted to all of the connected clients, and the new client is given the master list of clients:
And that’s it! SignalR figured out what types of communication my browser supports, managed the tunnel, and just made the connection work. Enjoy!