Cet article a fait l'objet d'une traduction automatique.

À la pointe

Interrogation longue et SignalR

Dino Esposito

Nous construisons les applications Web de plus en plus sophistiquées d'un protocole qui, paradoxalement, a été conçu et conçu pour beaucoup plus simples formes d'interaction. HTTP n'a aucune prise en charge intégrée pour l'État ou à la même sécurité. Son hypothèse de base est que le client fait une demande au serveur Web émet une réponse. En somme, cela signifie aucune demande, aucune réponse.

Compte tenu de la pénétration actuelle du Web et l'omniprésence des solutions Web, changer les piliers du Web (HTTP, HTML, JavaScript) est hors de question. Mais nous devons améliorer certains de ces piliers ? la réponse est bien sûr ! Applications modernes ont des exigences particulières qui poussent les protocoles Web et les langues à leur limite — ou au-delà.

Dans les épisodes récents de cette colonne, j'ai discuté une main mise en œuvre d'un mécanisme qui interroge le serveur et les rapports des changements pour le client. Le mois dernier, j'ai implémenté la même idée en utilisant les services d'une bibliothèque émergente — SignalR. Maintenant je vais fournir un bref aperçu des techniques et un résumé des options que vous avez aujourd'hui. Je vais mettre SignalR sous les feux de la rampe et de regarder sa mise en œuvre — et une partie de sa magie.

Considérations du scrutin

Compte tenu de la contrainte de demande/réponse HTTP, le vote est la seule façon de mettre en place la communication direct entre un client et un serveur Web. Le client exécute un push de demandes à sa convenance et le serveur répond avec diligence. Pour évaluer l'efficacité du vote est le sens réel que vous assignez à l'expression « à sa convenance ». Il y a toujours une demande client au cœur de toute solution basée sur le Bureau de vote. La demande s'élève jusqu'à ce que le serveur a répondu. Toute demande en attente consomme une connexion du navigateur et, plus important encore, engage un thread du serveur, rendre cette précieuse ressource indisponible aux autres demandes. En bref, des demandes trop fréquents construisent la pression sur le serveur Web.

Mais n'est pas de la capacité du serveur à gérer un nombre croissant de demandes, l'idée de l'évolutivité ? En fait, le scrutin ne crée pas de nouveaux problèmes d'évolutivité, mais elle ajoute un nombre important de nouvelles demandes au serveur qui doit prendre en compte afin d'assurer un serveur évolutif et haute performance. Nous allons voir comment nous pourrions mettre en œuvre des bureaux de vote.

AJAX sondage

Dans mon décembre 2011 (msdn.microsoft.com/magazine/hh580729) et de janvier 2012 (msdn.microsoft.com/magazine/hh708746) colonnes, j'ai présenté un cadre pour le contrôle de la progression d'une opération de distance. L'ensemble du cadre repose sur des appels AJAX. Tout d'abord, le client appelle un point de terminaison de serveur pour démarrer une tâche potentiellement longue ; Ensuite, il établit une minuterie pour placer des appels simultanés à un autre point de terminaison toutes les 500 millisecondes. Comme la tâche de serveur fait son travail, il met à jour un emplacement connu. Le point de terminaison de serveur qui a invoqué périodiquement vérifie simplement les données à cet endroit et retourne tout le contenu qu'il trouve au client.

Ce modèle d'AJAX-vote fonctionne merveilleusement et est largement utilisé dans de nombreux scénarios de l'industrie. La plupart des sites qui fournissent de nouvelles mises à jour ou live scores suivent ce modèle. Dans mes articles, j'ai simplement adapté le patron au scénario spécifique de suivi de la progression d'une opération de distance.

En fin de compte, le problème avec le vote de l'AJAX est de déterminer l'intervalle d'actualisation droit — qui représente un bon équilibre entre la pression sur le serveur et l'exactitude des renseignements signalés aux utilisateurs. Une solution efficace de AJAX-vote donne un sens concret « à des clients commodité » en envoyant des demandes.

Vote long

Avant AJAX, les développeurs a utilisé l'actualisation meta balise HTML pour ordonner aux navigateurs pour actualiser une page chaque nombre donné de secondes. Avec vote AJAX, vous obtiendrez la même chose, mais en de façon beaucoup plus lisse.

Pour un nombre croissant d'applications, cependant, cette forme de vote pas assez. Vote AJAX introduit presque inévitablement un délai entre la survenance d'un événement sur le serveur et la notification de l'événement pour le client. Réglage de la fréquence des mises à jour, vous pouvez travailler les bonnes solutions, mais vote AJAX ne peut pas livrer ce lien constant et continu que de nombreuses applications (surtout sociales) semblent avoir besoin aujourd'hui.

