opendds初入门之考虑为什么要用opendds

受限于场景和历史因素，在考虑业务方案时直接以opendds为中心进行了探索，但是考虑到它的本质也就是基于基本的tcp/ip的一套通信框架，我们的业务使用也仅仅是它的通信能力。

如果只是使用opendds的通信能力，只需要它的发布订阅逻辑，我为什么要用这么复杂的opendds呢？（本质就是通信能力，基于tcp或者udp）

1. 为什么opendds最适合

首先考虑opendds的能力：

支持基于corba的面向对象的rpc交互，支持udp/tcp/共享内存/rtps自动发现/广播等传输方式，支持qos服务质量控制，底层支持线程池和reactor处理，内置主题提供了对上层能力的支持，支持idl格式提供面向数据的业务交互（有数据模型的概念）。

拆分说明：

====》支持udp，低延迟，强实时 （可通过qos进行配置传输质量）。
====》rtps自动发现（传统的发布订阅一般都有个注册中心）。
====》reactor处理网络（高效处理网络，但是其他组件一般也都支持）。
==》面向数据的业务交互（这里主要说的是提供了idl定义数据的方式，以及有topic概念，底层处理）=》对比其他框架的使用，topic的含义是不一样的，除此之外，面向数据可以用上层协议适配替换(如proto),但是需要上层适配处理。

opendds中可以发布多个topic，谁订阅谁才能收到，按订阅topic分开数据模型处理。

====》支持qos服务质量配置 （这个就挺好了，淡化了qps的概念，满足一定业务需要）。
====》内置主题 （自带的分布式“注册中心 + 元信息广播“，同时，提供了一些能力，让上层可扩展）

这里又抛开一个话题，opendds对topic的发布和订阅，第一：如何设计基于topic的业务模型。 第二：关于多个topic的发布，如何进行处理（每个topic都有对应的监听回调处理，还是线程单独循环read）第三：基于topic的发布订阅上，设计业务层的交互协议差异。

总结：

对比其他的发布订阅开源代码（就理论理解，待使用探索），opendds在设计上更重，更复杂一些，支持的功能更多，实时性也支持更好，与其他的库比，在设计的目的上就已经有差异了（opendds适合复杂实时场景）。

2. 考虑发布多个topic的处理

1. 每个 Topic 建立单独的 Subscriber 和 DataReader，用单独的类型进行区分处理。
2. 共享订阅者 + 多个 DataReader，一个Subscriber管理多个DataReader。（可以设置Subscriber的qos，统一生效，牺牲了隔离性）
3. 使用统一的 Listener 处理多个 Topic。 （Listener 的回调函数中，根据 DataReader 或 Topic 的标识来区分处理逻辑，qos的处理需要在listener中适配）。
4. 创建线程，每个 DataReader 可以运行在独立线程中，异步接收和处理数据。
5. 使用统一的数据类型或封装结构。（业务上层区分解析，但是影响qos设置，无法分类设置）。

====》考虑对带宽的影响，默认情况下是共享底层带宽通路的，但是上层qos策略对带宽是有影响的。

3.总结

如何实现节点监控，内置主题对节点监控的影响？集中模式和非集中模式下内置主题的影响差异是什么？