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

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

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

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

    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）。 一个调用者将方法调用请求发给 被调用者，然后被调用者返回调用是否成功与相应返回值。

3. 连接模式：

下面将简述节点与其他节点如何进行连接，最后初始化一个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的协议头占用过多带宽）