D-Bus: Multicast Messages

[Simon McVittie]

On Tue, 16 May 2017 at 15:19:41 +0200, David Herrmann wrote:
> The behavior of a multicast message is exactly that of a sequence of
> unicast messages, with the exception that it is handled atomically
> regarding message-ordering. IOW, the message broker simply forwards a
> multicast to each destination, turning each forwarded message into a
> unicast. The receiver of a multicast will be unable to distinguish it
> from a unicast.
...
> So far, there has been no attempt to implement this.

Implementing multicast
----------------------

I spoke to Allison Lortie about this at the most recent GTK hackfest.
If I remember correctly, she tried implementing a form of multicast
very similar to yours for dconf's benefit, but ran into problems with the
reference implementation of D-Bus making it impossible (or at least
inexplicably difficult) to insert non-basic types into a message header.

(In particular, an array of strings representing multiple destinations
seems like the natural implementation of "please send to all these
recipients", but an array is not a basic type.)

I think the problems Allison encountered involved the weird machinery
that libdbus has for constructing a properly aligned header in a
single buffer, which is implemented in terms of inserting rather
than appending; unfortunately, that means everything after the
insertion point potentially has to be realigned (even though header
fields are structs, which we know are maximally aligned already).
Sending the header using more than one buffer, or having a copying
slow-path for the cases where the header needs to be rewritten, seem
like potential approaches to this.
<https://bugs.freedesktop.org/show_bug.cgi?id=38288> and
<https://bugs.freedesktop.org/show_bug.cgi?id=38289> are relevant.

Obviously, deficiencies in the reference implementation are really bugs
in that implementation, rather than requirements for the specification.
However, I think it's important that we have a portable implementation
(so not something like sd-bus, which is Linux-specific) that acts as the
reference. If the reference implementation does not implement the
specification then we have a problem. It doesn't necessarily have to
be optimal, but it does have to work.

Who needs to support what?
--------------------------

If it is intended to act as a drop-in replacement for broadcasts, this
approach would also require a protocol by which the dbus-daemon can
pass through relevant signal (un)subscriptions to the broadcaster (while
not passing through irrelevant subscriptions, for privacy!), and would
require the broadcaster to implement the signal match rule syntax and
the matching tree. Error handling is problematic here: if a signal
match rule is relevant to more than one broadcaster, is accepted by
one of them, and is rejected by another, then what? (Bear in mind that
some callers of AddMatch() ignore most errors anyway, because waiting for
a round-trip is undesired, and if it fails, it isn't clear what a caller
can do about it.)

If this is merely an optimization for sending the same unicast repeatedly,
then APIs making use of this protocol would need to have a hard dependency
on a sufficiently new dbus-daemon (or a reimplementation like your "broker"),
an out-of-band protocol for dealing with subscriptions, and, again, they
would have to work out who is to receive which signals internally.

My instinct here is to say that the signal match tree is probably something
we do not want to duplicate in all the parallel implementations.

Untrusted endpoints
-------------------

<https://bugs.freedesktop.org/show_bug.cgi?id=100344> is an alternative
approach to dealing with untrusted D-Bus connections, inspired by kdbus'
*endpoint* concept. I'm hoping to have some time to spend on implementing
that later this summer.

    S