Jouons un peu avec les websockets

Dans notre présentation d’html5, nous avons brièvement évoqué les websockets.

Les websockets sont un protocole de communication bi-directionnel, standardisé par le w3c et qui est progressivement implémenté par les navigateurs.

La promesse des websockets est d’offrir un mécanisme client / serveur dans votre navigateur. À l’heure actuelle le principal mécanisme existant est HTTP, qui est un protocole sans état.

Concrètement il n’a pas de possibilité de réutilisation de la connexion. Une fois que le serveur a répondu, votre navigateur affiche la réponse mais le serveur n’a pas la possibilité de dire «oups j’ai oublié de te dire quelquechose».

Qui plus est la réponse est enrobée d’un tas de données complémentaires (headers…). Ce n’est pas le cas pour les websockets.

Utiliser les websockets

La question qui brûle les lèvres est «peut on l’utiliser là tout de suite ?»

Oui, d’ailleurs nous le faisons. Coté navigateur, utiliser les websockets directement comporte les même soucis que faire du js pur, c’est à dire qu’il y a un certain nombre d’implémentations.

D’autre part la fonctionnalité a été désactivé dans Firefox 4 et 5 (puis réactivée), suite à la découverte d’une faille de sécurité.

Opera 11 l’a aussi désactivé pour cette raison tandis qu’Internet Explorer ne la supporte pas encore.

Une nouvelle version corrige cette faille du protocole. Elle est implémentée par Firefox 6+ et Chrome 14+.

Pourquoi l’utiliser si ce n’est pas encore supporté partout ?

Comme pour HTML5 ou CSS3, la prise en charge va aller croissante, et tous les navigateurs vont être amenés à l’implémenter (même IE 10).

Et puis il existe aussi des outils capables de mettre en œuvre des mécanismes de substitutions quand la fonctionnalité n’est pas présente ou activée.

socket.io

socket.io est un outil fantastique, capable d’utiliser plusieurs fallback si les websockets ne sont pas disponibles:

• socket flash
• ajax
• iframe
• jsonp

Cela vous ouvre la porte à tous les navigateurs, même mobiles.

L’utilisation est vraiment simple, on démarre une écoute côté serveur, on récupère côté client le fichier socket.io.js livré par le serveur (grâce à une balise script), et les deux parties sont prêtes à discuter.

socket.io vous permet de faire facilement du broadcast ou de la gestion de channel. Quant à la déconnexion, elle est prévue de base par le protocole.

Sécurité

On l’a vu plus tôt la spécification évolue pour prendre en compte la sécurité.

Et comme http a https, ws a son pendant wss qui permet d’ouvrir une connexion sécurisée.

En route vers le temps réel

Les websockets ne sont pas comparables à AJAX, elles permettent l’ouverture d’un canal de communication entre le client et le serveur. Du coup le serveur peut devenir une passerelle entre clients, par exemple pour réaliser un tchat.

De même les weksockets peuvent permettre de communiquer entre serveurs, ce n’est pas une technologie utilisable uniquement par les navigateurs.

De nombreuses implémentations existent dans différents langages, que ce soit PHP, Java ou encore ruby et javascript (node.js).

Il existe même un framework bâti avec ruby, cramp

Démo

Plutôt que de vous ennuyer avec un tchat j’ai écrit un puissance 4, afin que 2 joueurs puissent s’affronter.

Le code est disponible sur github.

Puissance 4 from synbioz on Vimeo.

L’essentiel du code est dans src, et il n’est pas énorme, environ 160 LOC de coffee pour le serveur et une 100aine pour le client.

À propos du code

La présence d’un Gemfile est simplement liée au fait que j’utilise un guardfile pour compiler mon coffeescript en javascript.

La couche serveur est gérée en node.js, la page web est statique.

Pour faire tourner le jeu vous avez uniquement besoin de node, npm et du module socket.io

Le jeu est en fait représenté par une classe game. Le client n’a pas de référence sur le jeu, toute la logique du jeu est gérée par le serveur.

Le serveur est en attente de connexion. Une fois qu’un client se connecte il vérifie qu’un jeu est disponible et le signifie au client si c’est le cas en lui indiquant s’il est le joueur 1 ou 2.

Si aucun jeu n’est démarré et que la limite (2 actuellement) n’est pas atteinte, un jeu est créé et la matrice initialisée.

Une fois que les 2 utilisateurs sont enregistrés on envoie aux 2 joueurs un message indiquant que le jeu démarre.

Le premier inscrit commence. À chaque coup joué on vérifie s’il est gagnant ou non, plutôt que de parcourir la grille entière, et on change de joueur.

Si le coup est gagnant on notifie le gagnant et le perdant, et on réactive le bouton permettant de lancer un jeu tout en supprimant la référence sur le serveur.

Le jeu est simplement un exemple de la puissance des websockets. Il ne vise pas à implémenter complètement la logique du jeu, mais si l’envie vous en prend n’hésitez à proposer une pull request.

L’équipe Synbioz.

Libres d’être ensemble.