On Thu, Feb 28, 2008 at 12:06 PM, Sander van Grieken <[EMAIL PROTECTED]> 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. > 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?
