dbus通信与接口介绍

DBUS是一种高级的进程间通信机制。DBUS支持进程间一对一和多对多的对等通信，在多对多的通讯时，需要后台进程的角色去分转消息，当一个进程发消息给另外一个进程时，先发消息到后台进程，再通过后台进程将信息转发到目的进程。DBUS后台进程充当着一个路由器的角色。

DBUS中主要概念为总线，连接到总线的进程可通过总线接收或传递消息，总线收到消息时，根据不同的消息类型进行不同的处理。DBUS中消息分为四类：

1.  Methodcall消息：将触发一个函数调用 ；

2.  Methodreturn消息：触发函数调用返回的结果；

3.  Error消息：触发的函数调用返回一个异常 ；

4.  Signal消息：通知，可以看作为事件消息。

1.2  DBUS应用场景

根据DBUS消息类型可知，DBUS提供一种高效的进程间通信机制，主要用于进程间函数调用以及进程间信号广播。

1 . 函数调用

DBUS可以实现进程间函数调用，进程A发送函数调用的请求（Methodcall消息），经过总线转发至进程B。进程B将应答函数返回值（Method return消息）或者错误消息（Error消息）。

2 . 消息广播

进程间消息广播（Signal消息）不需要响应，接收方需要向总线注册感兴趣的消息类型，当总线接收到“Signal消息”类型的消息时，会将消息转发至希望接收的进程。

1.3  DBUS通信特点

DBUS是一种低延迟、低开销、高可用性的进程间通信机制。其协议是二进制的，避免序列化的过程，通信效率较高。DUBUS可以提供一些更高层的功能：

1.  结构化的名字空间；

2.  独立于架构的数据格式；

3.  支持消息中的大部分通用数据元素；

4.  带有异常处理的通用远程调用接口；

5.  支持广播类型的通信。

 

2. 技术实现

2.1 实现原理

DBUS是一种高级的IPC通信机制，通信流程如图 2‑1所示。在DBUS通信过程中，存在一个后台进程（BUS Daemon Process）。后台进程和普通进程间信息交互是通过域套接字进行通信。

 

图 2-1 DBUS通信原理

如图 2‑1所示，进程1（Process1）需先连接到总线（dbus_bus_get），其次构造消息（dbus_message_new_signal），然后发送消息（dbus_connection_send）到后台进程。后台进程接收消息，然后根据消息类型对消息进行不同处理（bus_dispatch_matches）。

进程2（Process2）接收消息前需要连接到总线，并告知总线自己希望得到的消息类型（dbus_bus_add_match），然后等待接收消息（dbus_connection_pop_message）。进程2（Process2）收到总线转发的消息时会根据消息类型，做不同的处理（若是信号类型则不需要发送返回值给总线）。

2.2 连接到总线

进程间通信前，需要连接到总线。调用dbus_bus_get函数连接进程到总线，建立进程和总线之间的连接（DBusConnection）。建立连接后，需要为这个连接注册名称，方便后面对这个连接进行操作，调用dbus_bus_request_name函数对连接进行注册名称。

建立连接和注册名称是在程序开始时执行，程序结束时，调用dbus_connection_close函数关闭一个连接。函数接口声明如程序清单 2‑1所示。

程序清单 2-1 建立、注册名称和关闭连接

1. DBusConnection  *dbus_bus_get  (DBusBusType  type,  DBusError   *error)             /*  建立和总线的连接  */
2. int  dbus_bus_request_name  (DBusConnection   *connection,
3. const char         *name,
4. unsigned int        flags,
5. DBusError        *error)                                   /*  注册连接名称      */
6. void  dbus_connection_close  (DBusConnection  *connection)                           /*  关闭连接          */

2.3 信号发送与接收

2.3.1 信号发送

DBUS中信号是一种广播的消息，当发出一个信号，所有连接到 DBUS 总线上并注册了接受对应信号的进程，都会收到该信号。

进程发出一个信号前，需要创建一个 DBusMessage 对象来代表信号，然后追加上一些需要发出的参数，就可以发向总线了。发完之后需要释放消息对象。信号发送的函数声明如程序清单 2‑2所示。

程序清单2-2  信号发送接口

