Абонент РТИ ДДС не получает данные от издателя

Question

Короткая история: мой подписчик DDS не может видеть данные от моего издателя DDS. Что мне не хватает?

Длинная история:

QNX 6.4.1 VM A -- Broken Publisher. IP ends with .113
QNX 6.4.1 VM B -- Working Publisher. IP ends with .114
Windows 7      -- Subscriber/Main Dev box. IP ends with .203
RTI DDS 5.0    -- Middleware version

У меня есть виртуальная машина QNX (размещенная в сети, а не на моей машине), которая публикует некоторые данные через RTI DDS. Данные никогда не отображаются в моем приложении подписчика Windows 7.

Интересно, что я могу поставить тот же код на ВМ В, и подписчик получает данные. Думая, что это должно быть проблемой брандмауэра Windows 7, я поменял IP-адрес ВМ А на ВМ В, но это не помогло.

Используя Wireshark, я вижу некоторый пульсирующий трафик с ВМ А, но нет данных. От VM B я вижу сердцебиение трафика и данных. Ниже приведен фрагмент кода Wireshark.

NDDS_DISCOVERY_PEERS устанавливается для включения как многоадресной рассылки, так и явного IP-адреса другой стороны каждого разговора. Профили QOS одинаковы, и анализатор RTI показывает, что анализ совпадений был успешным (все зеленые).

ВМ А:NDDS_DISCOVERY_PEERS=udpv4://239.255.0.1,udpv4://127.0.0.1,udpv4://BLAH.203

VM B:NDDS_DISCOVERY_PEERS=udpv4://239.255.0.1,udpv4://127.0.0.1,udpv4://BLAH.203

Windows 7 box:NDDS_DISCOVERY_PEERS=udpv4://239.255.0.1,udpv4://127.0.0.1,udpv4://BLAH.113,udpv4://BLAH.114

Когда я включаю их в NDDS_DISCOVERY_PEERS Кроме того, другие пользователи сети могут видеть трафик DDS от виртуальной машины A с DDS SPY на своем компьютере с Windows 7. Моя Windows 7 коробка не может.

В журнале событий Windows 7 не отображается брандмауэр или WFP, останавливающие пакеты данных.

RTI DDS Spy, запущенный с моего компьютера с Windows 7, показывает, что пишущие устройства VM A (0A061071) видны в сети, но данные не принимаются. Это также показывает, что читатели в моем подписчике на моей машине Windows 7 видны, хотя это обнаруживается в нечетном IP-адресе.

Бонусный вопрос (только из любопытства, а НЕ основной вопрос): почему трафик на моей локальной машине отображается в DDS SPY как 192.168.11.1 вместо IP моей машины или даже 127.0.0.1?

Главный вопрос: что мне не хватает?

Обновить:route print в моем Windows 7 появляется окно, показывающее, что я присоединился к многоадресной группе с ВМ А.netsh interface ip show joins казалось, согласился.

Обновление расследования:

1. Я перезагрузил ВМ безрезультатно.

2. Я перезагрузил Windows окно безрезультатно.

3. Я удалил мультикаст из NDDS_DISCOVERY_PEERS Переменные среды с обеих сторон не влияют.

4. Windows 7 имеет три сетевых интерфейса (плюс шлейф): 1 подключение к локальной сети и 2 (не связанных) адаптера VM. Мы работаем с подключением по локальной сети. Виртуальная машина QNX имеет один сетевой интерфейс (плюс шлейф). Обратите внимание, что работающая виртуальная машина и сломанная виртуальная машина используют разные драйверы Ethernet, отличающиеся друг от друга, так как они немного отличаются от QNX 6.4.1. Сломанный имеет wm0 как интерфейс, так и рабочий en0 в качестве интерфейса. Я не верю, что это проблема, но это разница.

5. Я запустил DDS SPY на "сломанной" виртуальной машине QNX, пока она воспроизводилась, и получил данные DDS. У меня нет хорошего метода, чтобы перехватить сеть между местом, где размещена виртуальная машина, и моей машиной с Windows 7, чтобы узнать, не выходит ли она из интерфейса, но я смотрю на количество переданных пакетов из интерфейса Ethernet на виртуальной машине QNX. указывает на то, что он определенно что-то передает, а перехваты Wireshark на самой машине Windows 7 показывают, что по крайней мере некоторый трафик проходит через них.

6. Другие люди в локальной сети могут видеть трафик DDS от "сломанной" виртуальной машины, что наводит меня на мысль, что это проблема установки Windows, а не сломанной виртуальной машины - я просто не вижу, что это может быть. Я перепроверил брандмауэр, но безрезультатно. Я бы подумал, что если бы это была проблема с брандмауэром, проблема исчезла бы, если бы я поменял местами IP-адреса между ВМ А и В. В любом случае брандмауэр Windows 7 в настоящее время отключен, но безрезультатно.

7. Ниже приведены несколько экранов вывода Wireshark. Я пропустил кучу между третьим и четвертым, так как после четвертого трафик до конца был похож на дно четвертого.

(Пропустил кучу здесь)(В значительной степени продолжается, как последние 11 строк выше)

Что еще я должен попробовать?

Обновление: чтобы ответить на вопрос Роуз ниже, используя rtiddsping -publisher на плохой ВМ и rtiddsping -subscriber работает правильно.

Интересно, вызвана ли эта проблема странным IP-адресом? IP-адрес, который он публикует и каким-то образом привязывает, является локальным адаптером Ethernet для виртуальной машины (отдельно от VM A). Смотрите скриншот ниже.

