dbus(dbus-daemon)

如何高效的利用dbus做client-server架構

  //如果要傳回資料到client側，假設處理過的資料為：your_strcut_tdealed_with_data　　g_array_append_vals(*output_garray,&dealed_with_data,sizeof(your_strcut_t));　　returnTRUE;//一定要傳回TRUE,否則client側收不到資料的；}　　上述通用步驟中，1，2在今後的擴充中，是不要要改的，尤其是第一步，dbus的xml接口描述非常　　麻煩；如果為每個API自己去定義xml接口描述，搞不好，client和server之間不通；而且，一段時間　　後，不看dbus的文檔，就會忘記如何寫其xml接口；是以做個通用的xml接口描述很省事；　　3,4是client/server側的各自實作，結構是釘死的，不用改多少；一個函數如此，N個函數也是這樣；　　如果你有30個函數，要分别實作它們嗎？不必要，隻要給各自的函數定義其ID就行；　　在client/server側的函數裡面搞個switch-case結構就分開了；　　架構定好了，傳遞資料也非常友善，比dbus自己的dbus_g_type_struct_set效率高的多，目前開源軟體　　多用dbus_g_type_struct_set，效率很低，對于傳遞批量資料，效率很低；　　如果大家對于如何提高dbus傳遞消息/資料的效率，有什麼更好的看法，歡迎交流。

為什麼要用dbus,如果不用dbus要用什麼來代替？

目前dbus 生态系統建構得還是比較廣泛的，已經被 kernel 吸收, gtk 和 qt 也封裝出high-level的架構。dbus 是 low-level 的消息機制，可以基于dbus 定制開發出自己的 event system. dbus 的性能和具體的技術架構還沒有弄清楚(想着也是epoll/poll/select 的reactor)。由 dbus-daemon 為中心化的 C-S ，兼有route，device manager等作用。覺得 dbus 主要的優勢在于 接口化(idl / xml)。

dbus 最底層無非是 八種 IPC 組合(pipe, socket, msgqueue, sharebuffer,...) ，是以替換dbus 從底層就是socket。如果想使用類似的機制，有各種 msgqueue(zeromq, Java 裡的 ActiveMQ, Appach 的 RabbitMQ), 類似的消息中間件還有 Kafka(Scala)， libevent, libev, libuv(Node.js)。

各有各的特性，可以根據自己的需求選用。

目前移植 boost 的時候遇到了 asio ，好像和 reactor 架構不一樣的一種架構。也可以參考。你好！

為什麼資料總線DBUS(或者其它任何總線)在任一時刻，最多隻能有一個資料源向它輸出？