1. DBusMessage  *dbus_message_new_signal  (const  char  *path,
2. const  char  *iface,
3. const  char  *name)                       /*  创建信号类型消息      */
4. void  dbus_message_iter_init_append  ( DBusMessage     *message,
5. DBusMessageIter  *iter)                /*  加入参数到信号        */
6. dbus_bool_t  dbus_connection_send  ( DBusConnection  *connection,
7. DBusMessage    *message,
8. dbus_uint32_t    *serial)                       /*  发送信号到总线        */
9. void  dbus_message_unref  (DBusMessage *message)                                 /*  释放消息              */

2.3.2 信号接收

    进程接收信号时，需先告知总线进程感兴趣的消息，然后等待接收消息。信号接收函数声明如程序清单 2‑3所示。

程序清单 2-3 信号接收接口

1. void  dbus_bus_add_match  ( DBusConnection  *connection,
2. const char        *rule,
3. DBusError       *error)                                 /*  告知总线感兴趣的消息   */
4. DBusMessage  *dbus_connection_pop_message  ( DBusConnection  *connection)         /*  接收消息               */
5. dbus_bool_t  dbus_message_is_signal  (DBusMessage  *message,
6. const char      *iface,
7. const char     *signal_name)                    /*  判断消息是否为信号     */

2.4 函数调用和提供函数调用

2.4.1 函数调用

调用一个远程函数与发送一个信号原理类似，需要先创建一个消息（DBusMessage），然后通过注册在 DBUS上的名称指定发送的对象。然后追加相应的参数，调用方法分为两种，一种是阻塞式的，另一种为异步调用。异步调用的时候会得到一个“DBusMessage *” 类型的返回消息，从这个返回消息中可以获取一些返回的参数。

函数调用的函数声明如程序清单 2‑4所示。

程序清单 2-4 函数调用接口

1. DBusMessage  *dbus_message_new_method_call  (const char  *destination,
2. const char  *path,
3. const char  *iface,
4. const char  *method)                    /*  创建一个函数调用消息    */
5. void  dbus_message_iter_init_append  (DBusMessage     *message,
6. DBusMessageIter  *iter)                     /*  为消息添加参数           */
7. dbus_bool_t  dbus_connection_send_with_reply  (DBusConnection   *connection,
8. DBusMessage      *message,
9. DBusPendingCall  **pending_return,
10. int            timeout_milliseconds)       /*  发送消息                */
11. void  dbus_pending_call_block  (DBusPendingCall  *pending)                           /*  阻塞等待返回值           */
12. DBusMessage  *dbus_pending_call_steal_reply  (DBusPendingCall  *pending)             /*  获得返回消息            */
13. dbus_bool_t  dbus_message_iter_init  (DBusMessage     *message,
14. DBusMessageIter  *iter)                     /*  获取参数                */

2.4.2 接收函数调用

    提供远程函数调用，首先需告知总线进程感兴趣的消息，其次从总线获取消息并判定消息是方法调用。然后从消息中获取参数进行函数执行，最后创建返回消息，并发送消息至总线，由总线转发至调用的进程。函数声明如程序清单 2‑5所示。

程序清单 2-5 接收函数调用接口

1. void  dbus_bus_add_match  ( DBusConnection  *connection,
2. const char        *rule,
3. DBusError       *error)                                   /*  请求获取调用消息       */
4. DBusMessage  *dbus_connection_pop_message  ( DBusConnection  *connection)           /*  从总线获取消息         */
5. dbus_bool_t  dbus_message_is_method_call (DBusMessage  *message,
6. const char     *iface,
7. const char     *method)                       /*  判定消息是方法调用     */
8. dbus_bool_t  dbus_message_iter_init  (DBusMessage     *message,
9. DBusMessageIter  *iter)                    /*  获取参数               */
10. DBusMessage  *dbus_message_new_method_return  (DBusMessage *method_call)            /*  创建返回消息           */
11. void  dbus_message_iter_init_append  ( DBusMessage     *message,
12. DBusMessageIter  *iter)                   /*  在消息中填入参数       */
13. dbus_bool_t  dbus_connection_send  ( DBusConnection   *connection,
14. DBusMessage     *message,
15. dbus_uint32_t     *serial)                        /*  发送返回消息          */

3. 小结

DBUS是一种高效、易用的进程间通信方式。本文档介绍了DBUS的通信原理，以信号收发和方法调用为框架，介绍了DBUS中常用的函数接口。

DBus分为两种类型：system bus(系统总线)，用于系统(Linux)和用户程序之间进行通信和消息的传递；session bus(回话总线)，用于桌面(GNOME, KDE等)用户程序之间进行通信。

上节补存：

