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).
Problématique
Pour garantir ce transport, des règles ont été établies. Les plus gros routeurs, véritable piliers du trafic mondial, rencontrent tous le même problème : la taille de leur table de routage. Si cette dernière devient trop volumineuse, l’accès aux entrées croît très vite et le temps de traitement des paquets (au final, de la requête) augmente. Si on multiplie ce temps par le nombre de routeurs traversés, alors la latence devient énorme (plusieurs secondes)…
Pour remédier à ce problème, le routeur a pour tâche d’effacer périodiquement les entrées les plus anciennes/moins utilisées dans sa table de routage. Il doit adapter ce temps de suppression en fonction de sa capacité à traiter les informations (configuration matériel) et du trafic subit (nombre de paquets à router/temps).
Le NAT, par exemple, a lui aussi une table avec une durée de vie limitée. il en existe surement d’autres…
Tout ça pour dire qu’une requête ne peut plus forcement revenir là d’où elle vient si elle est bloquée trop longtemps. C’est pourquoi, dans la plupart des systèmes, il existe un système de timeout permettant de ne pas attendre indéfiniment la requête. Il est appliqué par tout le monde. Il représente le temps maximum qu’une entité (exemple : un client web) est prête à attendre avant qu’une réponse de l’entité distante dont il attend cette même réponse, lui parvienne. Au-delà de ce temps, on soulève donc l’erreur timeout, ou en français « temps d’attente dépassé ».
Explication
En pratique, on ne devrait jamais laisser notre server push maintenir une connexion plus d’une minute. Le timeout est inévitable sur internet… C’est pourquoi, on ruse en employant la technique du « connexion refresh ». Détaillons.
Schéma du principe du connection refresh
Le connection refresh est une technique simple visant à forcer le rafraichissement de la requête coté serveur.
Par exemple, si toutes les 40 secondes, je n’ai pas d’événements à notifier, afin d’éviter que le client parte en timeout, je réponds quand même au client avec « n’existe pas » et je ferme la connexion. Le client, de son coté, va simplement ré-établir une nouvelle connexion qui durera également 40 secondes si aucun événement se produit. Et ainsi de suite…Avec cette technique, on évite donc ainsi les désagréments dus au transport « physique » de notre requête (paquets IP).
Conclusion
Il faut l’avouer, cette technique reste très proche du « polling ». C’est pour cela que la technique du server push est également appelée « long polling ».
On n’a pas réellement trouvé mieux à l’heure actuelle, mais elle est beaucoup plus efficace en termes de latence et de charge qu’une répétition de demande (scrutation) toutes les x secondes.
Romain LAFOND
