SignalR : les websockets façon ASP-principe de fonctionnement

Parcourant depuis quelques temps la Virtual Academy de Microsoft pour me former à l’architecture système, je suis passé par leur Jump Start sur la création d’application web avec ASP.NET.

Outre l’intérêt très fort que j’ai pour ce framework qui permet de faire des sites mais aussi des API web, j’ai pu y découvrir un outil assez formidable : SignalR.

Le problème que tente de résoudre SignalR est celui très connu du partage en temps réel. Faire un chat en javascript avec la technologie AJAX (ou tout simplement de l’asynchrone) est une problématique qui est apparue depuis longtemps. Pourtant un problème se pose : comment on fait communiquer les mises à jours à tous les membres?

Une technique est le long polling, c’est à dire qu’on va demander sans cesse au serveur des mises à jours. Cette méthode a pour principal inconvénient d’être gourmande en bande passante et surtout en bande passante inutile : dans la plupart de vos requêtes c’est l’entête qui prend le plus de place, ce qui est ridicule.

Autre technique, l’infinite frame. On met une balise iframe mais le serveur n’envoie jamais le message de fin de page. ainsi la frame charge sans cesse et affiche au fur et à mesure les données. Outre que ça utilise les iframe (souvent déconseillé), cela demande un rafraichissement de la page en cas d’interruption du service. En outre certains navigateurs au nom onni ne supporte pas cette technique.

Mais est venu l’HTML5 qui est plus que de l’HTML. HTML5, c’est une API pour plein de choses (vidéo, dessin…) et entre autre les websocket.

fonctionnement d'une websocket

fonctionnement d’une websocket

SignalR est une technologie open source qui partage un développement .NET côté serveur et un plugin JQuery pour le côté client pour utiliser ces websocket et faire du temps réel.

L’avantage de cet outil c’est qu’il comprend que votre utilisateur n’a pas un navigateur de dernière génération et, de manière totalement transparente, va utiliser une des deux techniques citées au dessus en cas de non support des websockets.

En réel, ça donne quoi?

Côté serveur vous allez créer un ou plusieurs hubs. Un hub c’est un ensemble de fonctionnalité autour d’un thème. Par exemple, si vous avez deux outils en temps réel dans votre site, un paint et un chat, vous aurez un hub pour chaque outil. Le hub paint permettant de dessiner des choses et le hub chat d’ajouter, retirer, modifier des messages. Les méthodes du hub sont appelées à chaque communication client vers serveur.

Côté client, vous allez créer des “proxy” en javascript. Ces proxys seront les méthodes appelées par le script à chaque communication serveur vers client.

Dans le prochain poste, je me consacrerai au code afin de montrer la puissance de l’outil.