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.
First a good understand of what the JabberBox is and does is critical. JabberBox 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 biggest benifit of using JabberBox is that you can host multiple transports on one IP address or server, allowing ICQ, AIM, and Jabber transports to all live together easily. It also manages incoming and outgoing data to other servers, delivering to the correct local transport. All transports will connect to the local JabberBox and communicate with it to do any transport-2-transport communication.
A simple transport would:
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 JabberBox in the handshake. After the configuration data has been loaded, if the transport needs to be internet-addressable, it 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 JabberBox to deliver data addressed to that name(since the JabberBox 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 JabberBox.
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:
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 JabberBox). Combined, the sender of the message would be fromID@transport.<message><from nick='JoICQuser'>321451</from><to>jeremie</to><say>Hello!</say></message>
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.
Coming...
Things like handling ID's, logging in on behalf of others, etc... coming soon...