Once the slave has retrieved session information from the session service, it will connect to the indicated gateway. The initial connection will be using XML, but the HTTP Upgrade:/101 format is used to switch to a binary (less verbose, lower latency) format. It is possible to introduce an UDP connection at this point, but for version 1, it's probably simpler to keep it at TCP, and live with the high latency that will involve. Additionally, if this is done with Connection: keep-alive, there is some chance that Web proxies will actually let these requests through, which might be a useful way to get through restrictive firewalls.
The request looks something like:
Upgrade: entity-stream/1.0
<?xml version="1.0">
<connect version="1.0" compatible="1.0">
<sessionid>123456</sessionid>
<credentials method="hash-auth">
<slaveid>9876</slaveid>
<cookie>abcd</cookie>
''<!-- hash of slaveid, sessionid and nonce with session-
specific password (separately exchanged) -->''
<hash>cdcdcdcd</hash>
</credentials>
</connect>After the 101 status is returned, the session will immediately switch to binary format.
It might be beneficial to provide for re-authentication on the entity
connection every so often. This should use the nonce provided by the
original session, the slave id, the separate password and some challenge
provided by the gateway to freshen the credentials.
Possibly worry about authenticating the master gateway to the slave,
too? or just use SSL for it all instead?