Hi, I would like to define whether Telepathy D-Bus MUC tubes have some properties and document it, so that application developers who want to use Telepathy Tubes can design their interfaces properly.
Resources: http://telepathy.freedesktop.org/wiki/Tubes http://people.collabora.co.uk/~danni/telepathy-book/sect.tubes.dbus.html Message filters --------------- 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. Total ordering -------------- 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. For Salut, I think it is guaranteed by the clique protocol and the reliable multicast protocol. Sjoerd, can you confirm? 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). 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. Message loss ------------ No message loss on Gabble thanks to the centralised MUC server. Depending of the MUC server, you can receive messages which were emitted before you join the D-Bus MUC tube (backlog). No message loss on Salut thanks to the reliable multicast protocol. Ordering in membership change by DBusNamesChanged ------------------------------------------------- Each participant is informed of changes in the tube's membership by the D-Bus signal DBusNamesChanged. It is emitted in the bus used by Telepathy (not inside the D-Bus tube). Does all participants receive the changes of membership in the same order? Atomicity in membership change by DBusNamesChanged -------------------------------------------------- The signal DBusNamesChanged can contain several new members or removed members. Does all participants receive the same atomicity? Are they grouped in the same manner? At least the ones who joins don't get the same DBusNamesChanged signal since they are informed of all the others' presence. Ordering between membership change by DBusNamesChanged and messages ------------------------------------------------------------------- If a participant emits continuously a D-Bus signal in the D-Bus tube and at some point is informed of a new member by DBusNamesChanged, it cannot know which messages are received and which messages are not. I don't know if the Connection Manager can know, but the application cannot because the signal DBusNamesChanged and the signals emitted in the tube are not on the same bus, hence not on the same socket, so no ordering. It is the same problem when a new member joins the tube. We could implement a bus driver (such as org.freedesktop.DBus or similar, and messages to the bus driver would be local only) to have the ordering: the equivalent of DBusNamesChanged/NameOwnerChanged would be emitted in the D-Bus tube bus and not in the session bus used by Telepathy. But in the case of Gabble with a MUC server, the server can send messages from the past (the backlog), so it is more difficult. Regards, Alban _______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
