Re: Re[2]: + поправка на мультиплексирование

[David Mzareulyan]

Hello Vitaly,

DM>> 1) Nginx НЕ передаёт ID соединения бэкенду. Вместо этого бэкенд сам
DM>> решает,
DM>> к какой группе (!) относится данный юзер (на основании
DM>> авторизационной информации
DM>> и т.п.) и возвращает nginx-у список ГРУПП (или их uid-ов), к
DM>> которым относится
DM>> данное соединение. Таблицы соответствий ConnectionID <-> GroupID
DM>> хранит у
DM>> себя сам nginx, это не должно быть особо ресурсоёмко. Чистятся
DM>> таблицы по
DM>> мере отваливания клиентов.
> Не просек фишку про группы. Почему это лучше, чем передавать ID
> соединения, возложив работу с группами на скрипт? Если поддержку групп
> пихать в nginx, получится, что мы в него уже бизнес-логику
> заталкиваем, о вредности которой предупреждали большевики :)
> 
> Вы не могли бы подробнее объяснить, в каких ситуациях без групп
> непосредственно в nginx не обойтись? Или когда от них будет огромный
> выигрыш.

Огромный выигрыш будет, когда в чат придут 10000 человек, и их всех придётся 
перечислять при постинге очередного сообщения:) И nginx-у парсить такие запросы 
-- никакого интереса. Ну пусть не 10000, пусть 100 -- вполне реальная цифра. 
Зачем каждый раз пихать в запрос сто лишних хедеров, при том, что их состав 
почти не меняется? А с группами мы можем вообще не волноваться, сколько там 
народу, кто отвалился, кто подсоединился. Опять же, можно создавать группы 
для конкретных юзеров. Эмулировать же группы на бэкенде в случае с ID-ами 
соединений довольно сложно -- надо где-то хранить состояния, обновлять их 
при подсоединении-отсоединении... А пул коннектов в nginx и так имеется, 
разбить его на группы -- совершенно не сложно.

Мне кажется, группы -- это настолько общий паттерн, что его вполне можно 
перенести в мультиплексор. На "бизнес-логику" это никак не тянет.


-- 
С уважением
Давид Мзареулян
david at hiero.ru