【DDS】DDS-RPC通信机制
DDS-RPC通信机制
基本概念
- 关于DDS的概念请见：DDS与OpenDDS
- 什么是DDS-RPC:
OMG官网给出关于DDS-RPC概念的定义：OMG DDS-RPC
This specification defines a Remote Procedure Calls (RPC) framework using the basic building blocks of DDS, such as topics, types, DataReaders, and DataWriters to provide request/reply semantics. It defines distributed services, described using a service interface, which serves as a shareable contract between service provider and a service consumer. It supports synchronous and asynchronous method invocation. Despite its similarity, it is not intended to be a replacement for CORBA.
DDS-RPC又叫PRC over DDS，RPC指Remote Procedure Calls，关于RPC的概念请自行温习。根据字面意思，以及OMG给出的定义。DDS-RPC可以总结为：
DDS-RPC构建在DDS上，实现请求/应答通信机制。
- DDS-RPC概念模型(简易)
请求端发送请求ID和请求信息，接收端通信请求ID和请求信息，调用相应的本地处理函数。然后，将结果，通过应答ID和请求ID和应答信息，告知给调用方。
DDS-RPC规范及实现方法
OMG给出了DDS-RPC这种通信机制，自然要定义一套规范，DDS-RPC的实现方要遵循这个套规范进行实现，这样即使不同的DDS-RPC实现方，它们相互之间，可可以利用DDS-RPC通信。
由于DDS-RPC是构造在DDS之上的，因此DDS-RPC通信的实现过程，包括以下几个关键点：
- 服务定义
- 服务映射(请求/应答主题)
- 发现/匹配RPC服务
- 请求/应答关联
服务定义
所谓服务定义是指：如何描述RPC中的服务接口信息。
下面给出一个例子IDL文件(DDS使用IDL作为接口文件)。
module robot { // 模块
interface RobotControl // 接口
{
void command(Command com); // 函数
void getStatus(out Status status);
float setSpeed(float speed);
}
}
详细请参考：https://www.omg.org/spec/DDS-RPC/1.0/PDF (7.3 Service Definition)
服务映射
- Mapping Service Specification To DDS Topics
服务映射指：将服务定义转换为DDS识别的Topic信息。
- Topic映射包括主题名映射与数据类型映射
- 主题名映射
DDS-RPC有三种映射机制：Default Topic Names、Specifying Topic Names using Annotations、Specifying Topic Names at Run-time。
这里给出“Specifying Topic Names using Annotations”例子：
@DDSService
@DDSRequestTopic (name=“RobotRequestTopic”) // @DDSRequestTopic (Requset主题注释关键字)
@DDSReplyTopic (name=”RobotReplyTopic”) // @DDSReplyTopic (Rely主题注释关键字)
interface RobotControl
{
}
详细请参考：https://www.omg.org/spec/DDS-RPC/1.0/PDF (Chapter 7.4)
- 数据类型映射
请求/应答主题(Topic)的结构由接口信息确定。根据DDS-DPC规定，主题包含消息头与数据两部分。
请求主题
struct RobotControl_Request
{
dds::rpc::RequestHeader header;
RobotControl_Call data;
};
应答主题
struct RobotControl_Reply
{
dds::rpc::ReplyHeader header;
RobotControl_Return data;
};
- 请求主题
如何将操作映射为一个请求主题呢？
首先，将操作映射到In structure，然后再In structure中定义操作的输入参数。
${interfaceName}_$ {operationName}_In
// 例：
RobotControl_setSpeed_In
- 应答主题：
首先，将操作映射到Out structure，然后在Out structure内定义操作的输出参数以及”reture_”返回值。
${interfaceName}_${operationName}_Out
// 例
RobotControl_setSpeed_Out
关于请求与应答主题，如何映射，这里只简单介绍了一小部分。详细规则，请参考
https://www.omg.org/spec/DDS-RPC/1.0/PDF
- Interface映射
上面，已经将操作映射为DDS可以识别的结构体。根据DDS-RPC的服务定义，可以知道，一个Interface包含一系列接口。那么如何对Interface进行映射？
请求(interface)映射：
${interfaceName}_Call
// 例
union RobotControl_Call switch(long)
应答(interface)映射：
union RobotControl_Return switch(long)
关于 服务映射，这里只说了一小部分。更多的内容，请参考：
https://www.omg.org/spec/DDS-RPC/1.0/PDF
OMG给出的IDL定义实例，请参考：
https://www.omg.org/spec/DDS-RPC/About-DDS-RPC/
【RPC over DDS 1.0 IDL .zip file】
- 总结
根据上面所说内容，可以将RPC定义的服务，映射为DDS可以识别的数据类型。
接下来，就需要调用端与服务提供端，进行RPC服务的发现与匹配。
发现与匹配RPC服务
请求与应答是两个独立的DDS Topic，因此不能保证两个主题同时被发现。
例：
请求主题发现完成。应答主题未发现。此时，服务器能够接收数据，但无法返回数据给服务的调用者。
DDS-RPC针对上述问题，定义了发现/匹配RPC服务机制，可以简单总结为：
- 服务器：激活服务器，初始状态不可读（不能接收请求）。当前请求与应答主题，两段相互发现（匹配完成)时，正常工作。
- 客户端：激活客户端，初始状态不可写（不能发送请求）。当前请求与应答主题，两段相互发现（匹配完成)时，正常工作。
详细请参考：https://www.omg.org/spec/DDS-RPC/1.0/PDF(7.6)
请求与应答关联
- 问题
- 解决方案：
请求主题实例数据与应答主题实例数据中添加某一个远程调用的样本身份。
服务请求ID（包含在请求主题消息头，根据系统信息生成）。
服务应答ID（包含在应答主题消息头，根据系统信息生成）
详细内容请参考：https://www.omg.org/spec/DDS-RPC/1.0/PDF
DDS系列
【DDS】DDS与OpenDDS
【DDS】DDS-RPC通信机制
【DDS】基于OpenDDS的DDS-RPC实现