UDP-широковещательная / многоадресная рассылка и одноадресное поведение (отброшенные пакеты)

У меня есть встроенное устройство (источник), которое отправляет поток (аудио) данных кусками по 20 мс (= около 330 байт) с помощью пакетов UDP. Таким образом, объем сети довольно низкий - около 16 кбит / с (практически несколько больше из-за накладных расходов UDP / IP). Устройство работает под управлением стека lwIP (v1.3.2) и подключается к сети Wi-Fi с помощью решения Wi-Fi от H&D Wireless (HDG104, WiFi G-mode). Пункт назначения (приемник) - это ПК с Windows Vista, который также подключен к сети Wi-Fi с помощью USB-ключа Wi-Fi (режим WiFi G). На ПК запущена программа, которая позволяет мне отслеживать количество отброшенных пакетов. Я также использую Wireshark для прямого анализа сетевого трафика. На данный момент никакие другие клиенты не отправляют данные по сети активно.

Когда я отправляю данные с помощью широковещательной или многоадресной рассылки, многие пакеты отбрасываются, иногда до 15%. Однако, когда я переключаюсь на одноадресную рассылку UDP, количество отброшенных пакетов незначительно (‹2%).

Используя UDP, я ожидаю, что пакеты будут отброшены (что нормально для моего аудио приложения), но почему я вижу такую ​​большую разницу в производительности между широковещательной / многоадресной передачей и одноадресной передачей?

Мой маршрутизатор - WRT54GS (FW v7.50.2), а ПК (приемник) использует сетевой адаптер trendnet TEW-648UB, работающий в режиме WiFi G.


udp multicast broadcast lwip
person djbuijs    schedule 24.06.2013    source источник

Ответы (2)


arrow_upward
9
arrow_downward

Похоже, это хорошо известная проблема с Wi-Fi:

Цитируется из http://www.wi-fiplanet.com/tutorials/article.php/3433451

Стандарты 802.11 (Wi-Fi) определяют поддержку многоадресной рассылки как часть асинхронных служб. Клиентская станция 802.11, такая как беспроводной портативный компьютер или КПК (не точка доступа), начинает многоадресную доставку, отправляя многоадресные пакеты в одноадресных кадрах данных 802.11, направленных только на точку доступа. Точка доступа отвечает кадром подтверждения 802.11, отправленным на станцию-источник, если в кадре данных не обнаружено ошибок.

Если клиент, отправляющий фрейм, не получает подтверждения, то клиент повторно передает фрейм. При многоадресной передаче участок пути данных от беспроводного клиента до точки доступа включает в себя восстановление после ошибок передачи. Протоколы 802.11 обеспечивают надежность между станциями как в инфраструктурных, так и в специальных конфигурациях при использовании одноадресной передачи кадров данных.

После получения одноадресного кадра данных от клиента точка доступа передает данные (которые исходящий клиент хочет многоадресной рассылки) в виде многоадресного кадра, который содержит групповой адрес в качестве пункта назначения для предполагаемых получателей. Каждая из станций назначения может принять кадр; однако они не отвечают подтверждениями. В результате многоадресная рассылка не обеспечивает полный и надежный поток данных.

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

В этой статье содержится дополнительная информация: http://hal.archives-ouvertes.fr/docs/00/08/44/57/PDF/RR-5947.pdf

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

person djbuijs    schedule 09.07.2013

arrow_upward
1
arrow_downward

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

Потоковая передача UDP с потерей пакетов - это хорошо известная проблема, которая обычно решается с помощью некоторого типа прямого исправления ошибок. В последнее время класс, известный как фонтанные коды, такой как Raptor-Q, показывает многообещающую проблему потери пакетов, в частности, когда существует несколько ненадежных источников данных одновременно. (пример: несколько точек доступа Wi-Fi на территории)

person Bjarne Vinkelhake    schedule 08.03.2014
comment
Спасибо за добавление, это очень интересно. Мы рассматривали возможность прямого исправления ошибок, но я не смотрел на Raptor-Q. Одна из проблем заключается в том, что для моего приложения допустимая задержка составляет <300 мс. В большинстве случаев, когда возникает проблема, вы получаете строку пропущенных пакетов, что затрудняет исправление ошибок. Решение для нас оказалось довольно простым: большинство профессиональных точек доступа поддерживают функцию многоадресного перевода в Unicast. Вы все равно получите некоторую потерю пакетов, но не такую ​​большую. - person djbuijs; 14.03.2014