DDS有经纪人吗？

Question

我一直在尝试阅读DDS标准，特别是OpenSplice，我对这个架构感到疑惑。

DDS是否要求运行代理或任何特定守护程序来管理不同方之间的消息交换和协调？ 如果我只是为一个主题启动一个流程发布数据，并启动另一个订阅同一主题的流程，这是否足够？有没有理由可能需要另一个进程运行？

另一方面，它是否使用UDP多播在发布者和订阅者之间进行某种自动发现？

总的来说，我试图将其与传统的队列架构（如MQ Series或EMS）进行对比。

如果有人能帮忙解释一下，我真的很感激。

谢谢，

Faheem

Answer 1

DDS没有中央代理，它使用基于多播的发现协议。 OpenSplice有一个为每个节点提供服务的模型，但这是一个实现细节，如果你检查例如RTI DDS，他们就没有。

Answer 2

DDS规范的设计使得实现不需要具有任何中央守护进程。但当然，这是实施的选择。

RTI DDS，MilSOFT DDS和CoreDX DDS等实现具有分散式架构，这些架构是点对点的，不需要任何守护进程。 （在LAN网络中使用多播进行发现）。这种设计具有许多优点，如容错，低延迟和良好的可扩展性。而且它也非常容易使用中间件，因为不需要管理守护进程。您只需运行发布者和订阅者，其余部分由DDS自动处理。

OpenSplice DDS用于要求在每个节点上运行的守护程序服务，但是他们在v6中添加了一个新功能，因此您不再需要守护程序。 （他们仍然支持守护进程选项）。

OpenDDS也是点对点的，但据我所知，它需要运行中央守护进程才能进行发现。

Answer 3

认为区分“集中式代理”架构（该代理可能/成为单点故障）和每台基于DDS-QoS管理流量的机器上的服务/守护程序确实很好例如重要性（DDS：传输优先级）和紧急性（DDS：延迟预算）。

有趣的是，大多数人认为在将CPU作为关键/共享资源管理的机器上拥有（实时）进程调度程序是绝对必要的（基于时间限制，优先级等等）但是当涉及到DDS，这是关于分发信息（而不是处理应用程序代码）时，人们发现'网络调度程序经常“奇怪” '将'方便'（至少）作为共享资源管理网络（接口）并调度流量（基于QoS策略驱动的'打包'和利用多个流量形状的优先级通道）。 / p>

这正是OpenSplice在使用其（可选）联合架构模式时所做的工作，其中在单台机器上运行的多个应用程序可以使用共享内存段共享数据，并且有一个网络服务（守护程序）每个物理网络接口，根据其实际的QoS策略调度入站和出站流量紧迫性和重要性。这种服务“访问”所有节点信息这一事实也有助于将来自不同应用程序的不同主题的不同样本组合成（可能很大的）UDP帧，甚至可能利用这种“打包”的一些可用延迟预算和从而允许在效率（吞吐量）和确定性（延迟/抖动）之间进行适当的平衡。通过使用“私有”Rx / Tx线程和DIFSERV设置在预配置的流量形状“优先级通道”上调度流量，可以进一步促进端到端确定性。

因此，每个节点拥有一个网络调度守护进程肯定有一些优势（同时它将网络与错误的应用程序分离，这些应用程序可能要么“过度生产”，即炸毁系统或“反应不足”导致系统全局重传......在争论“网络调度守护程序”可以被视为“单点故障”这一事实时经常会忘记的一个方面，因为“其他视图”可能是没有任何一个仲裁，任何直接与线路交谈的“独立”应用程序，如果出于任何原因如上所述，当它开始行为不端时，可被视为潜在的系统线程。

无论如何......它总是一个有争议的讨论，这就是为什么OpenSplice DDS（截至v6）支持两种部署模式：联合和非联合（也称为“独立”或“单一进程”）。

希望这有点帮助。