D-Bus usage

Shawn Rutledge shawn.t.rutledge at gmail.com
Thu Feb 28 19:06:44 CET 2008

On Thu, Feb 28, 2008 at 5:38 AM, Tilman Baumann <tilman at baumann.name> wrote:
> Shawn Rutledge wrote:
>  > On Wed, Feb 27, 2008 at 10:46 AM, Tilman Baumann <tilman at baumann.name> wrote:
>  >> First, im not in any way a authority on this.
>  >>  But i would say classic IPC is everything but d-bus.
>  >
>  > Well it's not old enough to be classic yet.  :-)
>  >
>  > But I'm curious, what do you dislike about using it for IPC?  (I'm
>  > just learning how to use it.)
>  >
>  Foremost Performance.
>  D-Bus is a abused unix domain socket interface for broadcasts and multicast.

Once I was messing with broadcast IP packets (I wrote a network
caller-ID notifier and client program) and the trouble was that only
one listener could be registered on a machine's broadcast address, so
it can really be used only from one process on one machine to one
process on another.  But for multicast, multiple processes can listen
on the same IP address and port, right?  So isn't it true that
multicast UDP packets could be used both for between-process
notifications on the same machine, and also across a network?  Why
wouldn't DBus have been based on that, rather than each process
needing to keep a connection open to the bus daemon?  I think
processes should use DNS-SD to discover each other (discover services
that other processes are providing), use multicast for one-to-many
notifications, and use direct IPC of some sort in cases when that is
appropriate.  DBus could simply have been a library to facilitate all
of that.  Unless I'm missing something that would make it

DBus is not usually used for between-machine communication, right?  So
I figured the conclusion is that it doesn't scale well.  Maybe in a
few years we'll all be running grid-style supercomputers (integrated
into a single box though), so the "desktop" will be spread across
multiple processors on some kind of network or inter-processor bus
rather than being limited to SMP.  (The reason would be to increase
the total memory bandwidth by giving each core its own memory rather
than having a chance of contention.)  Then actual multicast will be
more important.  Will DBus evolve to support that, or will it become

>  IPC is usually somethig the OS provides you at a basic level. Signals,
>  semaphores and of course shared memory...


It also seems to me that DBus has more namespace qualifiers than you
need: service, interface, path, and method-name.  I think I understand
the inspiration behind all of those, but I believe path and
method-name would have been enough.  It's more string
parsing/comparing work for the daemon to qualify incoming packets on
the basis of 4 things rather than just 2.  It would be a nice clean
conceptual model to say that there is simply a tree of callbacks, and
you need to provide the path to the node of the tree that you want.
But "interface" seems thrown in as an afterthought, inspired by Java;
and both interface and service resemble reverse-domain-names.  But a
domain name addresses a specific machine; an interface or a service is
just an arbitrary namespace division.  A "bus" is represented by a
running instance of the daemon, so the tree of registered callbacks is
all in one place, and the path and method name would be enough
information to find one callback.

Now if DBus provided network IPC, then I could see a use for the
"service" name: it would be registered via DNS-SD for example, so that
one machine can discover services on another.  The "service" would
have a use: it is the thing which is advertised, and after you have
connected to that service on a particular machine then you still need
to provide the path and method name.  But DBus doesn't do anything
like that, does it?

More information about the openmoko-devel mailing list