А хотите тоже пример, но только куда более реальный?
Возьмем unicast вещание видеопотоков.
Конкретнее - предоставление доступа к ТВ контенту.
Учитывая объявленную гуглем концепцию интернет-ТВ года через 2-4 эта тема так или иначе выйдет на поток.
В силу разного рода причин в таких системах не удастся применить только multicast потоки. Прежде всего потому, что сервис в большинстве случаев будет отвязан от сетевой инфраструктуры ISP конечного абонента. Пример мы уже видим - проект "Бонус-ТВ".
Задача для транспортных сетей формулируется как необходимость доведения до пользователя потоков данных на скорости 1-5М.
Принципиальных моментов здесь два:
1) Речь идет не о web серфинге, а о воспроизведении/переключении видеопотоков в реальном времени. Здесь будет иметь смысл рубиться (в прямом смысле этого слова) за интегральное время отклика системы на действия пользователя (где сетевое взаимодействие клиент-сервер играет не последнюю роль).
2) Потребление данного типа трафика может сильно добавить трафика в сети.
Арифметика по трафику здесь простая: число абонентов данного сервиса * 0.1 * средний битрейт для SD канала(в зависимости от метода кодирования 0.5-5М). При условии распространения СТБ в качестве доступа к сервису коэффициент 0.1 можно смело менять на 0.2-0.35.
Ну и самое интересное.
Какую связность должен купить контент-провайдер, если он планирует обслуживать к примеру украинских абонентов? Думаю UAIX будет рассматриваться как вариант.
А если проект расчитан на одесситов? Ммммм....здесь уже вопрос сложный.
Предже всего потому, что вся необходимая связность и так покупается в Киеве (?).
Но по большому счету это уже вопрос конкуренции разных IX...
Надо будет вернуться к анализу этого вопроса весной 2011.




Тема:


Ответить с цитированием
. Были и немало. Или ты думаешь, что в одикс всех участников в пьяном виде заманили, что ли? Паритетов никто не отменял. Деньги, если ты еще помнишь, тебе уплачены
)

Социальные закладки