D-Bus usage

[Sander van Grieken]

On Thursday 28 February 2008 20:43:49 Shawn Rutledge wrote:
> On Thu, Feb 28, 2008 at 12:06 PM, Sander van Grieken <sander at 3v8.net> wrote:
> >  No. multicast can only deliver the same packet to different IP
> > addresses.
>
> Well I just tried the example code from here:
>
> http://ntrg.cs.tcd.ie/undergrad/4ba2/multicast/antony/index.html
>
> and I was able to run multiple instances of both the sender and the
> receiver on the same machine.  All the receivers got all the packets.

Ok, it seems that the receiving host network stack can duplicate 
them : "...there can be many sockets which receive IP multicast packets off a 
single local port.."

> >  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.
>
> How do you think that works then?  I figured it's analogous to the
> connection between an X program and the X display server: there is an
> abstraction that looks like a connection but it could really be either
> a socket or shared memory or maybe something else.

Between application and libdbus it could simply be a registered callback.

> > Going through
> >  the network stack is much slower than using assisted IPC (that's what
> > d-bus essentially provides).
>
> It's well-known that network sockets are slower than shared memory.
> Unix sockets are somewhere between, right?  But dbus adds overheads of
> its own.  As I understand there are two connections - one from the
> emitter to the daemon, and another from the daemon to the receiver.
> The daemon has to do some string-compares and a lookup in order to
> figure out to which of its connections the message needs to be
> dispatched.  Then the dbus library to which the receiver is linked
> would have to do some more string-compares and lookups to find the
> callback that is to be called.  Are we sure all that adds up to less
> than the cost of a multicast message with only the receiver doing
> "dispatching" in its own way to the relevant callback?  Have you seen
> a comparison of latencies somewhere?  It would be interesting...

Nope, haven't seen comparisons, but string compares are low cost and hashing 
can make lookups fast (faster than O(n) anyway)

> >  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.
>
> Well that's a big undertaking.  DBus seems to have been created to
> replace Corba.  (At least Gnome used to use Corba and now they use
> DBus.)  When things like that happen I wonder whether the reasons were
> mostly technical or psychological (too many steps and too many things
> to understand when you need to write Corba code).

Corba adds way too much overhead if you stay within the same machine, but for 
remote calls it's somewhat suitable (although there are many alternatives to 
explore). Corba isn;t ideal, given the work that needs to be done by the 
programmer, and all the incompatibilities between corba implementations. 

Maybe dbus could use some marshalling solution to connect the dbus transport 
channel between hosts, so you won't need to add network tranparency to each 
service/interface separately?

> >  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.
>
> So if a service has registered a method with all possible names (the
> service name, the interface, the path and the method name) how many of
> those are necessary to uniquely identify the method, actually call it
> and get a response?

identifying and calling isn't the problem. It's more about finding out the 
capabilities of the service you want to call.

For instance, there is a caption() method on a KApplication interface, but 
there could also be caption() methods on other interfaces (e.g. child 
windows). The method signatures are the same, but the interface is different.

Also, when logging out, the session manager just has to enumerate all 
KApplication interfaces and call quit() on them, without triggering quit() 
methods on non-KApplication  quit() methods.