D-Bus usage

[Sander van Grieken]

On Thursday 28 February 2008 19:06:44 Shawn Rutledge wrote:
> 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?  

No. multicast can only deliver the same packet to different IP addresses.

> 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?

Maybe I don't know dbus well enough, but it seems to me that a process merely 
registers a session with dbus, not keeping a connection open. Going through 
the network stack is much slower than using assisted IPC (that's what d-bus 
essentially provides).

> DBus is not usually used for between-machine communication, right?  So
> I figured the conclusion is that it doesn't scale well.

You could always use corba for that. It would be just a matter of writing an 
IDL for the particular object you want to expose.

> 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.  

Well not really, since a service could conform to multiple interfaces. It 
enables applications to call a service, even if it doesn't know the actual 
service, but only one of its interfaces.