我正在写一个服务器（在C中），它服务于不同的机器。我想通过互联网使用D-Bus进行远程过程调用，但我听说D-Bus不能用于很多机器，而是用于一台机器。是对的吗？我可以在这种情况下使用D-Bus吗？
答案 0 :(得分：7)
简短的回答是肯定的，这是可能的; dbus可以在不同的机器上使用（但请参阅下面的安全警告）。
在您的服务器上，dbus-daemon配置文件（您可能只想为您的服务设置整个其他总线而不是重用系统或会话总线）需要配置为通过TCP接受连接而不是仅通过/tmp中的本地套接字。设置适当的listen commands in dbus-daemon有一些技巧，有充分的文件记录。
此外，如果您无法修改本地dbus-daemon（或者您被迫使用与RHEL一起分发的旧的，破坏版本的dbus-daemon，它不会在远程套接字上侦听），您可以运行一个名为dbus-daemon-proxy将侦听套接字并转发到本地dbus-daemon的连接。
无论哪种方式，在客户端计算机上，您都需要设置 DBUS_SESSION_BUS_ADDRESS 变量，以获得dbus-daemon或代理服务器正在侦听的IP地址和端口。
安全警告：线路上没有数据加密，dbus访问机制仅适用于本地连接，而不适用于TCP连接。要正确保护使用TCP传输机制的dbus连接，您将面临一些工作。
答案 1 :(得分：0)
即使您最终没有使用完整的D-Bus总线（如dbus-daemon）进行多台机器之间的通信，一个有趣的中途步骤是使用D-Bus线路协议进行串行化消息，然后实现自己的总线仲裁器和拓扑。
这意味着您不必重新发布有线协议（包含所有潜在的解析器错误和漏洞），但可以保留一些灵活性，而不是高级系统拓扑和传输;例如，可能与单独的现有身份验证系统集成。
最简单的方法是使用GLib中的GDBusMessage或GVariant API，使用g_dbus_message_to_blob()或g_variant_get_data()进行序列化。 不使用libdbus，因为它太低级了，并且使用过时的API设计，这些设计比GLib更现代的API更难以正确使用。同样，不要使用dbus-glib，因为它的设计也很笨拙和过时。
答案 2 :(得分：-1)
我无法确定dbus-daemon的实现，但是从以下场景的有线协议的角度来看：
1）您希望机器A和B交换消息，它们都可以通过tcp连接到服务器C上的dbus总线守护程序。对于C，它们只是由连接名称标识的“连接” - 作为{{1}的结果}或org.freedesktop.DBus.Hello - 请参阅“message bus names”
2）机器A连接到机器B并使用点对点（无消息总线）模式来交换消息。