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

Tubes are contact-to-contact networking. Tubes enable one-to-one, one-to-many or many-to-many communication between contacts using either network sockets (stream tubes) or a private D-Bus bus (D-Bus tubes). This allows applications to support collaboration between users, with a minimal amount of effort on the part of both application developers and the end-user. Application developers can now focus on their application protocols, without having to worry about networking, firewall traversal or service discovery. End users no longer have to configure collaboration accounts, share IP addresses or forward ports on their firewalls.

Here’s how it works. An application implements the Client.Handler interface, handling channels matching:

{ "...TargetHandleType": Contact, 
  "...ChannelType": "...StreamTube",
  "...StreamTube.Service": "sudoku",
}

Or, if the application uses D-Bus tubes:

{ "...TargetHandleType": Contact, 
  "...ChannelType": "...DBusTube",
  "...DBusTube.Service": "org.gnome.sudoku",
}

While the application is running, all connections will advertise that the user supports Sudoku tubes to contacts subscribed to the user's presence. (To advertise support while the application is not running, it must be made service-activatable and install a .client file.)

If Alice wants to play Sudoku against Bob, her Sudoku client requests a list of all her contacts who advertise the Sudoku Tube capability. She selects Bob; his Channel Dispatcher receives an incoming channel and passes it to an Approver which displays a dialog to Bob asking if he would like to play a game of Sudoku against Alice. Assuming he approves the channel, his Channel Dispatcher then passes the channel to the recommended Handler (the game client) which can then accept the Tube. At this point their two Sudoku applications are now connected via the Internet.

[The Telepathy Connection Manager takes care of the precise method of connection, utilising whatever technologies are available with the given communications protocol.]

XMPP XEP

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 (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