OpenDDS的实现

兼容性
    OpenDDS符合OMG DDS以及OMG DDS-RTPS规范，下面介绍符合这些规范的详细信息。

DDS的兼容性
    DDS规范定义了DDS实现的5点兼容性：
    1、最小的配置文件；
    2、内容-订阅配置文件；
    3、持久性配置文件；
    4、所有权配置文件；
    5、对象模型配置文件。
    从2.2版本开始，OpenDDS符合DDS规范的整个DCPS层，而且包括以下注释说明的QoS的实现：
    1、只有在使用TCP或IP组播传输，或者RTPS_UDP传输时，才支持RELIABILITY.kind = RELIABLE QoS策略。
    2、由于QoS的可变性，没有实现TRANSPORT_PRIORITY QoS策略。

DDS-RTPS兼容性
    OpenDDS的实现符合OMG DDS-RTPS规范的要求，但还没有实现的项目有：
    1、非默认的LIVELINESS QoS策略；
    2、公布端的内容过滤，只有所有订阅者都过滤掉的样本，公布端的数据写者才会不发布该样本，其它情况下，都是在公布端发布，在订阅端忽略该样本；
    3、PRESENTATION QoS策略相关；
    4、直接写；
    5、属性列表；
    6、关于DURABLE数据的写者信息，只能用于暂时性和长期性的持久保存，RTPS规范不支持；
    7、不生成哈希键值，但是可选择；
    8、wait_for_acknowledgements()方法；
    9、nackSuppressionDuration和heartbeatSuppressionDuration；

OpenDDS的架构
    下面给出了OpenDDS实现的简要描述、特征以及相应组件。环境变量 $DDS_ROOT指向OpenDDS的根目录。OpenDDS的源码位于$DDS_ROOT/dds/目录下，OpenDDS的测试程序位于$DDS_ROOT/tests/目录下。

设计原理
    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等多种传输协议。传输协议可以通过配置文件指定，并在发布和订阅进程中附加到各个不同的实体上。

图 2-1 OpenDDS可扩展的传输框架

    可扩展的传输框架可以使应用程序开发人员自行实现自己的传输协议。实现自定义的传输协议涉及到大量在传输框架中定义的类，UDP传输协议提供了良好的使用基础。细节请参考$DDS_ROOT/dds/DCPS/transport/udp/。

DDS发现
    DDS应用程序必须通过集中式代理或者分布式策略来发现彼此，而OpenDDS的一个重要特性就是：为发布订阅端的彼此发现提供了两种模式，应用程序的使用者可以在发布订阅应用程序运行之前，通过修改配置文件指定任意一种发现模式。当使用不同的发现模式时，数据写者和数据读者之间的数据传输方式是不同的。
    OMG DDS规范给出了发现到实现的详细过程，在DDS实现之间的互操作性方面，OMG DDS-RTPS规范则提供了关于端到端发现模式的要求。
    OpenDDS提供的两种发现模式：
    1、信息仓库（InfoRepo）：集中式的仓库模式，作为一个单独的进程运行，允许公布者和订阅者集中式的发现彼此。
    2、RTPS发现：端到端的对等发现模式，使用RTPS协议通知可用性和本地信息。
    因此，其它DDS实现的互操作性必须使用端到端的对等方法，但只在OpenDDS部署中才是有用的。

DCPSInfoRepo的集中式发现
    OpenDDS实现了一种独立式的，叫做DCPSInfoRepo信息仓库的服务，来实现集中式方法，它作为一个CORBA服务来实现。当用户请求对某个主题的订阅时，DCPS信息仓库定位主题，并通知所有发布者，新订阅者的位置。当OpenDDS使用非RTPS模式时，信息仓库进程需要一直运行。RTPS模式则不需要使用信息仓库。信息仓库不参与数据的传输，它的作用只是限制在让发布者和订阅者发现彼此。

图 2‑2 InfoRepo的集中式发现

    应用程序开发人员可以灵活、自由地运行多个信息仓库，每个信息仓库管理自己的非重叠DCPS域。
    也可以在一个域内运行多个信息仓库，形成一个分布式的虚拟仓库，叫做仓库联邦。为了使每个独立的仓库都参与到联邦中，信息仓库在启动时必须指定自己的联邦标识值（一个32bit的数值）。关于信息仓库联邦的更多细节请参见后续章节。

RTPS的端到端发现
    需要端到端对等发现模式的DDS应用程序可以由OpenDDS性能设定，使用当前发布版本的RTPS协议就可以完成这种发现模式。这种简单的发现形式可以通过DDS对数据读者和数据写者的简单配置来实现。应用程序启动之后，就创建线程，激活RTPS协议机制，向外组播本地的实体信息，一段时间之后，基于标准的、彼此寻觅的那些实体就会基于所配置的、可插拔的传输协议，发现彼此并建立连接。
    当开发并部署使用RTPS发现模式的应用程序时，需要注意以下限制因素：
    1、由于UDP端口被分配给域ID，域ID应当在0-231(包含)之间，在每个OpenDDS进程、每个域中，支持多达120个域参与者。
    2、主题名称以及类型名称被限制在256个字符以内。
    3、由于全局唯一标示符(GUID)的方式被指定，OpenDDS的本地多播传输不能与RTPS发现一并工作(如果试图这样，将会有一个警告信息)。

线程
    OpenDDS在一个单独的线程上创建并运行ORB。它还用自己的线程来处理非CORBA传输I/O的输入输出。当连接意外关闭时，会创建一个单独的线程用来清理资源，应用程序可以通过DCPS的监听机制从这些线程中得到回调。
    当通过DDS发布样本时，OpenDDS使用调用线程将样本发给已连接的所有订阅者。如果发送线程被阻塞，样本将会在单独的线程中排队等候发送。这种行为取决于应用程序配置的QoS策略值。
所有订阅端收到的数据都由服务线程调用数据读者监听者读取，并排队等待应用程序使用。

配置
    OpenDDS提供了一个基于文件的配置框架，用来配置全局项，例如调试级别、内存分配、发现、以及公布者和订阅者之间数据的传输细节等。也可以直接以代码的方式实现配置，建议使用具体化的配置，以便于维护起来简单，同时减少运行时错误。