[toc]
TPS - Tritium Packet System
by Kitto Flora
This is a summary of an SCTP[1] communications system to replace the HTTP, XML, LLUDP etc. system used by Second Life and OpenSim systems. It uses binary packets via a single SCTP connection per client. Much comparison is made to the existing SL/OS protocols.
"Tritium" is the codename for a new Virtual World software development, similar in overall functionality to Second Life or OpenSimulator but written from scratch in ANSII C and using a completely new architecture to avoid the limitation encountered in those products.
"Tritium" is neither a salable product nor a company or organization name. It is simply an internal codename.
[1] IETF description of version in UBUNTU is at [1](http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-24 "IETF description")
As of Jan 2011 there are additional functions, only partly implemented in UBUNTU, at [2](http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-30 "Additional functions")
Impact of Tritium Architecture
The Tritium server architecture is different to the LL/OS architecture in that Tritium has a single Agent Server to which a user connects rather than a separate login server and multiple Region Servers. This single Agent Server handles login requests and handles all data transfers between client and pseudo-regions, therefore it is only necessary for a client to make a single connection to the server for an entire session with the Tritium 'Grid'.
The architecture allows for multiple Agent Server processes running on separate cores or even separate machines, but each must have access to the RAM database.
Although the clients will still see 256M X 256M regions, internally the Tritium server has no separate regions. Regions are synthesized for the sake of the client system and to maintain dimensional accuracy. This architecture eliminates the border crossing problems encountered by SL and OS.
Comparison of LL and Tritium Protocols
SL and OS use a mixture of HTTP, XML and UDP protocols to communicate. Tritium uses only SCTP.
SCTP is a relatively new Internet Protocol and is somewhat like TCP and UDP. Unlike UDP it provides a continuous reliable secure client-server connection, more like TCP. Unlike TCP it provides discrete packet-based communications, like UDP. An extra feature of SCTP is built in 'streams' - which are individual communication paths within the single connection. Each stream is handled separately so that when packet loss occurs only one stream may be delayed while a lost packet is re-transmitted, but other streams keep running.
Because SCTP provides reliable, ordered delivery of multiple streams of packets between client and server the need for the continual session ID checking, circuit codes, 'reliable message' control systems and sequence numbers which are used by SL/OS are eliminated which offsets the extra overhead in SCTP compared to UDP. Once a socket-to-socket connection has been established by exchange of login information the connection is exclusive to a particular agent, and all data is reliable exchanged in exact sequence.
Using a single SCTP connection it is conceivable that if that connection is lost due to temporary Internet failure the client may be able to automatically reconnect with only a delay in the client functionality rather than the exit, restart and re-login sequence needed by the existing SL protocol.
A future expansion consideration is that SCTP can negotiate amongst multiple servers available at a given domain name, which aids the use of multiple Avatar servers.
Tritium Packet System - TPS
TPS packet contents are similar to LLUDP, though much simplified due to the secure reliable connection. Packet contents are binary bytes and limited to length 2048 bytes (unsigned char message[2048]). Transmission of file data longer than (2048 - overhead) bytes requires multiple packets, but no sequence number as correct sequencing is guaranteed.
Login verification is handled via TPS initially in the same way that a stand-alone OS region operates, using password hashing. Eventually it is expcted to use public key encryption rather that the massive overhead of HTTPS.
A packet starts with a two byte (16-bit, U16, little-endian) 'message type' value. The remainder of the packet depends on the message type. To avoid confusion, odd number message types are for messages from server to client, even numbers for client to server. There is no message 0. Messages are transmitted by the server as they are generated, there is no separate buffering and shuffling of messages. The Tritium server design creates messages at the optimum rate.
As with LLUDP, the payload of each message depends on the message type but because of the secure connection identity information is not necessary. Numerical values e.g. U16, S32, F32, U128 (UUIDs) are sent 'litte endian' which enables simple direct extraction in the majority of hardware. Text and file data bytes are sent in the sequence they are created or read.
SCTP Message Handling Code
An example of a client message handler is provided here TPS handler. Except that the server has code to deal with multiple connection on one port, the server-client system is symmetrical, the same code is used at both ends, and provides a full-duplex buffered messaging system for each client connection.
Data Types
U8 Unsigned 8-bit byte
U16 Unsigned 16-bit byte
U32 Unsigned 32-bit byte
S32 Signed 32-bit byte
F32 Float 32-bit IEEE
Tn Text string, n is number of bytes, or v=variable
Messages always start with U16 type.
TPS Messages
(work in progress!)
Format: Type (Origin) Use......
0x0001 (Server) On initial connect server tells client TPS version number. (Possible future extra: Public key.)
+F32 version
0x0002 (Client) On receipt of 0x0001 client sends server first and last names and hashed password
+T3 PW hash prefix, typically "$1$"
+T32 hashed password, md5 uppercase
+U8 following text length
+Tv <fistname>"."<lastname>, case does not matter
+U8 start location, 0=home, 1=last, 2=region, name follows
+Tv <region name>, optional
0x0003 (Server) On receipt of 0x0002 server sends client success or fail of login attempt.
+U8 result: 0=fail, 1=already logged in, 2=success
+Tv <text message>
0x0004 (Client)
0x0005 (Server) Avatar data
0x0006 (Client)
0x0007 (Server) Region Data