Tubes are Telepathy's mechanism for supporting arbitrary data transfer and remote IPC.
XEP-proto-tubes: Tubes over XMPP
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

