Techniques de communication en temps réel

Nous explorons le besoin de communications et d'obstacles en temps réel, ainsi que les techniques / cadres qui aident.

La vie se déroule en temps réel et l'échange d'informations devrait être le même. Il s'avère que c'est plus facile à dire qu'à faire. Les demandes de communication en temps réel ont fondamentalement changé notre façon de créer des applications Web et des applications clientes connectées. Cependant, c'est la promesse de la technologie de transformer les problèmes en opportunités.

Commençons par un peu d'histoire et explorons comment nous avons activé les communications en temps réel entre les systèmes informatiques. À mesure que les protocoles d'information et les serveurs / clients sont devenus plus intelligents, les développeurs ont pu tirer parti de techniques sophistiquées pour créer un échange d'informations en temps réel. Le résultat final est de meilleures applications connectées et une prise de décision en temps quasi réel – personne ne doute des avantages.

Besoins en temps réel

Nous: Ralentissons. Quelle est l'urgence?

La vie: tiens ma bière. L'information, c'est le pouvoir.

Il s'avère qu'il existe d'innombrables applications modernes qui ne bénéficient pas seulement mais dépendent activement des communications en temps réel pour être fonctionnelles. Voici quelques types d'applications:

1. Chat … Duh!
2. Titres boursiers
3. Enchères / sondages en direct
4. Mises à jour Sports / Actualités
5. Collaboration en ligne
6. Jeux multijoueurs
7. Services de localisation
8. Indicateurs de progrès

Et bien d'autres encore. Les techniques séculaires de communication demande-réponse ne sont souvent pas évolutives pour répondre aux besoins en temps réel des clients connectés modernes. Lorsque le besoin est réel, la technologie doit fournir des communications en temps réel. La bonne nouvelle est que malgré les obstacles, les solutions sont nombreuses et assez brillantes.

The Hurdle

1989 @ CERN — The European Particle Physics Lab. Sir Tim Berners-Lee a commencé les bases de ce qui allait devenir le web moderne aujourd'hui: un serveur et un client. Plus important encore, dans le cadre du World Wide Web Consortium ( W3C ), la norme d'échange d'informations a été établie. Voici la naissance du puissant Hypertext Transfer Protocol, ou comme il est mieux connu aujourd'hui, HTTP .

Le web tel que nous l'utilisons aujourd'hui est assez différent des années 90. Cependant, HTTP, qui est un protocole d'application pour les systèmes d'information collaboratifs distribués, reste le fondement de la communication de données pour le World Wide Web. HTTP a évolué au fil du temps, la norme HTTP / 2 se concentrant sur la sécurité, la compression des données, une meilleure efficacité et une latence plus faible. Cependant, le cœur de la communication HTTP n'a pas beaucoup changé, c'est toujours un protocole de demande / réponse. Un client doit demander des informations et le serveur répond ensuite, ce qui représente un défi fondamental pour les communications en temps réel.

Les solutions

Malgré l'obstacle évident, le besoin de communication en temps réel n'a rien de nouveau. Et pendant des années, nous avons essayé de contourner les barrages routiers HTTP de manière intéressante. Faisons un rapide tour d'horizon des techniques les plus populaires, chacune avec une anecdote du monde réel pour une explication plus facile.

Sondage régulier

Anecdote: Avez-vous déjà fait un long trajet avec de petits enfants? Juste quelques minutes sur la route et les enfants demanderont déjà: "Sommes-nous déjà là?" Vous répondez gentiment, mais la question continue d'être posée de manière répétée. Les parents du monde entier feront preuve d'empathie.

Lors d'un sondage régulier, le client demande à plusieurs reprises au serveur s'il y a de nouvelles informations à partager. L'intervalle des demandes peut varier en fonction des besoins de l'application et le serveur répond généralement sans nouvelles informations. Ce n'est clairement pas en temps réel, mais pourrait avoir certains avantages si l'intervalle d'interrogation est court. L'utilisation abusive de la bande passante n'est pas une préoccupation majeure car la plupart des demandes-réponses ne contiennent pas beaucoup de données, mais l'interrogation régulière implique des allers-retours répétés et inutiles entre le client et le serveur.

Interrogation longue

Anecdote: avec votre tout-petit. Cette fois cependant, lorsqu'on lui a demandé:
"Sommes-nous encore là?", Vous restez simplement silencieux et ne répondez pas avant d'arriver à destination. Ou vous êtes obligé de répondre lorsque vous sentez une crise de colère venir.

L'interrogation longue est une forme avancée d'interrogation, répondant aux communications en temps réel. Le client fait une demande d'informations jusqu'au serveur. Le serveur est simplement assis sur la demande jusqu'à ce que quelque chose de notable se produise ou que la demande soit sur le point d'expirer. Si le serveur répond pour éviter un délai d'attente, le client peut être programmé pour faire une autre demande immédiatement. Cela garantit que le serveur a une demande ouverte pour déclencher une réponse à tout moment – et peut transmettre des informations en temps réel. Bien que les longs sondages continuent d'être populaires, ils nécessitent souvent une orchestration personnalisée sur le serveur et le client pour être correctement implémentés.

Événements envoyés par le serveur

Anecdote: Vous magasinez en ligne sur un site Web de vente au détail populaire et acceptez de une case à cocher des termes et conditions inoffensifs. Bam – vous êtes inondé de fragments d'e-mails marketing trois fois par jour, sans moyen facile de vous désinscrire.

