Identity

Overview

Each user in a space must be uniquely identifiable. This identity is represented by a unique bitstring value for each person. During the time a person is in a space, the identity string remains the same. We use this identity string as a means to get information about users.

Each user gets an identity from a ID Server in the space when s/he first enters it. The ID Server keeps a small database of identities and avatar descriptions. The identity is used as the key in this database. Clients query the database with an Identity key and receive the associated avatar description.

The motion server only identifies clients by ID. It does not return any other identifying value or name. Thus, in order to correctly display a newly seen avatar, a client must ask the ID Server for the avatar data associated with the new avatar's ID.

Actions

The ID service implements five commands.

1. The GetID command requests a new ID to be allocated.
2. The SetID command informs the client of its ID.
3. The GetX command requests a value for a variable
4. The SetX command sets the value of a variable
5. The AckSetX acknowledges a SetX packet

Clients use these commands to get IDs for themselves and to get information about other clients for which they only have ID information. Currently the ID Server allows you to Get and Set two variables

NAME

The name to be associated with the Avatar, typically in text chat

VRML

The VRML for the Avatar

Entering Multiuser Space

If the client wishes to enter a multiuser space, it sends the ID Server a GetID command. The client requests that the server make and return a new ID for it. The ID Server responds to this request by returning a SetID command with a valid ID. This tells the client what ID to use in the space. It then sends GetX commands with its Name, and its VRML. This is a possible area for future enhancements.

Leaving Multiuser Space

A client informs the ID Server that it is leaving interactive space and reliquishing control of its ID by sending a SetID command to the ID Server with the ID field set to invalid (0). The ID server checks to make sure that the host and port are known and signs off the appropriate client. It also tells the motion server to kill the client and make a ghost. The server replies with a SetID command with an invalid ID (0).

Requesting Information About Clients

Request commands are used by clients (in general) to find out information about other clients. The motion server returns a list of neighbors to a client. The other clients in the list are identified by their assigned IDs. The client sends a GetX command to the ID Server with the ID it wants identifying and the type field set to VRMLTYPE. The server responds with a SetX packet mapping the unknown ID to an avatar description. If the ID Server doesn't have any entry for this ID, it will send back invalid data (a NULL string).

The client can request information about another client's textserver by sending a GetX packet to the ID Server with a type field set to ADDRESSTYPE, which will return with a TextInfo packet containing the host and port to send text messages to (if any). Typically the client will also want the user's name, by sending GetX with the typefield set to NAMETYPE.

Timeouts

A number of techniques are used to reduce the problem of ghosts, i.e. Avatars that remain on the screen when their client has done an ungracefull logout (e.g. crashed!).

1. The ID Server is told that IDs are not valid by a SetID(INVALID_ID) command from either the client in question or a valid motion server. The ID Server waits at least a certain timeout before reusing these IDs.
2. Motion servers timeout people who have not sent an update for at least five seconds. When timed out, the motion server informs the ID server.
3. Clients timeout based on an algorithm documented in the Horizon document. (no longer available on the net)

   If the client has received the ID after it has been declared to be invalid (e.g. due to latency), when it tried to send a Request, it will get a Command Failed packet in return with the reason being INVALID ID.

   Thus, the maximum amount of time a "ghost" will be visible on the screen is XXXXX seconds.

ID Packets

• GetID Packet

  Sent By:

  Client

  Received By:

  Server

  When Sent:

  This is sent when the client is connecting to a new MultiUser Server to obtain a new ID

  Interpretation:

  The client needs an ID, one is assigned and replied via a SetID Packet. The sending IP number and port are recorded for future contact, and to confirm that packets came from this user.

  Fields:
      Command=GETID 
  

• SetID Packet

  Sent By:

  Server

  Received By:

  Client

  When Sent:

  In response to a GetID

  Interpretation:

  The ID field contains the ID to use with the servers in future transactions

  Fields:
  	Command=SETID
  	ID
  

• GetX Packet

  Sent By:

  Client

  Received By:

  Server

  When Sent:

  To request the value of some variable.
  Variables currently supported are NAME, VRML and ADDRESS

  Interpretation:

  The server looks up the ID and returns the data requested.

  Fields:
  	Command=GETX
  	ID
  	DataType         (NAMETYPE | VRMLTYPE | ADDRESSTYPE)
  

• SetX Packet

  Sent By:

  Anyone

  Received By:

  Anyone

  When Sent:

  From Client to ID Server to inform it of some variable value, or from Server to Client in response to a GetX packet.

  Interpretation:

  The variable data is associated with this ID.

  Fields:
  	Command=SETX
  	ID
  	DATATYPE    (NAMETYPE | VRMLTYPE | ADDRESSTYPE)
  	DATA   (for NAMETYPE or VRMLTYPE this is a string, For ADDRESSTYPE its the IP Number and Port)
  

• AckX Packet

  Sent By:

  Server

  Received By:

  Client

  When Sent:

  To acknowledge receipt of a SetX

  Interpretation:

  The client knows the server received and handled the SetX Packet.

  Fields:
  	Command=ACKX
  	DATATYPE ( NAMETYPE | VRMLTYPE | ADDRESSTYPE )