Introducing the concept of 'DBus domains'

Alban Crequy alban.crequy at
Thu Jul 15 11:48:24 PDT 2010

Le Thu, 15 Jul 2010 02:52:28 +0200,
Kybernetik Kollektiv <kybernetikkollektiv at> a écrit :

> Two points
> of the design of DBus caused me the most headache: 1) An Object
> connected to the DBus message bus is under no circumstances allowed to
> spoof _all_ messages transported over the bus.

An application can spy all messages on the bus, this is what
dbus-monitor and Bustle does.

dbus_bus_add_match() in libdbus registers an arbitrary match rule to
dbus-daemon. Then, unless the configuration of your bus
in /etc/dbus-1/{session,system}.conf doesn't allow eavesdropping, you
will receive _all_ messages. dbus-monitor and Bustle use that to
receive all D-Bus method calls, returns, signals and errors.

> 2) Each application
> can only hold exactly one connection to the message bus at one time. I
> mean, from the DBus designer's point of view, this is absolutely
> alright, but building a 'dbus network router/proxy' with these
> limitations makes things unnessary complex. The easiest way, in my
> oppinion, would be to add an interface to the DBus message bus daemon
> that external routing/proxy mechanisms can use to easily/fast access
> the bus and then do the major work of connecting different 'dbus
> domains' themselves.

An application can have several connections (several sockets) to the
bus. Each connection will have one unique name and can request several
well-known names.

The thread "Remote DBus" on this mailing list some months ago has links
to do dbus on network: Telepathy Tubes, Gabriel, and dbus-daemon-proxy:


More information about the dbus mailing list