System Architecture

The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

System Architecture

Model

The model of the world we want to simulate: shared 3d environment, objects with programmable behavior

Definitions

Object -
Behavior -
Object Reference -

User -

Authentication -
Authorization -

Introduction -
Message -
Location -
Physical Rules -

Content -

Architecture

High level overview of how space, object host, and content servers fit together.

Space

Must Provide:

Authentication and authorization of object hosts, objects
Introduction of objects to each other via some mechanism
- Prior knowledge or all-to-all (e.g. for a small, multi-player game)
- Spatial queries
Message routing - opaque messages - source, dest, opaque data, might enforce constraints like limiting scope to guarantee service
Enforcement of physical rules - only externally visible in the sense that objects can see results and might be informed of rules so clients can provide better interpolation
- Collision detection and resolution
- Rigid body physics
- Null
- Implies certain state owned by space - location, mesh/collision hull - specifics depend on what is enforced

Could provide additional services, advertised via a service discovery protocol, such as:

Efficient VOIP/audio mixing service
Image based rendering service for higher quality graphics (image based far-geometry rendering)
Secure money transaction service, could be using internal currency system ala Linden $
- Or generalize to safe exchange mechanism - trust space as 3rd party to handle exchange with untrusted party

Object Host

Simulate objects
Provide interfaces for objects to access
- All space services, possibly including dynamically discovered services
- Content distribution

Lots of optional services here
- Rendering
- Interactive Input
- Internal storage service, i.e. within the object host, for persistence of state. Could have a wide variety of guarantees and performance.

Clients

Clients are just another type of object. Gives clean interface for everybody to the system.

Content Server

Serves content - long lived, slow changing data
Hash based
May have naming layer on top

What's Missing?

State sharing - pub/sub, separate service, directly with each other via space?
Inventory services - higher layer

Use Cases

List of use cases accompanied by diagrams showing the logical setup (including boundaries indicating administrative domains).

Game

One administrative domain containing space and object hosts. Clients are object hosts outside admin domain, have .

Social Virtual World ala Second Life

Single admin domain containing space and object hosts. Clients have special authentication/authorization to space, limiting what they can do (e.g. only control their objects/avatar). Object hosts may be exposed directly (i.e. clients also have component to talk to internal object hosts directly, internal object hosts have plugin added to expose them), or may work through a service in the space (allowing additional policies/constraints in the space).

Meeting Room

Space hosted in administrative domain. Most object hosts are outside that domain. Maybe some objects, like chairs, board, etc are setup inside that domain. Avatars and any objects users want to instantiate come and go with them and are simulated by their machines (or some 3rd party object host). Example: add object to space on a 3rd party host so it will stay even after the user logs out of the space.