Name: 图模型中的Name 在ROS的封装体系中非常重要，所有的resource（从node到topic到service和 parameter等）都是在某个namespace中用特定的Name进行了定义。 一般来说，resource 可以在自己的namespace中创 建新的resource，访问和使用已有的resource。链接可以建立在不同的资源之间，namespace保证了不同resource间的Name 不会冲突，也封装了resource内部。

（可以参考C++中namespace的概念。因为ROS分布式系统的设计思路，对与不同主机上，不同功能区块，都可以用namespace对其中 的resource name 包括 topic name 等 进行保护，使得name管理更加结构化，更多体现在对于代码重用性的提高）

Computation graph： Computation graph是一个p2p的网络结构。Node之间的链接关系的拓扑结构为 mesh（网状）

Node：node是一个处理计算的进程。（操作系统中的一个进程，因为要占用端口号进行通讯，多机分布式系统中还要标明ip，详见后面的 uri）Node在graph中使用topic service和parameter相互通讯，协调工作。在不同的系统设计中，node承载的功能粒度也 不一样。比如大部分的设备驱动都是单独占用一个node，为了提高代码复用率经常会有细粒度的划分，而在很多视觉处理的系统避免使用多节点结构，传递图像 数据会造成系统资源浪费（nodelet的应用）。Node的使用极大的增加了系统模块化和代码封装的程度，也给系统带来了一些错误容忍的能力。

Master node： master node 给ros系统中其他节点提供命名与注册的服务。它跟踪节点中的publisher与 subscriber，service 的server与client，记录其他节点的位置（uri标明，host与port），并将这些信息通知给需要 建立链接的节点。（从分布式系统的角度分析，ros这样p2p网络中集中式管理peer信息，也为仿真环境提供虚拟时钟 /clock 重要：ROS多机系统中，ros的全局时钟仅是本机的系统时钟，多机需要同步系统时间的工具来实现ros内时钟同步，一般是ntp，pr2应用 linux中的chrony进行基于ntp的系统时间同步）

Message： node之间通讯规定的统一数据格式，ros内部有数据格式规定语言来定义，然后由相应语言的client library中的message_generation 组件生成目标代码。提供统一的串行化/解串行化 方法。

Topic：ros中广为使用的是异步的 publish-subscribe 通讯模式。这种方式将信息的产生和使用双方解耦。一般来说，节点没 有通讯对方那边的信息。Node从需要的topic那取得消息，topic 可以有多个 subscriber 与publisher。Topic 一般 用于单向，消息流通讯。Node 需要同步通讯交换信息时一般使用service。Topic 一般拥有很强的类型定义：一种类型的topic只能接受/ 发送特定数据类型（message type）的message。Publisher 没有被要求类型一致性，但是接受时subscriber会检查类型 的md5，进而报错。

Service： service 用于处理ros通讯中的同步通讯，采用server/client 语义。每个service type拥 有 request 与 response两部分，对于service中的 server，ros不会检查重名（name conflict），只有最后 注册的server会生效，与client建立连接。

Parameter： parameter 可以看作为ros系统运行时中定义的全局变量，而master node 中有 parameter server 来维护这些变量。而namespace的存在使得parameter 拥有了非常清晰的层次划分，避免了重名，而且使 得parameter访问可以单独访问也可以树状访问（层层解析namespace）

URI：定位node在分布式系统中的位置，格式为： protocol://host:port，protocol一般为http或者 rosrpc， host为 hostname 或者 ip 地址，port则为端口号。

TCPROS：基于tcp协议的ros应用层数据协议，用于解析topic 与 service的二进制数据流。

• 远程过程调用（RPC）

ROS 通讯中，节点通过远程过程调用来实现建立连接，传输数据。ROS 中远程过程调用采用XML-RPC 实现。远程调用负责管理节点对计算图 中信息的获取与更改，还有一些全局的设置。RPC不直接支持数据的流传输（通过TCPROS与 UDPROS支持）。XML-RPC 优势在于支持它的语 言类型很多，而XML本身的文本属性导致方便人调试。XML-RPC被封装在http协议中传输，XML-RPC 调用时无状态的 （stateless），没有状态信息需要追踪，简化了控制逻辑。

1》数据类型：

在XML-RPC中，方法参数和其返回值被封装在value 的实体中，value有以下几种固定的类型可以选择。（xml中体现为value的子标签）

string 为ascii 码的字符串，为value的默认格式。不合法的字符只有& 和 <,s & <；表示。

