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 _______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
