Connections

Each connection, using its native protocol library, lives within its own thread. This thread blocks on the I/O for that connection, and blocks on a message port for the Jabber side.

All incoming Jabber data is via etherx. Every incoming Jabber packet is checked for the from="jid", that Jabber ID is known as the owner. A global table contains all the existing connection threads for, and the owner of the incoming packet is checked against that list. If there is an existing connection from that owner, the packet is sent via a message port to that connection thread. If the global table contains an owner with an ID of "user@host", any from ID's of the type "user@host/resource" will also match and be forwarded.

Buddy Management

All other packets that werent delivered to a connection are dealt with as follows:

The pbuffer stores all incoming presence availability packets for a short period of time (a minute or two). The pbuffer is used when a connection thread starts to build the list of ID's that the owner has notified of their availability (the entries on their roster for this transport). This list of ID's is used as the approved buddy list for the native protocol.

Registration

IQ registration submissions should start a special thread to deal with it. If the native protocol supports new account creation, a thread can be started to create new accounts. If the registration is for an existing account, a thread is started to authenticate and check the credentials submitted. Upon success these threads confirm the IQ registration (type=result) and upon failure they return a type=error.

Presence

With a successful registration, the transport needs to know whenever the owner comes online, so it sends a presence subscription request to the submitter. The special presence subscription is sent with a from attribute generated by the transport, with embedded data needed to login to the native protocol. The from of the presence subscription might look like "jabber:transport.foo.net/registered?from=user@hostusername=foopassword=bar" (and could be crypted to be hidden).

New presence announcements to the special registered resource will fire off a new connection thread and create an entry in the global table with the registered owner ID. This connection thread, upon logging in, should send presence back to the owner. The connection thread can then use the pbuffer to extract the approved roster for the native protocol, and should accept new incoming presence announcements from the owner and modify this list appropriately. Any received presence from the native protocol reguarding any of the ID's on the approved roster should be sent to the owner with the correct from ID.

Messages are bridged from the owner to the mapped ID they sent them to within the connection thread, and incoming native protocol messages are sent to the owner with the correct from.

All incoming presence sent to the special registered address should be stored in a presence proxy, to determine if the owner is available or not based on the availability of all their resources.

Legal Information