D-Bus入门（序）——d-bus官方介绍

目录(?)[+]

序 网上摘录 

        D-Bus实质上一个适用于桌面应用的进程间的通讯机制，即所谓的IPC（inter-processcommunication）机制。它最初产生于Linux平台，是做为freedesktop.org项目的一部分来开发的。现在已经深入地渗透到Linux 桌面之中。在Qt4，GNOME，Windows以及Maemo中都已实现。在KDE4中已经取代了著名的DCOP，在GNOME取代笨重的Bonobo。在嵌入式系统中常用来实现C/S结构。

        目前有很多IPC（interprocess communication），用于不同的解决方案：CORBA是用于面向对象编程中复杂的IPC的一个强大的解决方案。DCOP 是一个较轻量级的IPC 框架，功能较少，但是可以很好地集成到K 桌面环境中。SOAP 和 XML-RPC 设计用于 Web 服务，因而使用HTTP 作为其传输协议。D-Bus设计用于桌面应用程序和OS通信。D-Bus(D原先是代表桌面“Desktop” 的意思)，即用于桌面操作系统的通信总线。现在逐渐被引入到嵌入式系统中，只是名字还保留原先的叫法而已。

        典型的桌面都会有多个应用程序在运行，而且，它们经常需要彼此进行通信。DCOP 是一个用于KDE 的解决方案，但是它依赖于 Qt，所以不能用于其他桌面环境之中。类似的，Bonobo 是一个用于GNOME 的解决方案，但是非常笨重，因为它是基于 CORBA 的。它还依赖于 GObject，所以也不能用于GNOME之外。D-Bus的目标是将DCOP 和 Bonobo 替换为简单的 IPC，并集成这两种桌面环境。由于尽可能地减少了D-Bus所需的依赖，所以其他可能会使用D-Bus的应用程序不用担心引入过多依赖。相对于其它的IPC,D-Bus丢掉了一些不必要的、复杂的东西，也正是因为这个原因，D-Bus比较快、简单。D-Bus不和低层的IPC直接竞争，比如sockets, shared memory or messagequeues.这些低层点的IPC有它们自己的特点，和D-Bus并不冲突。

点击链接查看网络介绍，一下是本人的翻译，基本不用看了。

一概述-DBUS官方文档

README

d-bus是一个简洁的进程间通讯和协调的一套系统。

d-bus的协调能力是dbus的一个特色，它提供了一个守护进程用于：
 通知某程序，其它程序已经退出;
 根据需求启动服务;
 支持single-instance程序;

libdbus是D-bus的一个核心概念，它属于low-level API的部分。大多程序员会使用类似于Glib，Qt，Python，等上实现的接口。这些接口有不同的完成程度，与main D-bus包分开维护。main D-bus 包包含了low-level libdbus，bus daemon，以及一些command-line工具（比如d-bus launch）。

dbus-specification.html

dbus是一个低延迟，低开销简单易用的IPC机制。低延迟是由于它被设计成避免round trips并且允许异步操作。低开销是因为它使用二进制协议，而不需要转换成XML之类的text格式，dbus被设计成本机通讯，这是一个有趣的优化。dbus很易用，因为它是基于消息的。

dbus的核心协议是一个one-to-one协议（peer-to-peer或者client-server）。它是一个单程序与单程序通信的机制。

dbus可以用于系统硬件改变，桌面交互，

dbus-tutorial.html

What is D-Bus?

d-bus是一个进程见通信机制，从结构上分，它可以分为这么几层：
  libdbus
  messages bus daemon
  wrapper  或者 bindings
libdbus只支持one-to-one

bus daemon支持接受消息，并在合适的时候传递给合适的程序

within-desktop-session: 继承GNOME和KDE 的IPC解决方案的经验，保持了它们的特色。

在系统层和与OS通信：解决hotplug通知事件

异步的二进制协议

稳定可靠

消息总线是一个守护进程

规定实现方法

二 工作方式-网络资源

