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

From: "Jay C. Weber" <[email-masked]>
Date: Mon, 25 Jun 2007 13:51:24 -0700

[email-masked] 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

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

---

From: [email-masked]
Date: Tue, 26 Jun 2007 13:07:17 -0400

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" <[email-masked]> 
06/25/2007 04:51 PM

To
[email-masked]
cc
[email-masked]
Subject
Re: [SWMP] Media Machines' initial design and code

[email-masked] 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

---

From: "Jay C. Weber" <[email-masked]>
Date: Tue, 26 Jun 2007 10:34:43 -0700

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?

In the client/server architecture we implemented, when a client
connects to the server and sends a Hello message, the server responds
with a Hello message followed by a series of set messages containing
latecomer state data.  So there is no explicit get request, unless you
want to consider Hello to subsume the semantics "send me latecomer
data".

Generalizing this issue a little, pub-sub requests are implicit in our
system.  Our applications and supporting architectures don't need
explicit pub-subs, but I can imagine some uses for pub-sub messages,
maybe we should add them to SWMP.

jay