前言

最近做毕设要做一个DDS系统和TISA系统的网关，完全没有基础，只好对着OpenDDS的Developers’ Guide和《分布式系统实时发布/订阅数据分发技术》这本书一点一点学(顺便吐槽这本书就是guide的翻译版，很多语句不通)。遇到很多问题，持续更新，随着慢慢看能解决一部分，希望高手指正。

一些概念

• entity是什么？
  答：DCPS entities包括topic, data writer,data reader, publisher, subscriber, domain participant。
• sample数据样本?
  答：需要发布/订阅的数据。
• DDS application是什么？
  答：dds应用程序，可以认为是需要发布、订阅数据的双方，datawriter,datareader是它们用于收发的一部分。
• 实例和对象的区别？
  答：抽象类是无法实例化的，它们的对象只能叫对象；一般类的实例化对象，即可简称对象，也可简称实例。
• sample，instance（实例），fields（字段）和key（键）的关系？
  
  OpenDDS要求数据类型是结构体（类），instance便是这个类的对象（实例），具体来说就是被传输的sample。
  一个域里有多种主题；发布消息时，一个主题下有按照结构体（类）创建多个实例instances；key用来识别同一主题下的不同的实例。发布时，拥有不同key的sample是同一主题下的不同实例。默认QOS下，同一个key下的后继的样本视为之前样本的替代。而字段其实就是只源码里的某一段代码。

（汉语书中对example和instance的翻译都是“实例”，我也是迷醉。。。。）其实有点面向对象的概念。

源文件解读

Chap3的例子

• chap3的例子中message.subject_id是键，用来区分不同实例。可是明明Messenger::Message message;只创建了一个message实例,每次更改键值其实不是创建不同实例，而是同一个实例改变了值发出去。
• chap3例子里面用了一个for循环来发布不同的实例，所有发布出去之后，再等待subscriber接收。因此，wait_for_acknowledgements()是在for循环之外的。原因：

由于DDS内部数据的发布和订阅是解耦的，因此，如果在发送的所有数据已经被订阅所接收之前，发布被断开/关闭，则不能保证数据被递送。如果应用要求所有的发布数必须被接收，那么，可以进行wait_for_acknowledgements()操作，允许发布进行等待，直到subscriber接受完所有写入数据。

其他例子

待解决的疑问

1. 有关概念的疑问
   • 域参与者工厂（Participantfactory）是个什么？
   • 一个订阅者、一个发布者的体系是怎么发布订阅的？InfpRepo怎么工作？
2. 有关创建工程的疑问
   • Chapter3的messenger.idl和后面的publisher有什么关系？
   • perl干什么用的？run_test.pl为什么可以在命令行中显示发布/订阅过程？
   • chapter3示例中在cpp文件中先建立subscriber和publisher，然后是datawriter和datareader，是不是和实际情况相反？
   • 如何拓展到多个订阅/发布体系？
   • 似乎只创建了发布者和订阅者，和需要发布数据的应用程序如何建立联系（接口）？
3. 有关命令行运行的疑问
   • 运行chapter3的示例老出现：
     [warning] Could not find FQDN. Using "QUBPJJDAV3WB803" as fully qualified hostname, please correct system configuration.
     什么原因？和系统configuration有什么关系？

Example使用和编译工程

• 文件夹介绍
  /bin/中有DCPSInforepo.exe
  /DevGuideExamples/主要包含三个示例程序
  /docs中包含很多说明文档，可以在github中阅读效果更好
  /examples里有四个例子
  /tools/里有monitor和图形化界面

• OpenDDS自带的各种例子如何解读、加以学习？
  汉语书和Developer’s Guide上只有一个例子，是此路径
  D:\OpenDDS-3.13.1\DevGuideExamples\DCPS\Messenger下的publisher.exe和subscriber.exe罢了。example文件夹和Devexampl’e文件夹下的其他例程，运行方法参照README文档，同样命令行启动就好。**自己编写publisher和subscriber编译之后运行，方法是一样的。只是自己编写的过程中需要注意头文件的引用。

• 以D:\OpenDDS-3.13.1\DevGuideExamples\DCPS\Messenger.minimal为例，里面有三个工程文件:

  MessengerMinimal_Idl.vcxproj
  MessengerMinimal_Publisher.vcxproj
  MessengerMinimal_Subscriber.vcxproj
  

一个示例文件夹下，Messenger，Publisher’和Subscriber是三个工程，分别由三个工程文件.vcxproj组织。点开之后可以看到各种依赖项、头文件、源程序等等。其中Messenger是没有源文件和头文件的，因为仅IDL文件编译得到，没有自己编写的.cpp源文件，只有IDL编译器编译生成的.cpp文件。在MessengerMinimal_Idl.vcxproj工程中能看到定义数据类型的.IDL文件和辅助编译的.mpc文件。另外，两个中能看到Publisher.cpp和Subscriber.cpp源文件。

• 搞清楚一对一体系从头开始，需要写哪些文件，进行什么步骤的编译，最后能生成在cmd中运行的.exe文件？
  答：

  1. 创建Demo.idl文件，在里面定义要传输的DCPS数据类型（定义结构体）、加入编译指令、定义DCPS数据类型的键；
  2. 编写Demo.mpc文件，里面定义了一个idl工程；
  3. 使用MPC命令生成Visual Studio的解决方案文件和工程文件.sln和.vcproj；
  4. VS中打开.sln文件，直接编译，即可编译前面的idl文件，生成各种支持文件；
  5. 在Demo.idl中加入publisher相关的内容，新建Publisher.cpp文件，再用之前的命令生成.sln文件。
  6. 更改publisher.cpp中的逻辑内容；
  7. 编译publisher.cpp生成.exe，即得到publisher应用。
     build publisher from scratch

