Building real-time applications isn’t easy. You need tools to synchronize content, pushing information between servers and clients. While technologies like WebSockets or the media layers of WebRTC go some of the way to deliver the underlying protocols that you need, they’re only part of the story.
Introducing SignalR
Microsoft’s ASP.Net introduced SignalR for delivering real-time data over the web. It’s a bi-directional protocol that’s built on top of WebSockets, with a set of APIs that treat it as a remote procedure call. Servers can call procedures on registered clients, while clients can do the same to connected servers. Using SignalR, you can broadcast datato all the clients that are currently connected to a server, or target messages to only one—all at a high frequency.
Because SignalR uses WebSockets, each connection is persistent. There’s no setup and teardown associated with a message, so it can be used in near real-time. It’s also scalable, and by using the ASP.Net version you can work with a very large number of clients indeed. But that does mean having the hardware in place to manage your predicted load, and being ready to add more physical or virtual machines as you need them.
If a WebSocket connection isn’t available, you can either specify an alternate protocol (often using a long HTTP session) or let SignalR negotiate its own fallbacks between client and server. With modern browsers like Google Chrome now predominant, you’re less likely to need a fallback option in your code, but it’s still worth considering if you’re likely to need to support users running old versions of Internet Explorer.
