Subject: [mmox] MMOX Protocol Proposals

From: Morgaine <[email-masked]>
Date: Sat, 28 Feb 2009 11:42:29 +0000

Just a quick note to highlight that we now have three concrete proposals as
input to MMOX work.  In order of appearance:

   1. Open Grid Protocol (OGP Draft
3)<https://wiki.secondlife.com/wiki/OGP_LLSD_Draft_3>, extra links
   here <https://wiki.secondlife.com/wiki/OGP>
   2. MXP: a universal Metaverse eXchange
Protocol<http://www.cybertechnews.org/?p=499>
   3. MMOX Live Entity State Stream (LESS)
Protocol<http://www.interopworld.com/mmox-less-protocol>

Hopefully the Solipsis <http://www.solipsis.org/> model often mentioned by
Jesrad will be added to this list as a concrete proposal at some point, as
well as the Qwaq <http://www.qwaq.com/> and
Croquet<http://www.opencroquet.org/>models since they have expressed
interest in interop, and also the Project
Darkstar and Wonderland <http://www.projectdarkstar.com/> models (sadly, no
representation from them yet).

I'm tracking the appearance of concrete proposals on my unofficial links
page at
https://wiki.secondlife.com/wiki/MMOX#MMOX_Protocol_Proposals_and_MMOX_Draft_Protocols.

Morgaine.

---

From: Jon Watte <[email-masked]>
Date: Sat, 28 Feb 2009 11:20:39 -0800

Morgaine wrote:
> Just a quick note to highlight that we now have three concrete 
> proposals as input to MMOX work.  In order of appearance:
>
>    1. Open Grid Protocol (OGP Draft 3)
>       <https://wiki.secondlife.com/wiki/OGP_LLSD_Draft_3> , extra
>       links here <https://wiki.secondlife.com/wiki/OGP>
>    2. MXP: a universal Metaverse eXchange Protocol
>       <http://www.cybertechnews.org/?p=499>
>    3. MMOX Live Entity State Stream (LESS) Protocol
>       <http://www.interopworld.com/mmox-less-protocol>
>

Thanks for collecting this!

I don't see how MXP is an interop protocol, though. From reading through 
the latest version, it seems to be building one kind of server cloud, 
similar to one Second Life grid, using an open and published protocol. 
This is no different in approach than the existing OpenSim effort. It 
doesn't talk at all about how different grids should interoperate. I can 
see no technology neutral affordances in the protocol -- the only 
"interop" possible seems to be through a defined client/server 
interface. That doesn't solve any of the hard problems, like how to 
interoperate different objects that are built using different execution 
environments within the same space.

Perhaps Tommi can chime in with a clarification of the interop goals of 
MXP in this context?

Sincerely,

jw

---

From: Morgaine <[email-masked]>
Date: Sun, 1 Mar 2009 01:39:39 +0000

On Sat, Feb 28, 2009 at 7:20 PM, Jon Watte <[email-masked]> wrote:

> similar to one Second Life grid, using an open and published protocol. This
> is no different in approach than the existing OpenSim effort. It doesn't
> talk at all about how different grids should interoperate. I can see no
> technology neutral affordances in the protocol -- the only "interop"
> possible seems to be through a defined client/server interface. That doesn't
> solve any of the hard problems, like how to interoperate different objects
> that are built using different execution environments within the same space.
>

Oddly enough, I find MXP to be almost identical to OLIVE, and I see it
bearing almost no relationship to Second Life at all.  (I'll explain in a
second.)  From this plus the fact that it seems to be able to handle
Opensim-to-Opensim communications despite Opensim being
*originally*designed to work like SL seems to be a great testament not
only to the
flexibility of Opensim but also to the architecture-neutrality of MXP.

On the similarities between MXP and OLIVE, the two architectures look like
variations on a theme to me.  In both cases every client performs the same
simulation, this being of a "shared space/room" in OLIVE and of a "Bubble"
in MXP.  In both cases, the communication seems to be a form of P2P,
proxy-aided in the case of MXP.  Both approaches seem unable to simulate
widely diverse world environments because simulation is done on every
client, which means that the same simulation code has to exist on every
client for the simulation to be accurate.  This would seem to preclude
effective interop with different worlds whose simulation code is not
divulged --- at best some rough feedback telemetry can then attempt to
reflect something vaguely sensible to "foreign" local simulations.  And in
neither case is there a "world-centric" model as in SL or Opensim, since
rooms and bubbles aren't really topological entities per se.

I have no doubt that both of you will disagree with my evaluation since you
have the details and I don't, but that's how it looks to me from the
explanations I've read. :-)

I do agree that the hard questions do not appear to have been answered, but
this is true for every proposal so far:  the detailed semantics of interop
remain to be defined.

Morgaine.

