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

["Tony Parisi" <[e-mail]>]

Hi everyone,

> The easiest way to explain how x3d (and vrml) work is a
> simple example.
> 
> DEF Object Transform {
>  translation 0 0 0
>  children [
>  ]
> }
> 
> To set translation to something you'd use javascript like
> this in a Script node(*).
> 
> Object.translation=value;
> 
> This is commonly refered to as object, attribute, value. So
> SWMP needs to support the same data.
> 

Paul, that is an incredibly lucid and concise way to illustrate X3D. Nice
:-)

Yes, SWMP does need to support X3D data types in order to transmit state
changes for an X3D simulation. However, please note that there is nothing
X3D-specific about SWMP. It is X3D-friendly... for sure. The paper we
published for the Web3D Symposium was totally oriented toward X3D because
that was the general topic area of the conference. But SWMP could be used to
transmit messages for other non-X3D simulations as well. At least, that is
the intent.

> Messages may not just be simple values, you can also send
> entire scene graphs or nodes via SWMP.
>

Yes, true, but in general it's not a good idea to do that for a good-sized
chunk of scene graph. For that case it's better to use HTTP to transfer the
data.

That's how Media Machines is designing our applications: HTTP for the data
transfer and SWMP for the dynamic state changes (in both directions). Oh and
XMPP for the chat, etc. Our general philosophy is to use the best protocol
for the specific task, and use existing ones wherever we can. We created
SWMP because there wasn't an existing open protocol to handle MMO-style
scene state changes.

Tony


> 
> (*) or ROUTE from another node
> 
> I'll reply further on this soon.
> 
> --- [e-mail] wrote:
> 
> > 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> _______________________________________________
> > SWMP mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/swmp
> >
> 
> 
> 
> 
> 
> __________________________________________________________________________
> __________
> Need Mail bonding?
> Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users.
> http://answers.yahoo.com/dir/?link=list&sid=396546091
> 
> _______________________________________________
> SWMP mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/swmp




_______________________________________________
SWMP mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/swmp