Http proxy/fastcgi/scgi não fechando conexão quando o cliente desconectado - bug ou recurso?

Question

Eu estou trabalhando em Suporte ao cometa por CPPCMS estrutura por meio de longas pesquisas XMLHTTPrequest. Em muitos casos, essa solicitação é encerrada pelo cliente antes que qualquer resposta do servidor fosse dada - por exemplo, a página está fechada, o usuário se move para outra página ou é apenas refazer.

No lado do servidor, espero receber a notificação de que a conexão é descartada. Eu testei o aplicativo via 3 conectores: fastcgi, scgi e proxy HTTP simples.

A partir de três principais servidores da Web Unix, Apache2, LightTPD e Nginx, apenas a última foi fechada, como esperado, permitindo que meu aplicativo remova a solicitação da fila de espera - funcionou para conectores proxy FastCGI e HTTP. (Nginx não possui módulo SCGI por padrão).

Outros, Apache e LightTPD não fecham a conexão ou informam o back -end sobre os clientes desconectados, o processo como se o cliente ainda estivesse on -line. Isso acontece para todas as 3 APIs suportadas: FASTCGI, SCGI e HTTP Proxy.

Eu tinha aberto um problema para Lighttpd, mas o que mais me consta é o fato de que o Apache - maduro e bem suportado servidor da Web como LightTPD e não divulga o back -end do servidor que o cliente havia desaparecido.

Perguntas:

1. Isso é um bug ou isso é um recurso? Existe algum motivo para não fechar a conexão entre o servidor da web e o back -end do aplicativo?
2. Existem aplicativos cometes da vida real funcionando por trás desses servidores via back-ends de fastcgi/scgi/http-proxy?
3. Se o acima é verdade, como eles lidam com esse problema? Entendo que posso limitar todas as conexões a cada 10 segundos, mas gostaria de mantê -las ociosas no que diz respeito ao cliente - porque isso permite uma escala mais fácil - cada conexão é muito cheia - o custo é apenas o soquete aberto.

Obrigado!

Answer 1

(1) recurso. Ou, mais especificamente, as consequências de um detalhe de implementação.

Uma conexão TCP/IP não envolve um fluxo constante de tráfego para frente e para trás. Portanto, não há como saber que um cliente desaparece sem (a) o cliente dizendo que está fechando a conexão ou (b) um tempo limite.

(2) Não estou familiarizado especificamente com o Comet ou CPPCMS. Mas, sim, existem todos os tipos de servidores CMS em execução atrás dos servidores da Web mencionados e todos precisam lidar com esse problema (e, sim, é uma dor).

(3) Os tempos limite são a única maneira, mas você pode mitigar a dor, por assim dizer. Peça ao cliente ping o servidor em toda a conexão a cada N Segundos quando não houver atividade. Não precisa fazer nada e você pode prender coisas na resposta; notificações de edições simultâneas ou o que você precisa.

Você está correto, pois é surpreendente que o MOD_FASTCGI não suporta dizer ao back -end que o Apache detectou a desconexão ou a conexão cronometrada. E você não é o primeiro a ficar consternado.

O segundo patch nesta página deve corrigir esse problema específico:

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

Answer 2

http://ncannasse.fr/blog/Tora_comet

Não tenho nenhuma informação concreta para você, mas este artigo menciona que eles podem detectar quando o cliente está desconectado do Apache. Ver tora.Queue. E parece que a fonte está disponível no Neko CVS, para que você possa encontrar algumas pistas lá. Boa sorte.