[版权声明:可以任意转载,转载时请务必以超链接形式标明文章原始出处和作者信息]
本文以一个实作为例, 介绍D-Bus在QT4下的绑定。在实作中,我们会在Session Bus上注册一个Hotel Service,通过这个Service,可以实现check in,check out以及query的动作。
为避免歧义,本文对D-Bus中的一些关键术语的表述依然采用英文。这些术语包括:D-Bus, IPC, Message, Message Bus, System Bus, Session Bus, Service, Object, Method, Signal, Interface, Unique Connection Name, Well-known Name等。
本文的源代码可以从这里下载:
|
文件: | hotel.tar.bz2 |
大小: | 4KB |
下载: | 下载 |
|
D-Bus概述
什么是D-Bus?
D-Bus是一种进程间通信的机制,它被设计成为一种低开销、低延迟的IPC,并被多种桌面环境(如KDE、GNOME等)所采用。
关于D-Bus的详细介绍可以参考freedesktop.org提供的两份文档, 和 。
基本概念
D-Bus提供了多种Message Bus用于应用程序之间的通信。通常,Linux发行版都会提供两种Message Bus:System Bus和Session Bus。System Bus 主要用于内核和一些系统全局的service之间通信;Session Bus 主要用于桌面应用程序之间的通信。
D-Bus中用于通信的基本单元叫做Message,Message的具体格式可以参考 。
当应用程序连接到M essage Bus上时,D-Bus会分配一个unique connection name,这个unique name通常的格式如":34-907"。Unique name以":"开头,后面的数字没有特别的意义,只是为了保证这个unique name的唯一性。
另外,应用程序还可以向Message Bus请求一个well-known name,格式如同一个反置的域名,例如"com.mycompany.myapp"。当一个应用程序连接到Message Bus上时,可以拥有两种名称:unique connection name和well-known name。这两种名称的关系可以理解为网络上的IP地址和域名的关系。
在D-Bus规范里,unique connection name和well-known name都叫做Bus Name。这点比较奇怪,也比较拗口,Bus Name并不是Message Bus的名称,而是应用程序和Message Bus之间的连接的名称。
应用程序和Message Bus之间的连接也被称为Service,这样一来,把Bus Name称作Service Name在概念上会更清晰一点。
当应用程序连接到Message Bus上时,该应用程序可以在Bus上创建一到多个Object(我们可以把D-Bus的object理解成面向对象语言里的object)。Service通过Object 为其他应用程序提供访问接口。因为在Message Bus上,一个应用程序可以对应多个Object,所以不同的Object必须由Object Path(类似于文件系统的路径)来区分。Object Path的格式如"/foo/bar"。
对于Service Name和Object Path,QT4文档中有一个类比还是比较直观的,如下图所示: