RTI DDS 阅读器无法识别主题答案

【问题标题】：RTI DDS reader fails to identify topicRTI DDS 阅读器无法识别主题
【发布时间】：2021-03-09 03:54:44
【问题描述】：

随后显然是阅读/接受该主题。有问题的主题在BuiltinQosLibExp::Generic.KeepLastReliable.TransientLocal 策略下发布，并且消息仅在发布者应用程序启动时触发一次。有几点需要考虑：

我没有使用此策略并在代码中采用默认策略配置

dds::sub::qos::DataReaderQos tempQos = inSubScriber->default_datareader_qos();
m_EntitySpecReader = new dds::sub::DataReader<XXX_ICD::Entity_Specification_DT>(*inSubScriber, topicLocal, tempQos, m_EntitySpecListener);

来自订阅者

问题不是防火墙或某些连接问题，因为我知道接收其他循环主题没有任何问题。
如果我尝试使用 rtiddsspy 或 RTI 管理控制台进行监控，我看到此主题令人沮丧。
最后一个子弹和最令人沮丧的是，当我真正感到卡住时，我有一个配置了所有可用回调的侦听器，我认为如果不是数据，至少接收一些关于可能不匹配、丢失等的回调线索.. .. 但无论我想做什么，它都会保持沉默:)

如果有人有答案或可能的检查方向，将非常乐意了解:)

【问题讨论】：

标签： data-distribution-service

【解决方案1】：

您正在为 DataReader 使用默认 QoS。这意味着它的耐久性策略是VOLATILE。即使 DataWriter 被配置为TRANSIENT_LOCAL，它也不会向您的 DataReader 传递“旧”样本，因为由于其不稳定的持久性，它不会请求这些样本。在这种情况下，“旧”样本是在 DataWriter 发现 DataReader 之前编写的样本。

当您将 DataReader 配置为具有持久性策略 TRANSIENT_LOCAL 时，事情应该会按预期开始工作。

如果您在 DataReader 上检测了一个侦听器，它应该会告诉您匹配已经发生，或者匹配失败。如果您同时实现了 on_subscription_matched 和 on_requested_incompatible_qos 回调，那么如果两个应用程序都已启动并且它们能够相互发现，那么至少应该触发这两个回调中的一个。

由于您发现问题是类型不匹配，因此我想展示 AdminConsole 工具如何帮助您找到该问题。重现您的问题，这就是它所显示的：

【讨论】：

嗨 Reinier，实际上我已经尝试过监听器但没有成功。也没有数据不匹配或任何其他回调。这是我的代码 'tempQos.policy<:core::policy::durability>().kind(dds::core::policy::DurabilityKind::TRANSIENT_LOCAL)' 。你怎么看？
您是否能够在管理控制台中同时看到参与者及其 DataWriter/DataReader，并且它们是否按预期连接匹配？您是否仔细检查过您使用的主题名称是否正确？
最后我发现了一个问题，是主题的字符串参数。在 IDL 中，它被配置为没有特定的长度。发布者生成了带有“无限支持”标志的代码，而我在订阅者中生成了它没有。每一方都接收到不同大小的字符串，一个只是字符串，另一个是字符串。奇怪的是，这种不匹配并没有触发订阅者的侦听器不匹配回调，但现在这是另一个故事 :) 谢谢你的帮助。
很高兴您找到了原因。这不是 QoS 不匹配，因此不会触发关联的回调。没有为类型不一致定义回调，但 AdminConsole 可以帮助您，就像我在添加的屏幕截图中显示的那样。