[ANNOUNCE] D-Bus Broker Project

David Herrmann dh.herrmann at gmail.com
Mon Sep 4 16:18:46 UTC 2017

Hey Thiago!

On Wed, Aug 23, 2017 at 8:26 PM, Thiago Macieira <thiago at kde.org> wrote:
> I'm interested in how you solved the total ordering problem in a triangle (or
> bigger polygon).
> - Connections A, B, C.
> - A sends a message to B and then to C
> - B receives its message from A and because of that, sends a message to C
> - C receives both messages
> D-Bus currently guarantees that C will see A's message before B's message. In
> the C11/C++11 memory model, this is called "sequential consistent" and is
> different from a regular acquire/release barrier.
> The blog indicates that you've thought of this problem and have solved it,
> without sacrificing the peerness. I'm interested in how.

Right now, dbus-broker *sacrifices* peerness. It is a pure
re-implementation of a D-Bus Message Bus, hence it runs as
intermediate hop and forwards messages just like dbus-daemon(1). We
are fully aware of this ordering-problem, and we consider it
unsolvable with AF_UNIX. Thing is, as soon as you get multiple
separate channels between peers, they will all have their own message
queue, and as such ordering across queues will be broken. This can be
fixed with ordering protocols, but to make those trusted you need to
add kernel verification or cryptography. I am not aware of a third

This issue is *exactly* why "bus1" exists. It is a transport that
implements 1:n communication, but guarantees causal ordering (and
more). Our intention is to allow running D-Bus over bus1, and thus
getting rid of the broker in the middle. This is not yet finished,
though. dbus-broker exists to guarantee backwards-compatibility, once
we get this ready.

If you are interested in details on the ordering, see the bus1 wiki:


This explains in detail how we guarantee causal ordering without any
global context. We guarantee that two message transaction never share
a single cache-line or variable, unless they have a causal

> Also interested in how you determine what's unsolicited for directed signals.

A directed signal (or in fact *any* signal) is considered solicited if
a Match-Entry of the receiver matches the message. Unlike broadcasts,
unsolicited *unicast* signals are still delivered (mostly for
backwards compatibility).


More information about the dbus mailing list