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(或者其它任何总线)在任一时刻，最多只能有一个数据源向它输出？