Telepathy Wiki

Tubes are Telepathy's mechanism for supporting arbitrary data transfer and remote IPC.

Support

Old API	One-to-one	Group
D-Bus tubes	Gabble	Gabble, Salut
stream tubes	Gabble	Gabble, Salut

New API	One-to-one	Group
D-Bus tubes	Gabble	Gabble
stream tubes	Gabble	Gabble

Stream tubes are useful for applications that already uses TCP because the application protocol does not need to be changed to use Telepathy tubes. Applications that uses D-Bus tubes need to have a specific protocol. Applications can use several types of tubes.

Stream tubes currently means TCP. UDP tubes may be added in the future.

When a contact A offer a stream tube in a chatroom, it's equivalent to listening on a TCP socket with listen()/accept(). Then anyone in the chatroom who can see the stream tube can connect to that socket as a client. For 1-1 stream tubes only one person can see the tube, but the applications can still connect to contact A multiple times. So it's really a factory for 1-1 connections. If the contact A is offering httpd over a tube, the other contact's firefox instance can open multiple tcp connections to the httpd.

IB means In Band. The tubes' data use the same path as other messages. For XMPP (Gabble) it means the tubes' data is encapsulated in XML stanza and sent to a jabber server. It could be very slow for applications like VNC.

OOB means Out Of Band. The tubes' data use a different path than other messages. The tubes' data is sent directly to the remote contact.

Gabble

One-to-one D-Bus tubes: Stream initiation and SOCKS5 if possible; In Band Bytestream (<message>s containing base64) if not.
Group D-Bus tubes: Some kind of In Band Bytestream in a MUC. See the pseudo XEP.
One-to-one stream tubes: For each tube connection: Stream initiation and SOCKS5 if possible; In Band Bytestream if not.
Group D-Bus tubes: For each tube connection: Stream initiation and SOCKS5 if possible; In Band Bytestream if not.

Salut

One-to-one D-Bus tubes: not implemented
One-to-one stream tubes: for each tube connection: direct TCP connection
Group D-Bus tubes: raw data using the Clique protocol
Group Stream tubes: for each tube connection: Stream initiation and P2P connections (ab)using the OOB protocol

Properties of D-Bus MUC Tubes

Total ordering: Yes
No message loss: Yes
Ordering in membership change by DBusNamesChanged: ? - does all participants receive the changes of membership in the same order? (except the one who just joins of course)
Atomicity in membership change by DBusNamesChanged: ? - when several participants join or leave "at the same time", does all participants receive the same content of DBusNamesChanged? Are they grouped in the same manner? (except the one who just joins of course)
Ordering between membership change by DBusNamesChanged and messages on the d-tube: No. It cannot, it is not the same socket