发现机制
常规的网络编程,以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