Особенности работы с Multicast
Хочу поделиться небольшим опытом работы с технологией групповой передачи данных, или иначе UDP Multicast, и проблемой особенностью, которая возникает при написании кроссплатформенного кода.
Сразу оговорюсь, что в этой статье не будет рассматривать сама технология и протокол UDP, для этого лучше обратиться к UDP, а потом к Multicast.
Итак, вся работа начинается с создания сокета и его «настройки». В общих чертах выглядит это так
1. создать сокет
2. сделать bind
3. подключится с Multicast группе.
Создание сокета
Тут все просто и без подвохов
Связывание сокета
Первое что мы должны сделать, это позволить использовать PORT повторно, т.к. помимо нас кто-то еще может работать с этим портом.
Функция setsockopt позволяет задать опции для сокета. Интересным моментом является то, что значение опции передается по указателю на void, т.к. некоторые опции требует не просто флаг включено/выключено, а структуры с дополнительными то данными.
Далее нам необходимо связать сокет с портом. А может еще и адресом? Тут вступает в силу первая проблема особенность — различная идеология ядер Windows и Linux. А именно то, что под Windows мы не можем забиндиться на адрес Multicast группы (получаем ошибку) и должны биндиться на INADDR_ANY
На Linux мы можем так же забиндиться на INADDR_ANY, но в этом случае мы будем получать все дейтаграммы пришедшие на забинденный нами порт. Для того чтобы получать дейтаграммы только из нужной группы, необходимо забиндиться именно на адрес этой группы (ну и порт конечно не забыть).
Подключение к группе
Главной особенностью Multicast является то, что наш хост не будет получать данных до тех пор пока мы не подключимся к Multicast группе. Подключение на уровне пользователя выглядит как установка опции для сокета.
где ip_mreq.imr_multiaddr это адрес мультикаст группы. А ip_mreq.imr_interface это адрес интерфейса, на котором мы ожидаем получать дейтаграммы. INADDR_ANY в данном случае говорит о том, что мы оставляем это право за ядром, которое выберет интерфейс исходя из таблицы роутинга. Далее ядро проверит не подключены ли мы уже к этой группе, и если нет, то отправит запрос на ближайший Multicast сервер. Тот в свою очередь дальше и т.д. После чего нам на хост будут отправлять дейтаграммы, отправляемые в данную Multicast группу.
Но что делать с Windows который забинден на INADDR_ANY? Он что будет получать все дейтаграммы отправленные на слушаемый порт? Судя по всему ядро Windows, при указании этой опции для сокета, само производит фильтрацию получаемых данных. И таким образом на сокет доставляются данные только из подписанных групп.
На Linux для того, чтобы получать данные на сокет только от подключенной Multicast группы, необходимо забиндиться на ее же адрес.
Если вы мне не верите (а я сам в это в начале не поверил) то поверьте ему
Unix Network Programming 3 издание. глава 21.6 страница 599
— Чтобы получить дейтаграмму многоадресной передачи, процесс должен присоединиться к группе, а также связать при помощи функции bind сокет UDP с номером порта, который будет использоваться как номер порта получателя для дейтаграмм, отсылаемых данной группе.
…
Связывая порт, приложение указывает UDP, что требуется получать отправляемые на этот порт дейтаграммы. Некоторые приложения в дополнения к связыванию порта также связывают при помощи функции bind адрес многоадресной передачи с сокетом. Это предотвращает доставку сокету любых других дейтаграмм, которые могли быть получены для этого порта.
А как в boost’e ?
Разочарую вас, в boost все аналогично API, никакой адаптации под единую логику не производится. Таким образом, используя его для написание кроссплатформенного приложение вам все равно придется делать
Несколько групп для одного сокета
Пока писал пост, понял, что путь, предложенный для Linux, скрывает одно ограничение. Мы должны работать по принципу один сокет — одна Multicast группа. Так как навряд ли возможно забиндиться сразу не несколько адресов.
Обрисую ситуацию. Есть сервер, он вещает данные в несколько мультикаст групп на один порт.
Есть клиент, он желает получать от сервера данные только в нескольких группах. Тогда ему нужно предпринять следующие действия:
1. биндиться на INADDR_ANY
2. далее фильтровать все полученные дейтаграммы в ручную определяя их destination 1 адрес.
Процесс фильтрации полученных на сокете дейтаграмм по destination адресу вытекает из того, что возможна ситуация когда на машине клиента есть еще другой софт который подключается к каким то другим группам но с тем же портом и тогда оба сокета будут получать дейтаграммы со всех подключенных групп на этом порту.
Но при этом на лицо проблема избыточности данных.
Ну собственно об тих особенностях работы с Multicast я и хотел вам рассказать, не зная которых вы рискуете наступить на грабли.
PS. Для того что бы все это прочувствовать предлагаю проделать следующие шаги.
1. Собрать receiver
2. Собрать sender
Далее на Linux запустить
3. Запустить: receiver 0.0.0.0 239.192.100.1
4. Запустить: receiver 0.0.0.0 239.192.100.2
5. Запустить: sender 239.192.100.1
6. Убедить что оба receiver’a получат данные
Далее тоже запустить на Windows
7. Убедиться что данные получит только тот кому мы их отправили.
1 Еще одной особенностью UDP является то, что адрес отправителя и получателя явным образом не указывается в заголовке UDP сообщения. Но он учитывается при подсчете чексумы, таким образом получая дейтаграмму UDP модуль должен составить свой псевдо заголовок, рассчитать чексуму и сравнив ее с полученной, принять решении о том что дейтаграмма адресовалась именно нам. Судя по всему Linux делает эту проверку, используя в качестве destination адрес на который мы забиндились, из за чего и получается описанная выше проблема особенность.
Windows multicast windows 7
The following forum(s) have migrated to Microsoft Q&A: All English Windows 7 IT Pro forums!
Visit Microsoft Q&A to post new questions.
Answered by:
Question
We have an established piece of software that uses IGMP UDP multicast messages to establish direct TCP communication. The software joins the multicast group using the address 224.100.0.1, then simultaneously sends UDP multicast messages while listening for UDP multicast messages from other copies of the same software running on other machines on the local network. The messages contain information then used for establishing direct TCP connections for further communication.
This software has been running successfully for many years now on Windows XP machines. We are in the progress of upgrading these machines to Windows 7, resulting in locations with mixed Windows 7 and XP machines on the same network, and have encountered a frustrating issue. Sometimes the Windows 7 machine will mysteriously refuse to send the multicast messages. The software is running fine on Windows 7, but the UDP multicast messages are not even reaching the router, much less any other machines on the network.
There is only one network interface on the Windows 7 machine, so it’s not the known issue of Windows 7 multicast getting confused about which interface to broadcast on. The firewall is turned off, and the network adapter itself is set to allow broadcast messages through. What else could be blocking/misdirecting the multicast messages?
Приручаем multicast
Остановимся на анализе мультикаст-трафика через IGMP-протокол. Рассмотрим реализацию работы протокола IGMP, работы протокола PIM, отправки JOIN-запросов. После анализа проблемы была разработана оптимальная конфигурация сетевого оборудования, эффективная настройка QOS. Данная задача появилась после обнаружения проблемы в сети, такой как прерывание сигнала у клиентов, наличие фризов и прерывание звука.
IGMP — Internet Group Management Protocol — это сетевой протокол взаимодействия абонентов мультикаст-трафика и ближайшего к ним сетевого оборудования.
Пользователь имеет подписку на следующую группу IP-адресов: 224.0.0.0 до 239.255.255.255. PIM Protocol реализован в режиме Sparse mode. Это означает, что трафик льется только на ту ветку, в которой есть клиенты, желающие войти в мультикаст-группу. Они отправляют сообщения PIM Join. Если клиенты не отправляют Join, то трафик им отправляться не будет. PIM Sparse Mode включен на двух интерфейсах. В сторону источника мультикаст-трафика и в сторону клиента. На стороне клиента имеет цифровой ресивер или абонентское устройство —IPTV-приставка.
Для справки: dense mode предполагает, что мультикаст-трафик идет до абонента, и неважно, подписывается ли он на определенный канал. Мультикаст идет во все порты, потом, если он не нужен по месту назначения, то отправляется служебный пакет PIM Prune, и трафик перестает идти по этой ветке.
IGMP-протокол реализуется в сторону клиента. PIM-протокол устанавливает соседство с другими маршрутизаторами. Для этого применяются служебные сообщения PIM Hello.
В нашей сети применялась вторая версия протокола IGMP.
Абонентское устройство, которое решает получить multicast-трафик, отправляет запрос в сообщении IGMP Membership Report (так называемый репорт).
Если абонентское устройство больше не желает получать мультикаст-трафик, то оно отправляет сообщение IGMP Leave. Эта функция реализована коммутаторах уровня доступа. IGMP Membership Group-Specific Query — повторное сообщение коммутатором в сеть о том, есть ли клиентские устройства, которые будут запрашивать мультикаст-трафик. Если их нет, то передача трафика прекращается.
IGMP snooping реализуется на сетевом оборудовании, отдельного включения функции недостаточно, необходима дополнительная настройка. После включения данной функции управляемые коммутаторы могут анализировать трафик — мультикаст-поток.
Если коммутатор обнаруживает IGMP-пакет, то он вносит порт в список мультикаст-групп. Если от абонента идет сообщение IGMP Leave, то коммутатор удаляет порт из подписчиков групп.
IGMP snooping позволяет предотвращать мультикаст шторм. Если функция IGMP snooping не включена, то оборудование ретранслирует multicast-трафик во все порты, которые находятся в одном VLAN. Это не эффективно, а также способно вызвать проблемы на сетевых устройствах, вынужденных обрабатывать высокий поток данных. Это может загружать CPU-оборудования. IGMP snooping улучшает работу сети.
Однако для того, чтобы получить мультикаст-трафик, нужно реализовать эту функции на стороне клиента. К примеру, если клиент подключен через роутер, то необходимо позаботиться о включении этой функции на роутере.
Проверить корректность работы мультикаст-вещания можно путем анализа трафика через Wireshark, после включения телевидения через VLC-медиаплеер. В настройках VLC указываем, к примеру, udp:@239.255.0.A:5500. Для передачи потока используется UDP протокол, далее идет мультикаст адрес, далее порт.
При разработке QOS учитывалось, что «красить» трафик желательно ближе к ядру сети. Его необходимо красить ближе к Randezvous Point. (Ну это для нашего случая)
На коммутаторах уровня доступа у нас применялись следующие настройки:
Глубокий анализ проблемы, применение средств диагностики и понимание работы протокола IGMP позволяет выработать эффективную и оптимальную конфигурацию мультикаст-трафика в вашей сети.