Broadcasting with Azure SignalR Service Management SDK
Azure SignalR is a fully-managed scalable service that adds real-time functionality to applications. It has lowered the bar to building high-frequency data flows with large numbers of concurrent connections. Most commonly, these applications are browser-based web apps with two-way messaging. However, that is only one of the many possible use cases. This article describes SignalR broadcasting using the Azure SignalR Service Management SDK.
Broadcast Defined
The term “broadcasting” can be somewhat confusing at first since it can mean different things in different contexts. Broadcasting in the context of Azure SignalR messaging is simply sending messages from the server to the client. Also referred to as “listen mode,” messages can only be sent from the server(s) to the client(s). Remembering this is at the message — and not the transport/protocol — level will keep you on track. A common use case would be high frequency data push (dashboards, monitoring, etc).
Solution Architecture
There are four components required:
The client application receives the messages from the Azure SignalR Service. However, it is not recommended for a client to directly communicate without first negotiating the connection with the Negotiation Server. Early examples of SignalR Service omitted this important step. A Negotiation Server prevents clients from having tokens stored locally and allows for easier endpoint management (such as revoking access). Finally, a Message Publisher is necessary to dispatch messages.
The Negotiation Server and Message Publisher can be hosted on the same web server, but I keep them as stand-alone servers to better illustrate their roles.
Management SDK
The connection negotiation process does add additional (but necessary) plumbing to our code. Fortunately, Microsoft has created the Azure SignalR Management SDK to make it easy to implement. I won’t rehash the steps in detail here, as the SDK sample is an excellent resource. I’ll just briefly touch on the important APIs that the SDK provides.
IServiceManager
IServiceManager provides methods to generate client endpoints and access tokens for SignalR clients to connect to Azure SignalR Service. It is used by the Negotiation Server to get the client endpoint with access token and handoff to the clients. It is also used by the Message Publisher to create a connection to Azure SignalR Service.
IServiceHubContext
After the Message Publisher has established a connection to Azure SignalR Service, it can create a ServiceHubContext instance to publish messages to a specific hub. Messages can be targeted to specific users or groups. Additionally, methods to add and remove a user from a group are available on this interface.
HubConnectionBuilder
The clients will use the HubConnectionBuilder to connect and receive messages from Azure SignalR Service. The “On” method handles the SignalR client callback, where you would take action on the message received.
Conclusion
In this article I described broadcasting messages using Azure SignalR Service. The Management SDK makes quick work of sending high frequency data to clients while leveraging all the benefits of a managed service. This was just a small sliver of what Azure SignalR Service has to offer.
