3

小故事：我的 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 VM（托管在网络上，而不是我的机器上），它通过 RTI DDS 发布一些数据。数据从未出现在我的 Windows 7 订阅者应用程序中。

有趣的是，我可以将相同的代码放在 VM B 上，然后订阅者获取数据。认为这一定是 Windows 7 防火墙问题，我将 VM A 的 IP 地址与 VM B 交换，但这并没有帮助。

使用 Wireshark，我可以看到来自 VM A 的一些心跳流量，但没有数据。从 VM B，我看到了心跳流量和数据。下面是经过消毒的 Wireshark 片段。 Wireshark 输出

NDDS_DISCOVERY_PEERS设置为包括多播和每个对话另一方的显式 IP 地址。QOS 配置文件相同，RTI Analyzer 指示匹配分析成功（全为绿色）。

虚拟机甲： NDDS_DISCOVERY_PEERS=udpv4://239.255.0.1,udpv4://127.0.0.1,udpv4://BLAH.203

虚拟机乙： NDDS_DISCOVERY_PEERS=udpv4://239.255.0.1,udpv4://127.0.0.1,udpv4://BLAH.203

Windows 7 盒子： NDDS_DISCOVERY_PEERS=udpv4://239.255.0.1,udpv4://127.0.0.1,udpv4://BLAH.113,udpv4://BLAH.114

当我将它们包含NDDS_DISCOVERY_PEERS在行中时，网络上的其他人可以在他们的 Windows 7 机器上通过 DDS SPY 看到来自 VM A 的 DDS 流量。我的 Windows 7 盒子不能。

Windows 7 事件日志似乎没有显示任何防火墙或 WFP 停止数据包。

在我的 Windows 7 机器上运行的 RTI DDS Spy 显示 VM A (0A061071) 写入器在网络上可见，但没有接收到数据。它还显示我的 Windows 7 机器上的订阅者中的阅读器是可见的，尽管它显示在一个奇怪的 IP 地址上。

额外的问题（只是出于好奇，不是主要问题）：为什么我的本地机器上的流量显示在 DDS SPY 中192.168.11.1而不是我机器的 IP 甚至127.0.0.1？

RTI DDS 间谍输出

主要问题：我错过了什么？

更新： route print在我的 Windows 7 盒子上似乎显示我已经加入了一个带有 VM A 的多播组。 netsh interface ip show joins似乎同意。

调查更新：

  1. 我重新启动了VM，但没有效果。

  2. 我重新启动了 Windows 框，但没有效果。

  3. 我从NDDS_DISCOVERY_PEERS两边的环境变量中删除了多播，但没有效果。

  4. Windows 7 机器具有三个网络接口（加上环回）：1 个 LAN 连接和 2 个（不相关的）VM 适配器。我们正在使用 LAN 连接。QNX VM 有一个网络接口（加上环回）。请注意，工作 VM 和损坏的 VM 使用不同的以太网驱动程序，因为它们与 QNX 6.4.1 的风格略有不同。坏的有wm0接口，工作的有en0接口。我不认为这是问题所在，但这是不同的。

  5. 我在“损坏的”QNX VM 上运行 DDS SPY，而它正在播放，我得到了 DDS 数据。我没有一个很好的方法来嗅探虚拟机所在的位置和我的 Windows 7 机器之间的网络，看看它是否会离开接口，但是查看 QNX 虚拟机上以太网接口的传输数据包计数表明它肯定在传输某些东西，而 Wireshark 在 Windows 7 机器上捕获的内容表明至少有一些流量正在通过。

  6. LAN 上的其他人可以看到来自“损坏的”虚拟机的 DDS 流量，这让我相信这是 Windows 设置问题，而不是损坏的虚拟机——我只是看不出它可能是什么。我重新检查了防火墙，但无济于事。我原以为如果是防火墙问题，当我在 VM A 和 VM B 之间交换 IP 地址时，问题就会消失。无论如何，Windows 7 防火墙当前已关闭，但无济于事。

  7. 下面是 Wireshark 输出的几个屏幕。我在第三和第四之间跳过了一堆，因为在第四之后，流量往往看起来像第四的底部，直到结束。

图 1 图 2 图 3 （这里跳过了一堆） 图 4 （几乎像上面的最后 11 行一样继续）

我还应该尝试什么？

更新： 要在下面回答 Rose 的问题，rtiddsping -publisher请在坏的 VM 上使用并rtiddsping -subscriber正常工作。

我想知道这个问题是否是由奇怪的 IP 地址引起的。它碰巧发布并以某种方式锁定到的 IP 地址是本地 VM 以太网适配器（与 VM A 分开）。请参阅下面的屏幕截图。

Win7 ipconfig

我希望它附加的地址是 10.6.6.203。有什么办法可以指定吗？

4

3 回答 3

4

