Nous verrons dans cet article les limites du principe de Server Push lorsqu’il est implanté avec une API I/O standard (non multiplexée). Pour mieux comprendre, rappelons brièvement le cycle de vie d’une servlet (source).
Archives de la catégorie : Comet
La solution du server push : « connection refresh »
Le protocole TCP/IP s’assure, entre autre, du bon transport d’une information (un ensemble de paquets IP) d’un point A au point B (rapide résumé de ce qui nous intéresse sur ce protocole). Cette traversé, si on peut l’appeler comme ça, est composée d’une multitude d’obstacles comme par exemple des routeurs, des firewall, des proxy, des VLAN, etc. Chaque élément est soumis à des contraintes physiques (avoir un temps de réponse acceptable), des contraintes de sécurité et des contraintes de bon fonctionnement (ne pas altérer l’intégrité des données).
Comet ? Qu’est-ce que c’est ?
Le terme « comet » est employé à toutes les sauces aujourd’hui. C’est devenu un terme fourre-tout et ultra tendance lorsqu’on veut parler de web 2.0 ou 3.0. Lorsqu’on parle de comet, on parle également de reverse-ajax, cometd, long polling, slow polling, long-lived HTTP connections, server push…Une petite explication s’impose !
On va tâcher d’expliquer la différence entre server push et comet. Nous verrons que ce n’est pas tout à fait la même chose, bien qu’ils soient, aujourd’hui, très souvent associés l’un à l’autre.
Les mécanismes du Server Push : les problèmes
Dans ce billet, nous allons soulever les problèmes liés à la mise en place du mécanisme de Server Push dans une application web.
L’alternative du « Polling » (en français scrutation)
Définition:
Vérification répétitive et automatique de l’état d’un ou plusieurs éléments d’un système pour y détecter un changement. (source: wikipedia).
Détaillons ce que cela signifie:
Exemple: un client tchate sur une application web, il demande à récupérer la ligne 200 de sa discussion (la dernière ligne écrite lue est donc 199). Pour cela, il fait une requête au serveur du style:
http://mon.chat.app/getChatLine?idx=200
Si la ligne n’existe pas (parce que personne n’a envoyé de message), le serveur répond simplement « n’existe pas ». Le client doit donc relancer la même requête 1 ou 2 secondes plus tard pour obtenir les nouveaux messages et cela tout le temps. C’est le principe du polling (traduit en français par « interroger » ou « scruter »).
Il a deux problèmes majeurs à cette technique:
Inefficace: si l’application interroge le serveur toutes les secondes pour savoir s’il y a eu une nouvelle ligne et que la discussion a en moyenne un nouveau message toutes les 30 secondes, alors 29 des 30 requêtes contiendront « n’existe pas ». Rappelons également que pour une requête échangée, le client et le serveur consomme plusieurs kilo-octets de contenus et d’entêtes HTTP. Le ratio entre l’information utile et l’information consommée (utile+transport) est très mauvais. Bref, c’est une utilisation totalement inefficace de la bande passante.
Lent: imaginez un moment que l’un de vos interlocuteurs vous envoie quelque chose juste après avoir reçu la notification « n’existe pas ». Dans ce cas, vous serez obligé d’attendre 1 ou 2 secondes pour voir le message (ça dépend comment on règle le polling). En conclusion, c’est lent.
Le Push Server évite ce genre de problèmes. C’est pour cela qu’il est bien plus avancé et efficace que la technique de polling. Dans la pratique, le Server Push reste lié au principe de polling, mais on l’appelle également long polling.
Romain LAFOND
Qu’est-ce que le Server Push ?
Rappel
Les applications web communiquent via le protocole HTTP. C’est aujourd’hui un des protocoles les plus utilisés et aussi un des plus vieux. Mais le hic…c’est qu’il n’est pas prévu pour opérer en « mode connecté » ou « stateful » (ce qui diffère des connexions par sockets/connexion persistante). Il est basé sur le modèle requête-réponse où le client (navigateur web) envoie une requête au serveur qui ne fait que répondre avec une autre requête contenant les données de la réponse. Une fois la réponse donnée, il n’y a plus aucun moyen de renvoyer une autre information à ce même client. La connexion est fermée (vu qu’elle est non persistante). On dit que son mode de connexion est « non connecté » ou « stateless ». De plus, si un client envoie 2 requêtes au serveur, celui-ci n’a même pas le moyen de faire le lien entre ses 2 dernières, sauf avec l’aide de cookie ou de session.
Principe
Le principe du Server Push est de permettre au serveur d’envoyer les données au client lorsqu’il en a envi, on appelle ça plus couramment de la « notification », que l’on peut traduire en français par « pousser les données » du serveur vers le client. Malheureusement, en HTTP la notification est impossible pourtant certains sites internet réagissent comme si.
Exemple
Par exemple, le célèbre site « facebook » illustre parfaitement ce mécanisme puisque le client reçoit des notifications en « temps réel » sans à rafraichir sa page.
Le cas classique utilisant le “Server Push” est le client web de messagerie instantanée. Dans les mécanismes d’une telle application, il y a plusieurs types d’événements (nouveau message, connexion ou déconnexion d’un client) qui doivent tous être communiqués (notifier) aux clients. Et dans ce type d’application, cela doit être, comme son nom l’indique, « instantané ».
Mais alors…comment font-ils si le protocole HTTP ne le permet pas?
Avec un peu d’imagination (et du bon bricolage), on peut simuler le principe de notification du serveur vers le(s) client(s).
Nous allons voir quels sont les différents moyens de l’implanter dans le framework Google Web Toolkit (GWT), du moins élégant à la solution, qui semble être à l’heure actuelle, la plus robuste et la plus performante et qui est sur le point d’être intégrée à l’API de Servlet 3.0.
Sur internet, les termes Comet, Cometd, Bayeux, long polling, ou Reverse Ajax sont souvent associés au Server Push.
Romain LAFOND
