[ANNOUNCE] D-Bus Broker Project

[Thiago Macieira]

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.
[snip[
> 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.

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