Nginx-ru mailing list archive (nginx-ru@sysoev.ru)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re[3]: + UPD
AT>> Задам те же два вопроса
AT>> 1) новому подключенному клиенту что выдавать (не выдать ничего -
AT>> для чата - нехорошо, ему нужно полэкрана текста таки насыпать) ?
ММ> Это не задача мультиплексора. Насыпать ему пол экрана текста должен
ММ> бэкенд при подключении к чату. Т.е. алгоритм такой: подключаемся к
ММ> мультиплексору и получаем от него сообщения. Одновременно делаем
ММ> запрос к другому локейшну на получение последних сообщений чате.
ММ> Получаем эти сообщения, мержим их с тем, что уже в чат нападало,
ММ> удаляям дубли и показываем юзеру.
Есть подозрение, что второго запроса делать не понадобится. Так как
мультиплексор позволяет адресовать клиентов персонально, можно прямо
при подключении бакендом сформировать хистори и протолкнуть новенькому.
AT>> 2) Клиенту, который не успевает забрать, по каким местам скипать ?
ММ> Наверное лучше иметь возможность это конфигурировать. Варианты:
ММ> скипать новые сообщения, если в очереди на отправку какому-то
ММ> конкретному коннекту более х неотправленных сообщений, разрывать
ММ> соединение по такому же условию, скипать первое в очереди сообщение,
ММ> если в очереди более х пакетов. Последняя опция проще всего
ММ> реализуется: на все коннекты одна очередь, которая в случае
ММ> переполнения продолжает наполняться, а первые сообщения, стоящие в
ММ> очереди на отправку, скипаются.
А вы уверены, что об этом вообще надо задумываться? У вас чат сейчас
это учитывает? Это ж насколько дохлый должен быть канал, чтобы там
plain text стопорился.
Я б не усложнял. Либо надо сразу сказать, что мы обсуждаем не чат, а
какую-то другую задачу, для которой условие "клиент не успевает
забирать" будет более правдоподобными.
В конце концов, никто не мешает раз в минуту гонять в стриме пинги, и
переподключать клиента по watchdog-у.
|
