Комментарии 27
Он не зависит от получателя и формируется из адреса мультикаст-группы. Соответственно, на такие пакеты претендуют все клиенты, подключенные к беспроводной точке доступа. Вследствие этого нам достается лишь часть пакетов и мы видим обрывистую картинку.
это звучит как минимум странно и как максимум совершенно неверно. Подозреваю, что вы не полностью разобрались. wiFi является средой с одновременным множественным доступом. Соотвественно broadcast/multicast пакеты слышат все клиенты и принять могут тоже все, в зависимости от конкретных условий приема. То, что кто-то из клиентов таки принимает multicast-пакет с широковещательным dst mac-адресом группы не удаляет этот пакет из эфира (чудес не бывает).
Согласен, причину падения трафика не рассмотрел должным образом.
Вот-вот. Я тогда не понял — в чём сложность мультикаста и wifi в среде с общим доступом-то?
В том, что WiFi в общем случае организует надежную доставку сообщений. За исключением broadcast и multicast трафика. В итоге если клиент получает битый мультикастовый фрейм, то он не будет перепослан.
Разве мультикаст где-то перепосылается?
Какой-то вопрос у вас странный. Я же написал выше, что в WiFi мультикаст не перепосылается. Но если вы, например, будете транслировать мультикаст через VPN-tunnel-over-TCP, то он будет замечательно перепосылаться на участке VPN, если будут потери. Потому что VPN в данном случае для мультикаста — это уровень L2, который организует надежную доставку независимо от payload.
Отвечая на ваш вопрос более коротко — зависит от L2.
Отвечая на ваш вопрос более коротко — зависит от L2.
В противном случае, точке доступа пришлось бы отслеживать кол-во клиентов, которые подписаны на этот мультикаст через вайфай и количество полученных ack'ов. А ещё каждый новый фрейм вызывал бы шквал ack'ов: по одному от каждого клиента, что приводило бы к частым коллизиям при получении доступа к среде, испорченным (из-за наложения) ack'ам. Испорченные ack'и вызывали бы повторные не нужные перепосылки multicast'а. И всё по кругу.
В мультикасте не ACK на каждый пакет, там по таймеру(измеряемый в секундах)посылается пакет для подтверждения подписки.
Вы вообще путаете тёплое с мягким. Я вам рассказываю о том, как работала бы надежная доставка в WiFi, если бы она была включена для multicast, а вообще сейчас говорите о протоколе IGMP. Это вообще про разное.
В мультикасте вообще нет ACK. ACK есть в WiFi, есть в TCP. А мультикаст — это вообще не протокол, это способ адресации всего лишь. Как правило используется для UDP трафика, но не только. Какая-то у вас каша.
В мультикасте вообще нет ACK. ACK есть в WiFi, есть в TCP. А мультикаст — это вообще не протокол, это способ адресации всего лишь. Как правило используется для UDP трафика, но не только. Какая-то у вас каша.
Скорее всего для мультикаст траффика не работает механизм надежной доставки WiFi.
Он и не нужен. Пока пакет приедет повторно — он уже окажется ненужен.
Ваше утверждение как минимум спорно. Потому что когда через WiFi вы имеете дело с таким же трафиком, но unicast, то таких лагов, как у автора не наблюдается. Учитывая, что вероятность успешной передачи пакета не зависит от его типа (u-cast vs. m-cast), то это означает, что WiFi механизмы в случае unicast работают и работают успешно.
И ещё, вы говорите только о риалтайм трафике (голос/видео), передаваемых через UDP, как правило. Да будет вам известно, что мультикаст применяется ещё в куче протоколов. Тут вы найдёте не полный список протоколов, который используют мультикаст и которым зачастую до одного места риалтаймовость. Кстати, сам протокол IGMP, тоже работает через multicast.
А ещё мультикаст применяют на биржах, для рассыки рыночной информации. И там пропуск одной дейтаграммы будет означать невозможность накатить обновления. Для этого там существуют TCP-сервисы, через которые можно запросить пропущенные номера пакетов.
В общем ситуаций много разных. Не всегда можно просто взять и забить на неполученный по мультикасту пакет.
А ещё мультикаст применяют на биржах, для рассыки рыночной информации. И там пропуск одной дейтаграммы будет означать невозможность накатить обновления. Для этого там существуют TCP-сервисы, через которые можно запросить пропущенные номера пакетов.
В общем ситуаций много разных. Не всегда можно просто взять и забить на неполученный по мультикасту пакет.
НЛО прилетело и опубликовало эту надпись здесь
> Поэтому я написал свой софт для UDP->HTTP@TCP: www.netlab.linkpc.net/wiki/ru:software:msd:lite
Интересно, надо попробовать. В IPTV новичек.
А на сколько оно лучше по производительности? Udpxy ругают за то, что после определенного числа клиентов оно начинает тормазить, вне зависимости от мощностей железа. Честно сказать, юзаем udpxy на небольшом числе клиентов, и проблем нет. Тестировали ли данный софт на больших нагрузках?
Интересно, надо попробовать. В IPTV новичек.
А на сколько оно лучше по производительности? Udpxy ругают за то, что после определенного числа клиентов оно начинает тормазить, вне зависимости от мощностей железа. Честно сказать, юзаем udpxy на небольшом числе клиентов, и проблем нет. Тестировали ли данный софт на больших нагрузках?
За мультикаст отдаваемый клиентам я бы бил по рукам, ибо клиентам этот мультикаст девать некуда, им юникаст много удобнее
В статье речь шла о передаче трафика от роутера до приставки. Об отдаче клиентам мультикаста по WiFi речи и не было.
Маршрутизация и ретрансляция это немного разные понятия
Таки маршрутизация, ибо отправка пакета зависит от таблицы маршрутизации, а не от виртуальных интерфейсов, как это сделано стандартно.
Заменив мак на юникастовый вы похерили единственное преимущество этого способа трансляции — саморазмножение потока
Простите, а зачем на IPTV-приставке дальнейшее размножение потока?
Поэтому я написал свой софт для UDP->HTTP@TCP
Опять же, если у вас неизменяемый список каналов из мультикаст-адресов, полученные от вашего провайдера, то чем вам поможет UDP->HTTP@TCP? Я говорю как клиент, а не провайдер.
> За мультикаст отдаваемый клиентам я бы бил по рукам, ибо клиентам этот мультикаст девать некуда, им юникаст много удобнее.
Пожалуйста, раскройте этот тезис подробнее. А имено: в чем разница для клиента какой траффик ему принимать, когда речь идет о UDP?
Пожалуйста, раскройте этот тезис подробнее. А имено: в чем разница для клиента какой траффик ему принимать, когда речь идет о UDP?
Уже несколько раз присматриваюсь к вашему костылю (я про полную версию), но пока сижу на астре, чего я не нахожу в вашем решении, так это возможности переопределить имя канала так, чтоб полностью спрятать источник от абонента, очень нужная фишка при коммерческой ретрансляции.
Прошу прощения, но чем это черевато? Допустим, можно из этой информации узнать поставщика контента. Но как навредить этим можно?
НЛО прилетело и опубликовало эту надпись здесь
Кроме отвеченных вариантов, еще чисто политические заморочки, просто пример, я обслуживаю сеть в Крыму, так что легально каналы я могу брать только в РФ, но из Украины поток взять намного дешевле, за астрой прячем реальный источник и нам спокойно и поставщику, который тоже не должен нам вещать. Иногда провайдеры разбавляют свою сетку каналами от конкурентов, естественно без разрешения, тоже нужно прикрыть источник, иногда один источник на несколько юрлиц одного оператора и на разных юрлицах разная цена, короче есть свои заморочки не считая эстетики когда в плейлисте только свой домен.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Юникастовая маршрутизация мультикаст-трафика