[ANNOUNCE] D-Bus Broker Project
thiago at kde.org
Mon Sep 4 17:18:26 UTC 2017
On Monday, 4 September 2017 13:18:46 -03 David Herrmann wrote:
> > The blog indicates that you've thought of this problem and have solved it,
> > without sacrificing the peerness. I'm interested in how.
> 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
Thanks, I'll take a look. That sounds interesting.
On a related note, this is the first time I've heard of a reason bus1 exists at
all. It may also be the first message in this mailing list that mentions bus1
in the first place.
> > 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).
Most of the directed, unicast signals are used in place of replies, as a
result of a method call. This allows one to implement a series of replies,
like CoAP's OBSERVE functionality.
That means those signals are hardly ever subscribed to. Most importantly, the
first of such signals is often sent before the receiver even has the
information required to subscribe to it in the first place. According to your
description, those signals would be considered unsolicited, even though the
higher level API would consider them solicited (due to the method call that
caused it to be emitted).
How would this affect your solution? Suppose a malicious program makes a call
which results in a system daemon sending a series of directed signals back at
the caller. Those should be accounted to the caller, not the system daemon.
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
More information about the dbus