Off-topic: D-Bus in the kernel
remi at remlab.net
Tue Sep 21 10:43:52 PDT 2010
On Tuesday 21 September 2010, Havoc Pennington wrote:
> > 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.
So you're saying Telepathy should not use DBus the way it does, I guess.
> 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.
Sure. But it seemed to me that libdbus did not really make peer-to-peer DBus
so easy (though it certainly allows it).
> 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.
I guess I did not mean to say DBus is misdesigned, but misused then. Most
applications use DBus correctly as a rendez-vous mechanism, but also
incorrectly for peer-to-peer signaling.
> > 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.
If two clients A & B try to send a message to the same client C, one (say B)
will have to wait for the other (say A). Then if B also wants to send a
message to a forth client D, the message to D will be stuck in B's queue.
Effectively, the communication between B & D ends up being blocked by the
communication between A & C.
You can mitigate it with low message size limits and/or large receive buffers
on the bus daemon to *some* extent.
More information about the dbus