FrontPageWelcomeAll the content is licensed under Apache 2.0 License unless stated differently.We are looking for more contributors with interest in networked virtual environments, network protocols or 3d graphics. Please leave a message to forums or join us at IRC if you are interested to contribute. Our official IRC channel is #mxp at freenode IRC network. You can join the channel with web IRC here. Table of Contents [-]
IntroductionThe goal of this open source project is to define minimal and easy to implement open protocol for networked virtual environments (for example virtual worlds, social 3d environments, online games and first person shooters). Metaverse Exchange Protocol (MXP) is a second generation virtual environment protocol specification. MXP has a coherent theoretical model (Bubble Cloud) for networked virtual environments and proposes a working engineering solution. See Domain Model for term definitions. NVEs are in this context systems with multiple thin clients and servers simulating single seamless virtual environment. All parties are upkeeping local partial scene graphs which are synchronized using metaverse exchange protocol. MXP concentrates on messages required for the defined 3d simulation model. MXP specification does not contain application specific concepts but acts as a transport layer for specialized interaction and state data encoded as Metaverse Structured Data (MSD). In addition to MSD/MXP there are the following protocol candidates for authentication, asset and inventory access. These additional protocols leverage HTTP as a transport layer protocol. HTTP access to internet is available in most networks without explicit firewall configurations.
Why Should I Choose MXP?MXP protocol solves many challenges of distributed virtual environments to offer the following features:
BackgroundThe ideas and design principles for MXP originate from internet (see Background Reading) and two protocols specifications: SETP and CICP. SETP stands for Simple Environment Transfer Protocol. CICP stands for Content Injection and Control Protocol. These protocols are previous work of Tommi Laukkanen and Ben Lindquist respectively. CICP has a public domain provisional patent application which will not be completed to actual patent but is used to provide prior art protection for CICP against future patents. The patent application can be viewed here: http://www.cybertechnews.org/downloads/CICP_app.pdf I filed this provisional application in the US on March 14th, 2008. I have deliberately allowed it to lapse and have released all interest in CICP to the public domain. - Ben ProcessThe MXP design process is a simple community process driven through MXP wiki and discussion group. The process details and materials can be found at the end of this page under wiki table of contents. Datagram SpecificationMXP over UDP is a detailed specification describing how MXP is realized over UDP protocol. MXP could be realized using other transport layer protocols. One of the MXP over UDP key concepts is to have a small set of UDP messages concentrated on connectivity, transport and distributed virtual environment scene graph synchronization. All application specific information is transmitted as payload over the core UDP messages encoded in MSD format. Another key concept is to multiplex all the data (excluding binary assets) through one UDP port to simplify session handling and network connectivity. Reference ImplementationA C# reference implementation of MXP can be found at http://setp.googlecode.com/. The reference implementation covers all message types and implements functional application interfaces. DemosBubble BouncerBubble Bouncer Interactive Demo is a simple demonstration of MXP reference implementation in action. Multiple users can chat and interact with dynamic spheres according to simple physics model. Clients are connected to server using MXP. Sphere objects are simulated by AI participant which is communicating with the server through MXP: Cloud DemoCloud demo is a demonstration of bubble cloud under works. The demo consist of CloudDeck viewer based on Horde3D and CloudTank which is a configurable server program built on top of the CloudService class of reference implementation. AdoptionApplying MXP to traditional virtual world implementation with region concept is straightforward. Region corresponds to bubble and all MXP messages are directly applicable. This is demonstrated by OpenSimulator adoption of MXP. The implemented functionality is an MXP module to OpenSimulator server which adds MXP as additional protocol and similar module to IdealistViewer. The work is ongoing but transmit of prims, terrain and avatars is currently operational. InteroperabilityInteroperability between different virtual world implementations can be realised by supporting MXP protocol and a shared MXP extension like Open Metaverse Structured Data. This enables objects to see and traverse between Bubbles from different vendors. Interactions between objects injected by different participant implementations are a question of common interaction extensions or support for other vendors extensions. It is also possible for participants to interact with objects owned by different software implementations in similar manner. If business transactions are required then existing mechanisms like WebServices should be used. MXP is about virtual environment functionality not reinventing remote procedure calls for online business. Bubble Cloud ModelNetworked virtual environments (Cloud) consist of simulations nodes (Bubble). One bubble has cubic or spherical volume. Bubbles in a simulation cloud do not necessarily form a cubic lattice. Bubbles may be sized and placed using various strategies. Bubbles can overlap. Locations in messages are always presented in local simulation coordinates relative to the center of the source bubble or parent object. Each bubble is linked to coexisting and adjacent bubbles to enable object perceptions, interactions and handovers between bubbles. Client (Participant) is connected to a single bubble at a time which is responsible for routing information from adjacent bubbles. Object is simulated by one bubble at a time even if it is located in shared volume. Handover is a process where object is handed over from one bubble to another in analogy with mobile devices and base stations.
The Big PictureMXP protocol is responsible for 3d scene synchronization. There are several other functional areas which are needed to build a distributed virtual environment. This chapter describes these other areas and their relation to MXP protocol. Identity ManagementIdentity management, authentication and authorization are well established areas. Identities are managed by open identity providers. Participant identity is represented by OpenId URL. Participant may authenticate to identity provider by any means available. Identity provider hands out OAuth tokens to participant. These tokens are then used to to authenticate to bubbles and other services. Bubbles and other services verify the tokens by invoking verification requests to the identity provider. This process can be optimized by using session authentication where client is authenticated only once per session by validating the one time token against identity service provider. After this the session is trusted. To avoid man in the middle attacks both MXP and HTTP connections should be encrypted. See OpenId and OAuth for detailed description. User groups are well established pattern for managing access rights for large groups of people. Groups can be succesfully applied to distributed systems by identity providers or specialized group identity providers. Group identity providers persist group hierarcies and member lists. Group identities are exposed as security principals through standard identity provider interfaces. Group identity is similar to user identity all though it is not possible to authenticate directly as a group. These group identities can be bound to access lists the same way as user identities. Inventory ManagementInventories are analogous to remote file systems with metadata support. Users and groups own inventories where data can be stored. Inventory service can be freely acquired from any compliant provider. Inventory service is not bound to the identity provider or home bubble of the owner. Each user and group can have zero to many inventories. See OpenSimulator AssetServer Proposal for detailed description of a protocol proposal.
Asset ManagementAsset management, storage and delivery are challenging from ideological, theoretical and engineering view points. MXP is not an asset delivery protocol. In ideological level it is enough to state that any asset can easily be extracted with a specialized client. Because of this there is no feasible technological way to absolutely protect assets from theft in an open system. MXP currently relies on the same model as world wide web does. If a better model is introduced it will be adopted. In practice this means that assets are delivered to all connected participants by the asset cache of a bubble over HTTP. This allows for bubble to track asset integrity and load balance asset delivery. Original assets are stored in an inventory of user or group. When user creates an object he assigns his own inventory or group inventory as the object home inventory. The assigned inventory contains assets of the object. This inventory is then used by bubble to load the assets to local cache for further delivery to clients. In this scheme the asset distribution is load balanced through bubbles and inventory owners can control spread of their objects by limiting the bubbles which may access the inventory in question. Asset ids are all always assigned by inventories according to the proper UUID generation algorithm which will effectively remove threat of id collisions between assets from different inventories. Defining home inventory to object offers both the object metadata persistent storage location and aggregate asset storage location. Multiple objects can share assets but only inside one inventory. Furthermore this information architecture allows for reference counting and carbage collection inside single inventory provider. It can also be argued that object home inventory elegantly solves problem of asset delivery when object is handed over from bubble to bubble. This is especially true for bubbles from different providers which do not share back end services. It is good to consider supporting identification of assets by traditional urls. Some public asset servers could be www servers or svn http servers. All 3d modeling programs are refering to aggregate assets using file paths. It would be easy to upload the model to SVN http server and then using viewer pull out the model and aggregate assets for viewing. This could be alternative asset distribution model. It could work through bubble asset cache or directly from viewer to the http server. See OpenSimulator AssetServer Proposal for detailed description of a protocol proposal. Asset file format candidates
TeamIn alphabetical order:
Project
Processes
Design Rationale
Design
Specification
Implementation
Installation
Archive
Related Articles
24257 Views |
