Comet

[Vitaly Puzrin]

Hello Михаил,

Если конкретно про чаты говорить, то там 2 задачи: предварительная
синхронизация, и подкачка.

Предварительная синхронизация идет по стандартному каналу, а подкачка
и постинг сообщений - через мультиплексор. Это просто 2 разных локейшена,
архитектура nginx тут вообще ни каким местом не затрагивается.

Для подкачки - специальный локейшен-мультиплексор. Данные (в нашем
случае - сообщение в чат) шлет кто угодно, а ответы получают все кто
держит соединение. По-моему, довольно логично. Мультиплексор - штука
универсальная. Остальное на совести js-кодера.

По ходу новый вопрос возник. Реально ли сделать модуль, который
позволит держать открытые сессии и передавать их ID в скрипты? Задумка
простая - делать на php демонов. У меня сейчас NNTP-гейт написан на
библиотеке NET_Server, но штука не шибко быстрая, и под нагрузкой
вякнется. Может, в рамках кометовской инициативы посмотреть на
проблему шире?

ММ> Здравствуйте Виталий,

ММ> Вероятно  nginx может слушать какой-то ещё хост/ip/порт и принимать на
ММ> него  все  запросы,  которые  приходят от постящих в чат месаги, затем
ММ> прокидывать их на бэкенд, который будет что-то отвечать. Но этот ответ
ММ> бэкенда улетит в другой блок server{...}, в котором висит куча юзеров,
ММ> "медленно  качающих"  не кончающуюся страничку. Т.е. приходит запрос к
ММ> одному server{}, а отдаётся через другой.

ММ> Только  нужно ещё придумать что отдавать тому, кто запостил. Можно его
ММ> на  однопиксель  зарулить.  Или можно бэкендом как-то 2 ответа в одном
ММ> формировать: один для всех и один для постящего...

ММ> Или вместо server{...} можно location{}-ы использовать.

ММ> Возможно   подобная   схема,   не  ломая  архитектуры  nginx,  поможет
ММ> реализовать  Комет.  При  этом  нагрузка  будет  минимальна  -  бэкенд
ММ> обслуживает  только  постинги,  а  всю  раздачу  этих постингов делает
ММ> nginx.

AS>>> какой функционал то ? непонятно что вы в данном случае хотите от nginx

VP>> Видимо, модуль для работы с постоянно открытыми соединениями, и API
VP>> для работы с данными соединениями со стороны сервера, если я правильно
VP>> понимаю.

VP>> В обычной ситуации после того как скрипт закончил работу, нельзя
VP>> сказать серверу, чтобы он удерживал соединение открытым, и потом туда
VP>> что-нибудь еще "долить" или получить данные при следующем вызове.



ММ>   

ММ> --

ММ> С уважением,
ММ> Михаил Монашёв, SoftSearch.ru
ММ> mailto:postmaster at softsearch.ru
ММ> ICQ# 166233339
ММ> http://softsearch.ru/
ММ> Без бэкапа по жизни.