2012-03-26 2 views
0

Я пишу приложение, которое получает многоадресные данные на сервере Redhat Enterprise Linux 6. Группа поддержки дает мне приложение, которое используется для проверки того, может ли сервер получать многоадресный поток данных.Redhat Enterprise Linux 6 Multicast Feed

Как только я начинаю тестовое приложение, а также имея TCPDUMP ход, я могу видеть, широковещательные данные поступают, например,

12:58:21.645968 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 729 
12:58:21.648369 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 969 
12:58:21.649406 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 893 
12:58:21.651823 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 604 
12:58:21.654079 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 913 
12:58:21.656724 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 1320 
12:58:21.658194 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 124 
12:58:21.658226 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 217 
12:58:21.658348 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 182 
12:58:21.658625 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 1014 
12:58:21.659592 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 135 
12:58:21.659842 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 242 
12:58:21.660674 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 242 
12:58:21.660743 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 84 
12:58:21.662327 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 84 
12:58:21.669154 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 161 
12:58:21.669365 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 166 
12:58:21.670792 IP 10.26.12.22.60002 > 238.230.230.100.60002: UDP, length 49 
12:58:21.670796 IP 10.26.12.22.60002 > 238.230.230.100.60002: UDP, length 49 
12:58:21.670798 IP 10.26.12.22.60002 > 238.230.230.100.60002: UDP, length 49 
12:58:21.670799 IP 10.26.12.22.60002 > 238.230.230.100.60002: UDP, length 49 

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

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

Мне интересно, какие настройки Linux я должен искать, что потенциально может остановить приложение, получающее данные многоадресной передачи, даже если вы думаете, что tcpdump может видеть данные. Отсутствуют библиотеки или пакеты?

Спасибо.

ответ

3

Прежде всего, стоит проверить, что RHEL 6 поддерживает многоадресную рассылку на уровне ядра. (это возможно, но у меня нет RHEL 6, доступного для проверки). Убедитесь, что файл/proc/net/igmp существует.

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

Другая задача - проверить содержимое файла/proc/net/igmp во время работы тестового приложения. Файл/proc/net/igmp будет содержать список всех групповых адресов многоадресной передачи, которые сервер активно получает. Если в столбце «Группа» есть запись, соответствующая групповому адресу групповой адреса, который предполагается использовать тестовому приложению (в вашем случае 238.6.6.36 и 238.230.230.100), то параметры сокета IP_ADD_MEMBERSHIP (или IP_ADD_SOURCE_MEMBERSHIP), вероятно, были правильно названы и на правильном сетевом адаптере. Обратите внимание, что в столбце Group перечислены групповые адреса групповой адреса в шестнадцатеричном и обратном направлениях, поэтому 238.6.6.36 будет указан как 240606EE.

Ваша ситуация может быть более сложной, если у вас есть многоадресный маршрутизатор (например, Xorp, igmpproxy), работающий на том же компьютере, на котором вы запускаете тестовое приложение. Если это так, вы должны также изучить файлы/proc/net/ip_mr_vif и/proc/net/ip_mr_cache, чтобы убедиться, что есть соответствующие записи.

+0

Спасибо Эндрю за ваш добрый ответ. Поскольку я не эксперт в сети, я отправлю это команде поддержки. – 2607

+0

Полезная информация, у меня такая же проблема. Не знал о/proc/net/igmp, но использовал netstat -g. Все еще не нашел проблемы – easytiger

1

У меня была аналогичная проблема на машине RHEL 6. Я разрешил его, добавив необходимый порт UDP к разрешенным портам через брандмауэр. Попробуйте добавить udp-порт 50002.

+0

Благодарим вас за ответ.Как selinux, так и iptable отключены на сервере. Что происходит, так это то, что перед многоадресными данными процесса приложения требуется моментальный снимок из другого источника данных одноадресной передачи, и этот порт источника одноадресной рассылки не открыт. – 2607

2

PLS проверить на уровне переключателя. В моем случае я был застрял в кластеризации. Мой кластер будет работать только на mulitcast. Но я столкнулся с некоторыми потерями пакетов в mulitcast. Это было слишком странно для меня. Но в итоге я получил решение от одного из моих лучших друзей (google). Я только отключил IGMP на моем уровне переключателя, и он работает нормально.

Смежные вопросы