de Comet aux websockets...

Il y a un peu plus d'un an je faisais le choix de Hookbox pour le site de jeu multi joueur qu'on développe.

Tout ça était expliqué ici : http://backteam.blogspot.com/2010/08/comet-se-passer-de-bayeux.html

1 an plus tard force est de constater que j'ai fait fausse route.

Aujourd'hui Hookbox est un choix qui aujourd'hui est très discutable :

o   Actuellement on a clairement des problèmes de tenue en charge de hookbox (mais qui sont partiellement lié à l'architecture mis en place pour notre site) et on a pas de visibilité claire sur la capacité de tenue en charge de hookbox

o   Le choix de hookbox a était fait il y a plus d'1 an maintenant à une époque où les différentes solutions possibles étaient très restreintes.

o   La communauté  autour du projet existe mais est très réduite, le principal auteur ne s'occupe plus que très peu du projet

Au-delà du choix de Hookbox il y a aussi le choix de comet.

La promesse de Comet s'était de pouvoir s'approcher de ce qu'on fait en WebSocket sans attendre que les navigateurs supportent les webSockets.

Sauf qu'aujourd'hui la donne a changé !

En effet aujourd'hui il est possible de faire un fallback flash pour les navigateurs ne supportant pas nativement les websockets. En clair, il est possible de faire du websockets en flash si le navigateur ne le permet en natif.

Comet a donc vécu puisque les WebSockets sont maintenant accessible à tous les navigateurs !

Quid des navigateurs ne supportant pas flash me direz-vous ?  (iOS…)Et bien c pas grave puisqu'ils supportent les websockets en natif (du moins à partir de IOS 4.2…tant pis pour les Iphone 3G…).

Un tableau simple concernant le support des websockets : http://pusher.com/docs/browser_compatibility

Donc oublions comet …parlons des WebSockets.

Pour en revenir à mon projet de jeu multi joueur, les besoins sont les suivants :

-          Capacité à s'interfacer avec le site PHP

-          Maturité de la solution , pérennité et qualité du support

-          Capacité de tenue en charge (> 2 000 connexions simultanées)

-          Capacité à être facilement exploitable et scalable

-          Facilité de mise en œuvre.

Les  solutions techniques suivantes m'ont semblé être les plus intéressantes :

-          socket.io http://socket.io/#home  Livrairie Javascript (coté serveur) open source basé sur node.js 

node.js est probablement le projet open source le plus prometteur de la décennie car derrière il y a une communauté phénoménale et quantité de projet très  innovants

        Socket.io offre de nombreuses possibilité mais reste une solution de « bas niveau » cad que l'utiliser dans bingo nécessiterait beaucoup de développements.

-          Push-it : http://aaronblohowiak.github.com/Push-It/ Solution Javascript (coté serveur) open source basé sur socket.io et node.js  implémentant le protocole de bayeux à partir de socket.io

Cette solution est particulièrement intéressante pour les besoins de Bingo mais  il n'y a pas une vrai communauté derrière, aucun gage de pérénité.

-          SocketStream : https://github.com/socketstream/socketstream Framework Javascript (coté serveur) open source basé sur socket.io et node.js  (et sponsorisé par AOL)

La solution SocketStream  est très ambitieuse et s'adresse à de gros projets. Est en place une architecture permettant une très grande scalability

Par contre :

§  Ca nécessite pas mal de développements (Facilité de mise en œuvre….)

§  C'est très peu mature c'est en version 0.2. La 0.1 date de juin 2011 !

-          Pusher : http://pusher.com/ Solutions SAAS (donc sous abonnement) permettant de mettre en œuvre des websockets et offrant une API REST.

C'est édité par une société Londonienne créé il y a environ 1 an.

Ça passe par un abonnement, il y a différentes formules en fonction du nb de joueurs connectés simultanés qu'on souhaite et du nb de message qu'on fait transiter via leur plateforme chaque jour.

§  Dans la philosophie de l'outil c'est assez similaire à Hookbox mais avec un champ fonctionnel assez différent.

§  C'est donc assez facile à mettre en place (se brancher dessus)

§  Compte tenu que c'est une solution payant on a un support et on peut escompter de la pérennité.

§  La tenue en charge ne semble pas être un problème compte tenu de la teneur de leur offre commerciale (l'offre big boy à 199 USD/mois permet d'avoir 5000 connexion simultanées / 10 millions de messages par jour). 

Je suis vraiment séduit par la pile « node.js, socket.io et SocketStream ». C'est vraiment super puissant et je me demande si grâce aux avancées autour de node.js / redis / zeroMq on fera encore du PHP dans 10 ans…

Ceci dit à court terme je pense que SocketStream est une solution trop jeune pour pouvoir se reposer sur elle.

Par conséquent je penche, pour mon projet, sur Pusher.com

Avant d'acter ce choix il me faut  étudier en détail pusher.com pour m'assurer que ses fonctionnalités nous permettront de mettre en œuvre notre site…