Difference between revisions of "SLGOGP Teleport Strawman"

From Second Life Wiki
Jump to navigation Jump to search
Line 73: Line 73:


*Non-transport/server errors will be changed to 200 status in the future
*Non-transport/server errors will be changed to 200 status in the future
Terms of Service
  {
    'authenticated' : false
    'reason'        : 'tos'
    'message'      : <terms of service text>
  }
*Once user agrees to terms of service call authenticate again with { 'agreed_to_tos' : true }
Critical Message
  {
    'authenticated' : false
    'reason'        : 'critical'
    'message'      : <critical message text>
  }
*Once user has read the message call authenticate again with { 'read_critical' : true }
Miscellaneous Reason
* data - bad input or server side data fetch failed
* key - bad password
* god, restricted, ban, suspend, disabled  - denied based on account details


= Agent Information =
= Agent Information =

Revision as of 15:27, 28 July 2008

This strawman represents a possible open teleport protocol. The sequencing is described first, which also introduces the major players: Client, Agent Domain, Simulator/Region Domain A, Simulator/Region Domain B. For perspective, the current Second Life Grid teleport flow is also included. Following that are the draft specifications for the two main pieces, called rezAvatar and derezAvatar on the agent domain. The simulator side portions of this protocol have been tentatively dubbed "teleport_avatar" and "give_up_av_to_pipe".


Teleport Flow

Here is the basic flow for current SL teleports: Old teleport.png

Fine tuning the proposed protocol and cap names after discussion with AWG groupies resulted in a unified approach for Login, Teleport, and Logout, diagrammed below:

Login

Strawman-login-flowchart.png Open grid login.png

Teleport

Open Grid Teleport.png

Logout

Open Grid Logout.png

Authentication


Request: viewer -> auth.cgi

Required Parameters

{
    'firstname':  <string>,
    'lastname':   <string>,
    'password':   <string>
}

or

{
    'firstname':    <string>,
    'lastname':     <string>,
    'md5-password': <string>
}

Optional Parameters

{
    'agree_to_tos' : <bool>,
    'read_critical': <bool>
}

Response

Successful

 status:  302 
 {
    'authenticated': true
    'location'     : <agent host seed capability url> 
 }
  • Note: the 302 status code will be changed to 200 status in the future

Unsuccessful

 status:  4xx - login was unsuccessful
 status:  5xx - server error
 { 
    'authenticated' : false
    'reason'        : <one word identifier>
    'message'       : <error description>
 }
  • Non-transport/server errors will be changed to 200 status in the future


Terms of Service

 { 
    'authenticated' : false
    'reason'        : 'tos'
    'message'       : <terms of service text>
 }
  • Once user agrees to terms of service call authenticate again with { 'agreed_to_tos' : true }


Critical Message

 { 
    'authenticated' : false
    'reason'        : 'critical'
    'message'       : <critical message text>
 }
  • Once user has read the message call authenticate again with { 'read_critical' : true }


Miscellaneous Reason

  • data - bad input or server side data fetch failed
  • key - bad password
  • god, restricted, ban, suspend, disabled - denied based on account details

Agent Information

Agent Information

Name

agent/info

URL

capability from agent domain

Verb

GET

Response

{ agent_id: <uuid>, circuit_code: <int>, session_id: <uuid>, secure_session_id: <uuid>, presence: { status : online|offline, region_url: <url> }

a map of agent information for this session


rez_avatar/place

  • Once the viewer acquires the cap for place_avatar, it requests it from the agent domain
  • The viewer can also invoke place_avatar for teleport

Request: viewer -> agentd

{
    'region_url': <r_url>
    'position':  [x, y, z]
}

Response

{
  'seed_capability': uri string
  'look_at' : [f32, f32, f32]
  'sim_ip': ip string
  'sim_port': int
  'region_x': int
  'region_y': int
  'region_id' : uuid
  'sim_access' : <PG/Mature>
  'connect': bool
  'position': [f32, f32, f32]
// The above are the same as response to rez_avatar
// The following are only returned on login, not over teleport
   'session_id':<uuid>
   'secure_session_id':<uuid>
   'circuit_code':<int>
// Extra stuff
   'connect': <bool>
}


rez_avatar/request

Request: agentd -> simulator

{
   'agent_id' : <uuid>,
   'first_name': <string>,
   'last_name': <string>,
   'age_verified' : <boolean>,
   'agent_access' : <boolean>,
   'allow_redirect: <boolean>,
   'god_level':  <int>,
   'identified':  <bool>,
   'transacted': <bool>,
   'limited_to_estate': <int>
    'sim_access' : <PG/Mature>,
   'granters': []
}

Example: (hard coded)

{
  'agent_id' : <uuid>,
  'first_name': <string>,
  'last_name': <string>,
  'age_verified' : false, 
  'agent_access' : false,
  'allow_redirect: 1,
  'god_level':  0,
  'identified':  false,
  'transacted': false,
  'limited_to_estate': 1
  'sim_access' : 'PG'
}

Response to request_rez_avatar

{
   'connect':True
   'rez_avatar/rez':<cap>
   'sim_ip': ip string
   'sim_port': int
   'region_x': int
   'region_y': int
   'region_id' : uuid
   'sim_access' : <PG/Mature>
   'seed_capability': uri string

Optional params for Second Life regions only:

   'src_can_see_mainland':<bool>,
   'src_estate_id':<int>
}

Failed request.

{
   'connect':False
   'redirect':False
   'resethome':False
   'message': string
}

Failed request. Need to reset home location.

{
   'connect':False
   'redirect':False
   'resethome':True
   'message': string
}

Failed request. Need to redirect to new location

{
   'connect':False
   'redirect':True
   'resethome':False
   'message': "You have been redirected to a telehub."
}

rez_avatar/rez

Request: agentd -> simulator OR simulator a -> simulator b via derez_avatar

  • For login, the agent domain then invokes rez_avatar on the simulator at the given region_url
  • For teleport, the agent domain invokes derez_avatar on simulator a, which invokes rez_avatar on simulator b
{
   'circuit_code': <int>,
   'god_overide':   <bool>,
   'position': [x, y, z],
   'secure_session_id':  <uuid>,
   'session_id':  <uuid>,
   'inventory_host':  <uri string>, // not really here!
   'voice_password': <string> // what to do?
   // The following are only sent from simulator a -> simulator b via derez_avatar
   // Note: No assets are actually being sent through when going from SL -> non-SL regions
   'attachment_data': [ {'attachment_point':<int>, 'item_id':<uuid>, 'asset_id':<uuid> | 'asset_data':<binary>}...]
   'baked_texture_data': [ {'texture_id':<uuid>, 'asset_host_name':<host?????>}...]
   'texture_data': [ <uuid>...]
   'animations':[{'state':<uuid>, 'source':<uuid>, 'sequence':<int>}...]
}

Response: simulator -> agentd

  • The simulator then returns the actual region (in case it might be different from requested) and the seed cap.
{
   'look_at' : [f32, f32, f32]
   'position': [f32, f32, f32]
// Extra stuff
   'connect': <bool>
}


rez_avatar/derez

Request: agentd -> simulator a

{
    'rez_avatar/rez': <url>
    'position':  [x, y, z]
}

Response: simulator a -> agentd

Response: simulator -> agentd

{
   'look_at' : [f32, f32, f32]
   'position': [f32, f32, f32]
// Extra stuff
   'connect': <bool>
}