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:

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

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.

Properties of D-Bus MUC Tubes

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