Re: [ANNOUNCE] D-Bus Broker Project

Hey Thiago!

On Wed, Aug 23, 2017 at 8:26 PM, Thiago Macieira <[email protected]> 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
solution.

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:

    https://github.com/bus1/documentation/wiki/Message-ordering

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
relationship.

> 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).

Thanks
David
_______________________________________________
dbus mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dbus