Un exemple d'implémentation d'une conversation textuelle en temps réel avec la bibliothèque SignalR

Auteurs : Denis Balant, Enej Hudobreznik

Le protocole HTTP (Hypertext Transfer Protocol) est encore principalement utilisé pour le transfert de données sur Internet. son dérivé crypté HTTPS (HTTP Secure) plus moderne et plus sûr. Ils sont basés sur une architecture client-serveur, où le client (client anglais) envoie une requête (requête HTTP anglaise) au serveur (serveur anglais), et le serveur y répond par une réponse (réponse HTTP anglaise).

Les protocoles HTTP et HTTPS conviennent aux transferts requête-réponse simples (par exemple transfert d'un fichier HTML à la demande du client). En utilisant ces deux protocoles, l'utilisateur ne peut obtenir des données mises à jour que lorsqu'il envoie une nouvelle demande, ils ne sont donc pas les plus adaptés au transfert de données en temps réel (par exemple chat en ligne, jeux vidéo en ligne, localisation... ), sur lequel une grande partie des fonctionnalités des applications Web modernes repose sur. L’agilité peut être mise en œuvre de différentes manières, chacune avec ses propres avantages et inconvénients.

La méthode de mise en œuvre la plus simple est l'interrogation régulière, dans laquelle le client envoie de manière répétée des demandes de nouvelles données au serveur à chaque intervalle d'interrogation, que le contenu ait ou non changé. Malgré sa simplicité, cette approche n'est pas adaptée aux services plus volumineux où l'accès au serveur nécessite de nombreux clients, car un grand nombre de requêtes inutiles et répétées peuvent le surcharger et ainsi ralentir les performances du service.

L'amélioration est obtenue en introduisant une interrogation à long terme, où le client envoie des requêtes au serveur de la même manière, mais le serveur n'y répond pas tant qu'il n'a pas détecté la présence de nouvelles données. L'inconvénient d'une telle approche est que le client doit définir un certain intervalle de temps, après quoi il reconnaît l'inactivité du serveur comme une erreur. Cela ajoute une couche supplémentaire de complexité à la configuration du client et du serveur.

La norme HTML5 moderne fournit également une API appelée Server-Sent Events. Il s'agit d'un protocole dans lequel le client n'a pas besoin d'envoyer périodiquement des requêtes au serveur, mais le serveur renvoie les données nécessaires lorsque des modifications sont apportées, facilitant ainsi la communication en temps réel.

La norme HTML5 propose également le protocole WebSockets, qui permet une véritable communication bidirectionnelle en temps réel. Au début de l'établissement, une poignée de main est effectuée, au cours de laquelle le client et le serveur se mettent d'accord sur l'ensemble des normes qu'ils utiliseront. Après une poignée de main réussie, une connexion permanente avec un léger délai est établie entre les deux participants. Ce protocole est particulièrement utile lorsqu'il s'agit d'une connexion point à point (une connexion directe entre un client et un serveur).

En plus de l'architecture client-serveur classique, il existe d'autres solutions où la connexion entre clients ne passe pas par des serveurs, mais directement entre clients qui jouent à la fois le rôle de client et de serveur (ces réseaux peer-to-peer). Un protocole populaire pour la communication en temps réel dans de tels réseaux est WebRTC.

Dans l'environnement .NET pour la communication en temps réel, nous pouvons utiliser la bibliothèque open source SignalR, qui fait partie du framework Web ASP.NET Core, il est donc facile de l'ajouter aux projets existants en tant que niveau supplémentaire de middleware lorsque traiter les demandes entrantes. La bibliothèque simule les appels de méthode sur le client côté serveur et les appels de méthode sur le serveur côté client (Remote Procedure Call - RPC), mais ne garantit pas la pertinence du no. paramètres et leurs types. Depuis le serveur, nous pouvons appeler des méthodes sur tous les clients, sur un groupe spécifique de clients ou sur un seul client.

Son principal avantage est la simplicité de mise en œuvre grâce aux packages de développement logiciel (SDK) pour de nombreuses plateformes différentes, qui cachent le fonctionnement interne du service aux programmeurs, et la possibilité d'un hébergement facile avec le service Azure SignalR. Un avantage supplémentaire est que le service choisit lui-même le type de connexion le plus approprié (décrit ci-dessus) entre le client et le serveur.

L'utilisation de la bibliothèque est basée sur des classes spéciales appelées hubs, qui représentent une abstraction de la connexion entre les clients et le serveur. Pour eux, nous définissons des méthodes que les clients peuvent appeler sur le serveur.

L'exemple ci-dessous montre un exemple d'implémentation d'une conversation textuelle simple. Tout d'abord, nous définissons le nœud de base de la conversation sur le serveur. Les méthodes de cette classe représentent des méthodes pouvant être appelées par les clients sur le serveur. Lorsque la méthode SendMessage est appelée, le client envoie l'ID utilisateur (userId) et le contenu du message (message), tandis que le serveur appelle la méthode ReceiverMessage sur tous les clients avec les paramètres spécifiés.

L'exemple ci-dessous montre une implémentation de client Web JavaScript utilisant la bibliothèque officielle (@microsoft/signalr). Les clients se connectent à l'URL du nœud (/chat dans l'exemple ci-dessous). Une connexion est représentée par l'objet de connexion. La méthode on représente un écouteur de l'appel de méthode dont le nom est donné en premier paramètre, et en second la fonction qui est exécutée sur l'événement. Nous implémentons les méthodes sur le serveur via la méthode d'invocation de l'objet de connexion, qui nécessite le nom de la méthode comme premier argument, suivi de ses paramètres.

Par défaut, les données sont transférées entre le serveur et les clients au format JSON, mais la bibliothèque prend également en charge le format MessagePack, plus efficace.

Bien que la bibliothèque facilite grandement le développement, elle présente des inconvénients. L'un des principaux est l'évolutivité du système pour s'auto-héberger et assurer un fonctionnement ininterrompu, car sa mise en œuvre est très difficile à répartir sur plusieurs serveurs distincts. Cela s'avère particulièrement difficile si nous voulons réduire la latence pour les utilisateurs distants et les hôtes situés dans plusieurs emplacements différents, car la conception de la solution est limitée à un seul. De plus, la bibliothèque ne garantit pas une livraison et un classement fiables des messages, ce qui peut dégrader l'expérience utilisateur.