前面一篇講了DBus的 C 編程接口。現在開始解釋一下 DBus 的基本概念，順序反了，但和我的理解過程是一致的。看到 C 的編程接口之後，至少對於它的理解會有一定的感性認識。
DBus是用來進行進程間通信的。下面這張圖展示了一些DBus的大部分東西，但是它太複雜了：
DBus 本身是構建在 Socket 機制之上。真正的通信還是由 Socket 來完成的。DBus 則是在這之上，制定了一些通信的協議，並提供了更高一層的接口，以更方便應用程序之間進行數據的交互。
在DBus的體系中，有一個常駐的進程 Daemon，所有進程間的交互都通過它來進行分發和管理。所有希望使用 DBus 進行通信的進程，都必須事先連上 Daemon，並將自己的名字註冊到 Daemon 上，之後，Daemon會根據需要把消息以及數據發到相應的進程中。
首先使用
conn = dbus_bus_get(DBUS_BUS_SESSION, &err);ret = dbus_bus_request_name(conn, "test.method.server",
DBUS_NAME_FLAG_REPLACE_EXISTING
, &err);將自己的進程名字註冊到 Daemon 上。（參考前篇的[共通用代碼]）。這樣通信就有了基礎了。
DBus 提供的最簡單的一種通信方式是信號（Signal），應用程序可以發送一個信號到 Daemon 上，之後，Daemon 會根據信號的種類和誰希望得到信號等信息，把相應的數據發給每個希望得到信號的進程。也就是 Signal 具有廣播的功能。信號具有兩個基本的屬性，一個是名稱，用來標識各個不同的信號，一個是數據，信號是可以帶一定的數據的。Signal 的通信過程可以用下面的圖大概展示出來：
如果一個進程（比如 B ）想接收接口名爲 test.signal.Type 的信號，那麼可以使用下面的函數向
Daemon 添加匹配信號，讓 Daemon 知道自己對這種信號感興趣。
// add a rule for which messages we want to see
dbus_bus_add_match(conn,
"type='signal',interface='test.signal.Type'",
&err); // see signals from the given interface
然後，
進程 B 可以使用下面的函數來進行等待：
dbus_connection_read_write(conn, 0);
msg = dbus_connection_pop_message(conn);一旦有消息發送過來，進程 B 就可以通過 msg 取到相應的數據了。（參考前篇代碼段[接收消息1、2] ）
現在有一個進程 A，
dbus_uint32_t serial = 0; // unique number to associate replies with requests
DBusMessage* msg;
// create a signal and check for errors
msg = dbus_message_new_signal("/test/signal/Object", // object name of the signal
"test.signal.Type", // interface name of the signal
"Test"); // name of the signal
// append arguments onto signal
dbus_message_iter_init_append(msg, &args);
if (!dbus_message_iter_append_basic(&args, DBUS_TYPE_STRING, &sigvalue)) {
fprintf(stderr, "Out Of Memory!\n");
exit(1);
}
// send the message and flush the connection
if (!dbus_connection_send(conn, msg, &serial)) {
fprintf(stderr, "Out Of Memory!\n");
exit(1);
}
到這裏爲止，已經涉及到了幾個基本而又核心的概念，搞清楚它們，幾乎就大概知道了 DBus 的使用方法了。
DBusMessage 是 DBus 中的核心數據結構。可以這樣理解：DBus中傳遞消息數據的時候，就是通過它來傳遞的。對於使用者來說，DBusMessage 中存儲了兩種重要的信息，一種是爲通信機制服務的各種 Name，一種是通信的數據本身。
各種名字（Name）
在前面用到的很多接口中都還有名稱/路徑字符串作爲參數。
DBus Name： 在 DBus 中最爲重要的名字是“Bus Name”，Bus Name 是一個每個應用程序（或是通信對象）用來標識自己用的。幾乎可以當成是“IP”地址來理解。Bus Name有兩種，一種是“Unique Connection Name”，是以冒號開頭的，是全局唯一但“人類不友好”的命名，一種是“Well-know Name”，人類友好的。Bus Name 的命名規則是：
- Bus name 就像網址一樣，由“.”號分割的多個子字符串組成，每個子字符串都必須至少有一個以上的字符。
- 每個子字符串都只能由“[A-Z][a-z][0-9]_-”這些 ASCII 字符組成，只有 Unique Name 的子串可以以數字開頭。
- 每個 Bus name 至少要有一個“.”，和兩個子字符串，不能以“.”開頭
- Bus name 不能超過 255 個字符
幾個例子是：Unique Name :392-2.33 org.freedesktop.DBus 等等
DBus Name 是用來給應用程序進行標識自己的，所以每當程序連上 DBus Daemon 後，就會分配到一個 Unique Name，同時應用程序還可以要求自己分配另一個 Well-know name （通過 dbus_bus_request_name 函數）。
Interface name： DBus 也有 interface 這個概念，主要是用來爲更高一層的框架使用方面而設定的。在 C API 這一層，你幾乎可以無視這個概念，只需要知道這個一個“字符串”，並在消息匹配是被 DBus 使用到，會隨着消息在不同的進程之前傳遞，從進程 A 發送一個消息或是數據到進程 B 時，其中必定會帶有一個部分就是這個字符串，至於 B 進程怎麼用（或是無視它）都可以。它的命名規則與 DBus Name 幾乎是一樣的，只有一點要注意，interface name 中不能帶有“-”字符。
Object path：DBus 中的 object path，與 interface 一樣，也只是個概念在更高一層的框架（QT Dbus）中才比較有用，在 C API 這一層，幾乎可以無視這個概念，把它當成一個普通的字符串，根據通信的需要，用來做一種標識和區分。Object path 的命名規則是：/com/example/MusicPlayer1
- object path 可以是任意長度的
- 以'/'開頭，並以以'/'分隔的若干子字符串組成
- 每個子串必須由“[A-Z][a-z][0-9]_”中的字符組成
- 不能有空子串（也就是不能連續兩個'/'符）
- 除了“root path”（'/'）之外，不能再有 object path 是以 '/' 結尾的了。
一個 object path 的例子：/com/example/MusicPlayer1
Member name：Member 包含兩種類型，一種是 Signal，一種是 Method。在大多數方面，他們幾乎是一樣的，除了兩點：1. Signal是在總線中進行廣播的，而Method是指定發給某個進程的。2. Signal 不會有返回，而 Method 一定會有返回（同步的或是異步的）。Member name的命名規則是這樣的：
- 只能包含"[A-Z][a-z][0-9]_"這些字符，且不能以數字開頭。不能包含“.”。
- 不能超過255個字符
以 C API 的層面來看，Member name最大的作用就是在兩個進程間共享“發出的消息的類型信息”。DBus 只能以 Signal / Method 來進行消息通信，這兩種方式都允許在消息發出之前，在消息中 append 各種類型的數據，當通信的對方收到消息後，它就可以通過 Signal / Method 的名稱知道如何把各種數據再解析出來。
到現在爲止，已經介紹了三種最爲重要的 Name，如果與的熟悉 windows 消息機制對比的話，我大概覺得，DBus Name 就是進程的 ID，有了這個你才能把消息發給指定的進程，object path ，interface等概念在“（QT等）高層框架中才有意義”，C API 級別的使用的話，可以無視它的概念，當成消息甄別用的信息就好了。 Member name 相當於 Message type，有了它你才知道怎麼去解析發過來的數據。
下篇將會記錄 DBusMessage 另一個主要的組成部分：通信數據。
轉自博客園唐風：http://www.cnblogs.com/muxue/archive/2012/12/06/2806305.html