unicast vs multicast analysis

[cauchy]

Всем привет!
Давненько что-то я тут не появлялся.
Тут такое дело, для диплома соорудил приложение на эйре которое общается с сервером и бд, умеет звонить (видеозвонки через p2p), ну и конференции (вещание с использованием multicast).
Руководителю всё понравилось, но теперь нужно приплести сюда математику, научность или ещё что-то в этом роде. Появилась мысль приплести всё это к моменту с конференциями:
типа есть юникаст (просто все слушают один outstream вещателя), а есть мультикаст. При 5ти юзерах разницы никакой, а вот при 5000 юникаст загнётся а мультикаст будет продолжать работать. Вот я типа проанализировал, сравнил две этих технологии и выяснил что мультикаст рулит, и поэтому реализовал на нём.
Вопроса два:
1) Нужно как то показать лаги при юникасте и множестве слушателей.
Думаю может искусственно ограничить скорость соединения до смешной, начать вещать - а с другого компа слушать, при 5-15 коннектах (коннекты все будут с одной машины) хотелось бы увидеть лаги, а при включенном мультикасте при тех же параметрах их не увидеть. Ведь так оно должно получится, я ничего не путаю?

2) может кому нибудь попадалась какая-нибудь инфа по теме, особенно если с формулами)) Сам перерыл уже пол инета, в основном что-то или слишком уж сложное, на уровне PhD, или наоборот одна формула, полоса пропускания сервера в зависимости от кол-ва клиентов.

[-De-]

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

[alatar]

У вас при 15 коннектах гоняющих видео клиентская машина лагать начнет раньше сервера.

Добавлено через 8 минут

При 5ти юзерах разницы никакой, а вот при 5000 юникаст загнётся а мультикаст будет продолжать работать. Вот я типа проанализировал, сравнил две этих технологии и выяснил что мультикаст рулит, и поэтому реализовал на нём.

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

[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 (то есть классический клиент-сервер) я не рассматриваю совсем.

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

[-De-]

Вещатель вещает на одну группу, в группе 100 слушающих юзеров. От него идёт один видеопоток, 100 раз профит. Это что такое вообще есть мультикаст. Демонстрируйте =)
Неприятности начинаются, когда вещатель вещает в несколько групп или в группе несколько вещателей, наверное та конференция была как раз про это.
Размножают мультикастовые пакеты специально обученные железки (в один интерфейс пакет входит, во много выходит). Они и генерят профит. И чтоб показать его нужны будут такие железки. Не думаю, что протокол поддерживает такое, что входит один пакет, а после он идёт в удвоенном количестве на один интерфейс, но на разные порты.

[cauchy]

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

Вещатель вещает на одну группу, в группе 100 слушающих юзеров. От него идёт один видеопоток, 100 раз профит. Это что такое вообще есть мультикаст. Демонстрируйте =)
Неприятности начинаются, когда вещатель вещает в несколько групп или в группе несколько вещателей, наверное та конференция была как раз про это.
Размножают мультикастовые пакеты специально обученные железки (в один интерфейс пакет входит, во много выходит). Они и генерят профит. И чтоб показать его нужны будут такие железки. Не думаю, что протокол поддерживает такое, что входит один пакет, а после он идёт в удвоенном количестве на один интерфейс, но на разные порты.

Хммм, точно, с той формулой я немного протупил. Она видимо как раз касается обычного слушающего пира и кол-ва его соседей, но не вещающего пира. Для вещающего действительно один поток и профит получается в n раз.
Конференция у меня как раз сейчас самая простая реализована, один вещает остальные слушают (точнее её даже нужно называть не конференцией а скорее просто вещанием).

Насчёт того кто размножает мультикастовые пакеты не совсем понял. Как я себе представлял: железки занимаются native mulicast(ом), а вот программным мультикастом занимается rtmfp, ну или сами экземпляры флеш-плеера, не знаю как точно сказать.

Теперь по поводу того, что удалось посмотреть:
поставил сканнер и ограничиватель траффика по винду.Вещаю с одного компа, на другом запускаю несколько экземпляров приложения. Для юникаста скорость возрастает пропорционально (на приложенной времянке видно как последовательно коннектятся 4 пира). Дальше идёт мультикаст, там также последовательно 4 пира, но полоса остаётся примерно одинаковой, профит действительно в n раз.
Вопрос только в том, почему при юникасте лагов не наблюдается, а при мультикасте все клиенты ловят видео с большими тормозами... Качество сейчас стоит 640х480х30fps, quality=100.
Наверное при качестве похуже лагов не будет, но без группы и с таким качеством лагов нет...