La solution ces jours semble être long du scrutin. Curieusement, lorsque AJAX est apparu il y a ans, vote plus intelligente de AJAX remplacé vote depuis longtemps parce que ce dernier ne était pas très efficace sur le Web. Long du scrutin est à faire sur le Web les mêmes choses que vous faites dans un scénario de bureau. Avec le vote de long, le client accorde la demande et le serveur n'est pas répondre jusqu'à ce qu'il a des informations à retourner. Le client Web maintient une connexion en attente qui est fermée que lorsqu'une réponse valide peut être retourné. C'est exactement ce que vous voulez aujourd'hui — sauf qu'il a le potentiel de ralentir le serveur Web.

Long du scrutin met un plus petit nombre de requêtes vers le serveur, comparé avec le vote de l'AJAX, mais chaque demande pourrait prendre beaucoup plus de temps. Au fil du temps, cela peut être préjudiciable à la santé du serveur Web parce qu'il garde de threads serveur engagés jusqu'à ce qu'une réponse peut être générée. Avec threads moins de travail disponibles à un moment donné, le serveur Web inévitablement obtient plus lent à répondre à toute autre demande, il reçoit. Pour être efficace, long de vote doit quelque travail sérieux de mise en œuvre et des compétences de programmes multithreads et parallèles. Ainsi, pendant des années, long de vote n'était pas vraiment une option, mais il n'avait aucune importance parce qu'il n'y n'avait aucun demande pour la connectivité continue.

Aujourd'hui, avec la bibliothèque parallèle de tâches dans Microsoft.NET Framework 4 et autres installations dans ASP.NET pour construire des gestionnaires HTTP asynchrones, longs de vote est devenu une option viable. Globalement, il est encore plus difficile qu'un cadre AJAX-Bureau de vote correspondant de trahir un cadre long-vote. Vous avez besoin d'un environnement de serveur bien conçu qui ne taxe pas le serveur Web et un environnement de client qui peut supporter une longue interrogation. Vote depuis longtemps, en fait, se réfère à une opération de client/serveur de macro qui se développe sur le Web et nécessairement sur un certain nombre de paquets de demande/réponse HTTP classiques. Le client doit être suffisamment intelligent pour établir une nouvelle demande immédiate jusqu'à ce que l'opération de macro se termine. Je vais revenir sur ce point plus tard.

SignalR à la rescousse

SignalR est un framework de Microsoft, spécialement conçu pour faciliter la communication client-serveur en temps réel. Il fournit une implémentation efficace de long du scrutin qui n'a pas un impact profond sur le serveur et en même temps, il s'assure que les clients sont correctement mises à jour sur ce qui se passe à distance. La figure 1montre un extrait de code j'ai présenté dans mon dernier article. La classe BookingHub est la méthode que vous appelez à partir du navigateur Web pour démarrer l'opération de macro « réserver le vol. »

Figure 1 SignalR classe qui exécute une opération Multistep

public class BookingHub : Hub
{
  public void BookFlight(String from, String to)
  {
    // Book first leg
    Clients.displayMessage(
      String.Format("Booking flight: {0}-{1} ...", from, to));
    BookFlightInternal(from, to);
    // Book return
    Clients.displayMessage(
      String.Format("Booking flight: {0}-{1} ...", to, from));
    BookFlightInternal(to, from);
    // Book return
    Clients.displayMessage("Charging credit card ...");
    ChargeCreditCardInternal();
    // Some return value
    Clients.displayMessage("Flight booked successfully.");
  }
}

C'est clairement une opération en plusieurs étapes, et pour chaque étape, la classe envoie une notification au client. Combien de demandes HTTP sont impliqués ? Jetons un coup de œil avec Fiddler (voir Figure 2).

La figure 2 la pile complète des requêtes HTTP pour l'opération de réservation de vol

À l'intérieur d'une opération SignalR

La première demande est déclenchée lorsque vous appelez le début de la méthode de la page du client ; Ceci identifie le client à la SignalR back-end. Il est à noter que la première demande est une demande particulière de négociation. Il sera toujours AJAX indépendamment du transport final négocié pour la connexion. N'importe quelle page SignalR Web inclut du code comme suit qui s'exécute lorsque le charge d'une page :

$(function () {
  var bookingHub = $.connection.bookingHub;
  bookingHub.start();
}

De cette façon, la page déclare son intention d'ouvrir une connexion pour appeler les services de l'objet côté serveur bookingHub. Notez qu'il est SignalR qui fait la magie de la création d'un objet client selon l'interface publique de l'objet côté serveur concentrateur. Le nom de l'objet JavaScript correspond au nom de l'objet serveur. Toutefois, vous pouvez utiliser l'attribut HubName pour modifier le nom utilisé sur le client :

[HubName("booking")]
public class BookingHub : Hub
{
  ...
}

La demande de démarrage renvoie un ID de client que le client va passer avec toutes les demandes successives.

{"Url":"/signalr","connectionId":"2a119962-edf7-4a97-954b-e74f2f1d27a9"}

Ensuite, la bibliothèque cliente met une autre demande de connexion. Il s'agit de la demande de « se connecter », qui se traduira par l'événement OnConnect être soulevée pour la connexion sur le serveur. Figure 3 montre un couple de demandes de connexion.

La figure 3, réitérant les demandes de connexion

La première, achevée en deux minutes ; la seconde est toujours en attente. C'est l'essence de long de vote — le client dispose d'un canal ouvert en permanence avec le serveur. Le serveur de temps à la demande après deux minutes si aucune action n'est exécutée sur le serveur qui nécessite l'envoi de données vers le client. Dans la demande de réservation de vol UI, il y a un bouton, que l'utilisateur peut cliquer pour commencer la réservation du vol. Lorsque l'utilisateur clique sur le bouton s'exécute le code suivant :

bookingHub.bookFlight("fco", "jfk");

Si vous avez créé l'exemple d'application de la colonne du mois dernier, ce code devez vous ont lien avec le gestionnaire d'événements click du bouton de page.

L'objet bookingHub appartient à un script qui SignalR télécharge via l'URL signalr/concentrateurs, comme le montre Figure 3. bookingHub est un objet simple proxy qui masque la complexité de la mise en œuvre d'un modèle long-Bureau de vote. En cliquant sur le bouton déclenche une nouvelle requête sur le serveur où l'ID client est incorporé. Lorsque le serveur reçoit un appel d'un client qui a un appel en attente, il se termine l'appel en attente et commence le traitement de la demande de nouveau, comme le montre Figure 4.

L'opération en plusieurs étapes de la figure 4 est prenant Place

Figure 4 montre une demande en attente (signalr/envoi), les deux demandes et une autre en attente de la demande. La demande de signalr/envoi est l'appel initial à l'exploitation de la macro pour la réservation du vol, dont le code source est montré dans Figure 1.

Le code de Figure 1 invite le client à différents stades d'aviser de tout progrès, comme suit :

Clients.displayMessage(...);

En même temps qu'une demande de signalr/envoyer est placée, une autre demande commence à attendre pour les notifications. Cette demande attend jusqu'à ce qu'il y a certaines données à renvoyer. Tout appel aux Clients dans le code serveur remplit la demande de notification et immédiatement déclenche un autre par le client, si la séquence Figure 4 signifie que les deux étapes ont été franchies et deux messages d'avancement ont été reçues par le client. Le processus serveur est maintenant occupé à accomplir la troisième étape. À la fin du code dans Figure 1, toutes les demandes en Figure 4 seront terminées et la situation sera de retour à un semblable à ce qui est montré dans Figure 2.

Au-delà du scrutin Long

Si vous comparez le comportement de longue telle qu'implémentée dans SignalR avec les étapes de vote je l'indiquais dans mes articles sur le vote de l'AJAX, vous devez reconnaître un modèle commun — le patron de l'indicateur de progression. AJAX du scrutin et long de vote est deux implémentations différentes du même modèle. Celui qui est le plus efficace dépend de la configuration du serveur Web et les conditions de la demande. C'est votre appel. En tout cas, si vous optez pour le vote long, vous devez SignalR ou une bibliothèque analogue. Si vous souhaitez créer votre propre cadre, je suggère que vous optiez pour les appels de nombreux-mais-rapide du scrutin de l'AJAX contre les appels de moins-mais-plus de long du scrutin.

Construction d'un cadre efficace de long-Bureau de vote peut être difficile. Avec vote AJAX vous probablement ne soyez connectivité continue, mais vous ne risquez aussi de ralentir le serveur. Dans cet esprit, je probablement ne tout le monde et à n'importe quel serveur Web en temps réel, de que je prends soin jour SignalR. Cependant, une fois SignalR est sorti, je ne vois aucune raison de ne pas l'utiliser pour de nouvelles applications.

Enfin, il est important de mentionner que SignalR supporte maintenant les autres transports de niveau supérieurs en dehors du scrutin long. Dans la dernière source, vous trouverez également le support des WebSockets sur les serveurs Windows 8 ; Serveur envoyé des événements sur Chrome, Firefox, Opera et Safari ; et pour toujours cadrer sur Internet Explorer. La bibliothèque commence au début de la liste et empêche la chute arrière jusqu'à ce qu'on trouve un transport pris en charge. Donc, en fin de compte, depuis longtemps du scrutin sera effectivement rarement utilisé dans la plupart des cas.

Dino Esposito est l'auteur de « Programming ASP.NET 4 (Microsoft Press, 2011) 4 » et « Programming ASP.NET MVC 3 » (Microsoft Press, 2010) et co-auteur de "Microsoft.NET: Architecting Applications for the Enterprise” (Microsoft Press, 2008). Basé en Italie, Dino Esposito participe régulièrement aux différentes manifestations du domaine organisées aux quatre coins du monde. Suivre sur Twitter à Twitter.com/despos.

Merci à l'expert technique suivant d'avoir relu cet article: Damian Edwards