Адрес, к которому я бы хотел присоединить это 10.6.6.203. В любом случае, я могу это указать?

Answer 1

Более года спустя это случилось со мной снова с другой виртуальной машиной. У меня это работало вчера, поэтому я был очень подозрительным. Я проверил все свои изменения кода за последние 24 часа на наличие проблем, но не нашел. Затем я решил посмотреть, не добавили ли ИТ какие-либо исправления на мой компьютер.

Угадай, что? Брандмауэр Windows был агрессивно обновлен с предыдущего дня. Правила отсутствуют или изменены и т. Д. В журнале сказано, что пакеты отбрасывались. Я немного открыл фильтры брандмауэра, и вдруг все снова заработало. Я не решаюсь закрыть этот вопрос, так как я не на 100%, это было точно так же, как в прошлом году, но кажется очень похожим. Я подозреваю, что в прошлом году настройки брандмауэра не регистрировали потери пакетов.

Короче говоря: если DDS внезапно перестает работать, проверьте настройки брандмауэра.

Answer 2

Несколько вещей, чтобы попробовать:

1. Попробуйте запустить rtiddsping -publisher на сломанной виртуальной машине и rtiddsping -subscriber в Windows. Это имеет два преимущества:

   • Тип данных небольшой и общеизвестный, поэтому, если есть некоторая проблема с фрагментацией данных из-за различных драйверов Ethernet, это не произойдет с rtiddsping и может помочь отследить проблему.
   • Rtiddsping распечатывается, когда издатель и подписчик обнаруживают друг друга, поэтому вы сможете подтвердить, что обнаружение завершается правильно с обеих сторон. Я предполагаю, что обнаружение работает, потому что Analyzer показывает оба приложения, но это хорошо для подтверждения.

2. Если вы видите ту же проблему с rtiddsping, которую вы видите с вашим приложением, увеличьте детализацию до rtiddsping -verbosity 3, а затем 5. На самом высоком уровне детализации это выведет (много) дополнительный вывод, который может дать нам намек на то, что происходит.

Чтобы ответить на ваш бонусный вопрос о шпионе: причина, по которой шпион показывает этот IP-адрес, заключается в том, что это один из адресов, который объявлен как часть обнаружения. Во время обнаружения DomainParticipant может объявить до четырех IP-адресов, которые могут быть использованы для его достижения. Шпион выберет один из них для отображения, но это может быть не фактический адрес, который используется для связи с приложением. Если ваша машина не имеет интерфейса с IP-адресом 192.168.11.1, это может указывать на более серьезную проблему. (Впрочем, это может быть нормально - пока правильный IP является одним из четырех объявленных.)

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

• Кажется, что в окончательном образе трассировки пакетов присутствует нормальная картина сердцебиений /ACKNACK. Это указывает на наличие двунаправленной связи между двумя приложениями.
• По этим изображениям трудно сказать, состоят ли данные, отправляемые с.113 по.203, из сообщений от участника к участнику или сообщений о реальном обнаружении, за исключением двух пакетов: пакета № 805 и пакета № 816 (фрагменты 811-815) выглядят как объявления об обнаружении, которые отправляются на.203. Это означает, что у вас есть как минимум четыре объекта (DataWriters или DataReaders) в вашем приложении на.113.

Итак, данные обнаружения отправляются приложением на.113. WireShark получает и повторно собирает его, но это не всегда означает, что оно было правильно получено приложением.

Пакет № 816 имеет сердцебиение на конце. Возможно, что пакет № 818 или № 819 может быть ACKNACK, который отвечает на этот пульс, но я не могу быть уверен по изображению. Следующим шагом является просмотр ACKNACK с.203 по.113, чтобы увидеть, считает ли.203, что он получил все данные обнаружения. Вот пример пары HB/ACKNACK, где DataReader для обнаружения получил все данные:

Submessage: HEARTBEAT
... 
firstSeqNumber: 1
lastSeqNumber: 1

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

Submessage: ACKNACK
... 
readerSNState: 2/0:
    bitmapBase: 2
    numBits: 0

Параметр readerSNState равен 2/0, что означает, что он получил все до второй последовательности, и ничего не пропало. Если в растровом изображении есть что-то отличное от 0, это означает, что DataReader не получил некоторые данные.

Если вы можете подтвердить, что приложение получает все данные обнаружения правильно, будет полезно, если вы сможете использовать фильтр WireShark для отображения только пользовательских данных, поскольку изображения не выделяют обнаружение по сравнению с пользовательскими данными.

Фильтр WireShark для пользовательских данных только rtps2: rtps2 && (rtps2.traffic_nature == 3 || rtps2.traffic_nature == 1)

Answer 3

У нас была похожая проблема с этим. Вот среда в очень краткой форме:

• Издатель
• Работающий абонент (ноутбук)
• Неработающий абонент (рабочий стол)

Оба подписчика держали одно и то же программное обеспечение (рабочий стол был клоном с ноутбука через Clonezilla), но rtiddsspy был слеп с точки зрения рабочего стола; однако, обратный путь сработал хорошо: rtiddsspy издательского компьютера увидел рабочий стол. Ноутбуки и издательские машины всегда работали хорошо. Ноутбук и настольный компьютер тоже (они видели подписки друг друга)

Обходной путь для этого (основанный на https://community.rti.com/content/forum-topic/discovery-issues) заключался в увеличении MTU на настольном NIC. Не спрашивай меня почему, но это сработало.

РЕДАКТИРОВАТЬ: В начале MTU в издателе было установлено более высокое значение, чем подписчик. Итак, мы изменили MTU в подписчике, чтобы соответствовать издателю.