System Architecture

This has fallen out of date and was never complete. See the the platform developer guide's component breakdown for a more up-to-date version.

Sirikata's architecture is still being actively developed, so be aware that the available information may fall out of date. To get started with the code, you likely only need a small bit of global knowledge to understand how the big pieces fit together, and then more detailed local knowledge on the parts you're actually developing on. This page contains detailed descriptions well as example use cases to justify our architecture.

Before you continuing down this page we recommend you watch this 25 min. video which gives you a high level overview over the system. In the event that the documentation is incomplete, try the developer list (and complain that the documentation is missing as well as asking your question).

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.

Virtual Museum

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