HTTP Прокси / FastCGI / SCGI не закрывает соединение при отключении клиента - ошибка или особенность?

Question

Я работаю над Поддержка Comet для CppCMS ( CppCMS ) фреймворк с помощью длинных опросов XMLHttpRequest.Во многих случаях такой запрос закрывается клиентом до того, как был получен какой-либо ответ от сервера - например, страница закрывается, пользователь переходит на другую страницу или она просто повторно подключается.

На стороне сервера я ожидаю, что получу уведомление о том, что соединение разорвано.Я протестировал приложение через 3 разъема:FastCGI, SCGI и простой HTTP-прокси.

Из 3 основных веб-серверов UNIX, Apache2, lighttpd и Nginx, был закрыт только последний соединение, как и ожидалось, позволяющее моему приложению удалить запрос из очереди ожидания - это работало как для соединителей FastCGI, так и для HTTP-прокси.(Nginx по умолчанию не имеет модуля scgi).

Другие, Apache и Lighttpd, не закрывают соединение и не информируют серверную часть об отключении клиенты, действуйте так, как будто клиент все еще подключен.Это происходит для всех 3 поддерживаемых API:FastCGI, SCGI и HTTP-прокси.

Я открыл выпуск для Полиция света, но что меня больше беспокоит тот факт, что Apache - зрелый и хорошо поддерживаемый веб-сервер, такой как lighttpd и не раскрывает серверную часть, на которую ушел клиент.

Вопросы:

1. Это ошибка или это особенность?Есть ли какая-либо причина не закрывать соединение между веб-сервером и серверной частью приложения?
2. Существуют ли реальные приложения Comet, работающие за этими серверами через серверные части FastCGI / SCGI / HTTP-Прокси?
3. Если вышесказанное верно, то как они справляются с этой проблемой?Я понимаю, что я могу отключать все соединения каждые 10 секунд, но я хотел бы, чтобы они оставались незанятыми, пока клиент слушает - потому что это позволяет упростить масштабирование - каждое соединение очень дешевое - стоимость зависит только от открытого сокета.

Спасибо!

Answer 1

(1) Особенность.Или, более конкретно, последствия от деталей реализации.

Соединение TCP / IP не предполагает постоянного потока трафика туда и обратно.Таким образом, нет никакого способа узнать, что клиент ушел, без (а) сообщения клиента вам о закрытии соединения или (б) тайм-аута.

(2) Я не особо знаком с Comet или CppCMS.Но, да, за упомянутыми веб-серверами работают всевозможные серверы CMS, и всем им приходится сталкиваться с этой проблемой (и, да, это непросто).

(3) Тайм-ауты - единственный способ, но вы можете, так сказать, смягчить боль.Попросите клиента пинговать сервер по соединению каждые N секунд, когда в остальном никакой активности нет.Не нужно ничего делать, и вы можете добавить что-то в ответ;уведомления о одновременных изменениях или о чем-то еще, что вам нужно.

Вы правы в том, что удивительно, что mod_fastcgi не поддерживает сообщение серверной части о том, что Apache обнаружил отключение или время ожидания соединения истекло.И вы не первый, кто приходит в смятение.

Второй патч на этой странице должен устранить эту конкретную проблему:

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

Answer 2

http://ncannasse.fr/blog/tora_comet

У меня нет для вас никакой конкретной информации, но в этой статье упоминается, что они могут определять, когда клиент отключился от Apache.Видишь tora.Queue.И похоже, что исходный текст доступен в резюме neko, так что вы могли бы найти там некоторые подсказки.Удачи.