>
> Вы не могли бы поподробнее объяснить, в чем проблема, и уточнить область
> применимости? Если б вы сразу сказали, что рассматриваете возможность
> передачи видео по кастомным протоколам, то тут естественно комет ни
> каким местом. По крайней мере, тот, который у буржуев описан.
Мы вообще начали с комета, а потом плавно перешли к мультиплексированию.
Хотя это сильно разные задачи, тот же комет не подразумевает раздачи
клиентам одного и того же.
Мультиплексор - штука крайне полезная (для узкого круга задач) и если
его иметь в хорошем общем виде, то будут и использовать. Другой вопрос,
что задач таких немного и пока не будет настоящей - не будет и соотв. модуля
в nginx.
> А для чатов, бирж, и живых лент новостей, особых проблем не вижу. По
> крайней мере, для чатов было названо несколько вариантов обхода узких
> мест.
Для чатов мгновенно выяснилось, что там поток данных к разным
юзерам таки неодинаковый. Приваты, комнаты и прочие особенности.
А дальше с чатами начинается интересно:
* мы либо держим на каждого клиента два потока (общий и приватный), но в
этом нет смысла (мы же хотим поэкономить соединения с backend),
* либо приделываем в nginx механизм фильтрации записей по конфигу,
динамически получаемому с backend (опять возникают записи и их
интерпретация на frontend)
* либо опять имеем по потоку на клиента.
* либо позволяем приватным сообщениям опаздывать и их подгружаем аяксом
по таймеру (раз в 10 секунд, например). Тоже странно....
> прозрачно. И проблем с DDoS ни чуть не больше, чем при отдаче статики
> больших размеров. Принципиальной разницы, сидит ли 100 клиентов на 1
> мультиплексоре, или качают ли 100 клиентов 3 часа гигабайтный файл, я
> не вижу.
Принципиальная разница тут есть. Поток от backend потенциально имеет
бесконечную длину (в отличие от файла) и его нужно где-то хранить.
Если его хранить в памяти, то имеем возможность DOS, если его хранить
на диске, то нужно научиться у файла откусывать начало, либо же
хранить это в миллионе мелких файликов.
Алексей Тутубалин
mailto: lexa@xxxxxxx
Web:
