DDS调试步骤

道格拉斯范朋克

已于 2022-12-12 18:54:52 修改

阅读量4.5k

点赞数 5

分类专栏： DDS 文章标签： DDS

于 2019-01-02 14:09:04 首次发布

本文链接：https://blog.csdn.net/xinqingwuji/article/details/85613484

版权

DDS 专栏收录该内容

47 篇文章 52 订阅

订阅专栏

HOWTO对系统级DDS进行基本调试

当您的应用程序之间没有通信或次优时，您可以执行一系列步骤来执行DDS系统的基本调试。

1.他们实际上是在同一个网络/子网上吗？

网络上的两台计算机可能具有不同的子网（例如，一台可能使用WiFi连接，另一台可能是有线的，这些可能位于不同的子网上，尽管本地交换机路由单播而不路由多播等，警惕网络和网络工程师，因为他们很狡猾，而且容易受到恶作剧的影响。

Linux的

  $ ifconfig |  grep inet

视窗

  C：\> IPCONFIG

查找inet地址并确定它们是否在同一子网上有任何内容。

警告！ 具有四个以上IP地址的机器（由于VM，VPN等）可能会导致痛苦和痛苦！ RTI Connext DDS仅选择它看到的前四个网络接口。这在Windows上尤其糟糕，因为Windows会随意重新排序接口列表！这意味着它有时会起作用，有时却不起作用。

你已经确定他们有一个共同的网络子网。现在，DDS会起作用了吗？

使用rtiddsping。 rtiddsping命令行工具是一个原始的，已知的工作DDS应用程序。在一台计算机上，运行rtiddsping[.exe] -publisher 。在另一台机器上，运行rtiddsping[.exe] -subscriber 。如果他们没有看到对方（在发布者端寻找“找到1个额外的ping用户”，或者在用户端找到“发布者”），那么问题是网络基础设施，它不是RTI Connext DDS。

如果rtiddsping实例没有看到对方，可能的原因是：

在任一台或两台计算机上，或在中间路由器或交换机中未启用多播。
防火墙规则配置为停止多播数据包，不路由UDP，或（更可能）默认为停止意外端口访问（在这种情况下，您需要为正在使用的域手动启用DDS发现端口）。 rtiddsping的默认域是0，对应于端口7400,7401,7410和7411.请记住，防火墙可以在任何地方，您可能需要在发布者端，订户端启用端口/禁用防火墙，以及任何干预路由器或交换机。

要调试网络基础结构，您可以按照以下步骤操作：

检查基本网络（IP）可达性。运行“ping”命令行工具以确保您在计算机之间进行基本的网络通信。此工具随大多数操作系统一起提供，包括Windows和Unix Variants。无法通过ping访问IP地址可能表示网络连接不良或存在阻止传入网络通信的防火墙（通常是基于主机的防火墙）。
验证基本多播可达性。运行ping 224.0.0.1 。 224.0.0.1是“所有主机”组。如果您对该组执行ping操作，则LAN上的所有支持多播的主机都应该应答（每个支持多播的主机必须在启动时加入该组的所有组播功能的接口）。如果您计划运行Connext DSD的LAN上的某个主机没有响应，则可能表示网络连接故障，防火墙（可能在该主机本身上）或不支持多播的操作系统配置。开箱即用的发现设置需要多播，因此这些主机不会通过开箱即用的配置通过DDS进行通信。

Ping至224.0.0.1永远不会被多播路由器转发，因此您只能从同一LAN上的计算机获得回复。如果您尝试让DDS在不同LAN上的计算机之间执行发现（即由路由器分隔），则需要将中间路由器配置为中继多播数据包。您可以通过运行ping 224.0.0.2来检查这一点。 224.0.0.2是“所有路由器”组，所有启用多播的路由器都应该响应。由于ping到“224.0.0.2”的ping不会被路由器转发，因此您希望只能从连接到同一LAN的路由器回复到您ping的机器。

请注意，运行rtiddsping允许在两台计算机由路由器分隔的情况下测试多播通信。如果路由器启用了多播（并配置为转发多播数据包），那么它将中继DDS多播发现流量，并且两个rtiddsping应用程序应该相互发现。这是因为DDS发现使用的多播地址是239.255.0.1 ，应由所有启用多播的路由器转发，从而允许DDS发现成功进行。

如果基本网络IP连接成功但运行rtiddsping不成功并且两台计算机位于不同的LAN上，则最可能的情况是中间的路由器未配置为路由和转发多播数据包。如果两台计算机位于同一LAN上，则不应存在nasic IP连接（包含多播）工作且示例/ CPP / Hello_simple不工作的情况。

3. rtiddsping工作，我的应用程序是否有效？

将-example <arch>与您的IDL for MyFooType一起使用后，您将获得默认发布者和默认订阅者。编译这些，不做任何改变。运行它们。

如果他们看到对方，太好了！这意味着它们位于同一个域中（因为您没有更改任何内容），Type是可分配的（显然，因为它们使用相同的IDL），Topic是相同的（因为您没有更改它生成的“示例MyFooType”主题）和QoS设置兼容（同样，因为您没有从默认设置更改它们）。 DDS正在工作，所以现在出去，并建立伟大的事物！

如果他们没有看到对方......嗯。在这种情况下，运行rtiddsspy。示例代码中的默认域为0，因此只需运行rtiddsspy而不使用-domainId <int>标志。我建议在发布者和订阅者计算机上运行它（一次一个）。在一个正在运行的分布式系统中，您应该在任一台计算机上看到“W + N”行（这是发布者）和“R + N”（订阅者）行：

  1408440707.896907 W + N C0A80064示例MyFooType MyFooType
 1408440706.509978 R + N C0A8006F示例MyFooType MyFooType

如果你没有得到这两行（在这种情况下，你可能得到的是一行，取决于Spy是在发布者端运行（“W + N”）还是用户端（“R + N”）如果看到这个......发布在这里，因为那很有意思。

你很好地开发了你的系统，但是现在有一个发布者没有看到订阅者（在一个孤立的情况下）

使用所述工具检查以下内容：

间谍可以看到发布者（来自发布者没有运行的机器）吗？
间谍可以看到订户（来自订户未运行的计算机）吗？

如果是这种情况，我的猜测是主题不同（一个可能是“示例MyFooType”，因为工程师忘了将其更改为正在使用的那个），或者类型不同且不可分配（因为工程师更新了IDL但未能告诉您这一点，而他的新发布者正在使用新类型，而您的旧订阅者正在使用旧类型。如果发布者和订阅者都给出了相同的主题，但主题QoS或类型有足够的不同，Spy将自我配置以同意它看到的第一个（在正在运行的系统中是任意的）。这可能导致不兼容的数据头QoS。

管理工具是否显示主题，类型，QoS或任何其他内容的红色标记？如果现在问题不明显，请在此处发布。

5.管理控制台（或分析器）显示DomainParticipants，但不显示任何子实体

发现是一个握手过程，从多播开始，但在单播中完成。当Discovery可以显示启动（DomainParticipants彼此可见）但未完成（没有Publishers，Subscribers，DataReaders，DataWriters）时，问题可能又是防火墙。

6.您的系统正常工作，但似乎工作不正常，或者QoS行为似乎不正确

您确定您认为正在使用的QoS是应用程序正在使用的QoS配置文件吗？要快速确定应用程序是否正在拾取不正确的USER_QOS_PROFILES.xml文件，请cd到包含您要使用的文件的目录，然后插入一些错误（格式错误的）XML。您可以简单地将一些文本作为文件的第一行，而不是XML标记。保存文件并启动您的应用程序。如果DomainParticipants确实已创建且应用程序开始运行，则应用程序不会获取您损坏的USER_QOS_PROFILES.xml文件。

DomainParticipants使用工作目录中的USER_QOS_PROFILES.xml文件。从USER_QOS_PROFILES.xml文件所在的目录（./objs/<arch> / <application>）启动应用程序，不要更改到应用程序目录（cd objs / <arch>; ./<application）。
如果您的应用程序是从脚本启动的，请验证脚本是否未更改为新的工作目录（没有'cd'命令）。
验证NDDS_QOS_PROFILES环境变量未设置，或者是否已设置，它确实包含相关文件。

如果您的步骤在任何时候被迫偏离上述步骤，请发布到论坛，我将修复上述内容以同意您所看到的内容。

RTI社区门户使用条款

注意：您提交给RTI Research Community Portal的任何内容，包括个人信息，均不受RTI网站其他部分收集的信息的保护。您对通过RTI社区门户上传，发布，发送电子邮件，传输或以其他方式提供的所有内容负全部责任。 RTI不控制访问者发布到RTI社区门户网站的内容，也不保证此类内容的准确性，完整性或质量。在任何情况下，RTI均不对任何未由RTI撰写的内容承担任何责任，或由于使用通过RTI社区发布，通过电子邮件发送，传输或以其他方式提供的任何内容而导致的任何损失或损害门户。