Re: [SWMP] Media Machines' initial design and code

Jay Weber wrote:

I'd like to point the group to Media Machines' initial work towards SWMP.

We presented an overview paper at the Web3D 2007 Symposium, which you can 
find at http://www.mediamachines.com/hydra/swampweb3d2007.pdf

I have now managed to look through the paper and I am ready to ask some 
questions.

First, let me state that I am not especially familiar with X3D.  I have 
looked quickly at it, but I have not gotten to the depth that the authors 
have.  It is possible that some of my questions are best answered by 
referring me back to X3D.

Second, I understand the swamp protocol (I use the name from the paper.) 
to be a peer-to-peer state replication protocol.  By peer-to-peer, I do 
not mean that it is useless for a server-based approach, but that it only 
addresses communication between two network nodes and this communication 
is completely symmetric; there is no assumption about either node having a 
different role from the other.  By state replication, I mean that both 
nodes maintain a copy of the state (at least the relevant, e.g., 
dynamically changing, state) and the protocol is used to keep these copies 
synchronized.

Third, I assume there is a desire for swmp to embrace the full breadth of 
virtual worlds implementations.  The paper (and subsequent postings) 
clearly recognize alternative network configurations (peer-to-peer, 
server-based, and hybrid) as an issue.  The paper is less clear on its 
position regarding varying approaches to where certain virtual worlds 
semantics, e.g., physics, collision detection, etc., will occur, i.e., 
centrally or peripherally.  I do not fault the paper for that, I just want 
to point out that this is a major differentiator among existing 
implementations and, if possible, we want to support many, if not all, 
alternatives.

Fourth, I assume that swamp supports packing multiple messages onto a 
single udp packet.  Without that I am having a little trouble 
understanding the obsession with keeping messages short (as evidenced by 
the setf method.).

Fifth, I assume that the purpose of swamp is for communicating state that 
is dynamic (ie, changing due to interactions with the virtual world) and 
not for the purpose of moving the static aspects of the 3D models.  It is 
not stated, but I am assuming that terrain, avatars, and in-world objects 
are initially obtained via prior download/install, http, or some other 
query-response protocol.  SWAMP is not for retrieving this static 
information; it is for maintaining the dynamic attributes of these models 
as they change due to being instantiated in a virtual world.

So, here are my questions:

1)  Should the base model be more generic with X3D as a specific type?

Many systems starting with Linda and moving through JavaSpaces and TSpaces 
have adopted the attitude that a state sharing system can use a very 
generic notion of how the state is organized.  These systems assume the 
state is in tuples; other systems assume something more akin to 
property-value pairs.  In any case, the base model is very generic and not 
tied to any particular purpose or specialized representation.  I wonder 
whether that would be a better approach for swmp.

I am not arguing that there is no place for X3D, just that we might prefer 
to treat it as a special case of a more generic state representation 
scheme.  X3D would be less embedded in the PDUs and more a conventional 
and well-defined set of types, fields, values, etc. that can be mapped 
into the generic PDU.  The value of this is that when we find some other 
kind of state that we would like to synchronize, we would not be 
struggling to map it into an X3D-based message structure.  Instead, we 
would map it into tuples or property-value pairs, which would certainly be 
less awkward and might also be more efficient.

As it stands, the biggest impediment to this approach posed by swamp is 
the rather small number of bits allocated to type information (and 
possibly the fieldID, though I do not fully understand its purpose.)

2)  Is X3D the right model?

I am not familiar enough with X3D to have a strong position on this.  I am 
mostly reacting to the idea that (to a first approximation) it is a scene 
graph representation.  That means it is tied to the display of the virtual 
world, which means it is more view than model in the model-view-controller 
(MVC) sense.  Presumably, our primary objective is to share the model of 
the world.

This is the chain of reasoning that drives my question.  In truth, it is 
more an aesthetic reaction to focusing on sharing views than a deep 
engineering concern.  I am aware that scene graphs often have highly 
abstracted grouping nodes that function like models in the MVC sense.  I 
also know that these high-level nodes have properties that can encode the 
more abstract model state.  In all likelihood, any model can be 
represented using the scene graph and therefore X3D is adequate.  But, 
should designers/developers be compelled to represent their models that 
way.  For example, must a fire be modeled as an X3D object or could we 
treat it as something unseen that causes changes to the visible objects 
based on complex computations?

Having said all this, I do understand that we must also be able to share 
the view objects.  I also recognize that X3D is a better representation of 
the state of a virtual world than something more abstract that I have not 
yet dreamed up.  Perhaps the best resolution of this question is to treat 
it as a special case of my argument in 1) above.  Supporting X3D 
synchronization is key, but it should not be the only form of state that 
we are prepared to synchronize.

3)  Should notifications of changes be distinguished from instructions to 
make a change?

Most of the time when I have constructed protocols of this sort, I have 
distinguished between messages that indicate a desire to change the state 
and messages that indicate that the state has been changed.  SWAMP does 
not seem to make this distinction.  I assume a set message is used both to 
reflect that a change should be made and that a change has been made.  My 
bias for differentiating these messages derives from working on 
client-server implementations, but I think it is useful even in a 
peer-to-peer situation.  Usually, one node has final say on whether a 
change of state will be permitted.  For the other node, a set, add, or 
remove message is a request.  It cannot count on the request being 
honored.  For the controlling node, a setNotify, addNotify, or 
removeNotify message is definitive.  This is not a request of the 
receiving node; it is informative.

I find this differentiation of requests for changes vs. notifications of 
changes easier to follow and I would strongly recommend that swmp follow 
this approach.

4)  How does swamp support latecomers?

Presumably one of the values of having a server keep track of the state of 
the virtual world is so that late arriving clients can retrieve the 
current values and get caught up.  This is generally referred to as the 
latecomer problem.  I do not see how a latecomer requests the current 
state of the virtual world using swmp.  I expected to find a get or read 
message that would be followed by a barrage of add messages (or better yet 
addNotify messages.)

Am I missing something?  Were you planning to use http to retrieve this 
state?  If so, what were you planning to do about race conditions between 
the http request and notifications of changes to the not yet received 
state?

jfp