CoreDX DDS有啥不一样

发现机制

常规的网络编程，以socket为例，是需要绑定主机IP地址，并能够清楚通信双方的端口号，才能像对方发起连接请求或者网络通信。
而发现机制，则不需要手动准备端口号等网络通信的细枝末节，这一切有定义好的算法进行临时指定。
发现机制要求通信双方向网络中发现发现信息，该信息可以通过单播的方式发送，同时也支持多播的方式进行发送。
单播要求配置与通信节点对话的端点信息，可以是网络远程端点，也可以是近端同一台主机这节点。

概述

CoreDX DDS中的标准（对等）发现过程封装在每个CoreDX DDS应用程序中，并且不需要任何其他守护程序或服务。 每个CoreDX DDS应用程序都执行发现过程，包括宣布其DDS实体的存在，侦听其他DDS实体以及寻找其自己的DDS实体与发现的DDS实体之间的匹配。 标准发现机制可在DDS实现之间互操作。

下图描述了此标准发现。

尽管“标准发现”机制具有许多优点，但对于某些系统体系结构而言确实存在一些缺点。 特别是，标准发现可能无法很好地扩展到大型DDS域。 在具有大量DDS实体（参与者，读者或作家）的DDS 150域中，由于每个参与者发现系统中的所有其他实体，因此标准发现机制可能需要大量的内存。 在许多情况下，DDS域的这种“世界观”是浪费的。 通常，要求参与者仅与整个DDS网络的一小部分子集进行通信。

为了解决标准发现的可伸缩性问题，CoreDX DDS支持一种称为集中式发现的特殊发现机制。 CoreDX集中式发现执行发现所有DDS实体的工作，并根据“需要知道”将这些实体适当地传达给参与者。 集中式发现机制可以扩展到非常大的DDS域，而无需在标准发现中发现大量的内存分配。

此外，集中式发现旨在与标准发现互操作。 这意味着DDS域可以根据需要组合两种发现机制：某些域参与者可以使用标准发现，而其他人可以使用集中式发现。 下图描述了此集中发现。

内存利用率和可伸缩性

使用标准发现，每个DomainParticipant都可以学习并记住DDS域中每个活动的DomainParticipant，DataReader和DataWriter。随着域中DDS实体数量的增加，每个DomainParticipant中存储的发现信息量也随之增加。

对于包含许多DDS实体的系统，可能需要减少此维护的发现信息的副本数。这是集中发现的好处。有关DDS域中所有DDS实体的发现信息存储在集中位置，从而降低了系统中的整体内存利用率。

集中发现守护程序确定所有与其连接的DomainParticipant潜在的读取器/写入器匹配。 DomainParticipant仅从集中发现守护程序中了解有关潜在匹配项的信息。 CoreDX集中式发现守护程序必须与配置为使用集中式发现的DomainParticipant运行在同一台计算机上。
因此，在以下情况下，可以看到减少内存的最大好处：

• 一台计算机上的所有DDS实体可以使用集中发现功能；
• 对于每个DomainParticipant，DDS域中的存在小部分DDS实体与自身匹配。

部署集中发现

必须在承载配置为使用集中发现的DomainParticipant的每台计算机上部署CoreDX集中发现守护程序。 一台计算机上应该只运行一个CoreDX Centralized Discovery Daemon。 未托管配置为使用集中发现的DomainParticipant的计算机不需要CoreDX集中发现守护程序。

下面显示了使用集中式发现的示例部署。

名词

文中名词
标准发现 - Standard Discovery
集中发现 - Centralized Discovery
域参与者（DDS标准定义）- DomainParticipant -
集中式发现守护进程 - CoreDX Centralized Discovery Daemon
读者（DDS标准定义）- DataReader
写者（DDS标准定义）- DataWriter

CoreDX DDS - links