Connection Sequence

Havoc Pennington hp at
Thu Dec 21 09:43:16 PST 2006

Pallavi Rao wrote:
> Hello,
> Please tell me if the communication sequence is still
> exactly like this:
> - app copies into DBusMessage
> - libdbus copies DBusMessage to the socket
> - bus daemon copies from socket to a DBusMessage
> - then from DBusMessage into another socket
> - other app copies from socket to DBusMessage

Yes, that sounds right.

> Also, what is the difference in the functionality of
> libdbus and the dbus-daemon. As far as I know, daemon
> is the running instance of libdbus, which other
> applications use. Is this correct?

dbus-daemon is a daemon that routes DBusMessage between applications. It 
uses libdbus to do so.

> Is it possible to have a communication between just 2
> applications on a computer, without having to look for
>  the session or system bus(in which case, there should
> be one more dbus running, which is neither a kind of
> session bus nor system, rather just my own dbus).

Yes. The dbus docs point this out several times, so they might be a good 
place to start... e.g. in the dbus tutorial there is mention of this.

> Am I right in saying that the dbus-connections are
> wrapped around unix domain or TCP/IP sockets.


> How far
> is the implementation of dbus for
> internet/multiple-machine stuff(considering second
> point in the Introduction in DBus-Specification).

TCP/IP works fine, but the only supported authentication for TCP/IP is 
to read a magic cookie file from a user's home directory (the home 
directory must be shared between both ends of the connection). So if you 
don't use NFS-mounted home directories, the TCP/IP support is not useful.

If you added support for something like Kerberos or another mechanism 
then you could use the TCP/IP support without the shared home directory.


More information about the dbus mailing list