MXP: a universal Metaverse eXchange Protocol
Tommi S. E. Laukkanen and I have merged the next versions of our protocols into something called Metaverse eXchange Protocol (MXP). This is a combination of the principles of CICP (see Ben’s earlier article about CICP), my protocol for allowing external entities to place interactive content into virtual worlds; and SETP, Tommi’s UDP-based protocol for efficient client->server and server->server interaction.
MXP begins with first principles, which are described below. Following the discussion of first principles is a list of terms which we consider “foundational definitions” for MXP; following that list is a description of the messages comprising MXP.
First Principles
We begin with the principle that a virtual world need only contain things which are perceivable. This is the key to interoperability. Logic, process, and internal object attributes exist outside the world. Just as knowledge and thought exist within the minds of humans and are only evidenced when they cause something perceivable to happen, such as a gesture or movement, or a sound; so the humans and programs participating in a virtual world are using the world only as a medium of expression and perception. Concepts such as internal object state, scripting, and logic belong to the participants, not the world.
Our next principle is one of layering. The communication necessary for a virtual world to provide a shared experience among participants takes place using a transport layer and a content definition layer. The transport layer provides a mechanism by which participants may make each other aware of the presence of objects, and then allow participants to transmit messages among their objects. The content definition layer provides the means for participants to publish any specific details and/or assets which define the appearance of their objects, the capabilities of their objects, the available options for interacting with their objects, and the state of any external attributes of their objects.
The layering principle allows us to limit the scope of MXP. MXP provides the transport layer and only enough of the content definition layer to enable the expression of the states of mutable, public attributes of objects. The content definition layer will specify the format and meaning of messages transmitted from object to object using MXP, and will provide a means for participants to publish and fetch content assets associated with objects. It is expected that the content definition layer will utilize XML for encoding of messages and definitions, and that assets and definitions will be fetched using HTTP. To extend the analogy to HTTP and the World Wide Web: the transport layer (MXP) is equivalent to HTTP, and the content definition layer is equivalent to MIME types, html, and other content.
To continue reading, please download the pdf version of the article.
Can this be instead accommodated in XMPP, or am i missing something?
One could certainly create a hub and client which use XMPP to communicate the same things they would communicate via MXP. The system would then be missing some of the following:
1) Architecture. The creation of a foundational way of thinking which builds easily into a rich set of detailed conclusions over time, while remaining consistent… principles such as spatially aware objects, equal participants, intelligence remaining outside the “world”… these principles are much more important than the protocol itself.
2) Simplicity. When you build something from scratch, for a specific purpose, you will end up with a much simpler system than you would if you adapt an existing “standard”.
Arkowitz
Yeah, but does all of that require another transport mechanism? In other words do you NEED a particular transport layer in order to define a world architecture? It seems to me what you’re dealing with is largely LOGICAL and how the data is transported from application to application is a whole other concern.
In other words, all of these concepts could be embedded in an XML based schema or set of schemas defining the structure of the messages.
Then there would need to be a high level sort of protocol definition which articulated required message flow and how the various message types were to be utilized, as well as probably conventions for location of external data, etc.
Finally an implementer would probably choose an appropriate transport mechanism for their software. It might be UDP, but it might just as well be XMPP or SOAP over HTTP or something entirely different.
I’d be interested in the documents (assuming they’re free and open and compatible with a BSD license). In OpenSimulator, we’re always looking to add-on interoperability with other systems.
Tommi has put a lot of work into the UDP implementation of MXP, due to expected performance gains over TCP. Other than performance, I have no problem at all with keeping the structure and principles of MXP and implementing using whatever the easiest, most ubiquitous transport layer is.
I think it is important to have multiple transport mechanisms, in fact. One that is very easy to use, for integration purposes when a programmer just wants to hook an app up to a virtual world; another, such as Tommi’s UDP version, which is very high performance (very few bits wasted) for use between “viewers” and the hub. The hub should be able to let participants choose the transports that they want.
Arkowitz
I should add that one of the goals of MXP is to enable physics and other simulation activities to be carried out client side OR server side; something Dan Miller was bringing up a few months back (seems like years).
Ark
Details of the protocol can be found from the MXP wiki: http://www.bubblecloud.org/