{"id":386,"date":"2009-12-13T20:02:55","date_gmt":"2009-12-13T18:02:55","guid":{"rendered":"http:\/\/loicmathieu.free.fr\/wordpress\/?p=386"},"modified":"2010-01-31T11:42:42","modified_gmt":"2010-01-31T09:42:42","slug":"chti-jug-html5-websocket-et-autres-protocole-de-communication","status":"publish","type":"post","link":"https:\/\/www.loicmathieu.fr\/wordpress\/informatique\/chti-jug-html5-websocket-et-autres-protocole-de-communication\/","title":{"rendered":"Ch’ti JUG: HTML5: WebSocket et autres protocole de communication"},"content":{"rendered":"
Jeudi s’est tenu dans les locaux d’ADEO<\/a> une session du Ch’ti Jug<\/a> sur HTML5 et tout particuli\u00e8rement les WebSockets: Kaazing HTML5 WebSocket Talk at the Ch\u2019ti JUG Meeting in Lille, France<\/a>\n\nPour ceux qui ne savent pas ce qu’est le Ch’ti Jug ou ce qu’est un Jug, voir l’introduction de mon article sur la session pr\u00e9c\u00e9dente:\u00a0 Ch\u2019ti Jug: les technologies Google<\/a>\n\nUne petite phrase de notre h\u00f4te, le groupe ADEO, qui rassemble entre autre les enseigne Leroy Merlin et Weldom. C’est donc ce qu’on appel dans le jargon des SSII un “client final”, et c’est la premi\u00e8er fois qu’une session du JUG se tient chez un client final. Le responsable des developpement de chez ADEO qui nous a re\u00e7u (je ne me rappel plus de son nom ni de sa fonction exacte) nous as expliquer la d\u00e9marche tr\u00e8s simple et que beaucoup d’autre client finaux (ou DSI) devrait mettre en place. Il fait en sorte que ses \u00e9quipes de d\u00e9veloppement s’organisent en communaut\u00e9 pour partager leur savoir et progresser ensemble. Et c’est dans cette optique qu’il trouve tout naturel de supporter les communaut\u00e9s ext\u00e9rieures qui permettent \u00e0 ses \u00e9quipes de prolonger en dehors du bureau leur esprit de communaut\u00e9 et de continuer \u00e0 grandir dans leur travail (l\u00e0 je trouve que je l’ai presque aussi bien dit que lui:) ).\n\nBon, apr\u00e8s cette longue digression, venons en a la pr\u00e9sentation elle m\u00eame. Elle \u00e9t\u00e9 assur\u00e9 par Peter Lubbers<\/a> de chez Kaazing<\/a>, qui \u00e9t\u00e9 de passage \u00e0 Paris pour une formation et as accept\u00e9 de venir faire un tour dans le nord avant de repartir dans la Silicon Valley. Et ce qu’on peut dire c’est que la pr\u00e9sentation \u00e9t\u00e9 de grande qualit\u00e9, digne des grandes conf\u00e9rences payantes de la communaut\u00e9 Java.\n\nPour commencer, Peter nous as expos\u00e9 le probl\u00e8me, \u00e0 grand renfort d’exemple et de d\u00e9mo: aujourd’hui de plus en plus d’applications web riche (RIA, Rich Web Application) n\u00e9cessitent une communication temps r\u00e9elle (ou quasi temps r\u00e9elle). Les protocoles web existants ne sont pas capable de faire \u00e7a, ils sont bas\u00e9 sur HTTP qui ne permet qu’une communication half-duplexe (soit montante: une request<\/em>, soit descendante: une response<\/em>, mais pas les deux en m\u00eame temps).\nIl existe donc diff\u00e9rents patterns de d\u00e9veloppement pour la mise en place de solution pour que les RIA puisse s’approcher le plus possible d’une communication temps r\u00e9elle. Je ne vais pas vous les pr\u00e9senter tous en d\u00e9tail mais il sont bas\u00e9 sur ce qu’on appel le polling (normal ou long polling) et ils souffrent tous de trois choses:\n\n
  1. Limitation d’une communication half-duplex: une request est obligatoire avant toute response, le serveur ne peut pas envoyer de donn\u00e9es sans qu’une request ai \u00e9t\u00e9 initi\u00e9 au pr\u00e9alable.<\/li>\n\n
  2. La communication temps r\u00e9elle n\u00e9cessite des mise \u00e0 jours constante qui n\u00e9cessite de nombreuses request\/response en un laps de temps tr\u00e8s court. Le protocole HTTP comprend des en-t\u00eate qui dans ce cas d’utilisation particulier peuvent \u00eatre importante. La taille d’une en-t\u00eate HTTP standard \u00e9tant de 500 \u00e0 2000 octets, dans le cas d’un polling vers 10 000 clients toutes les secondes bas\u00e9 sur une taille d’en-t\u00eate de 1K on a 200Ko\/s (10 000 * 1Ko * 2, une ent\u00eate pour la request et une pour la response) de bande passante prise uniquement pour les en-t\u00eate. Et si on calcul pour 100000 client avec un polling de 200ms (plus coh\u00e9rent pour donner une impression de temps r\u00e9el) \u00e7a nous donne 10Mo\/s de bande passante uniquement pour les ent\u00eates!<\/li>\n\n
  3. Le browser ne pouvant acc\u00e9der qu’a un serveur HTTP, on a n\u00e9cessit\u00e9 de d\u00e9ployer un serveur d’application ou autre composant complexe pour r\u00e9aliser ce polling.<\/li>\n<\/ol>\nEt voila la solution, les WebSockets. Ils permettent de se passer de tout ces probl\u00e8mes, en voici le m\u00e9canisme, dans une explication simplifi\u00e9:\n\n
    1. Le browser demande un upgrade de la connexion HTTP en web socket.<\/li>\n\n
    2. Le serveur acc\u00e8pte, la connexion HTTP devient un WebSocket vers le serveur: c’est un nouveau protocole directement au dessus de TCP.<\/li>\n\n
    3. La communication s’effectue alors en full-duplexe: request et response sont maintenant ind\u00e9pendante et peuvent \u00eatre \u00e9mise en m\u00eame temps. Ce qui ouvre la possibilit\u00e9 d’une r\u00e9el push data vers le serveur.<\/li>\n\n
    4. Les headers d’une request\/response WebSocket sont minimum: 1 octet de d\u00e9but et un octet de fin! La bande passante ne sert donc uniquement qu’aux donn\u00e9es!<\/li>\n<\/ol>\nOn peut m\u00eame imaginer faire directement communiquer un serveur de type JMS, Jabber ou autre directement avec un WebSocket sans passer par HTTP.\n\nDe plus, l’\u00e9tablissement d’une websocket est tr\u00e8s facile, via JavaScript on fait juste initialise juste un objet websocket en lui passant l’URL (de type ws:\/\/hote:port\/uri, websocket \u00e9tant un r\u00e9el protocole il a son propre addressage) et la m\u00e9thode javascript \u00e0 appeler en callback lors de la r\u00e9ception de la requ\u00eate: WebSocket \u00e9tant asynchrone.\n\nLes possibilit\u00e9 sont grande pour tout ce qui n\u00e9cessite des connexion de type temps r\u00e9elle.\n\nPeter Lubbers nous as ensuite pr\u00e9sent\u00e9 quelques autres nouveaut\u00e9s d’HTML5 acc\u00e8s sur la communications telle que:\n\n