Comet

[Vitaly Puzrin]

Я тут подумал, если применительно к чатам, было бы неплохо, чтобы
модуль умел скрипт дергать просто так, по таймеру (задается в
конфиге). Как опция - дергал при закрытии любого из подключенных
потоков с передачей ID закрывшегося.

Для чего нужно - например, чтобы сообщать остальным, что пользователь
вышел из чата.

Вроде бы это уровень абстракции порушить не должно. А таймер - в
хозяйстве штука полезная.

DM> Hello Andrew,

DM> Во-от! В этом-то и состоит нетривиальность задачи:)

DM> Очевидно, единственный способ -- это назначать всем коннектам из пула некие
DM> id-шники, которые надо а) как-то сообщать бэкенду и б) как-то принимать от
DM> бэкенда данные именно для этого id.

DM> Навскидку могу предложить примерно такую схему. Nginx (если в конфиге включён
DM> определённый comet-флаг) передаёт бэкенду вместе с запросом и ID соединения
DM> (отдельным HTTP-заголовком, скажем X-Comet-чтототам). Если бэкенд желает,
DM> чтобы данное соединение оставалось "висящим", то он в ответе тоже указывает
DM> некий флаг-заголовок. Тогда nginx, отдав клиенту ответ, не закрывает с ним
DM> связь (тут нужно, чтобы ответ был "правильным" -- не содержал Content-Lenght
DM> и т.п.).

DM> Теперь как послать данные нужному клиенту. Создаётся location с определённым
DM> comet-флагом, доступная только для бэкенда. Бэкенд в неё POST-ом в любой
DM> момент может что-то записать, указав, опять-таки, в
DM> HTTP-заголовке ID клиента-получателя. 
DM> Nginx, если клиент с этим ID-ом ещё не отвалился, пересылает ему POST-данные,
DM> а бэкенду говорит "200 OK". Если же клиент отвалился, то -- 404.

DM> Ну, естественно, можно и другие варианты придумать. Роль nginx-а тут исключительно
DM> в поддержании пула коннектов и маршрутизации данных между ними.

>> Hello David,
>> 
DM>>> a) дepжит пocтoянныe coeдинeния c клиeнтaми и б) пpинимaeт oт
DM>>> бэкенда дaнныe и paccылaeт иx в нyжныe coeдинeния.
DM>>> 
>> как он узнает что в какие-то соединения надо новые данные от бакендов
>> получить и засунуть ?
>>