Azure SignalR Service est-il prêt pour une utilisation en production ?
Oui, ASP.NET Core SignalR et ASP.NET SignalR sont tous deux en disponibilité générale.
Si plusieurs serveurs d’applications sont en place, les messages d’un client sont-ils envoyés à tous les serveurs ou à un seul d’entre eux ?
Un client et un serveur d’applications sont liés par un mappage un-à-un. Les messages d’un client sont donc toujours envoyés au même serveur d’applications.
Le mappage est conservé jusqu’à ce que le client ou le serveur d’applications se déconnecte.
Si l’un de mes serveurs d’applications est en panne, comment puis-je le trouver et recevoir une notification ?
Azure SignalR Service supervise les pulsations des serveurs d’applications. Si aucune pulsation n’est reçue pendant une période spécifiée, le serveur d’applications est considéré comme étant hors connexion. Toutes les connexions clientes mappées à ce serveur d’applications sont alors déconnectées.
Pourquoi mon `IUserIdProvider` personnalisé lève une exception quand je passe du SDK ASP.NET Core SignalR au SDK Azure SignalR Service ?
Le paramètre HubConnectionContext context varie entre le SDK ASP.NET Core SignalR et le SDK Azure SignalR Service quand IUserIdProvider est appelé.
Dans ASP.NET Core SignalR, HubConnectionContext context est le contexte de la connexion cliente physique avec des valeurs valides pour toutes les propriétés.
Dans le SDK Azure SignalR Service, HubConnectionContext context est le contexte de la connexion cliente logique. Le client physique étant connecté à l’instance Azure SignalR Service, un nombre limité de propriétés sont fournies.
Pour l’instant, seules les propriétés HubConnectionContext.GetHttpContext() et HubConnectionContext.User sont accessibles.
Vous pouvez examiner le code source.
Puis-je configurer les transports disponibles dans Azure SignalR Service côté serveur avec ASP.NET Core SignalR ? Est-ce que je peux par exemple désactiver le transport WebSocket ?
Oui. Pour savoir comment configurer, consultez Configuration du transport.
Vous pouvez également configurer des transports côté client comme indiqué dans Configuration d’ASP.NET Core SignalR.
Que signifient les métriques, telles que le nombre de messages ou de connexions affiché dans le portail Azure ? Quel type d’agrégation dois-je choisir ?
Vous trouverez plus d’informations sur le calcul de ces métriques dans Messages et connexions dans Azure SignalR Service.
Dans le volet Vue d’ensemble des ressources Azure SignalR Service, nous avons déjà choisi le type d’agrégation adapté à vos besoins. Vous pouvez utiliser les Métriques prises en charge par Azure Monitor comme référence.
Que signifient les modes de service « Par défaut », « Serverless » et « Classique » ? Comment faire mon choix ?
Pour les nouvelles applications, seuls les modes par défaut et serverless peuvent être utilisés. La principale différence est liée à la présence ou non de serveurs d’applications qui établissent des connexions serveur au service (par exemple, utilisez AddAzureSignalR() pour vous connecter au service). En présence de tels serveurs, utilisez le mode par défaut ; sinon, choisissez le mode serverless.
Le mode classique vise à assurer la compatibilité descendante des applications existantes. Il ne doit donc pas être utilisé pour les nouvelles applications.
Pour plus d’informations sur le mode de service, consultez Mode de service dans Azure SignalR Service.
Puis-je envoyer un message du client en mode serverless ?
Vous pouvez envoyer un message du client si vous définissez la configuration des points de terminaison en amont dans votre instance SignalR. Les points de terminaison en amont sont un ensemble de points de terminaison qui peuvent recevoir des messages et des événements de connexion du service SignalR. Si aucune configuration des points de terminaison en amont n’est définie, les messages provenant du client sont ignorés.
Pour plus d’informations, consultez Points de terminaison en amont.
La fonctionnalité des points de terminaison en amont est actuellement en préversion publique.
Existe-t-il des différences de fonctionnalités lors de l’utilisation d’Azure SignalR Service avec ASP.NET SignalR ?
Lorsque vous utilisez Azure SignalR Service, certaines API et fonctionnalités d’ASP.NET SignalR ne sont pas prises en charge :
- Il n’est pas possible de faire passer l’état arbitraire entre les clients et le hub (souvent appelé
HubState). - La classe
PersistentConnectionn'est pas prise en charge. - Le transport Forever Frame n’est pas pris en charge.
- Azure SignalR Service ne relit plus les messages envoyés au client lorsque le client est hors connexion.
- Lorsque vous utilisez Azure SignalR Service, le trafic pour une connexion cliente est toujours routé (également appelé rémanent) vers une instance de serveur d’applications pendant la durée de la connexion.
Comme la prise en charge d’ASP.NET SignalR se concentre sur la compatibilité, les nouvelles fonctionnalités d’ASP.NET Core SignalR ne sont pas toutes prises en charge. Par exemple, MessagePack et Streaming sont disponibles uniquement pour les applications ASP.NET Core SignalR.
Vous pouvez configurer Azure SignalR Service pour différents modes de service : Classic, Default et Serverless. Le mode Serverless n’est pas pris en charge pour ASP.NET. Le plan de données API REST n’est pas non plus pris en charge.
Où mes données résident-elles ?
Azure SignalR Service ne stocke aucune donnée client. Si vous utilisez Azure SignalR Service avec d’autres services Azure, tels que Stockage Azure pour les diagnostics, consultez le livre blanc (Vue d’ensemble de la confidentialité Azure) pour obtenir des conseils sur la façon de conserver la résidence des données dans les régions Azure.
Comment faire choisir entre le service Azure SignalR et le service Azure Web PubSub ?
Azure SignalR Service et le service Azure Web PubSub aident tous deux les clients à créer facilement des applications web temps réel à grande échelle et avec une haute disponibilité, et permettent aux clients de se concentrer sur leur logique métier au lieu de gérer l’infrastructure de messagerie. En règle générale, vous pouvez choisir Azure SignalR Service si vous utilisez déjà la bibliothèque SignalR pour créer des applications en temps réel. Par contre, si vous recherchez une solution générique pour créer une application temps réel basée sur le modèle WebSocket et publication-abonnement, vous pouvez choisir le service Azure Web PubSub. Le service Azure Web PubSub ne remplace pas Azure SignalR Service et vice versa. Ces services ciblent des scénarios différents. Les conseils suivants vous aideront à choisir le service à utiliser pour votre scénario.
Azure SignalR Service est plus adapté si :
- Vous utilisez déjà ASP.NET ou ASP.NET Core SignalR, principalement avec .NET ou la nécessité de s’intégrer à l’écosystème .NET (comme Blazor).
- Un client SignalR est disponible pour votre plateforme.
- Vous avez besoin d’un protocole établi qui prend en charge une grande variété de :
- modèles d’appel (RPC et streaming)
- transports (WebSocket, événements envoyés par le serveur et interrogation longue)
- Vous avez besoin d’un client qui gère la durée de vie de la connexion en votre nom.
Le service Azure Web PubSub est plus adapté aux situations où :
- Vous devez créer des applications temps réel basées sur la technologie WebSocket ou publication-abonnement sur WebSocket.
- Vous voulez créer votre propre sous-protocole ou utiliser des protocoles avancés existants sur WebSocket (par exemple MQTT, AMQP sur WebSocket).
- Vous recherchez un serveur léger, par exemple pour envoyer des messages au client sans passer par le back-end configuré.