Off-topic: D-Bus in the kernel

[Havoc Pennington]

Hi,

2010/9/21 Rémi Denis-Courmont <remi at remlab.net>:
> proper mechanism for multicasting message
> Service 'name resolutoin' is also nice to have.

With dbus, these are more like the primary reason for it to exist.

> But when it comes to request/response messages, it would be far more efficient
> to establish a direct connection between the client and the server. This would
> not only move most traffic out of the way of the DBus bus daemon, thus
> increasing perfomance.

And it would break the actual dbus use-cases. Not all IPC is the same!

The performance overhead of the bus does not matter for anything dbus
was actually designed for. What would matter, would be if every app
had a socket to every other app, instead of the "star" layout. Or
losing the ability to broadcast.

The way you do a performant link to to send lots of data, if dbus is
involved at all, is to use dbus to set up the link; and then on that
link you _could_ use dbus in 1-to-1 daemonless mode, or you could use
an IPC protocol appropriate for whatever you are doing.

Anyway designing IPC systems without clear use-cases isn't going to go
anywhere. The point of dbus is/was to solve these multicast and
lifecycle issues, not to be a faster kind of socket. If you want a
socket open a socket, not a dbus connection.

> It would also solve the head-of-line blocking problem
> that is inherent to multiplexing multiple flows of informations over a single
> stream (Unix socket).

This only happens between any two dbus daemon clients; the daemon
won't block to read or write to any client. So yes if message A is
going from client 1 to client 2, both of those clients have to wait on
message A. But other clients do not.

Havoc