Юникастовая маршрутизация мультикаст-трафика

[Karroplan]

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

это звучит как минимум странно и как максимум совершенно неверно. Подозреваю, что вы не полностью разобрались. wiFi является средой с одновременным множественным доступом. Соотвественно broadcast/multicast пакеты слышат все клиенты и принять могут тоже все, в зависимости от конкретных условий приема. То, что кто-то из клиентов таки принимает multicast-пакет с широковещательным dst mac-адресом группы не удаляет этот пакет из эфира (чудес не бывает).

[q1b]

Согласен, причину падения трафика не рассмотрел должным образом.

[nevzorofff]

Вот-вот. Я тогда не понял — в чём сложность мультикаста и wifi в среде с общим доступом-то?

[dmitrmax]

В том, что WiFi в общем случае организует надежную доставку сообщений. За исключением broadcast и multicast трафика. В итоге если клиент получает битый мультикастовый фрейм, то он не будет перепослан.

[nevzorofff]

Разве мультикаст где-то перепосылается?

[dmitrmax]

Какой-то вопрос у вас странный. Я же написал выше, что в WiFi мультикаст не перепосылается. Но если вы, например, будете транслировать мультикаст через VPN-tunnel-over-TCP, то он будет замечательно перепосылаться на участке VPN, если будут потери. Потому что VPN в данном случае для мультикаста — это уровень L2, который организует надежную доставку независимо от payload.

Отвечая на ваш вопрос более коротко — зависит от L2.

[nevzorofff]

Только мультикаст в вашем примере к перепосылке не имеет никакого отношения. Перепосылаться будет L2 пакет, а не мультикаст.

[dmitrmax]

Какой вопрос, такой ответ.

[dmitrmax]

В противном случае, точке доступа пришлось бы отслеживать кол-во клиентов, которые подписаны на этот мультикаст через вайфай и количество полученных ack'ов. А ещё каждый новый фрейм вызывал бы шквал ack'ов: по одному от каждого клиента, что приводило бы к частым коллизиям при получении доступа к среде, испорченным (из-за наложения) ack'ам. Испорченные ack'и вызывали бы повторные не нужные перепосылки multicast'а. И всё по кругу.

[nevzorofff]

В мультикасте не ACK на каждый пакет, там по таймеру(измеряемый в секундах)посылается пакет для подтверждения подписки.

[dmitrmax]

Вы вообще путаете тёплое с мягким. Я вам рассказываю о том, как работала бы надежная доставка в WiFi, если бы она была включена для multicast, а вообще сейчас говорите о протоколе IGMP. Это вообще про разное.

В мультикасте вообще нет ACK. ACK есть в WiFi, есть в TCP. А мультикаст — это вообще не протокол, это способ адресации всего лишь. Как правило используется для UDP трафика, но не только. Какая-то у вас каша.

[dmitrmax]

Скорее всего для мультикаст траффика не работает механизм надежной доставки WiFi.

[nevzorofff]

Он и не нужен. Пока пакет приедет повторно — он уже окажется ненужен.

[dmitrmax]

Ваше утверждение как минимум спорно. Потому что когда через WiFi вы имеете дело с таким же трафиком, но unicast, то таких лагов, как у автора не наблюдается. Учитывая, что вероятность успешной передачи пакета не зависит от его типа (u-cast vs. m-cast), то это означает, что WiFi механизмы в случае unicast работают и работают успешно.

[dmitrmax]

И ещё, вы говорите только о риалтайм трафике (голос/видео), передаваемых через UDP, как правило. Да будет вам известно, что мультикаст применяется ещё в куче протоколов. Тут вы найдёте не полный список протоколов, который используют мультикаст и которым зачастую до одного места риалтаймовость. Кстати, сам протокол IGMP, тоже работает через multicast.

А ещё мультикаст применяют на биржах, для рассыки рыночной информации. И там пропуск одной дейтаграммы будет означать невозможность накатить обновления. Для этого там существуют TCP-сервисы, через которые можно запросить пропущенные номера пакетов.

В общем ситуаций много разных. Не всегда можно просто взять и забить на неполученный по мультикасту пакет.

[calvin_rus]

> Поэтому я написал свой софт для UDP->HTTP@TCP: www.netlab.linkpc.net/wiki/ru:software:msd:lite

Интересно, надо попробовать. В IPTV новичек.

А на сколько оно лучше по производительности? Udpxy ругают за то, что после определенного числа клиентов оно начинает тормазить, вне зависимости от мощностей железа. Честно сказать, юзаем udpxy на небольшом числе клиентов, и проблем нет. Тестировали ли данный софт на больших нагрузках?

[q1b]

За мультикаст отдаваемый клиентам я бы бил по рукам, ибо клиентам этот мультикаст девать некуда, им юникаст много удобнее

В статье речь шла о передаче трафика от роутера до приставки. Об отдаче клиентам мультикаста по WiFi речи и не было.

Маршрутизация и ретрансляция это немного разные понятия

Таки маршрутизация, ибо отправка пакета зависит от таблицы маршрутизации, а не от виртуальных интерфейсов, как это сделано стандартно.

Заменив мак на юникастовый вы похерили единственное преимущество этого способа трансляции — саморазмножение потока

Простите, а зачем на IPTV-приставке дальнейшее размножение потока?

Поэтому я написал свой софт для UDP->HTTP@TCP

Опять же, если у вас неизменяемый список каналов из мультикаст-адресов, полученные от вашего провайдера, то чем вам поможет UDP->HTTP@TCP? Я говорю как клиент, а не провайдер.

[dmitrmax]

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

Пожалуйста, раскройте этот тезис подробнее. А имено: в чем разница для клиента какой траффик ему принимать, когда речь идет о UDP?

[RicoX]

Провтыкал значит эту возможность, а может и возможность авторизации для абонентов есть, а я не вижу?

[RicoX]

Уже несколько раз присматриваюсь к вашему костылю (я про полную версию), но пока сижу на астре, чего я не нахожу в вашем решении, так это возможности переопределить имя канала так, чтоб полностью спрятать источник от абонента, очень нужная фишка при коммерческой ретрансляции.

[calvin_rus]

Прошу прощения, но чем это черевато? Допустим, можно из этой информации узнать поставщика контента. Но как навредить этим можно?

[RicoX]

Кроме отвеченных вариантов, еще чисто политические заморочки, просто пример, я обслуживаю сеть в Крыму, так что легально каналы я могу брать только в РФ, но из Украины поток взять намного дешевле, за астрой прячем реальный источник и нам спокойно и поставщику, который тоже не должен нам вещать. Иногда провайдеры разбавляют свою сетку каналами от конкурентов, естественно без разрешения, тоже нужно прикрыть источник, иногда один источник на несколько юрлиц одного оператора и на разных юрлицах разная цена, короче есть свои заморочки не считая эстетики когда в плейлисте только свой домен.