RTI DDS订阅者无法从发布者处获取数据

时间：2013-05-22 13:29:01

标签： data-distribution-service

短篇小说：我的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 Output

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

VM A： 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框： NDDS_DISCOVERY_PEERS=udpv4://239.255.0.1,udpv4://127.0.0.1,udpv4://BLAH.113,udpv4://BLAH.114

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

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

从我的Windows 7计算机上运行的RTI DDS Spy显示VM A（0A061071）编写器在网络上可见，但没有收到任何数据。它还显示我的Windows 7计算机上的订阅者中的读者可见，但它显示在奇怪的IP地址。

加分问题（仅出于好奇，不是主要问题）：为什么本地计算机上的流量在DDS SPY中显示为192.168.11.1而不是我的计算机的IP甚至{ {1}}？

RTI DDS SPY Output

主要问题：我缺少什么？

更新： 我的Windows 7框上的127.0.0.1似乎显示我已加入了具有VM A的多播组。 route print似乎同意。

调查更新：

  1. 我重新启动虚拟机无效。

  2. 我重新启动Windows框无效。

  3. 我从netsh interface ip show joins环境中删除了多播 双方的变量都没有效果。

  4. Windows 7机箱有三个网络接口（加上环回）：1 LAN连接和2个（不相关的）VM适配器。我们正在合作 局域网连接。 QNX VM有一个网络接口（另外 环回）。请注意，工作VM和损坏的VM使用a 不同的以太网驱动程序，因为它们略有不同 不同风格的QNX 6.4.1。破碎的那个有NDDS_DISCOVERY_PEERS 接口，工作接口有wm0。我不相信这是问题，但这是一个区别。

  5. 我正在回放“破坏”的QNX VM上运行DDS SPY，并且 我得到了DDS数据。我没有一个好的方法来嗅探网络 在托管VM的位置和我的Windows 7计算机之间查看是否存在 使它脱离接口，但查看传输的数据包 从QNX VM上的以太网接口开始计数表明它 肯定会传输一些东西，而且Windows 7机器上的Wireshark捕获显示至少有一些流量正在通过。

  6. 局域网上的其他人可以看到来自的DDS流量 “破碎”的虚拟机，让我相信这是一个Windows安装问题， 而不是一个破碎的虚拟机 - 我只是看不到它可能是什么。我有 重新检查防火墙，无济于事。我原以为如果它是防火墙问题，当我在VM A和VM B之间交换IP地址时，问题就会消失。无论如何，Windows 7防火墙目前都处于关闭状态，但无济于事。

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

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

    我还应该尝试什么？

    更新 要回答下面的Rose问题，在错误的VM上使用en0并rtiddsping -publisher正常工作。

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

    Win7 Ipconfig

    我希望它附加的地址是10.6.6.203。我可以用任何方式指定吗？

3 个答案:

答案 0 :(得分：4)

一年多以后这件事发生在我身上再次与另一个虚拟机。我昨天工作了，所以我非常怀疑。我搜索了过去24小时内所有代码更改的问题，但没有发现任何问题。然后我决定看看IT是否已将任何补丁推送到我的计算机上。

猜猜是什么？自前一天起，Windows防火墙已经积极更新。规则丢失或更改等。日志表示数据包被丢弃。我打开防火墙过滤器了一下，突然间，一切都恢复了。我对这个问题犹豫不决，因为我不是100％这与去年完全相同，但感觉非常相似。我怀疑去年防火墙中的设置没有记录数据包丢失。

长短不一：如果DDS突然停止工作，检查防火墙设置。

答案 1 :(得分：2)

要尝试的几件事情：

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

    • 数据类型很小且众所周知，因此如果由于不同的以太网驱动程序而导致数据碎片出现问题，则rtiddsping不会发生这种情况，并且可能有助于追踪问题。
    • 当发布者和订阅者互相发现时，Rtiddsping打印出来，这样您就可以确认双方都正确地完成了发现。我猜测发现是有效的，因为Analyzer正在显示这两个应用程序，但最好确认一下。

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

    3. 回答关于间谍的奖金问题：间谍显示IP地址的原因是因为这是作为发现的一部分而宣布的地址之一。在发现过程中，DomainParticipant可以发布最多四个可用于访问它的IP地址。间谍将选择其中一个显示，但它可能不是用于与应用程序通信的实际地址。如果您的计算机没有任何具有192.168.11.1 IP地址的接口，则可能表示存在较大问题。 （但这可能是正常的 - 只要正确的IP是宣布的四种IP之一。）

    查看数据包跟踪图像，显然没有任何问题。我注意到的一些事情：

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

    因此，应用程序在.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＆amp;＆amp; （rtps2.traffic_nature == 3 || rtps2.traffic_nature == 1）

答案 2 :(得分：1)

我们遇到了类似的问题。这是一个非常概括的环境：

  • 发布商
  • 工作用户（笔记本电脑）
  • 非工作用户（桌面）

两个用户都持有完全相同的软件（桌面是笔记本电脑的克隆，通过Clonezilla），但从桌面的角度来看，rtiddsspy是盲目的;然而，相反的方式效果很好：发布商机器的rtiddsspy看到了桌面。笔记本电脑和发行商机器＆＃39;一直很好。笔记本电脑和台式机（他们看到了彼此的订阅）

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

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

相关问题
最新问题