Extending the Jabber Architecture: Transports

This document will provide a general guide to creating custom transports.

WORK IN PROGRESS

Transports are the most important aspect of Jabber, and provide the key features for the platform. Here we will discuss what the basic requirements are for a simple transport, as well as what issues a large-scale transport will have to deal with.

Etherx

First, a solid understand of what the Etherx does is critical. Etherx is an independant data router. It simply accepts connections, takes data, and delivers that data to other connections. It's the location-aware middleman. The most immediate benifit of using Etherx is that you can host multiple transports on one IP address or server, allowing ICQ, AIM, and Jabber transports to all easily live together. It also manages incoming and outgoing data to other servers, delivering to the correct local transport. All transports will connect to the local Etherx and communicate with it to do any transport-to-transport communication.

Simplistic Transport

A simple transport would:

Naming

How are transports identified and how does it relate to DNS? Good question! All transports(or transport projects) should choose a simple internal unique name to identify themselves. So, for the Jabber transport it calls itself "jabber" and the ICQ transport may call itself "icq". These names are used in the configuration file to identify transport-specific configuration. These names are also then the name sent to the Etherx in the handshake. If the transport needs to be internet-addressable the configuration should have contained it's DNS name, say "jabber.server.com" for the jabber transport. After it knows it's internet name, it needs to tell the Etherx to deliver data addressed to that name(since the Etherx handles all incoming data) to itself. A transport does this by sending <alias>jabber.server.com</alias>. Since all local transports can send data to each other via either the DNS name, the simple name, or ANY name placed in the alias, it might be wise to identify alternate aliases such as JABBER, JABBERTRANSPORT, or jab, etc... Also, note that all of the transport DNS names must resolve to the IP address that is used by the Etherx.

Messages

Now, lets start discussing the actual DATA that a transport will have to send/receive, starting with messages. A message will arrive encapsulated in the CDATA section as XML:

<message><from nick='JoICQuser'>321451</from><to>jeremie</to><say>Hello!</say></message>
The format is the same as a message anywhere else in Jabber. The ID in the from will have to be used in reference to the transport where this originated(as specified in the original r tag's from='' attribute from the Etherx). Combined, the sender of the message would be fromID@transport.

Statuses

The status system. I'll try to explain briefly how status are handled in Jabber. When a user comes online, a status should be sent containing the <say type='online'> tag, identifying this as a special status. When a transport receives one of these for one of ITS users, it should then and only then start delivering that local users statuses to the other user who just came online. When an incoming status contains type='offline' all outgoing status to that user should cease. So, to summarize, only send statuses when you KNOW the recipient is online. The exception being, whenever one of your local users comes online/offline, then always send the type='online' and type='offline' to everyone reguardless. This system will enhance privacy(guarantees it's a two-way agreement) and reduce traffic significantly.

A transport that is "proxying" for a Jabber user to another system has to use status packets uniquely. The Jabber user we are proxying for must have some of their buddies from the other system on their roster, such as 213424@ICQ, so that when the Jabber user comes online the @ICQ transport will receive that status packet from the Jabber user to 213424. This flags the transport to log into ICQ on behalf of the Jabber user, and change the ICQ status appropriately to match. The transport then should also receive the status of the 213424 ICQ user after having logged in to ICQ, and forward that status to the Jabber user.

Queries

Much of the configuration/setup and information gathering will happen via Queries. This section needs to be defined yet.

Gateway Issues(ICQ/AIM/etc)

Things like handling ID's, logging in on behalf of others, etc... coming soon...

Process Flow

VERY simple step by step for a transport to ABC instant messaging system

Startup...
Connect to local Etherx
Process Configuration
Load users(file or DB)
---
Processing incoming Jabber data from a user we are gatewaying for
  Status 
    log into ABC on behalf of user if not logged in yet
    chage status on ABC to match appropriately
  Message
    deliver/forward message to ABC user
Processing incoming ABC data for a user we are gatewaying for
  Forward/Deliver all data to appropriate Jabber user