Azure SignalR Service FAQ

Yes, both the support for ASP.NET Core SignalR and ASP.NET SignalR is all generally available.

There's a one-to-one mapping between a client and an application server. Messages from one client are always sent to the same application server.

The mapping is maintained until the client or application server disconnects.

Azure SignalR Service monitors heartbeats from application servers. If heartbeats aren't received for a specified period of time, the application server is considered offline. All client connections mapped to this application server will be disconnected.

The parameter HubConnectionContext context is different between the ASP.NET Core SignalR SDK and the Azure SignalR Service SDK when IUserIdProvider is called.

In ASP.NET Core SignalR, HubConnectionContext context is the context from the physical client connection with valid values for all properties.

In the Azure SignalR Service SDK, HubConnectionContext context is the context from the logical client connection. The physical client is connected to the Azure SignalR Service instance, so only a limited number of properties are provided.

For now, only HubConnectionContext.GetHttpContext() and HubConnectionContext.User are available for access. You can check the source code.

Yes. See Transport Configuration for how to configure.

You can also configure client-side transports as documented in ASP.NET Core SignalR configuration.

You can find details about we calculate these metrics in Messages and connections in Azure SignalR Service.

On the overview pane of Azure SignalR Service resources, we've already chosen the appropriate aggregation type for you. You can use Supported metrics with Azure Monitor as a reference.

For new applications, only default and serverless mode should be used. The main difference is whether you have application servers that establish server connections to the service (for example, use AddAzureSignalR() to connect to service). If yes use default mode, otherwise use serverless mode.

Classic mode is designed for backward compatibility for existing applications so shouldn't be used for new applications.

For more information about service mode, see Service mode in Azure SignalR Service.

You can send message from client if you configure upstream endpoints in your SignalR instance. Upstream endpoints are a set of endpoints that can receive messages and connection events from SignalR service. If no upstream endpoints are configured, messages from client will be ignored.

For more information.see Upstream endpoints.

The upstream endpoints feature is currently in public preview.

When you're using Azure SignalR Service, some APIs and features of ASP.NET SignalR aren't supported:

• The ability to pass arbitrary state between clients and the hub (often called HubState) isn't supported.
• The PersistentConnection class isn't supported.
• Forever Frame transport isn't supported.
• Azure SignalR Service no longer replays messages sent to the client when the client is offline.
• When you're using Azure SignalR Service, the traffic for one client connection is always routed (also called sticky) to one app server instance for the duration of the connection.

Support for ASP.NET SignalR is focused on compatibility, so not all new features from ASP.NET Core SignalR are supported. For example, MessagePack and Streaming are available only for ASP.NET Core SignalR applications.

You can configure Azure SignalR Service for different service modes: Classic, Default, and Serverless. The Serverless mode isn't supported for ASP.NET. The data-plane REST API is also not supported.

Azure SignalR Service does not store any customer data. If you use Azure SignalR Service together with other Azure services, like Azure Storage for diagnostics, see Azure Privacy Overview (white paper) for guidance about how to keep data residency in Azure regions.

Both Azure SignalR Service and Azure Web PubSub service help customers build real-time web applications easily with large scale and high availability and enable customers to focus on their business logic instead of managing the messaging infrastructure. In general, you may choose Azure SignalR Service if you already use SignalR library to build real-time applications. Instead, if you're looking for a generic solution to build real-time application based on WebSocket and publish-subscribe pattern, you may choose Azure Web PubSub service. The Azure Web PubSub service isn't a replacement for Azure SignalR Service and vice-versa; they target different scenarios. The following guidance will help you decide which service to use for your scenario.

Azure SignalR Service is more suitable if:

• You're already using ASP.NET or ASP.NET Core SignalR, primarily using .NET or need to integrate with .NET ecosystem (like Blazor).
• There's a SignalR client available for your platform.
• You need an established protocol that supports a wide variety of:
  • calling patterns (RPC and streaming)
  • transports (WebSocket, server sent events, and long polling)
• You need a client that manages the connection lifetime on your behalf.

Azure Web PubSub service is more suitable for situations where:

• You need to build real-time applications based on WebSocket technology or publish-subscribe over WebSocket.
• You want to build your own subprotocol or use existing advanced protocols over WebSocket (for example, MQTT, AMQP over WebSocket).
• You're looking for a lightweight server, for example, sending messages to client without going through the configured backend.