一年多后，这在我身上再次发生在不同的虚拟机上。我昨天就让它工作了，所以我很怀疑。我在过去 24 小时内搜索了所有代码更改的问题，但没有发现任何问题。然后我决定看看 IT 是否已经向我的计算机推送了任何补丁。

你猜怎么着？Windows 防火墙从前一天开始积极更新。规则丢失或更改等。日志说数据包被丢弃。我稍微打开了防火墙过滤器，突然间，一切都恢复了。我犹豫要不要关闭这个问题，因为我不是 100% 这与去年完全相同，但感觉非常相似。我怀疑去年防火墙中的设置没有记录数据包丢失。

总而言之：如果 DDS 突然停止工作，请检查您的防火墙设置。

于 2014-05-16T20:48:20.720 回答
2

有几件事可以尝试：

  1. 尝试在损坏的 VM 上运行 rtiddsping -publisher 并在 Windows 上运行 rtiddsping -subscriber。这有两个优点：

    • 数据类型小且广为人知，因此如果由于不同的以太网驱动程序导致数据碎片化存在问题，rtiddsping 不会发生这种情况，并且可能有助于追踪问题。
    • 当发布者和订阅者发现彼此时，Rtiddsping 会打印出来，因此您将能够确认发现在双方都正确完成。我猜发现正在起作用，因为 Analyzer 显示了这两个应用程序，但最好确认一下。

  2. 如果您在应用程序中看到与 rtiddsping 相同的问题，请将详细程度增加到 rtiddsping -verbosity 3，然后是 5。在最高详细级别，这将打印（大量）额外输出，这可能会给我们一个暗示正在发生的事情。

回答您关于间谍的额外问题：间谍显示 IP 地址的原因是因为这是作为发现的一部分宣布的地址之一。在发现过程中，DomainParticipant 最多可以宣布四个可用于访问它的 IP 地址。Spy 将选择其中一个来显示，但它可能不是用于与应用程序通信的实际地址。如果您的机器没有任何与 192.168.11.1 IP 地址的接口，这可能表明存在更大的问题。（不过，这可能是正常的——只要正确的 IP 是公布的四个 IP 之一。）

查看数据包跟踪图像，没有任何明显的问题。我注意到几点：

  • 最终数据包跟踪图像中似乎存在正常的心跳/ACKNACK 模式。这表明两个应用程序之间存在一些双向通信。
  • 从这些图像很难判断从 .113 发送到 .203 的 DATA 是包含参与者到参与者的消息还是真正的发现消息 - 除了两个数据包：数据包 #805 和数据包 #816（片段 811- 815) 看起来像正在发送到 .203 的发现公告。这表明您在 .113 上的应用程序中至少有四个实体（DataWriters 或 DataReaders）。

因此，应用程序正在 .113 上发送发现数据。WireShark 正在接收并重新组装它，但这并不总是意味着它被应用程序正确接收。

数据包#816 的末尾有一个心跳。包 #818 或 #819 可能是响应该心跳的 ACKNACK，但我无法从图像中确定。下一步是查看从 .203 到 .113 的这些 ACKNACK，以查看 .203 是否认为它已收到所有发现数据。以下是发现 DataReader 已接收所有数据的 HB/ACKNACK 对示例：

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

心跳序号为1，表示只发送了一个DataReader的公告。

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

readerSNState 是 2/0，这意味着它在序列号 2 之前收到了所有内容，并且没有丢失任何内容。如果位图中有 0 以外的内容，则表示 DataReader 没有接收到某些数据。

如果您可以确认应用程序正在正确接收所有发现数据，那么如果您可以使用 WireShark 过滤器仅显示用户数据将很有帮助，因为图像不会突出显示发现与用户数据。

仅用于 rtps2 用户数据的 WireShark 过滤器：rtps2 && (rtps2.traffic_nature == 3 || rtps2.traffic_nature == 1)

于 2013-06-03T04:25:10.177 回答
1

我们对此也有类似的问题。这里是一个非常概括的环境：

  • 出版商
  • 工作用户（笔记本电脑）
  • 非工作订户（桌面）

两个订阅者都拥有完全相同的软件（桌面是通过 Clonezilla 从笔记本电脑克隆出来的），但从桌面的角度来看 rtiddsspy 是盲目的；但是，相反的方法效果很好：发布者机器的 rtiddsspy 看到了桌面。笔记本电脑和出版机一直运行良好。笔记本电脑和台式机也是（他们看到了彼此的订阅）

解决方法（基于 https://community.rti.com/content/forum-topic/discovery-issues）是增加桌面 NIC 上的 MTU。不要问我为什么，但它奏效了。

编辑：一开始，发布者中的 MTU 设置为高于订阅者的值。因此，我们更改了订阅者中的 MTU 以匹配发布者的。

于 2015-08-28T15:14:01.840 回答