DDS规范定义了许多主题,这些主题被嵌入到DDS实现中。订阅这些嵌入式主题,使应用程序开发人员能访问正在被使用的域的状态,包括哪个主题被注册,哪个DataReader、DataWriter被连接以及被断开,以及各种各样实体的QoS设置。当被订阅时,应用程序接收样本,而这些样本指示在域内部、实体中所发生的改变。下表为DDS中定义的嵌入式主题。
主题名称 | 描述 |
---|---|
DCPS 参与者 | 每个实例代表了一个域参与者 |
DCPS 主题 | 每个实例代表了一个标准的(不是嵌入式的)主题 |
DCPS 发布 | 每个实例代表了一个DataWriter |
DCPS 订阅 | 每个实例代表了一个DataReader |
DDS规范定义了许多QoS策略,应用程序利用这些策略,指定它们对于服务质量QoS的要求。参与者指定:从服务中,需要什么行为。同时,服务也决定了如何实现这些行为。这些策略可应用到DCPS的所有实体中(比如主题、DataWriter、DataReader、发布者、订阅者、域参与者),但对于所有所有实体类型而言,不是所有的策略均有效。
通过使用请求-提供(Request-Offered,RxO)模式,可以把订阅者和发布者进行匹配。订阅者请求一组最低程度需求的策略。发布者向潜在的订阅者提供一组QoS策略。然后DDS的实现利用所提供的策略,开始尝试匹配提出的策略;如果兼容,形成关联。
DCPS层为每个实体定义了一个回调接口,便于应用程序进程可以侦听(Listeners)关于那个实体的某些状态改变或者事件。例如,当不存在可以读取的可用数据时,就会通知DataReader。
条件(Condition)和等待集(WaitSet)能够为Listeners在DDS中检测感兴趣的事件提供选择。一般模式为:
DDS规范定义了DDS实现的5点兼容性:
OpenDDS符合DDS规范的整个DCPS层,而且包括带有以下注释说明的所有QoS实现:
OpenDDS还没有实现的项目:
OpenDDS实现是在OMG IDL PSM严格解释说明的基础上的。几乎所有的案例中,OMG C++语言映射被用来定义如何将DDS规范中的IDL映射到C++ API,达到方便OpenDDS使用者的目的。
与OMG IDL PSM的主要区别:本地接口被用于实体以及各种其他接口。在DDS规范中,这些被定义为不受限制的非本地接口。把它们定义为本地接口,可以提高性能、减少内存的使用,简化使用者与接口的交互,让使用者更加容易创建实现。
OpenDDS使用由DDS规范定义的IDL接口,以便于初始化以及控制服务使用。通过一个OpenDDS特有的传输框架,可以实现数据传输,而此框架可以允许服务利用各种传输协议,因此可称为可插拔的传输层,使得OpenDDS的架构具有很大的灵活性。
目前,OpenDDS支持TCP/IP、UDP/IP、IP多点发送、共享内存以及RTPS_UDP等多种传输协议,如图。传输协议可以通过配置文件指定,并在发布和订阅者进程中附于各种实体。
可扩传输框架能够让应用程序开发人员自行定制传输协议,包括设定一些传输框架中的级别。当创建应用时,UDP传输协议为开发人员提供了良好的使用基础,可见目录$DDS_ROOT/dds/DCPS/transport/udp
。
DDS实现必须通过一些集中式代理或者分布式策略发现彼此,而OpenDDS的一个重要特征是:通过利用DCPS信息仓库(DCPSInfoRepo)或者RTPS发现(Discovery),但在DataWriter和DataReader之间采用不同的传输协议实现数据传输。
OMG DDS规范给出发现到实现的详细过程。在DDS实现之间的互操作性方面,OMG DDS-RTPS规范提供了关于发现对等类型的要求。OpenDDS提供两个关于发现的选项:
DCPSInfoRepo是OpenDDS执行的一种独立式服务,以便于实现集中式方法,他作为一个CORBA服务器进行实现。当用户请求一个关于主题的订阅时,DCPSInfoRepo就会定位主题,通知发布者目前有新的订阅者。当在非RTPS配置中使用OpenDDS时,就需要运行DCPSInfoRepo,而RTPS配置时则不需要使用DCPSInfoRepo。DCPSInfoRepo不包含在数据传播中,它的任务被限制在发现彼此的OpenDDS应用程序范围内。
应用程序使用者可利用DCPS域的非重叠性部分,灵活、自由地运行多个InfoRepo。
域操作可以在多个仓库上进行,从而形成一个分布式虚拟仓库,即仓库联盟(Repository Federation)。为了使每个仓库参与到联盟中,每个仓库都必须在启动时指定它自己的联盟标识符数值(一个32位的数字值)。
需要对等发现模式的DDS应用程序可由OpenDDS性能设定,通过使用RTPS协议可以完成这种类型的发现。这个简单的发现形式可通过DDS对DataReader和DataWriter简单配置发现,如图。
当每个参与者的进程激活DataReader和写入程序的DDS-RTPS发现机制时,利用默认的或者配置的网络端口,网络端点才能被创建,以便于DDS参与者可以发布DataReader以及写入程序的可用性。一段时间后,基于标准的、彼此寻觅的那些就会基于所配置的、可插拔的传输协议,发现彼此并建立一个连接。
当开发并部署需要使用RTPS发现的应用程序时,开发人员需考虑以下限制因素:
OpenDDS创建ORB以及单独的线程。它也使用它自己的线程,以便于处理输入的和输出的非COBRA传输I/O。由于存在不能预料的连接关闭,创建一个单独的线程,以便于资源的清除。应用程序可通过DCPS的Listener机制,从这些线程中得到回调。
当通过DDS发布一个样本时,OpenDDS试图通过调用线程把样本发送给已连接的任何订阅者。如果发送线程被堵塞,那么样本可能在单独的服务线程上,排队等待着发送。此行为取决于QoS策略的设定值。
所有订阅者中的输入数据,由服务线程进行读取,并由应用程序进行排队,等待读取。从服务线程调用DataReaderListener。
OpenDDS包括一个基于文件的配置框架,用于配置全局项。例如调试级别、内层分配以及发现,以及关于发布者和订阅者的传输实现详细信息。也可以直接以代码的方式实现配置,但建议使配置具体化,以便于是维护变得简单,并且减少运行时的错误。