On Sat, Feb 28, 2009 at 7:20 PM, Jon Watte <[email-masked]> wrote:

> Morgaine wrote:
>
>> Just a quick note to highlight that we now have three concrete proposals
>> as input to MMOX work.  In order of appearance:
>>
> similar to one Second Life grid, using an open and published protocol. This
> is no different in approach than the existing OpenSim effort. It doesn't
> talk at all about how different grids should interoperate. I can see no
> technology neutral affordances in the protocol -- the only "interop"
> possible seems to be through a defined client/server interface. That doesn't
> solve any of the hard problems, like how to interoperate different objects
> that are built using different execution environments within the same space.
>
> Perhaps Tommi can chime in with a clarification of the interop goals of MXP
> in this context?
>
> Sincerely,
>
> jw
>
>

---

From: Jon Watte <[email-masked]>
Date: Sat, 28 Feb 2009 19:24:57 -0800

Morgaine wrote:
> On Sat, Feb 28, 2009 at 7:20 PM, Jon Watte <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     client/server interface. That doesn't solve any of the hard
>     problems, like how to interoperate different objects that are
>     built using different execution environments within the same space.
>
>

But architecture neutrality is only a necessary constraint on a 
standard; it's not sufficient to provide interoperability. Specifically, 
I don't quite see how MXP supports the case where the same space 
contains entities simulated by different hosts -- given that it suggests 
entities are "handed off," that necessarily means that bubbles have to 
use the same technology, which necessarily precludes multi-architecture 
interop.

> On the similarities between MXP and OLIVE, the two architectures look 
> like variations on a theme to me.  In both cases every client performs 
> the same simulation, this being of a "shared space/room" in OLIVE and 
> of a "Bubble" in MXP.  In both cases, the communication seems to be a 
> form of P2P, proxy-aided in the case of MXP.  Both approaches seem 
> unable to simulate widely diverse world environments because 
> simulation is done on every client, which means that the 

Surely, there is simulation on the client even in Second Life? Else, you 
would need to get updates from each object at 60 Hz to be able to show 
smooth movement.
Specifically, MXP sends state snapshots, and lets the client dead reckon 
between those snapshots. That is, in itself, a robust technique, used by 
a lot of systems (harking back to before DIS, and used by pretty much 
all networked computer games) -- but it's nowhere near what OLIVE does 
internally. OLIVE requires deterministic simulation on client and 
server, and only forwards time-stamped command input, no state snapshots.
The LESS protocol I have proposed, though, is similar to MXP in this 
regard, because it's based on the "common ground" of state snapshots and 
dead reckoning. I based it on that just because it's so common, robust 
and well known, and the fact that MXP is also based on that proposal 
means it's probably a good common ground technology.
But, that in itself does not lead to interop. There is a difference 
between building a working virtual world protocol, which may be open, 
documented, and unencumbered, and building a protocol that is designed 
for interop between different virtual world implementations.

> same simulation code has to exist on every client for the simulation 
> to be accurate.  This would seem to preclude effective interop with 
> different worlds whose simulation code is not divulged --- at best 
> some rough feedback telemetry can then attempt to reflect something 
> vaguely sensible to "foreign" local simulations.  And in neither case 
> is there a "world-centric" model as in SL or Opensim, since rooms and 
> bubbles aren't really topological entities per se.
>

Bubbles are topological in the sense that they have location in 
cartesian 3D space. At the same time, they are not topological enough, 
if you want to map them 1:1 to arbitrary technologies, because OLIVE 
uses a sector partition where the shape and size of a given 
sector/bubble can be an almost arbitrary graph (including disjoint), and 
other technologies like BigWorld let sectors/bubbles be polygonal shapes 
(they use Voroni diagrams to partition space); the bubble concept 
doesn't map to that 1:1, either. When you build a virtual world protocol 
(to use as basis of a particular implementation), specifying the 
size/shape of bubbles is required. However, when you design for interop, 
specifying that actually may get in the way, and leaving it unspecified 
may actually be preferable.

> I do agree that the hard questions do not appear to have been 
> answered, but this is true for every proposal so far:  the detailed 
> semantics of interop remain to be defined.

Well, I tried to answer some hard questions in LESS. I think the biggest 
drawback of the LESS proposal is that it requires support from other 
protocols which have not yet been published (but which I have drafts or 
examples of). However, I believe LESS answers more of the hard questions 
than the others.

It may turn out that an agreeable protocol in the end uses the 
marshaling/entity/component/property/ownership separation of LESS, the 
connection/authority negotiation of OGP, and some other bits of MXP, but 
I don't think any one of those protocols can stand on its own, 
unmodified, as is. I think LESS would have to be modified the least, but 
that's because it attempts to solve the fewest problems, but in the most 
detail, of the three :-)

Sincerely,

jw