D-BUS 的内部工作方式

 D-BUS 设置将由几个总线构成。将有一个持久的 系统总线（system bus），它在引导时就会启动。这个总线由操作系统和后台进程使用，安全性非常好，以使得任意的应用程序不能欺骗系统事件。还将有很多会话总线（session buses），这些总线当用户登录后启动，属于那个用户私有。它是用户的应用程序用来通信的一个会话总线。当然，如果一个应用程序需要接收来自系统总线的消息，它不如直接连接到系统总线 —— 不过，它可以发送的消息将是受限的。

一旦应用程序连接到了一个总线，它们就必须通过添加 匹配器（matchers） 来声明它们希望收到哪种消息。匹配器为可以基于接口、对象路径和方法进行接收的消息指定一组规则（见后）。这样就使得应用程序可以集中精力去处理它们想处理的内容，以实现消息的高效路由，并保持总线上消息的预期数量，以使得不会因为这些消息导致所有应用程序的性能下降并变得很慢。

DBus有两种API接口，一种是直接使用DBUS的 low-levelAPI，一种是使用Binding，Bindings有不同的类型，有PERL Binding、PYTHON Binding、GLIBBinding等。这里主要关注使用GLIB binding。和low-level API不同的是，GLIB binding则能够完成GLIBOBJECT的本地事件（native signal）与DBus事件的绑定

用例

尽管 D-BUS 相对较新，但是却迅速地得到了采用。如前所述，可以构建具有 D-BUS 支持的 udev 以使得当热插拔（hot-plug）设备时它可以发送一个信号。任何应用程序都可以侦听这些事件并当接收到这些事件时执行动作。例如，gnome-volume-manager可以检测到 USB 存储棒的插入并自动挂载它；或者，当插入一个数码相机时它可以自动下载照片。

一个更为有趣但很不实用的例子是 Jamboree 和 Ringaling 的结合。Jamboree 是一个简单的音乐播放器，它具有 D-BUS 接口，以使得它可以被告知播放、到下一首歌、改变音量等等。Ringaling 是一个小程序，它打开 /dev/ttyS0（一个串行端口）并观察接收到的内容。当 Ringaling 发现文本“RING”时，就通过D-BUS 告知 Jamboree 减小音量。最终的结果是，如果您的计算机上插入了一个调制解调器，而且电话铃响，则音乐音量就会为您减小。这正是计算机所追求的!

三实例讲解 d-bus基础概念-网络资源

最后我们看这篇文章

http://blog.csdn.net/fmddlmyy/article/details/3585730

Bus Name

可以把Bus Name理解为连接的名称，一个Bus Name总是代表一个应用和消息总线的连接。有两种作用不同的Bus Name，一个叫公共名（well-known names），还有一个叫唯一名（Unique Connection Name）。

公共名是由一些圆点分隔的多个小写标志符组成的，例如“org.fmddlmyy.Test”、“org.bluez”。

当应用连接到消息总线时，消息总线会给每个应用分配一个唯一名。唯一名以“:”开头，“:”后面通常是圆点分隔的两个数字，例如“:1.0”。

有的连接只有唯一名，没有公众名。可以把这些名称称为私有连接，因为它们没有提供可以通过公共名访问的服务。 d-feet界面上有个“Hide Private”按钮，可以用来隐藏私有连接。

Object Paths

Bus Name确定了一个应用到消息总线的连接。在一个应用中可以有多个提供服务的对象。这些对象按照树状结构组织起来。每个对象都有一个唯一的路径（Object Paths）。或者说，在一个应用中，一个对象路径标志着一个唯一的对象。

Interfaces

Methods和Signals

接口包括方法和信号。

标准接口“org.freedesktop.DBus.Introspectable”的Introspect方法是个很有用的方法。类似于Java的反射接口，调用Introspect方法可以返回接口的xml描述。直接点击“Execute”按钮。

小结

客户端的C代码时，我们会看到同样的过程：用dbus_g_bus_get得到到session bus的连接。在这个连接上用dbus_g_proxy_new_for_name函数获得到拥有指定公共名的连接的指定对象的指定接口的代理。最后，用dbus_g_proxy_call函数通过接口代理调用接口提供的方法。