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? 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? I think processes should use DNS-SD to discover each other (discover services that other processes are providing), use multicast for one-to-many notifications, and use direct IPC of some sort in cases when that is appropriate. DBus could simply have been a library to facilitate all of that. Unless I'm missing something that would make it impossible... DBus is not usually used for between-machine communication, right? So I figured the conclusion is that it doesn't scale well. Maybe in a few years we'll all be running grid-style supercomputers (integrated into a single box though), so the "desktop" will be spread across multiple processors on some kind of network or inter-processor bus rather than being limited to SMP. (The reason would be to increase the total memory bandwidth by giving each core its own memory rather than having a chance of contention.) Then actual multicast will be more important. Will DBus evolve to support that, or will it become obsolete? > IPC is usually somethig the OS provides you at a basic level. Signals, > semaphores and of course shared memory... Yep. 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. A "bus" is represented by a running instance of the daemon, so the tree of registered callbacks is all in one place, and the path and method name would be enough information to find one callback. Now if DBus provided network IPC, then I could see a use for the "service" name: it would be registered via DNS-SD for example, so that one machine can discover services on another. The "service" would have a use: it is the thing which is advertised, and after you have connected to that service on a particular machine then you still need to provide the path and method name. But DBus doesn't do anything like that, does it?
