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 du tag : 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.
