dbus(dbus-daemon)

悠悠 2023-09-26 12:24 57阅读 0赞

## 如何高效的利用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-daemon)\_dbus(dbus-daemon)][dbus_dbus-daemon_dbus_dbus-daemon]

## 为什么要用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 架构不一样的一种架构。也可以参考。你好！

socket 。之所以用DBus,因为DBUS说：哥传递的不是数据，而是方法。

我的回答你还满意吗~~

## 为什么数据总线DBUS(或者其它任何总线)在任一时刻，最多只能有一个数据源向它输出？ ##

总线数据是点对点通讯，只是挂的设备在一条线上。线上的数据只能是单个单个的来支持一下感觉挺不错的

[dbus_dbus-daemon_dbus_dbus-daemon]: https://img2.baidu.com/it/u=1595337384,3250608944&fm=26&fmt=auto