Les événements envoyés par le serveur facilitent la communication en temps réel, mais sont en grande partie une poussée directionnelle du serveur au client. Un objet EventSource (normalisé en HTML5) est utilisé côté client pour capturer les notifications de diffusion à partir du serveur.

Forever Frames

Anecdote: Vous avez eu une rupture pas si amusante, mais une partie de vous ne veut pas oublier votre ex-petit ami / petite amie, peut-être par curiosité. Vous définissez un moment personnel secret chaque jour – pour vérifier les mises à jour de la présence sociale de votre Ex.

Forever Frame est une technique principalement spécifique à IE pour aider dans les communications en temps réel, et implique une iFrame cachée côté client qui maintient un connexion au serveur par script. Le serveur envoie des morceaux d'informations reçus dans l'iFrame et gérés par un code personnalisé côté client.

WebSockets

Anecdote: Vous avez appris à dire "Bonjour" dans une langue étrangère avant de visiter le site respectif. nouveau pays. Lors de votre première interaction, quelqu'un vous dit bonjour et vous répondez joyeusement en langue maternelle. Les vannes se sont ouvertes – et vous êtes frappé par le barrage de la langue locale, que vous compreniez ou non.

Avec la normalisation HTML5, les WebSockets sont devenues une merveilleuse technique (lire des trucs de licorne magique) pour faciliter les communications en temps réel. Au début, le serveur-client fait une petite poignée de main – pour s'assurer qu'ils peuvent tous les deux parler la même langue sur WebSockets. Une fois les négociations en place, WebSockets permet une véritable connexion persistante pour les communications bidirectionnelles – le serveur peut appeler le client et le client peut appeler le serveur à tout moment. Les WebSockets bénéficient désormais d'un large support de plateforme, permettant ainsi l'échange d'informations en temps réel avec une faible latence.

Tout mettre ensemble

Il existe donc clairement plusieurs techniques pour contourner les obstacles HTTP et faciliter les communications en temps réel. Le problème est que la plupart de ces techniques demandent un peu de travail au développeur. La pile réseau est une entreprise délicate – ne serait-ce pas bien s'il y avait des cadres qui résumaient la complexité des communications, afin que les développeurs puissent se concentrer sur la création d'applications en temps réel? Heureusement, oui – ils sont open source et assez brillants.

SignalR

SignalR facilite l'ajout de communications en temps réel aux applications Web exécutant ASP.NET et aux clients connectés sur une grande variété de plates-formes. Alors que SignalR a commencé il y a des années avec ASP.NET MVC, le dernier redémarrage s'appelle SignalR Core – il fonctionne sur ASP.NET Core et apporte une tonne de maturité.

SignalR fournit des API pour les appels de procédure distante (RPC) bidirectionnels entre serveur-client et résume les complexités de communication en temps réel. Alors que l'application d'hébergement SignalR doit être écrite en ASP.NET Core, les clients connectés peuvent être pris en charge dans divers langages de programmation, tels que JavaScript, .NET, Java, C ++ et les plates-formes mobiles. La forme préférée de transport en temps réel, ainsi que les techniques de sauvegarde, sont choisies spécifiquement pour une paire client-serveur donnée. Les développeurs bénéficient de SignalR qui fournit un canevas d'API uniforme pour la gestion des connexions et des clients, ainsi qu'une mise à l'échelle pour gérer l'augmentation du trafic. SignalR utilise le concept de concentrateurs côté serveur pour faciliter la communication et la gestion en temps réel des clients connectés. Le serveur et le client peuvent invoquer de manière transparente des méthodes l'un sur l'autre, et ces interactions peuvent être fortement typées. Bien que le format JSON basé sur du texte soit le format par défaut, SignalR prend également en charge le protocole Messagepack – sérialisation / désérialisation binaire des données pour une efficacité accrue.

SignalR concerne la communication en temps réel – les données de surfaçage changent le plus rapidement possible pour toutes les personnes connectées. Et cela fonctionne même si vous utilisez une interface utilisateur complexe et raffinée, comme DataGrids dans Kendo UI et Telerik UI pour ASP.NET MVC ou ASP.NET Core . L'objet DataSource sous-jacent utilisé pour la liaison d'objet facilite la communication avec les concentrateurs SignalR – nous vous couvrons.

gRPC

gRPC est un cadre RPC universel hautes performances, initialement développé chez Google. L'objectif ici est également d'abstraire les complexités au niveau de la couche réseau et de permettre aux développeurs de se concentrer sur la création d'applications en temps réel.

gRPC génère automatiquement des liaisons client / serveur multiplateformes idiomatiques pour une variété de langues et de plates-formes. La définition du service gRPC et le format d'échange d'informations sont Protocol Buffers – un puissant ensemble d'outils et de langage de sérialisation / désérialisation binaire. gRPC, prêt à l'emploi, offre de riches fonctionnalités telles que l'authentification intégrée, le streaming bidirectionnel et le contrôle de flux.

Conclusion

La vie est courte et les informations doivent être partagées en temps réel. Alors que les principes fondamentaux de HTTP ont fourni les premiers obstacles, des solutions techniques intelligentes ont rapidement trouvé le moyen de contourner le problème. Aujourd'hui, nous avons une pléthore de techniques de communication en temps réel puissantes et fiables – comme les WebSockets, les événements envoyés par le serveur et les longues interrogations. Et les frameworks open source comme SignalR et gRPC évitent une grande partie de la complexité de la couche réseau. Les développeurs se retrouvent avec des opportunités d'applications en temps réel où le ciel est la limite. En avant et vers le haut jusqu'à la prochaine application de chat en temps réel "Hello World"!