signalr-resource-faq.yml

### YamlMime:FAQ
metadata:
  title: Azure SignalR Service frequently asked questions
  description: Get answers to frequently asked questions about Azure SignalR Service, including troubleshooting and typical usage scenarios.
  author: vicancy
  ms.service: signalr
  ms.topic: faq
  ms.custom:
  ms.date: 03/21/2023
  ms.author: lianwei
title: Azure SignalR Service FAQ
summary: |

sections:
  - name: Ignored
    questions:
      - question: |
          Is Azure SignalR Service ready for production use?
        answer: |
          Yes, both the support for [ASP.NET Core SignalR](https://dotnet.microsoft.com/apps/aspnet/signalr) and [ASP.NET SignalR](/aspnet/signalr/overview/getting-started/introduction-to-signalr) is all generally available.
          
      - question: |
          When there are multiple application servers, are client messages sent to all servers or just one of them?
        answer: |
          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.
          
      - question: |
          If one of my application servers is down, how can I find it and get notified?
        answer: |
          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.
          
      - question: |
          Why does my custom `IUserIdProvider` throw an exception when I'm switching from ASP.NET Core SignalR SDK to Azure SignalR Service SDK?
        answer: |
          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](https://github.com/Azure/azure-signalr/blob/dev/src/Microsoft.Azure.SignalR/HubHost/ServiceHubConnectionContext.cs).
          
      - question: |
          Can I configure the transports available in Azure SignalR Service on the server side with ASP.NET Core SignalR? For example, can I disable WebSocket transport?
        answer: |
          Yes. See [Transport Configuration](https://github.com/Azure/azure-signalr/blob/dev/docs/advanced-topics/transport-configuration.md) for how to configure.
          
          You can also configure client-side transports as documented in [ASP.NET Core SignalR configuration](/aspnet/core/signalr/configuration#configure-allowed-transports-1).
          
      - question: |
          What is the meaning of metrics like message count or connection count shown in the Azure portal? Which kind of aggregation type should I choose?
        answer: |
          You can find details about we calculate these metrics in [Messages and connections in Azure SignalR Service](signalr-concept-messages-and-connections.md).
          
          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](../azure-monitor/essentials/metrics-supported.md#microsoftsignalrservicesignalr) as a reference.
          
      - question: |
          What is the meaning of the `Default`, `Serverless`, and `Classic` service modes? How can I choose?
        answer: |
          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](concept-service-mode.md).
          
      - question: |
          Can I send message from client in serverless mode?
        answer: |
          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](concept-upstream.md).
          
          The upstream endpoints feature is currently in public preview.
          
      - question: |
          Are there any feature differences in using Azure SignalR Service with ASP.NET SignalR?
        answer: |
          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.
          
      - question: |
          Where does my data reside?
        answer: |
          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)](https://go.microsoft.com/fwlink/p/?linkid=2220836) for guidance about how to keep data residency in Azure regions.

      - question: |
          How do I choose between Azure SignalR service and Azure Web PubSub service?
        answer: |
          Both [Azure SignalR Service](https://azure.microsoft.com/services/signalr-service) and [Azure Web PubSub service](https://azure.microsoft.com/services/web-pubsub) 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.