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

[Vitaly Puzrin <vitaly@xxxxxxxxxxx>]

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

Не просек фишку про группы. Почему это лучше, чем передавать ID
соединения, возложив работу с группами на скрипт? Если поддержку групп
пихать в nginx, получится, что мы в него уже бизнес-логику
заталкиваем, о вредности которой предупреждали большевики :)

Вы не могли бы подробнее объяснить, в каких ситуациях без групп
непосредственно в nginx не обойтись? Или когда от них будет огромный выигрыш.

DM> 2) При POST-е данных бэкенд указывает список групп, которым предназначен
DM> данный кусок. Все члены групп его получают.

DM> Например, пришёл Вася в чат, соединился. Мы определяем, что он относится
DM> к группам "все", "админы" и "Вася (userid=23243)". Теперь мы можем послать
DM> ему данные, предназначенные а) для всех в чате, б) только для админов и в)
DM> лично для Васи. Причём в группе "Вася (userid=23243)" может быть и больше
DM> одного соединения, юзер имеет право подключиться к чату сколько угодно раз
DM> одновременно.

DM> Недостаток схемы: мы теряем возможность определить на бэкенде, кто из 
коннектов
DM> отвалился. Но, возможно, это и не нужно -- пусть определяет JS на клиенте
DM> и, если надо, стучит по Аяксу на сервер.

Концептуального недостатка не наблюдаю. Как раз дополнительно дергать скрипт при
закрытии соединения - не проблема.