Off-topic: D-Bus in the kernel

[Rémi Denis-Courmont]

   Hello,

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.

-- 
Rémi Denis-Courmont
http://www.remlab.net/