Qu’est-ce qu’ASP.NET Core SignalR ?

  • 4 minutes

Toutes les applications connectées à Internet sont composées de serveurs et de clients. Les clients s’appuient sur les serveurs pour les données, et le principal mécanisme par lequel ils reçoivent les données consiste à effectuer des requêtes HTTP (Hypertext Transfer Protocol). Certaines applications clientes nécessitent des données qui changent fréquemment.

ASP.NET Core SignalR fournit une API pour la création d’appels RPC (appels de procédures distantes) de serveur à client. Les appels RPC permettent d’appeler des fonctions sur les clients à partir du code .NET Core côté serveur. Il existe plusieurs plateformes prises en charge, chacune avec son propre kit SDK client. C’est pourquoi le langage de programmation appelé par les appels RPC peut varier.

Il est utile de vous familiariser avec la terminologie commune associée à SignalR. Dans cette leçon, vous allez découvrir les composants SignalR nécessaires dans une application serveur, par rapport à ceux des applications clientes. De plus, vous allez mieux comprendre les différents mécanismes de communication duplex. SignalR encapsule plusieurs protocoles en temps réel et fait abstraction de la complexité de chaque implémentation. Pour plus d’informations, consultez la documentation relative à ASP.NET Core SignalR.

Les termes principaux utilisés dans SignalR sont présentés dans les sections suivantes.

Transports

SignalR prend en charge les techniques suivantes, ou transports, pour la gestion de la communication en temps réel :

  1. WebSockets
  2. Server-Sent Events
  3. Long Polling

L’ordre dans lequel les transports sont listés ici indique leur ordre de préférence. En d’autres termes, les connexions WebSocket sont préférées aux connexions SSE (Server-Sent Events), lesquelles sont préférées aux connexions Long Polling (interrogation longue), bien que tous ces modes de transport puissent être utilisés. SignalR choisit automatiquement la meilleure méthode de transport qui correspond aux capacités du serveur et du client. Pour plus d’informations, consultez la spécification officielle des protocoles de transport SignalR.

Serveur

Le serveur est responsable de l’exposition d’un point de terminaison SignalR. Le point de terminaison est mappé à une sous-classe Hub ou Hub<T>. Le serveur peut exister localement, chez un fournisseur de cloud (par exemple Azure) ou avec Azure SignalR Service. Le serveur expose des méthodes de hub qui peuvent être appelées à partir des clients ainsi que des événements auxquels les clients peuvent s’abonner. Il s’agit des procédures distantes.

Hub

Dans SignalR, un hub est utilisé pour la communication entre les clients et les serveurs. Un hub est un pipeline élémentaire qui permet à un client d’appeler des méthodes sur un serveur, et inversement. À cette fin, SignalR gère automatiquement la distribution à travers les limites des machines. Vous pouvez considérer un hub comme un proxy entre tous les clients connectés et le serveur.

Protocoles

Le protocole SignalR est un protocole qui permet une communication RPC bidirectionnelle sur n’importe quel transport à base de messages. L’une des parties de la connexion peut appeler des procédures sur l’autre partie. Les procédures peuvent retourner zéro ou plusieurs résultats, ou une erreur. SignalR fournit deux protocoles de hub intégrés :

  • Un protocole texte basé sur JSON, qui est la valeur par défaut.
  • Protocole binaire basé sur MessagePack, qui crée généralement des messages plus petits que JSON.

Pour utiliser le protocole MessagePack, le serveur et le client doivent l’accepter explicitement afin de permettre sa configuration. De plus, ils doivent tous deux le prendre en charge. Il existe un troisième protocole de hub, appelé BlazorPack, mais il est utilisé exclusivement avec les applications Blazor-Server. Il ne peut pas être utilisé sans le modèle d’hébergement Blazor-Server. Pour plus d’informations, consultez la spécification officielle du protocole de hub SignalR.

Utilisateurs

Un utilisateur du système agit en tant qu’individu, mais peut également faire partie d’un groupe. Vous pouvez envoyer des messages à des groupes, tous leurs membres en sont notifiés. Un même utilisateur peut se connecter à partir de plusieurs applications clientes. Par exemple, un même utilisateur peut utiliser un appareil mobile et un navigateur web et obtenir des mises à jour en temps réel sur les deux en même temps.

Groupes

Un groupe comprend une ou plusieurs connexions. Le serveur peut créer des groupes, ajouter des connexions à un groupe et supprimer des connexions d’un groupe. Un groupe a un nom spécifié, qui sert d’identificateur unique. Les groupes servent de mécanisme d’étendue pour aider à cibler des messages. Autrement dit, les fonctionnalités en temps réel ne peuvent être envoyées qu’aux utilisateurs d’un groupe nommé.

Connexions

Une connexion à un hub est représentée par un identificateur unique connu uniquement du serveur et du client. Il n’existe qu’une seule connexion par type de hub. Chaque client dispose d’une connexion unique au serveur. Autrement dit, un seul utilisateur peut être représenté sur plusieurs clients, mais chaque connexion cliente a son propre identificateur.

Clients

Le client est responsable de l’établissement d’une connexion au point de terminaison du serveur via un objet HubConnection. La connexion au hub est représentée au sein de chaque plateforme cible :

Pour plus d’informations, consultez Plateformes prises en charge par ASP.NET Core SignalR.

Une fois qu’une instance de connexion au hub a correctement démarré, les messages circulent librement dans les deux sens. Les utilisateurs sont libres de communiquer des notifications au serveur et d’en recevoir de la part du serveur. Un client est une application connectée, par exemple un navigateur web, une application mobile ou une application de bureau entre autres.