Skip navigation.
Home

Initial Connection Negotiation

jwatte's picture

The virtual world service hosting the session is known as the "master." The other virtual world services are known as "slaves." This relation is only intended to convey who initiates the session, and who connects to the session; both masters and slaves can introduce entities into the simulation, where all participants can see those entities.

There is one layer of indirection between the locator URL and the actual connection used for virtual world data. This allows systems to implement some amount of load balancing, and de-couples the web service for managing sessions from the provisioning of the actual session resources.

At some point, communication needs to step down from XML to something more compact and real-time. That's probably where the gateway has responded with protocol information. This can use the HTTP Upgrade/101 request format together with Connection: keep-alive. Thus, requests need to be POST so that web caches don't interfere.

Initiating a session might work something like:

  1. Slave makes HTTP POST request to start session.
    1. Request contains session identifier.
    2. Request contains credentials.
      1. This should probably be done per client that wants to connect.
      2. Although the master can't really prevent leeching if allowed on the slave.
      3. Thus, strong DRM shouldn't be part of this spec.

Greeting sent from slave to master session service

  <?xml version="1.0"?>
  <greetings version="1.0" compatible="1.0">
    ''<!-- this is the ID that was separately exchanged for the session, where "session" ''
      ''identifies where, when, who, etc (like a "meeting id") -->''
    <sessionid>123456</sessionid>
    ''<!-- I expect to stay for half an hour -->''
    <duration format="seconds">1800</duration>
  </greetings>

The session ID is part of the locator URL. The duration is a hint that the connecting host can give the master host -- it's not clear that there's a good way of coming up with this value, so it may not be necessary.

  1. Master provides connection information
    1. Here is the playbox.
    2. Here are links to the terrain.
    3. Here are links to gateways.
      1. Different gateways for different areas of playbox?
      2. Start out with just one, for simplicity?
    4. Here are credentials for the gateways. (?)
    5. Session may have a defined duration in time.

"Playbox" is the physical area of the simulation, in some coordinate system. For example, in WGS-84, it may be a longitude, a latitude, and some measurements of a bounding box. The master will not accept or forward updates for entities that go outside this playbox.

"Terrain" is the static (non-entity) geometry of the simulation. Typically, this will include the ground, buildings, trees, etc.

"Gateways" are hosts that can provide actual simulation data exchange. There may be one or more gateways for the same session, where a slave can choose an arbitrary gateway. If there's a preference, the first gateway in the response should be preferred; this allows the master to do simple round-robin load balancing, while allowing clients to re-establish a session connection to "the next" gateway if the first gateway in the response fails for some reason.

The master provides some credentials that will allow the slave systems to authenticate with the gateway, using some HMAC scheme. An alternative would be to use SSL for all communications, but that would not allow for UDP transport.

Here's a typical response from the web service to the slave:

  <?xml version="1.0"?>
  <connection version="1.0" compatible="1.0">
    <sessionid>123456</sessionid>
    <playbox>
      <coordsystem uri="canonical-uri">WGS84</coordsystem>
      <minimum>
        <longitude>-123.0</longitude>
        <latitude>37.0</latitude>
        <height>-10</height>
      </minimum>
      <maximum>
        <longitude>-122.0</longitude>
        <latitude>38.0</latitude>
        <height>1010</height>
      </maximum>
    </playbox>

    <duration>
      <starttime format="isodate">2008-05-18 10:00:00-8:00</starttime>
      <endtime format="isodate">2008-05-18 13:30:00-8:00</endtime>
    </duration>
    <terrain>
      <geometry>
        ''<!-- this is roughlythe geocentric center of the playbox -->''
        <center format="Y-up">-4262200,2352400,2715300</center>
        <uri>some-uri</uri>
      </geometry>
    </terrain>

    <gateway>
      <uri>some-uri</uri>
      <credentials method="hash-auth">
        <slaveid>9876</slaveid>
        <nonce>12354567</nonce>
        ''<!-- hash of slaveid and sessionid with master-secret key -->''
        <cookie>abcd</cookie>
      </credentials>
    </gateway>
  </connection>