hp at redhat.com
Thu Dec 21 09:43:16 PST 2006
Pallavi Rao wrote:
> 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