On Thursday 28 February 2008 19:06:44 Shawn Rutledge wrote: > On Thu, Feb 28, 2008 at 5:38 AM, Tilman Baumann <[EMAIL PROTECTED]> wrote: > > Shawn Rutledge wrote: > > > On Wed, Feb 27, 2008 at 10:46 AM, Tilman Baumann <[EMAIL PROTECTED]> 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.
