[bel]

берём vtund, в кач-ве транспорта выбираем tcp. на удалённом конце добавляем tap-интерфейс в бридж. благо, linux bridge умеет igmp snooping. потери отработает tcp, а задержку компенсирует буфер на клиенте.

Буфер на клиенте компенсирует не любую задержку. Если в один туннель будут завёрнуты несколько медиа-потоков, то потеря одного пакета будет приводить к задержке во всех медиапотоках. Задержки будут измеряться сотнями миллисекунд, а это уже много для IPTV.

Таких решений следует избегать.

[Alex/AT]

Просто такие решения стоят дешевле, нежели L3VPN/L2VPN нужной ёмкости с необходимым SLA (а между городами/регионами цена чаще всего такая, что плюнешь, и пойдёшь через паблик). Тем более, что можно поднять не один туннель, а пачку - по туннелю на 2-3-4 канала. Буфер у клиентов, кстати, весьма приличен. Ну и да - в паблике можно гораздо дешевле заиметь пару ног на случай отказа одной из.

 

"Следует избегать" - тоже не однозначный вариант. Вопрос весь в том, зачем multicast. Если он для физиков-ядерщиков в институте или для хирургов во время операции, то паблик исключён по-любому. А если тупо налить мультикаста для видеоконференций или трансляции клиентам - мелкие огрехи, происходящие раза два в сутки, никто не заметит.

 

потеря одного пакета будет приводить к задержке во всех медиапотоках

selective ACK никто не отменял.

Изменено 1 июля, 2012 пользователем Alex/AT

[bel]

потеря одного пакета будет приводить к задержке во всех медиапотоках

selective ACK никто не отменял.

Я имел в виду Selective ACK. Без него всё значительно печальнее.

[Ivan_83]

Я делал просто L2 туннелирование на фре в юдп, с помощью нетграфа. Им же пропускал в мост только юдп и игмп на мультикаст. Ходило петлёй через мск (те 10 часовых поясов в сумме). Всё работало отлично, даже лучше, чем по TCP - он со своими потерями и ретрансимтами только лаги доставлял, иногда, в юдп лился и лился и пофик ему на всё было.

Это я себе домой телек так одно время забирал.

 

но мне все не дает покоя вроде бы теоретически простое решение - подменить в заголовках пакетов мультикаст адреса на белые юникаст - отроутить куда надо через пиринг и на другой стороне обратное преобразование сделать (для начало тупо с помощью DNAT в iptables. Опять же, кто, как говориться мне мешает попробовать... просто, блин, интересно...

Вроде mrouted умеет как то туннели делать. Может быть xorp.

С подменой могут возникнуть проблемы - в игмп ип опции используются, которые некоторые любят резать, также ядро может мультикаст раньше захавать и куда то в другое место обрабатывать.

 

 

Для IPTV приемлемым процентом потерь пакетов можно считать 0.0004167% (оди пакет из 240000).

Откуда дровишки?

[Ilya Evseev]

На знаю, как это будет работать, но мне бы понравился вариант с двумя updxy:

центральный принимает мультикаст и отдаёт юникастовые потоки:

 

http://www.udpxy.com/forum/viewtopic.php?f=6&t=42&p=54

[voron]

Для IPTV приемлемым процентом потерь пакетов можно считать 0.0004167% (оди пакет из 240000).

Откуда дровишки?

Приемлемым уровнем потерь можно считать 1 пакет из 240000 (это приблизительно соответствует одному рассыпанию картинки за 10 минут).

[bel]

Для IPTV приемлемым процентом потерь пакетов можно считать 0.0004167% (оди пакет из 240000).

Откуда дровишки?

Из внутренних нормативных документов, по которым настроен мониторинг.

[white_crow]

всем спасибо - варианты ясны - надо пробовать. И тестить джиттер : )

[dr.Livci]

Linux/vtun (TAP-интерфейсы прекрасно гоняют мультикаст, проверено). Дешево и сердито.

 

Надо буит попробовать

Изменено 15 марта, 2013 пользователем dr.Livci

[^rage^]

Можно еще на gstreamer взглянуть. Он умеет как на вход мультикаст, так и на выход. А внутри - хоть hls :-)

[rdc]

Задержки будут измеряться сотнями миллисекунд, а это уже много для IPTV.

Если на приёмной стороне сделать большой буфер, сглаживающий джиттер, то это уже не имеет значения. Можно хоть на минуту задерживать.

Заметят это разве что в новый год, когда куранты опоздают :D

[boombastic]

Коллеги, подниму старючую тему т.к. у меня схожая задача.

Входные данные:

Есть центральный офис, в котором стоит сервер с мультикастом.

Есть несколько филиалов подключенных к центральному офису через OpenVPN (tun-mode).

В каждом филиале своя сеть с уникальной адресацией (192.168.1./24 для филиала-1, 192.168.2./24 для филиала-2 и т.п.).

Есть задача организовать передачу multicast "из центра" к филиалам.

 

Весь поиск информации на эту тему даёт мне решение вида: смена режима OpenVPN с tun на tap и бриджевание tap+lan интерфейсов для организации "прохода" мультикаста.

 

Но нельзя ли обойтись igmp-proxy + openvpn tun-mode (в варианте отдельный openvpn-процесс/tun-интерфейс на каждый филиал) ? point-to-point tunmode кажись называется?

 

Возможно что кто-то уже делал такое... интересует результат..

[Saab95]

Самое простое это преобразовать мультикаст в юникаст и передать его в таком виде, через публичные сети это более работоспособный вариант.

[boombastic]

это да, но что делать если не везде можно повставлять udpxy?

 

вот как было описано (openvpn/point-to-point tun mode + multicast) - встречались ли успешные инсталляции?

[Ivan_83]

Но нельзя ли обойтись igmp-proxy + openvpn tun-mode (в варианте отдельный openvpn-процесс/tun-интерфейс на каждый филиал) ? point-to-point tunmode кажись называется?

Всё что делает мультикаст мультикастом - это мак адрес, как ты его собрался передавать в л3?

Вернее передавать в л3 не проблема, проблема в твоём случае его туда запихнуть а потом вытащить.

Я на натграфе делал мост, который чисто игмп и мультикаст юдп пропускал и больше ничего, в инете оно ходило завёрнутым в юдп.

 

это да, но что делать если не везде можно повставлять udpxy?

Не везде а только в центре.

И не udpxy а msd_lite.

Если у тебя там какие то потоки большие а линки длинные и с дропами то тюнить ос обязательно.

Вообще вроде какие то PIM демоны есть которые умеют сами туннелировать мультикаст.

Если у тебя только иптв то можно попробовать астру.

Можно отдельно гре поднять под мультикаст и его туда заворачивать, отдельно от твоего опенвпн.