Le proxy HTTP/FastCGI/SCGI ne ferme pas la connexion lorsque le client est déconnecté - bug ou fonctionnalité?

Question

Je travaille sur Comet support pour le framework CppCMS via de longs scrutations XMLHttpRequest. Dans de nombreux cas, une telle requête est fermée par le client avant qu'une réponse du serveur ne soit donnée - par exemple, la page est fermée, l'utilisateur se déplace vers une autre page ou il est juste refait.

Sur le côté serveur, je m'attends à recevoir la notification que la connexion est abandonnée. J'ai testé l'application via 3 connecteurs: FastCGI, SCGI et simple HTTP Proxy. A partir de 3 principaux serveurs Web UNIX, Apache2, lighttpd et Nginx, seul le dernier avait fermé la connexion comme prévu permettant à mon application de supprimer la requête de la file d'attente - cela a fonctionné pour les connecteurs FastCGI et HTTP Proxy. (Nginx n'a pas de module scgi par défaut).

D'autres, Apache et Lighttpd ne ferment pas la connexion ou n'informent pas le backend sur les clients déconnectés, la procédure se déroule comme si le client était toujours en ligne. Cela se produit pour les trois API prises en charge: FastCGI, SCGI et HTTP Proxy.

j'avais ouvert un problème pour Lighttpd, mais ce plus me conserns est le fait que Apache - serveur web mature et bien pris en charge comme lighttpd et ne divulgue pas le back-end du serveur que le client avait disparu.

Questions:

1. Est-ce un bug ou c'est une fonctionnalité? Y at-il une raison de ne pas fermer la connexion entre le serveur Web et le backend de l'application?
2. Existe-t-il une application Comet réelle fonctionnant derrière ces serveurs via des backends FastCGI/SCGI/HTTP-Proxy?
3. Si ce qui précède est vrai, comment font-ils face à ce problème? Je comprends que je peux temporiser toutes les connexions toutes les 10 secondes, mais je voudrais les garder inactives autant que les clients écoutent - parce que cela permet une mise à l'échelle plus facile - chaque connexion est très chère - le coût est seulement le socket ouvert.

Merci!

Answer 1

(1) Caractéristique. Ou, plus spécifiquement, les retombées d'un détail d'implémentation.

Une connexion TCP/IP n'implique pas un flux constant de trafic en va-et-vient. Ainsi, il n'y a aucun moyen de savoir qu'un client est parti sans (a) le client vous disant qu'il ferme la connexion ou (b) un timeout.

(2) Je ne suis pas particulièrement familier avec Comet ou CppCMS. Mais, oui, il y a toutes sortes de serveurs de CMS fonctionnant derrière les serveurs Web mentionnés et ils doivent tous faire face à ce problème (et, oui, c'est une douleur). (3) Les délais d'attente sont le seul moyen, mais vous pouvez atténuer la douleur, pour ainsi dire. Avoir le client ping sur le serveur à travers la connexion toutes les N secondes quand il n'y a pas d'autre activité.Ne doit rien faire et vous pouvez virer des trucs sur la réponse; notifications de modifications simultanées ou tout ce dont vous avez besoin.

Vous avez raison car il est surprenant que mod_fastcgi ne supporte pas de dire au backend qu'Apache a détecté la déconnexion ou que la connexion a expiré. Et vous n'êtes pas le premier à être consterné.

Le deuxième patch sur cette page devrait fixer cette question particulière:

http://osdir.com/ml/web.fastcgi.devel/2006-02/msg00015.html

Answer 2

http://ncannasse.fr/blog/tora_comet

Je n'ai aucune information concrète pour vous, mais cet article ne mentionne qu'ils peuvent détecter lorsque le client est déconnecté de Apache. Voir tora.Queue. Et il semble que la source soit disponible dans le CVS de neko, donc vous pourrez peut-être trouver des indices là-bas. Bonne chance.