Utilisateur:Mrharispe/Brouillon
| Développé par | Microsoft |
|---|---|
| Dernière version | 2016 |
| Écrit en | C Sharp |
| Environnement | Windows |
| Type | Système temps réel |
| Site web | www.asp.net/signalr |
SignalR est une librairie de Microsoft conçue pour faciliter et accélérer le développement de fonctionnalités en temps réel pour des applications web sur ASP.NET. Le but des applications temps réel en web consiste à livrer du contenu du serveur vers tous les clients connectés dès qu’il est disponible. Sans les fonctionnalités temps réel, une page web se limite à un serveur en attente qu’un client lance une requête HTTP pour obtenir du contenu pour peupler la page.
La flexibilité de SignalR fait en sorte que n’importe quel type de fonctionnalité temps réel est possible dans une application ASP.NET, tant que certains critères soient respectés. Parmi ces critères, la page web doit pouvoir être rafraîchie ou elle doit implémenter le mode de communication client-serveur nommé Server Push, qui permet au serveur d’appeler du code client (contrairement au modèle requête-réponse populairement utilisé via des requêtes HTTP), pour être candidate à l’utilisation de SignalR. Entre autres, des applications de clavardage, d’édition collaborative ou même de jeux vidéo sur un navigateur web sont des exemples parfaits d’applications aspirantes à bénéficier de la technologie de SignalR.
L’avantage principal de l’utilisation de la technologie temps réel de Microsoft est la gestion automatique des connexions entre les clients et les méthodes de transport utilisées. Les connexions persistantes établies entre les clients et le serveur font en sorte que les communications sont rapides, contrairement à des requêtes HTTP qui sont forcées d’établir une connexion lors de chaque requête faite au serveur. De plus, SignalR permet de cibler spécifiquement à quels clients envoyer quel contenu. En effet, dans une application de clavardage il est important d’envoyer des messages directement à un autre client, alors que dans un jeu vidéo multijoueur tous les joueurs doivent être en mesure de voir le même contenu au même moment. [1]
Méthodes de transport
modifierSignalR a plusieurs méthodes de transport à sa disposition. Pour le programmeur, il n’est pas nécessaire de connaître le fonctionnement de toutes ces méthodes de transport, puisque SignalR en fait abstraction. Effectivement, il est possible que le programmeur ne soit pas au courant de quelle méthode de transport sera utilisée par son application temps réel, ce qui simplifie énormément le processus de développement.
Également, le développement est accéléré puisque, comme SignalR implémente directement plusieurs méthodes de transport, il n’est pas nécessaire d’implémenter un plan de contingence au cas où une des méthodes ne fonctionne pas sur une application hébergée sur un serveur en particulier. En d’autres mots, sans l’utilisation de SignalR, un programmeur est forcé d’implémenter plusieurs méthodes de transport, au lieu d’implémenter uniquement SignalR qui gère multiples méthodes de transport automatiquement.
Une application web qui utilise SignalR commence typiquement par établir une connexion HTTP standard. Ensuite, diverses méthodes de transport seront testées, de la plus performante à la moins performante, jusqu’à ce qu’une des méthodes se voit fonctionnelle pour l’architecture en place. La connexion HTTP sera donc transformée en une autre sorte de connexion, dépendamment de la méthode de transport sélectionnée.
Les méthodes de transport les plus rapides requièrent du support pour HTML5. Ces méthodes, WebSocket et Server Sent Events, seront donc utilisées respectivement sur les navigateurs qui supportent HTML5. Sinon, des méthodes de transport utilisant une approche de sorte Comet, Forever Frame et Ajax Long Polling, seront utilisées. Ces deux dernières méthodes permettent de maintenir une requête HTTP établie pendant une longue période, et c’est à travers cette connexion qu’un serveur sera en mesure d’envoyer du contenu aux clients, sans que ces derniers ne fassent nécessairement une nouvelle requête[1].
WebSocket
modifier
Une connexion via WebSocket est la méthode de transport préférée par SignalR, puisque c’est la méthode qui utilise la mémoire du serveur de la manière la plus efficiente, qui a la plus basse latence, et qui implémente le plus de fonctionnalités. WebSocket est aussi le seul moyen de transport qui implémente une véritable connexion persistante et bidirectionnelle entre le serveur et le client[1].
Malgré tous les avantages de WebSocket, sont plus grand désavantage est qu’il n’est souvent pas possible de l’utiliser, compte tenu du grand nombre d’exigences en ce qui concerne son implémentation. Il est supporté uniquement dans les versions les plus récentes de Microsoft Internet Explorer, Google Chrome et Mozilla Firefox, avec des implémentations partielles sur Opera et Safari. De plus, le serveur doit utiliser un système d’exploitation égal ou supérieur à Windows Server 2012 ou Windows 8, ainsi qu’une version du cadre d’applications .NET égale ou supérieure à 4.5. Finalement, certains serveurs requièrent une activation explicite de WebSocket lors de la configuration du serveur, comme c’est le cas par exemple de Microsoft Azure[2].
Sans le respect de ces exigences, une autre méthode de transport sera utilisée.
Server Sent Events
modifier
Cette méthode, aussi appelée EventSource (nom de l’objet utilisé par l’API de Server Sent Events), est disponible sur tous les navigateurs web qui supportent HTML5, sauf Microsoft Internet Explorer. Cette méthode permet l’émulation d’une connexion asynchrone, en envoyant des notifications basées sur des requêtes HTTP. Bref, le client s'abonne à un flux d'événements provenant du serveur, et lorsque le serveur annonce qu'il y a du contenu disponible via un événement, le client va chercher le contenu pour le traiter (modèle semblabe au patron de conception observateur).
Les avantages de Server Sent Events par rapport à WebSocket incluent le fait que les clients peuvent se reconnecter si la connexion est perdue en utilisant les identifiants des événements[3], qu’un simple protocole HTTP est utilisé pour la communication et que des versions plus vieilles de certains navigateurs web sont supportées[4]. Les plus grands inconvénients sont le manque de support pour Microsoft Internet Explorer et le fait que la connexion établie n’est pas une vraie connexion bidirectionnelle, ce qui fait en sorte que la connexion n’est pas aussi rapide et efficace.
Alors que WebSocket se voit idéal pour des connexions dont le client doit envoyer régulièrement du contenu au serveur pour le distribuer aux autres clients, comme dans le cas de jeux vidéo et des applications de clavardage, Server Sent Events est un candidat parfait pour des applications qui nécessitent surtout une option qui permet au serveur d’envoyer du contenu aux clients. Les applications qui consistent à envoyer des notifications (Twitter, Facebook, etc.) sont des exemples parfaits.
Forever Frame
modifier
Alors que Server Sent Events n’est pas supporté sur Microsoft Internet Explorer, Forever Frame est uniquement supporté sur ce navigateur web. Son implémentation repose sur l’utilisation d’un IFrame caché sur la page web qui fait une requête à un serveur, requête qui ne sera pas complétée pour garder une connexion établie. Le IFrame devra être correctement configuré dans le Document Object Model pour assurer la connexion avec le serveur Comet[5].
Via cette connexion, le serveur envoie en continu des scripts qui seront exécutés immédiatement du côté du client. Cette connexion est de type unidirectionnel; c’est uniquement le serveur qui peut envoyer du contenu, en temps réel, au client sur la connexion établie. La connexion reste ouverte tant qu’un délai d’attente n’est pas dépassé ou qu’un événement en particulier du côté serveur arrive[6].
Dans l’éventualité où le client désire communiquer avec le serveur, une nouvelle connexion est créée à chaque fois que de l’information doit être envoyée au serveur, exactement comme une connexion HTTP[1].
Un avantage de Forever Frame est que son utilisation permet une très basse latence, car elle évite l’utilisation de HTTP du côté serveur et évite aussi l’établissement d’une connexion TCP/IP en utilisant une seule connexion de longue durée. De plus, l’implémentation de Forever Frame est simple. Le plus grand inconvénient est qu’il n’y a aucun moyen d’implémenter une méthode de gestion des erreurs ni de gestion de l’état de la connexion. Ceci fait en sorte qu’il est impossible de savoir s’il y a un problème de connexion tant du côté client que du côté serveur[6].
Long polling
modifier
C’est la méthode de transport la moins efficace de SignalR, et n’est utilisée qu’en dernier recours. Au lieu d’établir une connexion persistante, le client fait une requête qui reste ouverte jusqu’à ce que le serveur reçoive les informations nécessaires pour répondre. Lorsque le serveur répond à la requête du client, cette requête est fermée et une nouvelle est immédiatement ouverte par le client pour se préparer à la réception du contenu qui sera éventuellement disponible.
Long polling est une méthode peu efficace, puisque le temps de fermer la connexion et de créer une nouvelle peut avoir un grand impact sur la latence; par exemple, si pendant la fermeture de la première connexion une nouvelle notification devient disponible, il va avoir un délai dans la réception de cette notification du côté client équivalent au moins au rétablissement d’une connexion[1].
Comme avec Forever Frame, l’utilisation de Long polling est faite via des balises script (sauf que dans ce cas elles ne se retrouvent pas nécessairement dans un IFrame). Puisque cette méthode est basée sur l’utilisation de balises HTML, Long polling est facile à implémenter et fonctionne sur la majorité de serveurs et machines clients. Cependant, comme pour Forever Frame, il est impossible de contrôler les erreurs qui surviennent ainsi que de gérer les connexions[6].
Utilisation forcée d'une méthode de transport
modifierAlors qu’il est recommandé de laisser SignalR choisir la meilleure méthode de transport (selon le respect des exigences de chaque méthode par rapport à la machine client et les spécifications du serveur), il peut être intéressant ou nécessaire dans certains cas de forcer l’utilisation d’une méthode de transport en particulier.
En effet, si l’application en question est utilisée dans un environnement contrôlé et qu’une méthode spécifiquement est préférable dans le cadre de cette application, il est possible de forcer l’utilisation de méthode voulue. De plus, ceci est plus efficace au niveau du temps et des ressources, car le processus de négociation et de vérification des exigences de chaque méthode est éliminé. Bref, SignalR permet de sélectionner la méthode de transport à utiliser, ainsi qu’une méthode de transport secondaire pour remplacer la première s’il y a un problème lors de l’établissement de la connexion[1].
References
modifier- « Introduction to SignalR », Microsoft, Microsoft (consulté le )
- « Introduction to WebSockets on Windows Azure Web Sites », Microsoft, Microsoft (consulté le )
- « The EventSource interface », WHATWG, WHATWG (consulté le )
- « Stream Updates with Server-Sent Events », Eric Bidelman, Google Developer (consulté le )
- « The forever-frame technique », Dylan Schiemann, SitePen CEO, Inc. (consulté le )
- « Introduction to Comet », IBM, IBM (consulté le )