int 或者 i4 是32位的有符号整型，十进制表示中，前缀-号则为负数。

boolean 只有两种取值，0和1，用于表示布尔类型。

double  实数类型，前缀-号表示负数。

dataTime.iso8601 日期时间，用iso-8601格式表示。

base64 用 base64算法编码的二进制字符串。

array values组成的表，在data实体下一层

Struct 又称为map 表示关系的集合，每一个struct实体是由一个 name 与 value的键值对组成。

2》 请求与应答：

远程过程调用由两个阶段组成：请求（request） 与 应答（response）。 一个调用者将方法调用请求发给 被调用者，然后被调用者返回调用是否成功与相应返回值。

1. 连接模式：

下面将简述节点与其他节点如何进行连接，最后初始化一个topic data的流传输，service 的实现有些许不同。

在之前对于节点与计算图的介绍中，节点在master node处注册 自己在publish /subscribe topic。通过 registerPublisher()和 registerSubscriber() 。节点在master处注册完自己的 subscribe/publish topic后，master都会返回一个成功的应答，其中包含所有publisher节点的URI，然 后 subscriber去与相应的publisher建立连接传输 topic 相关信息（topic name，树蕨类型，传输类型等）。有任何新的 节点去publisher 一个topic并且在master处已经完成自己的注册时，master会给所有subscribe 这个topic的节点发 出一个publisherUpdate() 请求，里面包含所有可用的 publisher的URI，topic 消息的数据由TCPROS协议传输。

简单来说就是各个节点在 master处注册信息，master发现有节点subscribe/publish相同的topic时，将 publisher的 信息通过 RPC 分发给各个subscriber，subscriber与publisher建立第一次连接，传输topic信 息，然后再根据publisher返回的topic 信息，建立第二次连接，publisher开始 传输具体的数据。

而对称的过程是 注销（unregisteration）， publisher 通过远程调用unregisterPublisher(), 然 后subscriber通过unregisterSubscriber()注销，然而，是否关闭publisher与 subscriber间的数据流传 输取决于节点本身。

Service的工作原理与topic有些许不同，同一个service能被多个节点注册，但是只有最后一个能被其他节点接受。一个节点调用 service时，通过lookupService() 远程调用在master处查找相应service的URI。然后它将通过一个request 消 息调用service的提供者，如果成功了，service提供者将返回一个相应的response 消息，失败了返回相应错误消息，（所有的消息传输默 认都是通过 TCPROS协议。）

• 数据流

XML-RPC为我们提供了方便整洁的远程调用协议，但是它的冗长与以文本为中心的编码格式使得它不适合高带宽，低延迟的数据传输任务。ROS定义 了自己的二进制数据流传输协议，减少了冗余的协议增加从而增加带宽，协议设计使得数据几乎不需要解析（相对于rpc），从而减少延迟。详细的TCPROS 协议内容可以在 wiki.ros.org/ROS/TCPROS 找到。

（现在ROS中也有实现的UDPROS协议，可以通过TransportHints 数据结构指定下层传输协议，甚至通过继承Trasport 类 自己实现本机的进程间通讯方法）。

下面捡一些TCPROS中的重点说一下：

Md5：TCPROS为了保证两边传输数据类型一致，会在协议头中给出topic name 的md5 hash算法处理过的值，而每次你生成新的msg 时，md5的值都会因为你内部数据类型的变动而改变，这样就避免了新msg与 旧msg 传输类型不一致的问题。

Subscriber 选项tcp_nodelay :如果是“1” 则给socket 设置 TCP_NODELAY 选项，降低延迟，可能会降低传输效率。

Service client 选项：persistent 设置为1，则service的链接会一直开放给多个 service request

（下面是一些理解：

• TCPROS的协议头占的字节数比较固定，所以传输一帧中只传输有效位几个字节是非常不划算的，很多情况下可以附上 std_msgs/header ，seq可以检测丢包，stamp可以检测消息实时性，frame_id很多情况下必备。
• Roscpp 对 数据流的控制api比rospy要丰富很多，比如roscpp中有对callback queue的操作，多线程回调函数的支持等，对数据传输要求比较高的节点还是老老实实用cpp吧
• 在一些对延迟要求比较高而又有一些无线通讯等高延迟传输介质存在的应用中，可以考虑用低延迟的方式互联，比如xbee模块代替wifi（自己写一些与其他节点的bridge），或者udpros代替tcpros，并且避免tcpros的协议头占用过多带宽）