System Architecture

From Sirikata Wiki
Revision as of 03:50, 7 June 2009 by Ewencp (talk | contribs) (Add virtual museum example)
Jump to: navigation, search

System Architecture


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


  • Object -
  • Behavior -
  • Object Reference -
  • User -
  • Authentication -
  • Authorization -
  • Introduction -
  • Message -
  • Location -
  • Physical Rules -
  • Content -


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


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 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).


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.

Virtual Museum

Space and object host holding current exhibits in museum's administrative domain. Clients may connect, maybe restricted - no avatars, restricted avatars.