shawn.t.rutledge at gmail.com
Thu Feb 28 20:43:49 CET 2008
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:
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.
> 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.
> 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...
> 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).
> 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?
More information about the openmoko-devel