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

Jay:

Thanks for the response.

It looks like I got the situation mostly right.  Here are some residual 
reactions resulting from your reply:

1)  I am OK with Node-Field-Value as a generic representation of state. It 
is not much different from Object-Property-Value, except I assume the node 
naming implies a hierarchical relationship.  I do think we will need a 
richer representation for type.  To be fully general, I question whether 
enumerated types is the way to go (as opposed to Mime types.)  Doesn't 
enumeration require one to know all possible types prior to defining the 
values.  We can't do that and be flexible for unanticipated uses of swmp.

One approach might be to define a notion of a type scheme and then use an 
enumeration within that scheme.  Thus, some more string-like value would 
indicate that these are X3D types and then a second field could indicate 
the enumerated types for that scheme.

2)  So long as X3D is a special case of a more generic state sharing 
technique, I am happy.  It is probably not worth the trouble to debate 
whether X3D is more model or view.  (It is in the nature of virtual worlds 
that the model is view-like.)  I'm just pretty sure that we will encounter 
situations when the state of something other than an X3D node needs to 
conveyed.

3)  I am glad that you see the value of a set vs setNotify message.  I 
didn't think of it before, but we are probably ready to talk about why 
there isn't any subscritpion message in the swamp protocol (and whether 
there should be one in swmp.)

4)  It sounds like you are saying that latecomer support is in your code 
even though it is not obvious how to do it based on the paper.  Does that 
mean there is a get request in your implemented protocol?

jfp

"Jay C. Weber" <jweber@mediamachines.com> 
06/25/2007 04:51 PM

To
john_patterson@us.ibm.com
cc
swmp@ietf.org
Subject
Re: [SWMP] Media Machines' initial design and code

john_patterson@us.ibm.com wrote: 
I have now managed to look through the paper and I am ready to ask some 
questions. 
Hi John, sorry for the delay, I had a little holiday last week.
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. 
Yes, it is intentionally independent of the architecture, so it can be 
used with peer-peer, client-server, peer-server, and other architectural 
variations.
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. 
Yes; overall our work encompasses system architectures and virtual world 
semantics (and X3D provides some of this), but that paper focuses on the 
sub-problem of a protocol for communicating world-state changes.
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.).
Absolutely, minimizing individual message size allows the system to 
optimize packet sizes and/or message buffering for bandwidth utilization. 
The message enveloping in the paper doesn't include this, nor does the 
reference implementation, yet.  I think the implementation should do the 
buffering automatically, perhaps with a time-to-wait parameter so the 
application can tune the buffering to trade off bandwidth and latency.
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. 
Right.  When we use it with X3D, the static "base scene" is retrieved via 
HTTP and loaded, and then the SWMP session starts up to manage the dynamic 
aspects.
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. 
Agreed that state descriptions should be as generic as possible.  Our SWMP 
is already an Object-Property-Value triple, except that we use the X3D 
terms (which are also used elsewhere) of Node-Field-Value.

But, as you noted, where this gets X3D-specific is with the types of the 
values.  Though I do not know of another open-standard enumeration of the 
types one needs for communicating the values one needs for 3D scenes, so 
it may be that the X3D enumeration is the best choice, given that we need 
some standardized enumeration.  Note that X3D's types are based on other 
standards, like IEEE floats, and our SWMP also uses the standard IETF 
Network Byte Order.
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.
I think the X3D is more model than view, in the MVC sense.  And a 
scene-graph model is prevalent enough that it is a reasonable choice for 
the model.

Of course a key advantage that X3D has over other scene-graph models, is 
that it is a mature International Standard.

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.
Very interesting issue, I left the change vs. notify semantics (and 
implemented it) as the semantics of the particular architecture but I can 
see some advantage to making this explicit through separate messages.
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.
That (who updates latecomers) is also in the architecture, and implemented 
in the current code base as the server updating latecomer clients.

jay