1. Qu’est-ce que SignalR :
ASP.NET SignalR est une bibliothèque de classes fournie pour simplifier le processus d’ajout de contenu web en direct aux applications par les développeurs. La fonctionnalité web en temps réel consiste à permettre au code serveur de pousser activement du contenu aux clients à tout moment, plutôt que de faire attendre au serveur une requête du client (avant de retourner du contenu).
Tous les types de fonctionnalités web « en direct » peuvent être ajoutés à votre application ASP.NET via SignalR. L’exemple le plus couramment utilisé est celui des salons de discussion, mais nous pouvons faire bien plus que cela. Considérons les situations suivantes : les utilisateurs doivent constamment actualiser la page web pour voir les données les plus récentes ; Ou récupérer (et afficher) de nouvelles données sur la page en implémentant un long polling, puis vous pouvez envisager d’utiliser SignalR pour ce faire. Par exemple : tableaux de bord et applications de surveillance ; Applications collaboratives (par exemple, plusieurs personnes éditant des documents en même temps) ; Mises à jour sur l’avancement du poste, formulaires de présentation en temps réel, etc.
SignalR convient également aux nouveaux types d’applications web nécessitant des mises à jour à haute fréquence depuis le serveur, comme le jeu en temps réel. Voici un bon exemple : ShoorR.
SignalR fournit une API simple permettant aux utilisateurs de créer des appels de procédures distantes (RPC) serveur vers client, facilement accessibles depuis le côté serveur. Code net. SignalR inclut également des connexions (par exemple, événements de connexion et de déconnexion) ainsi que le regroupement de connexions.
SignalR peut gérer automatiquement les connexions. Et cela vous permet d’envoyer des messages diffusés à tous les clients connectés, comme dans un salon de discussion. Bien sûr, en plus de l’envoi massif, vous pouvez aussi envoyer des messages à des clients spécifiques. La connexion entre le client et le serveur est persistante, contrairement au protocole HTTP traditionnel, qui nécessite de rétablir la connexion pour chaque communication.
SignalR prend en charge la fonctionnalité « push serveur », où le code serveur peut appeler le code client dans le navigateur en utilisant des appels de procédures distantes (RPC) au lieu des requêtes actuellement couramment utilisées sur le web – le modèle de traitement correspondant.
Les applications SignalR peuvent être étendues à des milliers de clients en utilisant Service Bus, SQL SERVER ou Redis.
SignalR est open source et accessible via GitHub.
2. SignalR et WebSocket
ignalR utilise la méthode de transport WebSocket - lorsque cela est possible. Et basculer automatiquement vers l’ancienne méthode de transport (par exemple connexion HTTP long). Vous pouvez certainement écrire votre application directement avec WebSockets, mais utiliser SignalR signifie que vous aurez plus de fonctionnalités supplémentaires sans avoir à réinventer la roue. Le plus important, c’est que vous pouvez vous concentrer sur l’implémentation métier sans penser à créer un code compatible séparément pour l’ancien client. SignalR vous permet également d’éviter de vous soucier des mises à jour WebSocket, car SignalR continuera d’être mis à jour pour prendre en charge l’évolution des méthodes de transport sous-jacentes afin d’offrir une interface d’accès cohérente aux applications à travers différentes versions de WebSockets.
Bien sûr, vous pouvez créer une solution qui n’utilise que le transport WebSocket, et SignalR fournit toutes les fonctionnalités dont vous pourriez avoir besoin pour écrire votre propre code, comme revenir à d’autres méthodes de transport et modifier votre application pour les nouvelles implémentations WebSocket.
3. Transport et retour
SignalR est une abstraction de la technologie de transport nécessaire pour implémenter des fonctions en temps réel entre clients et serveurs. SignalR commence par démarrer la connexion avec HTTP et vérifie si le WebSocket est disponible – si oui, passez à la connexion du WebSocket. WebSocket est la méthode de transmission la plus idéale pour SignalR car elle exploite le mieux la mémoire serveur, possède la latence la plus faible et des fonctions sous-jacentes complètes (comme la communication full-duplex entre le client et le serveur), mais elle a aussi les exigences les plus strictes : le serveur doit utiliser Windows Server 2012 ou Windows 8, et en même temps. .NET Framework version 4.5 et supérieure. Si ces exigences ne sont pas remplies, SignalR tentera d’utiliser une méthode de transmission alternative pour se connecter.
4. Expédition HTML5
La méthode de transport utilisée dépend du fait que le navigateur client supporte HTML5, sinon l’ancienne méthode de transport sera utilisée.
WebSocket (si le serveur et le navigateur supportent WebSocket). WebSocket est le seul moyen d’établir une véritable connexion bidirectionnelle durable à la fois côté client et côté serveur. Bien sûr, WebSocket a aussi les exigences les plus strictes : il n’est pris en charge que dans les dernières versions d’IE, Chrome et FF, et n’est que partiellement implémenté dans d’autres navigateurs comme Opera et Safari.
Le serveur envoie des événements, également appelé EventSource (si le navigateur prend en charge les événements d’envoi du serveur, pratiquement tous les navigateurs sauf IE prennent en charge cette fonctionnalité).
5. Transmission par comète
Les types de transport suivants sont basés sur le modèle d’application web Comet, où le navigateur ou le client maintient une longue requête de connexion HTTP, et le serveur peut envoyer des données au client sans demande explicite de la part du client.
Forever Frame (c’est-à-dire uniquement) Forever Frame créera un IFrame caché qui envoie une requête au serveur qui ne sera pas complétée. Le serveur envoie ensuite en continu des scripts au client et est exécuté immédiatement par le client, c’est-à-dire une connexion unidirectionnelle en temps réel du serveur au client. La connexion client-serveur utilise une connexion différente de cette connexion. Par exemple, une requête HTML standard crée une nouvelle connexion pour chaque donnée envoyée.
Le long polling Ajax ne crée pas de connexion persistante, mais interroge en effectuant constamment des requêtes au serveur. Attends que le serveur réponde et ferme cette connexion sur chaque connexion, puis fais immédiatement une nouvelle requête. Bien sûr, cela provoquera un certain délai lorsque la connexion sera réinitialisée et reconnectée.
Pour des informations sur les méthodes de transport prises en charge par diverses configurations, voir Plateformes prises en charge. (IE nécessite 8 ou plus, les autres navigateurs sont la version actuelle -1)
Processus de sélection des méthodes de transfert
La liste suivante montre comment SignalR décide quel type utiliser pour la transmission.
IE8 et les versions antérieures, utilisez le long polling.
Si JSONP est configuré (c’est-à-dire que le paramètre jsonp est réglé sur true lors de la connexion), utilisez le long polling.
Si vous utilisez une connexion inter-domaine (c’est-à-dire que le point de terminaison SignalR et la page ne sont pas dans le même domaine), alors utilisez WebSockets si les conditions suivantes sont remplies :
Le client prend en charge le partage de ressources inter-domaine (CORS), voir CORS à pour plus de détails
Le client prend en charge WebSocket
Le serveur prend en charge WebSocket
Si l’une des conditions ci-dessus n’est pas remplie, un sondage long est utilisé. Pour plus d’informations sur les connexions inter-domaines, voir Comment établir des connexions inter-domaines.
Si vous ne configurez pas l’utilisation du JSONP et que la connexion n’est pas cross-domaine, utilisez WebSocket, bien sûr, à condition que le client et le serveur supportent WebSocket.
Si le client ou le serveur ne prend pas en charge les WebSockets, utilisez le serveur pour envoyer des événements.
Si le serveur envoie un événement non disponible, utilisez une Forever Frame.
Si Forever Frame n’est pas disponible, utilisez le long polling.
Transmission par moniteurs
Vous pouvez voir la méthode de transport utilisée par votre application en activant la journalisation du Hub et dans la console de votre navigateur.
Pour activer la journalisation, ajoutez la commande suivante à l’application cliente :
nnection.hub.logging = vrai ;
6. Inspection et transport :
Vous pouvez voir la méthode de transport utilisée par votre application en activant la journalisation du Hub et dans la console de votre navigateur. Pour activer la journalisation, ajoutez la commande suivante à l’application cliente :
nnection.hub.logging = vrai ;
$.connexion.hub.logging = vrai ;
Dans IE, appuyez sur F12 pour ouvrir les outils de développement et cliquez sur l’onglet Console.
Dans Chrome, appuyez sur Ctrl+Majus–J pour ouvrir la console
En observant la connexion dans la console, vous pouvez voir la méthode de transmission utilisée par SignalR.
7. Transport désigné :
Négocier la méthode de transmission nécessite un certain temps et les ressources du serveur/client. Si l’environnement client est connu, alors la méthode de transport peut être spécifiée lors de l’initiation de la connexion pour améliorer les performances. Le code suivant démontre l’utilisation du long polling d’Ajax directement à l’initiation de la connexion si le client est connu pour supporter un autre protocole :
connexion.start({ transport : 'longPolling' }) ;
Si vous souhaitez qu’un client négocie le transport dans un ordre précis, vous pouvez spécifier l’ordre dans lequel la négociation est tentée. Le code ci-dessous montre comment essayer d’utiliser d’abord WebSockets et utiliser un long polling directement après l’échec.
connexion.start({ transport : ['webSockets','longPolling'] }) ;
Les constantes de chaîne spécifiées par l’utilisateur sont définies comme suit :
WebSockets
forverFrame
serverSentEvents
longPolling
8. Connexions et hubs L’API SignalR comprend deux modèles de communication client-serveur : les connexions persistantes et les hubs.
Une connexion représente un point d’extrémité simple pour envoyer un message unique, groupé ou diffusé. L’API PersistentConnection (représentée par la classe PersistentConnection dans le code .NET) donne aux développeurs un accès direct au protocole de communication sous-jacent de SignalR. Les développeurs ayant utilisé des API basées sur la connexion telles que WCF seront plus familiers avec le modèle de communication de connexion.
Les hubs sont des pipelines de communication basés sur une API mais de niveau supérieur qui permettent aux clients et serveurs d’appeler directement les méthodes entre eux. SignalR fait un excellent travail pour gérer la planification inter-machines, permettant aux clients d’appeler facilement des méthodes sur le serveur comme s’ils appelaient des méthodes locales, et inversement. Les développeurs ayant utilisé des AIP basées sur des appels à distance comme .Net Remoting seront plus familiers avec le modèle de hub. Avec le hub, vous pouvez aussi passer des paramètres fortement typés aux méthodes et les lier au modèle.
Diagramme d’architecture : Le diagramme ci-dessous montre la relation entre le moyeu, la connexion continue et la technologie sous-jacente utilisée pour le transport.
9. Comment fonctionne le hub :
Lorsque le code serveur appelle le client, le serveur envoie un paquet contenant la méthode appelante et les paramètres (lorsque l’objet est utilisé comme paramètre de méthode, il sera sérialisé en JSON à envoyer) au client. Le client vérifie alors le nom de la méthode reçue et effectue une recherche de correspondance dans la méthode définie par le client, et si la correspondance est réussie, la méthode est exécutée et l’objet désérialisé est utilisé comme paramètre de la méthode.
Vous pouvez utiliser des outils comme Fiddler pour surveiller l’exécution des appels de méthode. L’image suivante montre une méthode capturée à partir des journaux de Fiddler pour être envoyée du serveur SignalR au client du navigateur web. La méthode initiée depuis le hub s’appelle MoveShapeHub, et la méthode est updateShape.
Dans cet exemple, le nom du hub est identifié par le paramètre « H », le nom de la méthode par le paramètre « M », et l’objet paramètre envoyé à la méthode est identifié par le paramètre « A ». L’application générant le message a été implémentée dans le tutoriel de communication en temps réel haute fréquence.
Choisissez un modèle de communication :
La plupart des applications utilisent l’API du hub, qui peut être utilisée dans les situations suivantes :
Vous devez spécifier le format dans lequel le message est envoyé.
Les développeurs préfèrent utiliser un modèle de messagerie et de planification plutôt qu’un modèle d’appel à distance
Le modèle de messagerie est utilisé dans des applications existantes et il est prévu d’être porté vers SignalR.
|
Publié sur 05/07/2017 10:21:40
|
|
|
|
Propriétaire