unicast vs multicast analysis

[cauchy]

Сообщение от -De-

Это, а вы ж видели в вики картинки, что по ссылке на статью о мультикасте? Представляете, как он работает, откуда выгода и где рождается? Ну т.е. да, формула именно типа "полоса пропускания сервера в зависимости от кол-ва клиентов". Для мультикаста клиент какбэ один, множественный.
Вообще есть сомнения, что если идёт несколько коннектов от сервера на один айпи, то мультикаст даст профит. Возможно виртуалку на слушающей машине придётся подымать или таки изыскивать 5-15 компов/сетевух %)

Картинки видел, хотя как раз на вики они не самые понятные.
Я так понимаю если например взять 64 клиента (слушателя), то при юникасте вещатель (такой же обычный клиент, не сервер) будет отдавать 64 потока (по одному потоку для каждого клиента), а при мультикасте - он будет отдавать ~(2log2(64)+13) = 25 потоков. Формула взята с видеолекции на adobeTV, насколько я понял там говорится что при n вещателей каждый пир будет иметь примерно 2log2(n)+c соседей, где c>10, но и не оч большой чтоб лишних соседей не набирать. Ну а так как сеть одноранговая, то видимо и вещатель столько же соединений и будет иметь. То бишь при 64 клиентах нагрузка на вещателя уменьшится раза в два в теории.
Кстати, если эта формула хоть немного работает, то мне нужно не 15 клиентов а хотя бы 32... оО
А вот ситуация с тем что всё идет на один айпи действительно непонятная пока, возможно тут вообще ничего работать не будет...

Сообщение от alatar

Как думаете сколько на ютубе подключений в секунду? В реале никто на нагруженный сервис не будет ставить один сервер. Даже если вам удастся посчитать (с этим вопросом лучше обратиться к админам), то данные получатся потолочные.

Ну с ютубом там ситуация другая. У меня суть в том, что всё работает через p2p (сервер который я упоминал грубо говоря только хранит данные о пользователях и сессиях, он не участвует в вещании никаким образом)
Выбираю я между ситуациями:
1) p2p юникаст: клиент будет просто публиковать свой поток, а другие буду к нему коннектиться через Cirrus и слушать его поток.
2) p2p мультикаст: клиент публикует свой поток используя GroupSpecifier и multicastEnabled=true, другие слушают его используя такие же настройки.

Ситуацию с FMS или Red5 (то есть классический клиент-сервер) я не рассматриваю совсем.

А данные боюсь действительно получатся потолочные, особенно учитывая что я как всегда всё на последний момент отложил)))