9 février 2015 Groupe .NET/ASP.NET Sujets: Push to the Web - Le protocole Websocket et la librairie SignalR Conférencier: Dominic Marchand L'avènement des WebSockets et de la librairie SignalR permettent l'ajout de fonctionnalités "temps-réel" à des applications web de façon simple et élégante. Dans cette présentation, nous allons faire un survol du protocole, de la librairie SignalR en plus de voir plus spécifiquement quels scénarios ils permettent et comment échelonner son implémentation lorsque nécessaire.

1. Push to the Web - Le protocole WebSocket
et la librairie SignalR
Dominic Marchand
9 février 2015

2. À propos de moi
• Développeur web depuis 1996
• Réseautique / DevOps
• Agences et médias
• Stack Microsoft
• Aujourd’hui : backend électoral
pour Radio-Canada
@domimarch

3. Aujourd’hui – Push to the web
• Scénarios typiques
• D’où on part
• WebSocket
• SignalR
• Les bases
• Connexions
• Groupes
• Sécurité
• Performance / Scaling
• Conclusion

4. Scénarios typiques
• HTTP = OK pour énormément de cas d’utilisation, mais pas toujours…
• Discussions et messagerie en ligne (webchat)
• Informations financières et boursières (stock tickers)
• Enchères
• Jeux
• Résultats sportifs et électoraux
• Consoles de monitoring et autres dashboards dynamiques
• Capteurs (sensors)

5. D’où on part
• HTTP = stateless
• Serveur ne peut pas « initier » un échange
• Solutions inélégantes, workarounds
Comet | HTTP server push | Pushlet | Long polling | Flash XMLSocket relays
• Autres protocoles
IRC | BitTorrent | Push Access Protocol

6. WebSocket
• Protocole/API issu du standard HTML5 offrant un canal de communication
full-duplex sur une connexion TCP
• Seul lien avec HTTP : le handshake se fait au moyen d'une requête HTTP/S
de type UPGRADE
• Communication se fait en TCP sur le port 80/443, donc firewall-friendly

7. WebSocket – Support
CLIENT
• Firefox 6
• Safari 6
• Chrome 14
• Opera 12.10
• IE 10
• Inclut les versions
mobiles de ces
navigateurs
SERVEUR
• IIS 8
donc Windows 8 ou
Windows Server 2012

8. WebSocket
DEMO : JabbR

9. SignalR
• Librairie ASP.NET pour applications real-
time, 2-way
• Développement et support par Microsoft
• .NET Framework 4
• Open Source
• Event-driven
• Asynchronous
• Scalable
• Multiple transports
• Librairies client pour javascript (browser) et
.NET (server as client, WPF, WinForms,
WinRT, WinPhone, Console, etc.) via Nuget

10. SignalR
DEMO : Setup + Hubs

11. SignalR – Transports
• Support pour 4 différents types de transport;
tout est géré de façon transparente par
SignalR (aucune configuration)
• Niveaux disponibles (dans cet ordre)
• WebSocket
[ requiert IIS 8 sur le serveur et .NET 4.5 pour le runtime ]
• Server Sent Events / EventSource
[ sans cross domain; IE ne supporte pas ]
• Forever Frame
[ utilisation d’un <iframe />, IE seulement ]
• Ajax Long Polling

12. SignalR
DEMO : Transports

13. SignalR – Cycle de vie d’une connexion
• 3 niveaux d’abstraction de connexions
• SignalR (lien logique entre un client et un URL, y’a un ConnectionId unique
pour chaque connexion client/serveur)
• Transport (lien logique qui est lié au type de transport utilisé)
• Physique (câble réseau, lien wifi, routeurs, etc.)
• Une perte de connexion du réseau PHYSIQUE n’implique PAS
NÉCESSAIREMENT une perte de la connexion TRANSPORT

14. SignalR – Cycle de vie d’une connexion
• Start – déclenche le processus de handshake entre le client et le serveur,
c’est là que la sélection du type de transport optimal s’effectue
• ConnectionSlow – mécanisme de keepalive et disconnectTimeout – 10
secondes par défaut
• Reconnecting – handshake est essayé à nouveau – la connexion
logique n’est pas encore « perdue »
• OnReconnected – indique à la connexion logique (sur le serveur) que le
client a réussi à se rebrancher
• OnDisconnected (serveur) / Closed (client) – la connexion physique a
été perdue et le transport est fermé
• Stop – la connexion logique SignalR est complètement terminée
(volontaire ou non)

15. SignalR – Cycle de vie d’une connexion

16. SignalR – Cycle de vie d’une connexion

17. SignalR – Cycle de vie d’une connexion

18. SignalR – Cycle de vie d’une connexion

19. SignalR – Cycle de vie d’une connexion
• Les valeurs par défaut de KeepAlive (10 sec.), DisconnectTimeout
(30 sec.) et ConnectionTimeout (110 sec., utilisé pour le long polling)
peuvent être modifiées
• Les événements ConnectionSlow, Reconnecting et
Disconnected peuvent être utilisés pour informer le client de ce qui se
passe
• On peut automatiquement ré-appeler Start() dans le handler
Disconnected pour continuellement reconnecter un client
• Depuis SignalR 2.1, on peut aussi savoir si la fin d’une connexion était
voulue ou pas (stopCalled sur serveur, lastError sur client)
• Une option de debugging avancé est disponible pour voir plus de détails

20. SignalR
DEMO : Cycle de vie d’une connexion

21. SignalR - Groupes
• Un groupe représente un sous-ensemble d’utilisateurs à qui envoyer
certains messages, donc qu’on ne veut pas broadcaster à tous (une
chat room, un item spécifique dans une plate-forme d’enchères, une
circonscription dans le cadre d’une élection, une partie spécifique
pour un service de résultats sportifs, etc.)
• Les groupes sont créés et supprimés automatiquement par SignalR et
il n’y a pas d’API de gestion des groupes
• Aucune persistence d’un « abonnement » à un groupe au-delà de la
connexion logique SignalR, mais supporté lors d’un
OnReconnected
• Ce n’est PAS un mécanisme de sécurité

22. SignalR
DEMO : Groupes

23. SignalR - Sécurité
• Y’a aucune mécanique d’authentification des utilisateurs dans SignalR; tout doit
se faire en amont, dans l’application web qui « host » la couche SignalR
• On peut cependant appliquer l’attribut Authorize sur un Hub ou sur une
méthode spécifique d’un Hub
• Si de l’information sensible est échangée par SignalR, il est fortement
recommandé d’utiliser le protocole HTTPS/SSL/TLS qui fera aussi en sorte que les
échanges WebSocket seront sécurisés (wss:// au lieu de ws://)
• Les requêtes cross domain sont refusées par défaut; dans la mesure du possible,
laisser tel quel mais c’est possible de les autoriser
• Si on ne veut pas exposer tous les noms de méthodes disponibles sur un Hub, on
peut désactiver la génération dynamique de proxy pour javascript
• Ne pas retourner les exceptions aux clients; utilisez plutôt la méthode
DisplayError dans vos catch()

24. SignalR
DEMO : Sécurité

25. SignalR - Performance
• Fréquence élevée (plusieurs messages par seconde) ? Batch
• Réduire la taille des messages
• Paramètres de performance sur le serveur
• SignalR : DefaultMessageBufferSize
• IIS : appConcurrentRequestLimit
• ApplicationPool : queueLength et maxConcurrentRequestsPerCPU
• Utiliser WebSocket (IIS 8 + .NET 4.5) si possibleCompteurs de
performance disponibles (Microsoft.AspNet.SignalR.Utils)
• Outils de load testing : Crank

26. SignalR - Scaling
• Si un serveur ne suffit plus, Scaleout !
• Trois backplanes disponibles (via Nuget) :
• Azure Service Bus
• Redis
• SQL Server
• Une seule ligne de configuration !
GlobalHost.DependencyResolver.UseServiceBus(connString, "MyApp");
• Attention : backplane peut devenir un
bottleneck

27. SignalR - Conclusion
• Idéal pour les scénarios évoqués au début de la session
• Même si WebSocket n’est pas disponible (IIS < 8 et .NET < 4.5), allez-y
quand même
• Facile à implémenter, autant du côté serveur que client
• Pour des scénarios à petit ou moyen volume, c’est plug-and-play
• Pour des scénarios à grand volume, il faudra assurément fine tuner les
serveurs
• Pour des scénarios à grande fréquence, il faudra probablement
ajuster le code
• Bien documenté et communauté active d’utilisateurs

28. Merci :-)
http://asp.net/signalr