• 如何使用OpenDDS建立订阅/发布体系？
  答： 总体分为两步：写IDL、cpp逻辑、编译生成.exe文件，之后在命令行中采用共享文件或者其他方式启动；只使用Inforepo，其他的可以自己改写。

  • 建立发布者和订阅者编译过程：
    见上一个问题
  • 命令行启动：
  1. 使用DCPS信息仓库（DCSPInfoRepo.exe），在D:\OpenDDS-3.13.1\bin路径之下，命令行中输入

     D:\OpenDDS-3.13.1\bin\DCPSInfoRepo -o $publisher和subscriber的路径\simple.ior
     

     启动信息仓库，并将信息写入simple.ior文件，供Publisher和Subscriber使用。注意,为了能被publisher使用，需要写入publisher所在的目录或者启动publisher时注明.ior文件的系统路径。
     2. 启动订阅者和发布者,命令行中输入：

     //第一个命令行窗口
     subscriber -DCPSInfoRepo file://simple.ior
     //再开一个新的命令行窗口输入
     publisher -DCPSInfoRepo file://simple.ior
     

结构

• Datawriter和DataReader的作用：
  每个Datawriter只能绑定一个topic。应用程序使用Datawriter的指定类型的接口，在该Datawriter主题上发布数据样本。Datareader负责对数据进行编码，并传递给Publisher准备进行传输，Publisher负责获取待发布的数据并把它分发到所在域中所有的订阅者处。一个Publisher可以管理一个或多个Datawriter。

  每个Datareader只能绑定一个Topic。Subscriber从Publisher处接受数据，并将其传递给所有与其相连的Datareader。Datareader负责从订阅者那里获取数据，并解码为对应主题的适当类型，再将样本传递给应用程序。

集中式发现InfoRepo

1. 不参与数据传递，只用于DDS应用发现彼此；
2. 在一个DDS域上，可以运行多个Inforepo，分别负责互不重叠的部分；
3. 多个inforepo可以形成一个联邦，联邦中的不同repository为了互相识别，需要有识别码；

点对点发现

• networtrk port和network endpoints都是什么？网络端口和网络节点。
• RTPS，可以和非OpenDDS交互。
• 怎么理解’Interoperability with other DDS implementations must utilize the peer-to-peer method, but can be useful in OpenDDS-only deployments.‘
  答：OpenDDS系统中的应用程序如果希望和非OpenDDS系统，但遵循OpenDDS规范的应用进行交互，需要用RTPS，形成peer to peer发现。

QoS策略

1. DEADLINE

• 功能：允许应用程序在指定的时间内检测数据是否被写入或者读取，在订阅端指定writer()发布样本的最大间隔时间，在订阅端制定接受实例的新样本的最大时间间隔。
• 适用： 需要周期发布数据的应用程序，实体包括:DataWriter,DataReader，topic等。
• 生命周期：可在关联的实体启用之后修改策略，
  • 用于DataWriter和Datareader，需要所有关联的写着、读者都修改
  • 用于Topic，策略修改后，只影响以后创建的写者、读者。

2. LIFESPAN

• 功能：允许应用程序指定样本合适失效，失效的样本不会传递给subscriber；
• 适用：topic，DataWriter
• 生命周期：可在运行时修改，只影响修改后发布的数据。

3. TIME_BASED_FILTER

• 功能：指定接收者以多大的时间间隔接收数据；
• 适用：Datawriter

Note:4,5,6是分别为三类实体提供附加信息的策略，分别为user，topic，和group，其中datawriter和datareader是用户user，而publisher和subscriber属于group，参照结构图可以理解。

4. USER_DATA

• 功能：应用程序提供保护附加信息的方式；
• 适用：Domainparticipaint, DataReader, DataWriter;
• 生命周期：

5. TOPIC_DATA

• 功能：；
• 适用：topic;
• 生命周期：对于DataWriter， Datareader， 内置主题数据有效。

6. GROUP_DATA

• 功能：；
• 适用：topic;
• 生命周期：对于DataWriter， Datareader， 内置主题数据有效。

7. LIVELINESS

• 功能：控制何时以及如何检测参与者是否还存活，存活表示参与者仍然处于可访问和激活状态；
• 适用：topic,datareader,datawriter,在主题上使用该策略，会是与该主题关联的datawriter，datareader都有效;
• 选项：kind有三种选择，表示自动或者实体手动检测，检测参与者存活。

8. RELIABILITY

• 功能：按策略设置控制数据写者对数据样本的处理方式。
• 适用：主题，写者，读者
• 选项：kind设为REALIABLE_REALIABILITY_QoS表示表示服务最终把数据样本递送给适当的Datareader。BEST_EFFORT_QOS表示数据写者不保证数据有效性，允许丢弃样本。

后面14个之后再更新。。感觉当务之急是如何使用，不是背手册。

QOS的表示方法一个结构体

每个QoS策略都用一个结构来表示；每个实体都支持一部分策略，并用一个结构体把所支持的策略组合在一起。

QoS匹配模型

实体对象：除了前面说的实体，还包括DomainParticipantFactory

set_qos()用来为某个实体设置QoS,将新的策略添加到之前的策略集上，如果和之前的不一致，则更改失败。

为了保证通信，发布端和订阅端的QoS应当兼容。

“能否改变”特性决定了某个QoS策略能否在实体有效后再改变。

从Rxo和“能否改变"两个维度评价QoS。

第七章 传输配置

传输的概念