DBus 入門與應用－－基本概念 上（C API 層級的使用觀點）

轉載請註明出處。               作者： 唐風

前面一篇講了DBus的 C 編程介面。現在開始解釋一下 DBus 的基本概念，順序反了，但和我的理解過程是一致的。看到 C 的編程介面之後，至少對於它的理解會有一定的感性認識。

DBus是用來進行處理序間通訊的。下面這張圖展示了一些DBus的大部分東西，但是它太複雜了：

DBus 本身是構建在 Socket 機制之上。真正的通訊還是由 Socket 來完成的。DBus 則是在這之上，制定了一些通訊的協議，並提供了更高一層的介面，以更方便應用程式之間進行資料的互動。

在DBus的體系中，有一個常駐的進程 Daemon，所有進程間的互動都通過它來進行分發和管理。所有希望使用 DBus 進行通訊的進程，都必須事先連上 Daemon，並將自己的名字註冊到 Daemon 上，之後，Daemon會根據需要把訊息以及資料發到相應的進程中。

首先使用

1. conn = dbus_bus_get(DBUS_BUS_SESSION, &err);

讓應用程式和 DBus 之間取得串連。之後，使用函數

1. ret = dbus_bus_request_name(conn, "test.method.server",
2.                             DBUS_NAME_FLAG_REPLACE_EXISTING
3.                             , &err);

將自己的進程名字註冊到 Daemon 上。（參考前篇的[共通用代碼]）。這樣通訊就有了基礎了。

DBus 提供的最簡單的一種通訊方式是訊號（Signal），應用程式可以發送一個訊號到 Daemon 上，之後，Daemon 會根據訊號的種類和誰希望得到訊號等資訊，把相應的資料發給每個希望得到訊號的進程。也就是 Signal 具有廣播的功能。訊號具有兩個基本的屬性，一個是名稱，用來標識各個不同的訊號，一個是資料，訊號是可以帶一定的資料的。Signal 的通訊過程可以用下面的圖大概展示出來：

如果一個進程（比如 B ）想接收介面名為 test.signal.Type 的訊號，那麼可以使用下面的函數向 Daemon 添加匹配訊號，讓 Daemon 知道自己對這種訊號感興趣。

1. // add a rule for which messages we want to see
2. dbus_bus_add_match(conn,
3.                    "type='signal',interface='test.signal.Type'",
4.                    &err); // see signals from the given interface

然後， 進程 B 可以使用下面的函數來進行等待：

1. dbus_connection_read_write(conn, 0);
2. msg = dbus_connection_pop_message(conn);

一旦有訊息發送過來，進程 B 就可以通過 msg 取到相應的資料了。（參考前篇程式碼片段[接收訊息1、2] ）

現在有一個進程 A，

1. dbus_uint32_t serial = 0; // unique number to associate replies with requests
2. DBusMessage* msg;
3.  
4. // create a signal and check for errors
5. msg = dbus_message_new_signal("/test/signal/Object", // object name of the signal
6.                               "test.signal.Type", // interface name of the signal
7.                               "Test"); // name of the signal
8.  
9. // append arguments onto signal
10. dbus_message_iter_init_append(msg, &args);
11. if (!dbus_message_iter_append_basic(&args, DBUS_TYPE_STRING, &sigvalue)) {
12.     fprintf(stderr, "Out Of Memory!\n");
13.     exit(1);
14. }
15.  
16. // send the message and flush the connection
17. if (!dbus_connection_send(conn, msg, &serial)) {
18.     fprintf(stderr, "Out Of Memory!\n");
19.     exit(1);
20. }

到這裡為止，已經涉及到了幾個基本而又核心的概念，搞清楚它們，幾乎就大概知道了 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 的命名規則是：

1. Bus name 就像網址一樣，由“.”號分割的多個子字串組成，每個子字串都必須至少有一個以上的字元。
2. 每個子字串都只能由“[A-Z][a-z][0-9]_-”這些 ASCII 字元組成，只有 Unique Name 的子串可以以數字開頭。
3. 每個 Bus name 至少要有一個“.”，和兩個子字串，不能以“.”開頭
4. 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

1. object path 可以是任意長度的
2. 以'/'開頭，並以以'/'分隔的若干子字串組成
3. 每個子串必須由“[A-Z][a-z][0-9]_”中的字元組成
4. 不能有空子串（也就是不能連續兩個'/'符）
5. 除了“root path”（'/'）之外，不能再有 object path 是以 '/' 結尾的了。

一個 object path 的例子：/com/example/MusicPlayer1

Member name：Member 包含兩種類型，一種是 Signal，一種是 Method。在大多數方面，他們幾乎是一樣的，除了兩點：1. Signal是在匯流排中進行廣播的，而Method是指定發給某個進程的。2. Signal 不會有返回，而 Method 一定會有返回（同步的或是非同步）。Member name的命名規則是這樣的：

1. 只能包含"[A-Z][a-z][0-9]_"這些字元，且不能以數字開頭。不能包含“.”。
2. 不能超過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 另一個主要的組成部分：通訊資料。