Some quick notes on how a client socket manager talks to the session manager:

At any time c2s can send the sm "auth" packets.  These are usually iq:auth get requests or registrations.
They must be addressed to the user@host based on the data specified in the packet from the client.
The return address is whatever the c2s needs to locate that connected client again.

<route to="user@host" from="id@c2s" type="auth">
	... the packet from the client
</route>

For these requests, or for ANY request, you may get back a route type="error", meaning disconnect
the client.

Otherwise, the sm will just respond with an identical route (to/from reversed) containing 
the packet to send to the client.

The actual authentication works the same way, but additionally c2s must extract and specify the resource
in the to="user@host/resource".  It is up to c2s to look into the returning packet for that request
to determine if it was type="result" or type="error" to know if the user was actually authenticated.
(Yes, big hack, too late to fix it now)

After being authenticated, c2s must send a simple session-start request with the full user jid:

<route to="user@host/resource" from="id@c2s" type="session"/>

When the session is created, the reply from the sm will look like:

<route from="id@sm" to="id@c2s" type="session"/>

The sending from is important, that is the address all client packets must be sent to:

<route to="id@sm" from="id@c2s">
	... client packet
</route>

A type="error" from c2s to the id@sm signifies that the client has disconnected.



Some small examples of connection notification messages:

jadc2s can send messages to configured entities if a client connects or
disconnects. For example these messages can be used to implement a Jabber
based DDNS service or to offer some features to the user only if he has
connected over a secured connection. Also it would be possible to implement
a component where a user can query his own IP address.

A connecting user:

<message from="8@jadc2s" to="register@ddns.example.com">
    <update xmlns='http://amessage.info/protocol/connectionstate'>
	<jid>user@example.com/test</jid>
	<login/>
	<ip>192.0.2.100</ip>
	<tls>
	    <version>TLSv1</version>
	    <cipher>AES256-SHA</cipher>
	    <bits secret='256' algorithm='256'/>
	</tls>
    </update>
</message>

(The <tls/> element is not present, if the user is connecting without SSL/TLS.
The <bits/> element shows of how many bits the secret consits and how many bits
the algorithm processes. In case of old export ciphers the algorithm can
process more bits than are used by the secret. The security is better reflected
by the secret attribute than by the algorithm attribute.)

A disconnecting user:

<message from="8@jadc2s" to="register@ddns.example.com">
    <update xmlns='http://amessage.info/protocol/connectionstate'>
	<jid>user@example.com/test</jid>
	<logout/>
	<ip>192.0.2.100</ip>
	<tls>
	    <version>TLSv1</version>
	    <cipher>AES256-SHA</cipher>
	    <bits secret='256' algorithm='256'/>
	</tls>
    </update>
</message>