OpenDDS简介开源DDS解决方案
OpenDDS简介：开源DDS解决方案
文章目录
OpenDDS 简介
OpenDDS 是一个开源的 C++ 框架，用于在分布式系统中交换数据，遵循对象管理组织（OMG）关于数据分发服务（DDS）规范的实现。它不仅支持 C++，还为 Java 和 JMS 提供开发接口，允许 Java 程序员也能使用 OpenDDS。
该框架构建在 ACE（自适应通信环境）之上，确保了跨平台和可移植性。同时，OpenDDS 利用 TAO（基于 ACE 的 CORBA 实现框架），提供了 IDL 编译器等功能，以作为其 DCPS 信息仓库。
OpenDDS 遵循 OMG 的 DDS V1.2 规范，采用与 ACE/TAO 相同的许可证，允许开发者在保留版权声明的前提下，在各种场合（包括商业用途）使用和修改源代码。OpenDDS 的最新发行版本为 3.15。
用户可以通过 和 获取更多信息和资源。此外，OpenDDS 社区的用户还贡献并维护了对其他语言（如 C#、Node.js 和 Python）的绑定，进一步扩展了其适用范围。
ACE
TAO
ACE+TAO
读OpenDDS-latest.pdf
OpenDDS类型定义
OpenDDS定义IDL文件
@topic
struct Message
{
string from;
string subject;
@key long subject_id;
string text;
long count;
}@topic
注释说明：该类型可以与某一个Topic进行绑定，用作OpenDDS的传输类型。
@key
注释说明：subject_id字段被定义为键值。键值的作用是用来区分同一个topic下的不同的instance。
简单理解DDS中关于topic，instance和sample之间的关系，如图
同一个topic可以创建多个instance，不同的instance是按照key来进行区分的。而每一个instance可以理解为sample的模子，sample是实际的在节点间进行收发的数据。
OpenDDS Demo Code
简单如下：
OpenDDS 可扩展的传输框架
OpenDDS使用由DDS规范定义的 IDL接口 ，以便于初始化以及控制服务使用。通过一个OpenDDS特有的传输框架，可以实现数据传输，而此框架可以允许服务利用各种传输协议，因此可称为 可插拔的传输层 ，使得OpenDDS的架构具有很大的灵活性。
目前，OpenDDS支持 TCP/IP 、 UDP/IP 、 IP多点发送 、 共享内存 以及 RTPS_UDP 等多种传输协议，如图。传输协议可以通过配置文件指定，并在发布和订阅者进程中附于各种实体。
OpenDDS 发现
OpenDDS发现服务，一种是peer-peer的发现（RTPS的对等发现），该发现的特点是节点在启动前需要配置好我所关心节点的信息（IP）。另一种是与第一种相反的方式（DCPSInfoRepo的集中式发现），在整个OpenDDS的系统中，所有节点之间并不知道彼此的存在，在程序启动后，由程序去检索DCPSInfoRepo服务实现动态发现。
我理解为 动态发现 和 静态发现 。
信息仓库 （InfoRepo） ： 集中式 的储存库类型，其作为一个单独的进程运行，可以允许发布者和订阅者以集中式发现彼此。—动态发现
RTPS发现 ：一种 对等 的发现类型，使用RTPS协议通知可用性和本地信息。 —静态发现
与其他DDS实现的互操作性必须使用对等方法，但只在OpenDDS部署中才有用。
利用DCPSInfoRepo的集中式发现（动态发现）
DCPSInfoRepo是OpenDDS执行的一种 独立式服务 ，以便于实现 集中式方法 ，他作为一个 CORBA服务器 进行实现。当用户请求关于一个主题的订阅时，DCPSInfoRepo就会定位主题，通知发布者目前有新的订阅者。当在非RTPS配置中使用OpenDDS时，就需要运行DCPSInfoRepo，而RTPS配置时则不需要使用DCPSInfoRepo。DCPSInfoRepo不包含在数据传播中，它的任务被限制在发现彼此的OpenDDS应用程序范围内。
应用程序使用者可利用DCPS域的非重叠性部分，灵活、自由地运行多个InfoRepo。
域操作可以在多个仓库上进行，从而形成一个 分布式虚拟仓库 ，即 仓库联盟 （Repository Federation）。为了使每个仓库参与到联盟中，每个仓库都必须在启动时指定它自己的 联盟标识符 数值（一个32位的数字值）。
利用RTPS的对等发现（静态发现）
需要 对等发现 模式的DDS应用程序可由OpenDDS性能设定，通过使用RTPS协议可以完成这种类型的发现。这个简单的发现形式可通过DDS对DataReader和DataWriter的配置进行实现。
当每个参与者的进程激活DDS-RTPS发现机制时，需要利用默认（或者配置）的网络端口，网络端点才能被创建，这样才能方便后续DDS参与者发布DataReader以及DataWriter的详细配置信息。一段时间后，各个节点就会基于所配置的、 可插拔的传输协议 ，发现彼此并创建一个连接。
当开发并部署需要使用RTPS发现的应用程序时，开发人员需考虑以下限制因素：
- 由于UDP端口的方式被分配给域ID，那么，域ID应当在0~231（包含231）之间。在每个OpenDDS进程、每个域中，支持多达120个域参与者。
- 主题名称以及类型识别码被限制到256个字符。
- 由于全局唯一标识符（GUID）的方式被指定，OpenDDS的本地多点发送传输不能与RTPS发现一并工作（如果试图这样，那么将发布一个警告信息）。