A comparison of the startup methods used by SL/OS and TPS

by Kitto Flora August 2011

There are two initialization processes used by the OS communications protocol, HTTPS and HTTP.

HTTPS is used by SL and probably all OS grids. It is used to communicate with the login server, perform secure login and obtain some basic information, and to attain a connection with the region simulator. It is encrypted, therefore difficult to analyze.

HTTP is used for 'sandbox' mode connection between a client and a single region server. It is not encrypted, and the plain-text password is simply hashed and sent to the login section of the region server.

OS server code contains a simple user login system which is used by the HTTP system to get initial information and then obtain a connection to region server part. Clients, particularly Imprudence which was mostly used for this analysis, can deal with either login method.

Tritium is a Agent Server, not a region server, so it needs no separate login system. Because of the complexity and added load of an HTTPS system, and the problems analyzing what the HTTPS system is doing, TPS simply uses SCTP to initiate the connection much like the OS HTTP system. The password is sent hashed. In the future for better security, public key encryption will be used.

Tritium does not separate the login server and region server, thus the hand-off system that OS/SL uses to pass the connection from login server to region server is unnecessary. Also the SCTP connection is reliable, secure and closed, therefore continuous client and session key exchange, and the 'reliable message system' are unnecessary.

The OS-compatible Imprudence client needs a specific sequence of messages from the server to complete login and display a scene on the screen. I have analyzed and duplicated a lot of that communication in the non-TPS version of Tritium. It uses a mixture of HTTP, XML, JSON and LLUDP. The code in Tritium to handle all that is greater than 75% of the sum! My proposal is to replace the lot with TPS.

Here is the communications sequence used by Tritium and a OS server to perform login and attain a scene on the screen.

[The TPS replacements are in in brackets.]

1. Client sends HTTP header with "Expect: 100-continue" to server login port [Client opens SCTP connection to Avatar Server]

2. Server responds with HTTP "100 Please continue mate." [Msg 0x0001: version number]

3. Client sends HTTP/XML message containing:

methodName Login_to_simulator 
firstname 
lastname
password (hashed)
start (place, eg home/last/region name)
version (of client code?)
channel (client name)
platform (client OS)
mac  uuid of Network Interface
id0  uuid of HD0
last_exec_event (?)
options: (request for the following data?)
inventory parts
initial outfit
gestures
event categories
event notifications
classified categories
adult compliant
buddy list
ui-config
tutorial settings
login flags
global textures

[Msg 0x0002: name, password, start location]
[Do we care about platform or mac/id0? better to use IP# lockout]
[What is last_exec_event ?]
[if options are requests, what's the point? - server should just send them]

4. Server sends connected client an HTTP/XML message 'methodResponse'. The contents of this message cover several different subjects and are intermixed. For the sake of clarity I have sorted them into logical groups.

login true

[Msg 0x0003 login success/fail + message]

first name <First>
last name <Last>
agent id UUID
login flags  
  stipend since login N (or int?)
  ever logged in Y (or N)
  daylight savings N
  gendered Y
agent_access_max <A> (A-dult? etc)
seconds since epoch <int>  (Time sync?)
start location  home
home (location) <region x,y> <position x,y,z> <look at x,y,z>
look_at <x,y,z> (start  point?)
region x <int>  (start  point?)
region y <int>  (start  point?)

[Msg 0x0005 Name UUID locations flags time]

message <welcome string>

[Msg 0x0011 message]

sim_ip IP# (IP of region server)
http port 0 (unused?)
sim port <integer> (region server port#)
session ID UUID
secure session ID UUID
circuit code <int>

[not used]

seed capability <http: IP#:port# CAPS UUID>

[not used]

ui-config
[what is this for?]
allow first life Y
[what is this for?]
agent access M (or A...?)
[repeat of above?]

inventory root < folder-id UUID>
inventory skeleton  (the Av's inventory folders?)
(a colossal bunch of names and UUIDs)
inventory lib root
  folder id UUID
inventory lib owner
  agent id  UUID (root? gov linden?)
inventory skel lib (the library folders?)
  (a colossal bunch of names and UUIDs)

[Msg 0x00?? Inventory base]

event categories (empty)

[Msg 0x00?? events]

classified categories
  (a whole bunch of category names)

[Msg 0x00?? Classifieds]

buddy list (empty)

[Msg 0x00?? Buddies (is this 'friends on line?)]

gestures (empty)

[Msg 0x00?? Gestures]

initial outfit
  <string name of outfit> <string gender> (not used??)

[Msg 0x00?? Outfit (obsolete?)]

event notifications (blank)

[Msg 0x00?? Event Notifications]

global textures
  cloud.. UUID
  sun.. UUID
  moon.. UUID

[Msg 0x00?? Global Textures]

5. Client sends HTTP/llsd request to region http port, using the capability seed.

Header is "POST /CAPS/<uuid>0000/"
Aprox. 39 subjects are requested

[not used]

6. Region Server sends HTTP/llsd message to client containing a list of capabilities.

Aprox. 10 key + address/UUID pairs.

[not used]

7. Client now runs 2 communications streams:

7a. Client requests capablilies via HTTP connection, server replies with http message.

[replace all these with TSP messages]

7b. Client exchanges lludp messages with server.

[Most of these have close mapping to TSP messages]