dbus里面 name和path 怎么确定的，xml的不准确：
后来发现这个应该是在写debus server的时候自己制定的，xml只是理论上应该和这个保持一致
D-Bus三层架构
D-Bus是一个为应用程序间通信的消息总线系统, 用于进程之间的通信。它是个3层架构的IPC 系统，包括：
1、函数库libdbus ，用于两个应用程序互相联系和交互消息。
2、一个基于libdbus构造的消息总线守护进程，可同时与多个应用程序相连，并能把来自一个应用程序的消息路由到0或者多个其他程序。
3、基于特定应用程序框架的封装库或捆绑（wrapper libraries or bindings ）。例如，libdbus-glib和libdbus-qt，还有绑定在其他语言，例如Python的。大多数开发者都是使用这些封装库的API，因为它们简化了D-Bus编程细节。libdbus被有意设计成为更高层次绑定的底层后端（low-levelbackend ）。大部分libdbus的 API仅仅是为了用来实现绑定。
总线
在D-Bus中，“bus”是核心的概念，它是一个通道：不同的程序可以通过这个通道做些操作，比如方法调用、发送信号和监听特定的信号。在一台机器上总线守护有多个实例(instance)。这些总线之间都是相互独立的。
一个持久的系统总线（system bus）：
它在引导时就会启动。这个总线由操作系统和后台进程使用，安全性非常好，以使得任意的应用程序不能欺骗系统事件。它是桌面会话和操作系统的通信，这里操作系统一般而言包括内核和系统守护进程。这种通道的最常用的方面就是发送系统消息，比如：插入一个新的存储设备；有新的网络连接；等等。
还将有很多会话总线（session buses）：
这些总线当用户登录后启动，属于那个用户私有。它是用户的应用程序用来通信的一个会话总线。同一个桌面会话中两个桌面应用程序的通信，可使得桌面会话作为整体集成在一起以解决进程生命周期的相关问题。这在GNOME和KDE桌面中大量使用。
对于一些远程的工作站，在system bus中可能会有一些问题，例如热插拔，是否需要通知远端的terminal，这会使得kernel暴露一些设备的能力，不过，我们现在关心D-Bus，是因为手持终端设备的使用，这些将不会出现。在Internet Tablet，也包括我们的手机系统，所有的应用程序都是使用一个用户ID运行的，所以只有一个会话通道，这一点是和Linux桌面系统是有明显区别的。
D-Bus是低延迟而且低开销的，设计得小而高效，以便最小化传送的往返时间。另外，协议是二进制的，而不是文本的，这样就排除了费时的序列化过程。从开发者的角度来看，D-BUS 是易于使用的。有线协议容易理解，客户机程序库以直观的方式对其进行包装。D-Bus的主要目的是提供如下的一些更高层的功能：
A、结构化的名字空间
B、独立于架构的数据格式
C、支持消息中的大部分通用数据元素
D、带有异常处理的通用远程调用接口
E、支持广播类型的通信
Bus daemon总线守护
Bus daemon是一个特殊的进程：这个进程可以从一个进程传递消息给另外一个进程。当然了，如果有很多applications链接到这个通道上，这个 daemon进程就会把消息转发给这些链接的所有程序。在最底层，D-Bus只支持点对点的通信，一般使用本地套接字（AF_UNIX）在应用和bus daemon之间通信。D-Bus的点对点是经过busdaemon抽象过的，由busdaemon来完成寻址和发送消息，因此每个应用不必要关心要把消息发给哪个进程。D-Bus发送消息通常包含如下步骤（正常情况下）：
创建和发送消息 给后台bus daemon进程，这个过程中会有两个上下文的切换。
后台bus daemon进程会处理该消息，并转发给目标进程，这也会引起上下文的切换目标程序接收到消息，然后根据消息的种类，做不同的响应：要么给个确认、要么应答、还有就是忽略它。最后一种情况对于“通知”类型的消息而言，前两种都会引起进一步的上下文切换。
综上原因，如果你准备在不同的进程之间传递大量的数据，D-Bus可能不是最有效的方法，最有效的方法是使用共享内存，但是对共享内存的管理也是相当复杂的。
D-Bus进程通信简单框架
D-Bus常见概念
原生对象和对象路径
所有使用D-BUS的应用程序都包含一些对象, 当经由一个D-BUS连接收到一条消息时，该消息是被发往一个对象而不是整个应用程序。在开发中程序框架定义着这样的对象，例如Java，GObject，QObject等等，在D-Bus中成为native object。
对于底层的D-Bus协议，即libdbus API，并不理会这些native object，它们使用的是一个叫做object path的概念。通过object path，高层编程可以为对象实例进行命名，并允许远程应用引用它们。这些名字看起来像是文件系统路径，例如一个对象可能叫做“/org/kde/kspread/sheets/3/cells/4/5”。易读的路径名是受鼓励的做法，但也允许使用诸如“/com/mycompany/c5yo817y0c1y1c5b”等，只要它可以为你的应用程序所用。Namespacing的对象路径以开发者所有的域名开始（如 /org/kde）以避免系统不同代码模块互相干扰。
简单地说：一个应用创建对象实例进行D-Bus的通信，这些对象实例都有一个名字，命名方式类似于路径，例如/com/mycompany，这个名字在全局（session或者system）是唯一的，用于消息的路由。
方法和信号Methodsand Signals
每一个对象有两类成员：方法和信号。方法就是JAVA中同样概念，方法是一段函数代码，带有输入和输出。信号是广播给所有兴趣的其他实体，信号可以带有数据payload。
在 D-BUS 中有四种类型的消息：方法调用（method calls）、方法返回（method returns）、信号（signals）和错误（errors）。要执行 D-BUS 对象的方法，您需要向对象发送一个方法调用消息。它将完成一些处理（就是执行了对象中的Method，Method是可以带有输入参数的。）并返回，返回消息或者错误消息。信号的不同之处在于它们不返回任何内容：既没有“信号返回”消息，也没有任何类型的错误消息。
接口Interface
每一个对象支持一个或者多个接口，接口是一组方法和信号，接口定义一个对象实体的类型。D-Bus对接口的命名方式，类似org.freedesktop.Introspectable。开发人员通常将使用编程语言类的的名字作为接口名字。
Proxies代理
代理对象用来表示其他的remote object。当我们触发了proxy对象的method时，将会在D-Bus上发送一个method_call的消息，并等待答复，根据答复返回。使用非常方便，就像调用一个本地的对象。
Bus Names总线名字
当一个应用连接到bus daemon，daemon立即会分配一个名字给这个连接，称为unique connection name ，这个唯一标识的名字以冒号：开头，例如:34-907，这个名字在daemon的整个生命周期是唯一的。但是这种名字总是临时分配，无法确定的，也难以记忆，因此应用可以要求有另外一个名字well-known name 来对应这个唯一标识，就像我们使用域名来对应IP地址一样。例如可以使用com.mycompany来映射:34-907。应用程序可能会要求拥有额外的周知名字（well-knownname ）。例如，你可以写一个规范来定义一个名字叫做 com.mycompany.TextEditor。
你的协议可以指定自己拥有这个名字，一个应用程序应该在路径/com/mycompany /TextFileManager下有一个支持接口org.freedesktop.FileHandler的对象。应用程序就可以发送消息到这个总线名字，对象，和接口以执行方法调用。
ps:我觉得这里说法有问题，应该是在根据bus name : org.freedesktop.FileHandler 找到一个bus path是 : /com/mycompany /TextFileManager 的对象，支持method的调用
当一个应用结束或者崩溃是，OS kernel会关闭它的总线连接。总线发送notification消息告诉其他应用，这个应用的名字已经失去他的owner。当检测到这类notification时，应用可以知道其他应用的生命周期。这种方式也可用于只有一个实例的应用，即不开启同样的两个应用的情况。
地址
连接建立有server和client，对于bus daemon，应用就是client，daemon是server。一个D-Bus的地址是指server用于监听，client用于连接的地方，例如unix:path=/tmp/abcedf标识server将在路径/tmp/abcedf的UNIX domain socket监听。地址可以是指定的TCP/IP socket或者其他在或者将在D-Bus协议中定义的传输方式。
如果使用bus daemon，libdbus将通过读取环境变量自动获取session bus damon的地址，通过检查一个指定的UNIX domain socket路径获取system bus的地址。如果使用D-bus，但不是daemon，需要定义那个应用是server，那个是client，并定义一套机制是他们认可server的地址，这不是通常的做法。
通过上面的描述，我们可以获得下面的视图：
Address –> [BusName] –> Path –> Interface –> Method
bus name不是必要的，它只在daemon的情况下用于路由，点对点的直接连接是不需要的。
简单地说：Address是D－Bus中server用来监听client的地址，当一个client连接上D-Bus，通常是Daemo的方式，这个client就有了一个Bus Name。其他应用可以根据消息中所带的Bus Name，来判断和哪个应用相关。消息在总线中传递的时候，传递到应用中，再根据objectpath，送至应用中具体的对象实例中，也就是是应用中根据Interface创建的对象。这些Interface有method和singal两种，用来发送、接收、响应消息。
一个例子的示意图：
D-Bus 消息
消息通过D-Bus在进程间传递。有四类消息：
一、Method call消息：将触发对象的一个method
二、Method return消息：触发的方法返回的结果
三、Error消息：触发的方法返回一个异常
四、Signal消息：通知，可以看作为事件消息。
一个消息有消息头header，里面有field，有一个消息体body，里面有参数arguments。消息头包含消息体的路由信息，消息体就是净荷payload。头字段可能包括发送者的bus名，目的地的bus名，方法或者signal名等等，其中一个头字段是用于描述body中的参数的类型，例如“i”标识32位整数，"ii”表示净荷为2个32为整数。
发送Method call消息的场景
一个method call消息从进程A到进程B，B将应答一个method return消息或者error消息。在每个call消息带有一个序列号，应答消息也包含同样的号码，使之可以对应起来。他们的处理过程如下：
如果提供proxy，通过触发本地一个对象的方法从而触发另一个进程的远端对象的方法。应用调用proxy的一个方法，proxy构造一个method call消息发送到远端进程。
对于底层的API，不使用proxy，应用需要自己构造method call消息。
一个method call消息包含：远端进程的bus name，方法名字，方法的参数，远端进程中object path，可选的接口名字。
method call消息发送到bus daemon
bus daemon查看目的地的bus name。如果一个进程对应这个名字，bus daemon将method call消息发送到该进程中。如果没有发现匹配，bus daemon创建一个error消息作为应答返回。
进程接收后将method call消息分拆。对于简单的底层API情况，将立即执行方法，并发送一个method reply消息给bus daemon。对于高层的API，将检查对象path，interface和method，触发一个native object的方法，并将返回值封装在一个method reply消息中。
bus daemon收到method reply消息，将其转发到原来的进程中进程查看method reply消息，获取返回值。这个响应也可以标识一个error的残生。当使用高级的捆绑，method reply消息将转换为proxy方法的返回值或者一个exception。
Bus daemon保证message的顺序，不会乱序。例如我们发送两个method call消息到同一个接受方，他们将按顺序接受。接收方并不要求一定按顺序回复。消息有一个序列号了匹配收发消息。
发送Signal的场景
signal是个广播的消息，不需要响应，接收方向daemon注册匹配的条件，包括发送方和信号名，bus守护只将信号发送给希望接受的进程。处理流程如下：
一个signal消息发送到bus daemon。
signal消息包含发布该信号的interface名字，signal的名字，进程的bus名字，以及参数。
任何进程都可以注册的匹配条件（match rules)表明它所感兴趣的signal。总线有个注册match rules列表。
bus daemon检查那些进程对该信号有兴趣，将信号消息发送到这些进程中。
收到信号的进程决定如何处理。如果使用高层的捆绑，一个porxy对象将会十分一个native的信号。如果使用底层的API，进程需要检查信号的发送发和信号的名字决定如果进行处理。
Introspection
D-Bus对象可能支持一个接口org.freedesktop.DBus.Introspectable。该接口有一个方法Introspect，不带参数，将返回一个XML string。这个XML字符串描述接口，方法，信号。
D-Bus提供两个命令dbus-monitor，可以查看bus，dbus-send命令，可以发送消息。
Signal的收发小例子
从底层，即libdbus学习如何发送signal，以及如何监听signal。signal在D-Bus的Daemon中广播，为了提高效率，只发送给向daemon注册要求该singal的对象。
对于程序，第一步需要将应用和D-Bus后台建立连接，也就是和System D-Busdaemon或者Session D-Bus daemon建立连接。一旦建立，daemon会给这条连接分配一个名字，这个名字在system或者session的生命周期是唯一的，即unique connectionname，为了方便记忆，可以为这条连接分配一个便于记忆的well-known name。对于信号方式，分配这个名字不是必须的（在method_call中是需要的），因为在信号的监听中秩序给出Interface的名字和信号名称，在下面的例子中，可以将相关的代码屏蔽掉，不影响运行，但是通常我们都这样处理，尤其在复杂的程序中。在我们的例子中，定义这个BUS name为test.singal.source。当然一个好的名字，为了避免于其他应用重复，应当使用com.mycompany.myfunction之类的名字。 ，而interface的名字，一般前面和connection的BUS name一致。
Dbus data type
dbus用xml描述接口，例如：
<?xml version="1.0" encoding="UTF-8" ?> <node name="/org/freesmartphone/GSM/Device">
<interface name="org.freesmartphone.GSM.SMS">
<method name="SendMessage">
<arg name="number" type="s"/>
<arg name="contents" type="s"/>
<arg name="featuremap" type="a{sv}"/>
<arg type="i" direction="out"/>
</method>
<signal name="IncomingMessage">
<arg name="address" type="s"/>
<arg name="contents" type="s"/>
<arg name="features" type="a{sv}"/>
</signal>
</interface>
</node>
其实前两讲已经看过很多例子了。node就是接口中的对象，node可以包含node，构成对象树。 dbus的接口描述文件统一采用utf-8编码。我相信读者很容易理解这个接口描述文件。我只想解释一下描述参数数据类型的type域。 dbus的数据类型是由"s"或"a{sv}"这样的类型签名（Type Signatures）定义的。类型签名中可以使用以下标记：
| a | ARRAY 数组 |
| b | BOOLEAN 布尔值 |
| d | DOUBLE IEEE 754双精度浮点数 |
| g | SIGNATURE 类型签名 |
| i | INT32 32位有符号整数 |
| n | INT16 16位有符号整数 |
| o | OBJECT_PATH 对象路径 |
| q | UINT16 16位无符号整数 |
| s | STRING 零结尾的UTF-8字符串 |
| t | UINT64 64位无符号整数 |
| u | UINT32 32位无符号整数 |
| v | VARIANT 可以放任意数据类型的容器，数据中包含类型信息。例如glib中的GValue。 |
| x | INT64 64位有符号整数 |
| y | BYTE 8位无符号整数 |
| () | 定义结构时使用。例如"(i(ii))" |
| {} | 定义键－值对时使用。例如"a{us}" |
a表示数组，数组元素的类型由a后面的标记决定。例如：
- "as"是字符串数组。
- 数组"a(i(ii))"的元素是一个结构。用括号将成员的类型括起来就表示结构了，结构可以嵌套。
- 数组"a{sv}"的元素是一个键－值对。"{sv}"表示键类型是字符串，值类型是VARIANT。