[Telepathy] Properties of D-Bus MUC tubes

[Simon McVittie]

On Sat, 26 Sep 2009 at 01:46:07 +0100, Alban Crequy wrote:
> Gabble and Salut deliver a D-Bus message to the application only if the
> contact is one of the right recipient (either message sent to that
> contact or broadcast D-Bus signal). It is different for 1-1 D-Bus
> tubes: in this case everything is delivered. See message_received in
> src/tube-dbus.c.

That's an intentional difference, and should be documented in the spec.
MUC and 1-1 D-Bus tubes behave like the dbus-daemon and a 1-1 D-Bus connection,
respectively.

(Also, if I remember correctly, 1-1 D-Bus tubes never echo messages back to the
sender, but MUC D-Bus tubes mirror broadcasts back to the sender. Again, this
mirrors point-to-point D-Bus vs the dbus-daemon.)

> It is guaranteed by Gabble because it use a MUC server, so the server
> decides the order of the messages, and everybody receive the messages
> in the same order.

This is a useful implementation quirk in Gabble, and cannot be relied on by
Tubes applications.

> For Salut, I think it is guaranteed by the clique protocol and the
> reliable multicast protocol. Sjoerd, can you confirm?

Clique, and the abstract design of D-Bus Tubes, only guarantee causal ordering,
explained at <http://telepathy.freedesktop.org/wiki/CausalOrdering>

> When a broadcast signal is emitted, does the sender receive his own
> signal? If not, it would break the total ordering (the application
> cannot know whether its messages are before or after others' messages).

In Gabble, as an implementation quirk that may change at any time, the sender
receives the signal "at the right time", when they see the echo from the
MUC server. In Salut, the sender gets their own signal immediately.

> If one day we implement peer-to-peer connections between the
> participants of the D-Bus MUC tube to save the server's bandwidth, the
> total ordering may be reconsidered.

If we ever do this (unlikely, IMO), we should implement a Clique-like message
queueing and re-ordering facility in order to impose at least causal ordering
(but not total ordering!)

> Depending of the MUC server, you can receive messages which were
> emitted before you join the D-Bus MUC tube (backlog).

That's a bug, not a feature, I believe.

> No message loss on Salut thanks to the reliable multicast protocol.

I consider this to be an invariant of Tubes - clients that cannot guarantee
that they have received every message should signal it as disconnection from
the tube, dropping messages if necessary to avoid violating causal ordering.

Clique does this correctly - if it takes too long to fetch the old messages
necessary to provide causal ordering, Salut will leave the Clique room,
dropping the unprocessed messages.

    Simon