Subject: [SWMP] My understanding so far

From: [email-masked]
Date: Fri, 10 Aug 2007 02:44:15 -0400

I have proposed some changes to the swmp specification and there has not 
been much resistance.  I thought it might help to rearticulate the swmp 
message set with my changes.  There were two main issues that I discussed 
earlier:

A)  As originally specified, swmp does not distinguish between requesting 
a state change and being notified of a state change.  It tends to treat 
the state sharing as largely a replication task with neither network 
element having a controlling role over the state.  I think it is more 
realistic and practical to assume that each network element has control 
over its state and the other network element may request changes and be 
notified when changes happen.  This leads to distinguishing requests from 
notifications.

B)  As originally specified, swmp does an implicit subscription to all 
state once the intitial message is sent.  I believe it makes more sense to 
have explicit subscriptions to some, but not necessarily all of the state.

In addition, I have found that four new issues (not previously identified) 
have prompted me to make some additional changes.

C)  SET is overloaded as both a way to change and create (and probably 
remove) a Field.  I think it is clearer to separate these operations. This 
leads to an ADDFIELD, REMOVEFIELD, and a SETFIELD.  Then for clarity ADD 
and REMOVE need to become ADDNODE and REMOVENODE.

D)  I believe that swmp will need the full complement of CRUD (create, 
read, update, delete) operations.  I think the absence of read methods 
derived from the implicit subscription to all state.  Now, that one can 
subscribe to some, but not all of the state, I believe it will become 
desirable to request the values of unsubscribed state.  This prompted me 
to add a GETNODE and a GETFIELD request, which required GETNODEREPLY and 
GETFIELDREPLY messages to return the response.

E)  The ADD message (now ADDNODE) provided the new value of the node in a 
parsable string.  This seemed both ill-specified (Does it only contain 
fields or can it contain children as well?) and X3D-specific.  While there 
is some appeal to setting all the information in one message, I decided to 
simplify matters by assuming that the node must be built through a series 
of ADDNODE and ADDFIELD messages.  Thus, the parsable nodestr disappeared.

F)  The use of the fieldId on the SET message as a way to allow faster 
field references seemed to require modification.  For one thing, it did 
not seem right that the name/id association was being defined by the 
requesting network element rather than the network element controlling the 
state.  Also, the first opportunity to associate a fieldName with an id 
occurs on the GETFIELDREPLY or ADDFIELDNOTIFY messages.  After moving 
those parameters, the new SETFIELD message reduces to the old SETF 
message.

Most of this comes from the paper found at 
http://www.mediamachines.com/hydra/swampweb3d2007.pdf identified in an 
earlier message. 
(http://www1.ietf.org/mail-archive/web/swmp/current/msg00010.html)  I have 
identified the aspects that are changes introduced by me using square 
brackets.  Issues/questions/comments are in squiggly braces.

ASSUMPTIONS

1)  swmp is designed to provide a simple means for propagating low latency 
state changes between network elements.
2)  swmp is peer-to-peer in the sense that neither of the two network 
elements using swmp takes on a distinguished role.  In other words, all 
messages are available for either network element to send to the other. 
(This does not preclude using swmp in a client-server fashion, but this is 
not "built-in" to the protocol.)
3)  swmp is designed for transport by either TCP or UDP.  It is expected 
that applications will begin with a TCP connection and add on UDP 
connections, if needed.
4)  swmp messages are defined as byte-encoded rather than "human readable" 
in an effort to decrease the message latency.  {I am not addressing the 
actual encoding here.}
5)  swmp messages communicate about state [that is managed by one or 
another of the communicating network elements].  This state is organized 
as a hierarchy of Nodes.
6)  swmp Nodes have a name, a type, any number of child Nodes, and any 
number of Fields.  {The paper indicates that the child Nodes form an 
ordered set, but does not provide adequate capability for managing the 
order.  I have not fixed this problem.}
7)  The name of a node must be unique across the entire hierarchy 
maintained by the network element.
8)  Although Nodes may be of many types, the Node types of  X3D scene 
graphs are expected to be basic types.  [Another basic Node type is likely 
to be a shard, meaning a section of virtual real estate.  In all 
likelihood, Node types will be of three varieties: basic (dictatied by the 
standard), conventional (generally agreed upon after the standard's 
specification), and ad hoc (used idiosyncratically by some non-standard 
application.)]
9)  swmp Fields have a name, a type, an identifier, and a value.
10)  The name of a Field must be unique among its Node's Fields, but it 
may be reused for different Nodes.
11)  The identifier of a field must be unique across the entire hierarchy 
maintained by the network element.
12)  Although Fields may be of many types, the Field types of X3D scene 
graphs are expected to be basic types.  Another basic Field type is likely 
to be velocity as identified in the paper.  [In all likelihood, Field 
types will be of three varieties: basic (dictated by the standard), 
conventional (generally agreed upon after the standard's specification), 
and ad hoc (used idiosyncratically by some non-standard application.)]

MESSAGES

Control Messages  (These are for establishing that a connection exists and 
that communication may occur.)

HELLO id ticket -- Both network elements must send a HELLO message as the 
first message on a swmp channel.  They send an id by which they identify 
themselves and a ticket for the other network element to use.  [Although 
the original protocol uses the HELLO message as an implicit subscription 
to all the state of the receiving network element, this implicit 
functionality has been removed here and is subsumed under the SUBSCRIBE 
message below.]  {The id and ticket seem to be needed for UDP messaging. 
Although it is clear that the ticket is used in all future messages, it is 
not clear how the id is used again.}

{BYE -- If we need HELLO to indicate the start of traffic, don't we want 
something to indicate that the traffic has ended.}

COMM protocol host port -- The COMM message is used to indicate a desire 
to initiate another swmp channel over the indicated transport protocol 
using the host and port.

ACK protocol host port -- Following the establishment of a secondary swmp 
channel using the COMM request.  The recipient of a HELLO message on the 
secondary channel {which should be both network elements eventually} must 
send an ACK message over the primary channel.

Content Messages (These are for communicating about the state being 
managed by the network elements.)

[ADDNODE parentName childName] -- This is a request to create a new child 
node for the specified parent.  {This corresponds directly to the ADD 
message in the paper with the nodestr parameter eliminated.  The paper 
indicates that ADD places the new child last in the ordered list of 
children.  If order is important, then this seems like inadequate 
control.}

[REMOVENODE nodeName] -- This is a request to delete a node. {This 
corresponds directly to the REMOVE message in the paper with the 
parentNode parameter removed.  Since nodeNames must be unique over the 
entire Node hierarchy, it is unclear why the parentName was required, so I 
eliminated it.  Although the paper does not say so, presumably a 
REMOVENODE request deletes all the children of the node as well.}

[GETNODE nodeName -- This is a request to retrieve the information about a 
node.  I added this to round out the CRUD capabilities for Node.]

[GETNODEREPLY nodeName listOfChildNodeNames listOfFieldNames -- There are 
several ways to go with a reply like this.  I am assuming I will give you 
enough information to figure out the structure of a node, ie, the names, 
but not the actual values.]

[ADDFIELD nodeName fieldName type value -- This is a request to add a new 
field to an existing node.  The type and value may be specified by the 
requestor.  The fieldId is assigned by the controlling network element and 
is obtained in the ADDFIELDNOTIFY message, if a subscription is in place. 
In the absence of a subscription, a GETFIELD request would be needed to 
obtain the id.  {In the paper, I believe this capability was provided via 
the SET message.}]

[REMOVEFIELD fieldId -- This is a request to remove the specified field. 
The fieldId would have been provided by a prior GETFIELDREPLY or 
ADDFIELDNOTIFY message.  {I'm not sure how this was accomplished in the 
paper.}]

[SETFIELD fieldId value] -- This is a request to update the value of a 
Field. The fieldId would have been provided by a prior GETFIELDREPLY or 
ADDFIELDNOTIFY message.  {This corresponds directly to the SETF message in 
the paper.}

[GETFIELD nodeName fieldName -- This is a request to retrieve the value of 
a field.]

[GETFIELDREPLY nodeName fieldName type fieldID value -- This message sends 
back the information from a GETFIELD request.  This is one way to discover 
the name/id equivalence for a field.]

[SUBSCRIBE nodeName lastId -- This is a request to subscribe to all 
changes associated with this Node and any of its descendants.  If the Node 
is removed, there will be a final REMOVENOTIFY for the Node after which 
the subscription is canceled.  It is permissable for a network element to 
have more than one subscription request active at the same time.  In the 
event that a subscription is added for a descendant of another subscribed 
Node, both subscriptions are active, but only one notification is sent for 
any change that occurs.  A secondary purpose of the SUBSCRIBE request is 
to cause the controlling network element to "dump" the state of the 
subscribed node and its descendants.  This is done as a sequence of 
notifications.  The lastId parameter identifies the last notification from 
the subscribed network element for which an accurate record of the state 
is available. {The paper calls for all messages to contain a sequence 
number.  This seems a sensible candidate for identifying the last 
notification message.}  If the lastId is zero, then the subscribed network 
element should assume that the subscribing network element has no record 
of the subscribed nodes and will intitiate a series of ADDNODENOTIFY 
messages in breadth first order.  Following each ADDNODENOTIFY message 
will be the set of ADDFIELDNOTIFY messages needed to identify all the 
fields of the node.  If the last ID is non-zero, then the subscribed 
network element should assume tat the subscribing network element has an 
accurate record of the state as of the identified notification message. It 
should issue a series of REMOVENODENOTIFY messages, followed by a set of 
ADDNODENOTIFY messages in breadth first order.  Following each 
ADDNODENOTIFY message will be a set of REMOVEFIELDNOTIFY, ADDFIELDNOTIFY, 
and SETFIELDNOTIFY messages for establishing the state of the fields. 
{Note:  The collection of notifications should be efficient and not simply 
a log of all that happened since the prior subscription.}  All such 
notifications received in response to the SUBSCRIBE request should be sent 
prior to sending any notifcations caused by additional changes to the 
state.]

[UNSUBSCRIBE nodeName -- This is a request to cancel an existing 
subscription.  If the corresponding SUBSCRIBE request was never made or 
the subscription was canceled because the Node was removed, the 
UNSUBSCRIBE request is a no-op.  When subscriptions exist for a Node and 
one of its descendants, cancelation of the descendant's subscription will 
not affect the notifications received.  Cancelation of the ancestor's 
subscription reduces the set of subscribed nodes down to the subscribed 
descendant and its descendants.]

[FAILNOTIFY requestId reason -- Since all of the previous methods are 
requests of the network element controlling the state, it is possible that 
the controlling network element will reject the request.  There will need 
to be a way to communicate the failure and bind it to the rejected 
message. {The paper calls for all messages to contain a sequence number. 
This seems a sensible candidate for identifying the rejected message.}]

[ADDNODENOTIFY parentName childName originatorFlag -- This message 
notifies one network element of changes to any subscribed state due to an 
ADDNODE request.  This message is sent to the requesting node as well, if 
a subscription is in place. The originatorFlag is used to signal how the 
originating request was handled.  The flag has three values: 
not-requestor, asis, modified.  The not-requestor value is used when the 
recipient was not the requestor of the change.  The asis value indicates 
that the recipient originated the request and the request was honored 
without modification.  The modified value indicates that the recipient 
originated the request, but the actual value used is not the same as the 
requested value.]

[REMOVENODENOTIFY nodeName originatorFlag -- This message notifies one 
network element of changes to any subscribed state due to a REMOVENODE 
request.  The message is sent to the requesting node as well and the 
originatorFlag has the same meaning as in ADDNODENOTIFY, though it is 
difficult to imagine how the modified value might be used.]

[ADDFIELDNOTIFY nodeName fieldName type fieldId value originatorFlag -- 
This message notifies one network element of changes to any subscribed 
state due to an ADDFIELD request.  The message is sent to the requesting 
node as well and the originatorFlag has the same meaning as in 
ADDNODENOTIFY.  This message communicates the name/id equivalence for the 
field.]

[REMOVEFIELDNOTIFY fieldId originatorFlag -- This message notifies one 
network element of changes to any subscribed state due to a REMOVEFIELD 
request.  The message is sent to the requesting node as well and the 
originatorFlag has the same meaning as in ADDNODENOTIFY, though it is 
difficult to imagine how the modified value might be used.]

[SETFIELDNOTIFY fieldId value originatorFlag -- This message notifies one 
network element of changes to any subscribed state due to a SETFIELD 
request.  The message is sent to the requesting node as well and the 
originatorFlag has the same meaning as in ADDNODENOTIFY.  {Note: Signaling 
the SETFIELD originator is needed for situations like collision detection 
where the actual position of an object ends up being something different 
from the request.}]

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

---

From: Roland Weber <[email-masked]>
Date: Fri, 10 Aug 2007 18:49:27 +0200

Hello all,

my name is Roland Weber. I've subscribed to this list out of a purely academic
interest. I intend to invest a slice of my private time on following the
discussions, throwing in my two cents once in a while. This looks like a good
occasion to start with that. I'm not familiar with 3D graphics, except for
having read through a VRML spec about 10 years ago. I am familiar with HTTP
and have some understanding of communication protocols in general. My time
will not allow for installing and experimenting with software, nor for much
background reading. My apologies if some of my comments are already addressed
in the referenced paper, I didn't read it yet. So here are my thoughts on
reading the summary...

ASSUMPTIONS:
2) maybe mention explicitly that the protocol is meant for one-to-one
communication. That is not obvious from assumption 1, but implicit in
assumption 2 and the rest of the summary. Given the popularity of P2P
networks, many people will associate P2P with many-to-many communication.

4) I associate byte encoding more with message size rather than latency. Maybe
mention both?

6,7,9) Nodes have a name, where the name is unique across the hierarchy.
Fields have a name and identifier, where the name is not unique across the
hierarchy. Maybe the terminology is inherited from other specifications, but I
suggest to give the nodes an identifier instead of a name. Then identifiers
are unique across the hierarchy for both nodes and fields, while names are not.

Control MESSAGES:
For one-to-one communication, these messages look sufficient. For many-to-many
communication, I would expect some mechanism to exchange information about
peers. In that context, the id in the HELLO message would become significant.
It could also gain significance in content messages, for example to identify
the originator of a change in notification messages.
BYE is a good idea. It could implicitly cancel all subscriptions, assuming
that subscriptions are non-persistent.
The arguments in the COMM message are the sender's address, indicating where
the receiver of the message should send it's hello to. The tickets of the
primary channel will be used on all secondary channels, too?

Content MESSAGES:
I assume there will be a mechanism to send groups of these messages, for
example in a single UDP packet. There could be cases where for example several
fields of a node have to be updated simultaneously to avoid an inconsistent
intermediate state. If messages have sequence numbers, will those be on the
group level or on the message level? In the first case, FAILNOTIFY could not
use the message sequence number alone as the request id.
The GETNODEREPLY can become large, if there are many fields and/or children to
the node. This looks like a candidate for finer grained scoping in the
request. For example, only the fields or only the children. Or only a subset
of the children. In the latter case, order of children could become relevant
for subset selection. Or only fields and children that have changed since a
particular time, using the lastId trick of SUBSCRIBE.
The dumping of subtree state in response to a SUBSCRIBE has even more
potential to generate a lot of data in replies. In one-to-one communication,
there is probably no way to avoid it (many-to-many could engage other peers to
send some of the dump).
Are there cases where somebody could want a subtree dump without a
subscription, snapshot-like?

other thoughts regarding subscriptions:
The lastId based on message sequence numbers seems OK for one-to-one
communication. How about a scenario where a 3D world is hosted in parallel on
several servers? A client could have a session with server X at one time, and
choose server Y for the next session. Would the client have to get a full
dump? Would the servers be supposed to synchronize their message sequence
numbers? Should there be a world-specific lastId rather than one based on
message sequence numbers? Another solution could be structured IDs, so that
the client sends "server X, sequence number whatever" to server Y.
Can subscriptions run out of sync between peers? A request GETSUBSCRIPTIONS
with corresponding reply could help to recover from that. Again, a case where
the response may be large.

I hope you find some of my suggestions useful.

best regards,
  Roland Weber

---

From: "Jay C. Weber" <[email-masked]>
Date: Thu, 16 Aug 2007 08:00:20 -0700

Hi John, sorry for the late reply, I've been "swamped" with corporate
stuff.

[email-masked] wrote:

I have proposed some
changes to the
swmp specification and there has not been much resistance.  I thought
it might help to rearticulate the swmp message set with my changes.

Very thoughtful analysis and detailed proposals, and I, for one, agree
with most of it.  Your clear explication of assumptions is fantastic.
I'll add thoughts regarding details but first I want to make sure
everybody understands the context of this list.

This is an "interest" list for disucssion about the topic of a "simple
wide-area multiuser-3D protocol", being a first step towards a Working
Group and then the rfc process.  But just being at the
interest-discussion stage, we don't yet have a process for submission
of changes, approval of changes, or publishing of changes.  Indeed we
don't really have a specification to change except for the strawman
work I submitted, in the hopes that people find it useful as a starting
point.

Thus your analysis is most welcome, but to take it to the next step we
need to draft a charter, nominate and choose working group chairs.  Are
people anxious to go to the working group stage?  If so, lets pop up a
level and discuss the charter.

jay

There
were two main issues that I discussed earlier:

A)  As originally specified, swmp
does not distinguish between requesting a state change and being
notified
of a state change.  It tends to treat the state sharing as largely
a replication task with neither network element having a controlling
role
over the state.  I think it is more realistic and practical to assume
that each network element has control over its state and the other
network
element may request changes and be notified when changes happen.  This
leads to distinguishing requests from notifications.

B)  As originally specified, swmp
does an implicit subscription to all state once the intitial message is
sent.  I believe it makes more sense to have explicit subscriptions
to some, but not necessarily all of the state.

In addition, I have found that four
new issues (not previously identified) have prompted me to make some
additional
changes.

C)  SET is overloaded as both a
way to change and create (and probably remove) a Field.  I think it
is clearer to separate these operations.  This leads to an ADDFIELD,
REMOVEFIELD, and a SETFIELD.  Then for clarity ADD and REMOVE need
to become ADDNODE and REMOVENODE.

D)  I believe that swmp will need
the full complement of CRUD (create, read, update, delete) operations.
I think the absence of read methods derived from the implicit
subscription
to all state.  Now, that one can subscribe to some, but not all of
the state, I believe it will become desirable to request the values of
unsubscribed state.  This prompted me to add a GETNODE and a GETFIELD
request, which required GETNODEREPLY and GETFIELDREPLY messages to
return
the response.

E)  The ADD message (now ADDNODE)
provided the new value of the node in a parsable string.  This seemed
both ill-specified (Does it only contain fields or can it contain
children
as well?) and X3D-specific.  While there is some appeal to setting
all the information in one message, I decided to simplify matters by
assuming
that the node must be built through a series of ADDNODE and ADDFIELD
messages.
Thus, the parsable nodestr disappeared.

F)  The use of the fieldId on the
SET message as a way to allow faster field references seemed to require
modification.  For one thing, it did not seem right that the name/id
association was being defined by the requesting network element rather
than the network element controlling the state.  Also, the first
opportunity
to associate a fieldName with an id occurs on the GETFIELDREPLY or
ADDFIELDNOTIFY
messages.  After moving those parameters, the new SETFIELD message
reduces to the old SETF message.

Most of this comes from the paper
found
at http://www.mediamachines.com/hydra/swampweb3d2007.pdf identified in
an earlier message.
(http://www1.ietf.org/mail-archive/web/swmp/current/msg00010.html)
I have identified the aspects that are changes introduced by me using
square brackets.  Issues/questions/comments are in squiggly braces.

ASSUMPTIONS

1)  swmp is designed to provide
a simple means for propagating low latency state changes between
network
elements.

2)  swmp is peer-to-peer in the
sense that neither of the two network elements using swmp takes on a
distinguished
role.  In other words, all messages are available for either network
element to send to the other.  (This does not preclude using swmp
in a client-server fashion, but this is not "built-in" to the
protocol.)

3)  swmp is designed for transport
by either TCP or UDP.  It is expected that applications will begin
with a TCP connection and add on UDP connections, if needed.

4)  swmp messages are defined as
byte-encoded rather than "human readable" in an effort to decrease
the message latency.  {I am not addressing the actual encoding here.}

5)  swmp messages communicate about
state [that is managed by one or another of the communicating network
elements].
This state is organized as a hierarchy of Nodes.

6)  swmp Nodes have a name, a type,
any number of child Nodes, and any number of Fields.  {The paper
indicates
that the child Nodes form an ordered set, but does not provide adequate
capability for managing the order.  I have not fixed this problem.}

7)  The name of a node must be
unique across the entire hierarchy maintained by the network element.

8)  Although Nodes may be of many
types, the Node types of  X3D scene graphs are expected to be basic
types.  [Another basic Node type is likely to be a shard, meaning
a section of virtual real estate.  In all likelihood, Node types will
be of three varieties: basic (dictatied by the standard), conventional
(generally agreed upon after the standard's specification), and ad hoc
(used idiosyncratically by some non-standard application.)]

9)  swmp Fields have a name, a
type, an identifier, and a value.

10)  The name of a Field must be
unique among its Node's Fields, but it may be reused for different
Nodes.

11)  The identifier of a field
must be unique across the entire hierarchy maintained by the network
element.

12)  Although Fields may be of
many types, the Field types of X3D scene graphs are expected to be
basic
types.  Another basic Field type is likely to be velocity as identified
in the paper.  [In all likelihood, Field types will be of three
varieties:
basic (dictated by the standard), conventional (generally agreed upon
after
the standard's specification), and ad hoc (used idiosyncratically by
some
non-standard application.)]

MESSAGES

Control Messages  (These are for
establishing that a connection exists and that communication may occur.)

HELLO id ticket -- Both network
elements
must send a HELLO message as the first message on a swmp channel.  They
send an id by which they identify themselves and a ticket for the other
network element to use.  [Although the original protocol uses the
HELLO message as an implicit subscription to all the state of the
receiving
network element, this implicit functionality has been removed here and
is subsumed under the SUBSCRIBE message below.]  {The id and ticket
seem to be needed for UDP messaging.  Although it is clear that the
ticket is used in all future messages, it is not clear how the id is
used
again.}

{BYE -- If we need HELLO to indicate
the start of traffic, don't we want something to indicate that the
traffic
has ended.}

COMM protocol host port -- The COMM
message is used to indicate a desire to initiate another swmp channel
over
the indicated transport protocol using the host and port.

ACK protocol host port -- Following
the establishment of a secondary swmp channel using the COMM request.
The
recipient of a HELLO message on the secondary channel {which should be
both network elements eventually} must send an ACK message over the
primary
channel.

Content Messages (These are for
communicating
about the state being managed by the network elements.)

[ADDNODE parentName childName] --
This
is a request to create a new child node for the specified parent.
{This
corresponds directly to the ADD message in the paper with the nodestr
parameter
eliminated.  The paper indicates that ADD places the new child last
in the ordered list of children.  If order is important, then this
seems like inadequate control.}

[REMOVENODE nodeName] -- This is a
request
to delete a node. {This corresponds directly to the REMOVE message in
the
paper with the parentNode parameter removed.  Since nodeNames must
be unique over the entire Node hierarchy, it is unclear why the
parentName
was required, so I eliminated it.  Although the paper does not say
so, presumably a REMOVENODE request deletes all the children of the
node
as well.}

[GETNODE nodeName -- This is a
request
to retrieve the information about a node.  I added this to round out
the CRUD capabilities for Node.]

[GETNODEREPLY nodeName
listOfChildNodeNames
listOfFieldNames -- There are several ways to go with a reply like
this.
I am assuming I will give you enough information to figure out the
structure of a node, ie, the names, but not the actual values.]

[ADDFIELD nodeName fieldName type
value
-- This is a request to add a new field to an existing node.  The
type and value may be specified by the requestor.  The fieldId is
assigned by the controlling network element and is obtained in the
ADDFIELDNOTIFY
message, if a subscription is in place.  In the absence of a
subscription,
a GETFIELD request would be needed to obtain the id.  {In the paper,
I believe this capability was provided via the SET message.}]

[REMOVEFIELD fieldId -- This is a
request
to remove the specified field.  The fieldId would have been provided
by a prior GETFIELDREPLY or ADDFIELDNOTIFY message.  {I'm not sure
how this was accomplished in the paper.}]

[SETFIELD fieldId value] -- This is
a request to update the value of a Field. The fieldId would have been
provided
by a prior GETFIELDREPLY or ADDFIELDNOTIFY message.  {This corresponds
directly to the SETF message in the paper.}

[GETFIELD nodeName fieldName -- This
is a request to retrieve the value of a field.]

[GETFIELDREPLY nodeName fieldName
type
fieldID value -- This message sends back the information from a
GETFIELD
request.  This is one way to discover the name/id equivalence for
a field.]

[SUBSCRIBE nodeName lastId -- This
is
a request to subscribe to all changes associated with this Node and any
of its descendants.  If the Node is removed, there will be a final
REMOVENOTIFY for the Node after which the subscription is canceled.  It
is permissable for a network element to have more than one subscription
request active at the same time.  In the event that a subscription
is added for a descendant of another subscribed Node, both
subscriptions
are active, but only one notification is sent for any change that
occurs.
A secondary purpose of the SUBSCRIBE request is to cause the
controlling
network element to "dump" the state of the subscribed node and
its descendants.  This is done as a sequence of notifications.  The
lastId parameter identifies the last notification from the subscribed
network
element for which an accurate record of the state is available. {The
paper
calls for all messages to contain a sequence number.  This seems a
sensible candidate for identifying the last notification message.}  If
the lastId is zero, then the subscribed network element should assume
that
the subscribing network element has no record of the subscribed nodes
and
will intitiate a series of ADDNODENOTIFY messages in breadth first
order.
Following each ADDNODENOTIFY message will be the set of ADDFIELDNOTIFY
messages needed to identify all the fields of the node.  If the last
ID is non-zero, then the subscribed network element should assume tat
the
subscribing network element has an accurate record of the state as of
the
identified notification message.  It should issue a series of
REMOVENODENOTIFY
messages, followed by a set of ADDNODENOTIFY messages in breadth first
order.  Following each ADDNODENOTIFY message will be a set of
REMOVEFIELDNOTIFY,
ADDFIELDNOTIFY, and SETFIELDNOTIFY messages for establishing the state
of the fields.  {Note:  The collection of notifications should
be efficient and not simply a log of all that happened since the prior
subscription.}  All such notifications received in response to the
SUBSCRIBE request should be sent prior to sending any notifcations
caused
by additional changes to the state.]

[UNSUBSCRIBE nodeName -- This is a
request
to cancel an existing subscription.  If the corresponding SUBSCRIBE
request was never made or the subscription was canceled because the
Node
was removed, the UNSUBSCRIBE request is a no-op.  When subscriptions
exist for a Node and one of its descendants, cancelation of the
descendant's
subscription will not affect the notifications received.  Cancelation
of the ancestor's subscription reduces the set of subscribed nodes down
to the subscribed descendant and its descendants.]

[FAILNOTIFY requestId reason --
Since
all of the previous methods are requests of the network element
controlling
the state, it is possible that the controlling network element will
reject
the request.  There will need to be a way to communicate the failure
and bind it to the rejected message. {The paper calls for all messages
to contain a sequence number.  This seems a sensible candidate for
identifying the rejected message.}]

[ADDNODENOTIFY parentName childName
originatorFlag -- This message notifies one network element of changes
to any subscribed state due to an ADDNODE request.  This message is
sent to the requesting node as well, if a subscription is in place. The
originatorFlag is used to signal how the originating request was
handled.
The flag has three values: not-requestor, asis, modified.  The
not-requestor value is used when the recipient was not the requestor of
the change.  The asis value indicates that the recipient originated
the request and the request was honored without modification.  The
modified value indicates that the recipient originated the request, but
the actual value used is not the same as the requested value.]

[REMOVENODENOTIFY nodeName
originatorFlag
-- This message notifies one network element of changes to any
subscribed
state due to a REMOVENODE request.  The message is sent to the
requesting
node as well and the originatorFlag has the same meaning as in
ADDNODENOTIFY,
though it is difficult to imagine how the modified value might be used.]

[ADDFIELDNOTIFY nodeName fieldName
type
fieldId value originatorFlag -- This message notifies one network
element
of changes to any subscribed state due to an ADDFIELD request.  The
message is sent to the requesting node as well and the originatorFlag
has
the same meaning as in ADDNODENOTIFY.  This message communicates the
name/id equivalence for the field.]

[REMOVEFIELDNOTIFY fieldId
originatorFlag
-- This message notifies one network element of changes to any
subscribed
state due to a REMOVEFIELD request.  The message is sent to the
requesting
node as well and the originatorFlag has the same meaning as in
ADDNODENOTIFY,
though it is difficult to imagine how the modified value might be used.]

[SETFIELDNOTIFY fieldId value
originatorFlag
-- This message notifies one network element of changes to any
subscribed
state due to a SETFIELD request.  The message is sent to the requesting
node as well and the originatorFlag has the same meaning as in
ADDNODENOTIFY.
{Note:  Signaling the SETFIELD originator is needed for situations
like collision detection where the actual position of an object ends up
being something different from the request.}]

--

Jay C. Weber, Ph.D.

CTO, Media Machines Inc.

650-279-2311

---

From: "Jay C. Weber" <[email-masked]>
Date: Fri, 24 Aug 2007 08:39:21 -0700

Jon: there are many issues in your note so I will respond in pieces, so
we can discuss issues separately and without undue reading burden on
the others :-)

A)  As originally
specified, swmp
element may request changes and be notified when changes happen.

I agree that distinction is important.  The original SWMP doesn't take
a position on which elements have a controlling role, leaving that to
the semantics of the architecture.  My intent was to separate the two
layers of semantics, so that the protocol would be kept simple and be
applicable to many different architectures.

E.g., a peer-peer architecture would specify, as you say, that "each
network element has control over its state and the other network
element may request changes and be notified when changes happen", but
some client-server architectures (including most MMOGs) vest all
control over state in the server element.  That is, a state message
from the server is always an authoritative notification, and a state
message from a client is always a provisional request.  In such an
architecture, network elements get this semantics from their known
roles, they don't need to get it from inside the messages.

jay

--

Jay C. Weber, Ph.D.

CTO, Media Machines Inc.

650-279-2311

---

From: "Jay C. Weber" <[email-masked]>
Date: Fri, 24 Aug 2007 09:01:40 -0700

C)  SET is overloaded as
both a

It's true that setting a previously-nonexistent field had the
side-effect of "creating" the field.  Or, one could think of it as all
fields exist, but have undefined values until set.  This is usually the
semantics of associative arrays, and has a useful simplicity, e.g., in
web DOM and some XML apis.  I guess it's a matter of taste, but it is a
way to keep the protocol simpler.

jay

--

Jay C. Weber, Ph.D.

CTO, Media Machines Inc.

650-279-2311

---

From: "Jay C. Weber" <[email-masked]>
Date: Fri, 24 Aug 2007 09:03:44 -0700

D)  I believe that swmp
will need

Interesting, but the danger here is "return the response".  There's a
big advantage to resisting the introduction of RPC-style elements in a
context of minimizing latency -- obviously RPC involves a round-trip of
messaging.  Keeping SWMP asynchronous will keep it mapping simply and
efficiently onto datagram transports.

I like the PUB-SUB suggestions you've made, especially because PUB-SUB
can be designed to work well in an asynchronous protocol.

jay

--

Jay C. Weber, Ph.D.

CTO, Media Machines Inc.

650-279-2311

---

From: [email-masked]
Date: Fri, 24 Aug 2007 12:12:26 -0400

Jay:

I understand that in a client-server setup the role would disambiguate the 
message, but I don't see what is gained by making the message be the same. 
 There is no real saving in the protocol by using the same name for 
different purposes and it can be confusing to anyone trying to understand 
the protocol.  I lean in the direction of avoiding overloading messages. 
For distinct purposes, I am inclined to use distinct messages.  I don't 
think the code cares either way and it makes the whole thing clearer to 
anyone studying the protocol.

As for peer-to-peer situations, I was worried whether there might be 
situations in which the ambiguity of SET might create difficulties.  I 
haven't really figured it all out, but the kind of thing I was worried 
about was cycles in which a peer is receiving a SET message as 
notification for a change that it actually originated.  Being unable to 
tell that it is a notification and not a request for change, it might 
apply the change and send out its notifications and simply keep the cycle 
going.  My guess is that a simple two peer setup could detect and suppress 
the problem.  Perhaps it is only an issue when there are three or more 
peers and the communication patterns form a cycle.

In any case, I think it is better to use separate messages for distinct 
purposes.  The protocol only looks simpler in its message count.  For the 
diligent student of the protocol, overloading can actually make it all 
more complex.

jfp

"Jay C. Weber" <[email-masked]> 
08/24/2007 11:39 AM

To
[email-masked]
cc
[email-masked]
Subject
semantic layers

Jon: there are many issues in your note so I will respond in pieces, so we 
can discuss issues separately and without undue reading burden on the 
others :-)

[email-masked] wrote: 
A)  As originally specified, swmp does not distinguish between requesting 
a state change and being notified of a state change.  It tends to treat 
the state sharing as largely a replication task with neither network 
element having a controlling role over the state.  I think it is more 
realistic and practical to assume that each network element has control 
over its state and the other network element may request changes and be 
notified when changes happen.
I agree that distinction is important.  The original SWMP doesn't take a 
position on which elements have a controlling role, leaving that to the 
semantics of the architecture.  My intent was to separate the two layers 
of semantics, so that the protocol would be kept simple and be applicable 
to many different architectures.

E.g., a peer-peer architecture would specify, as you say, that "each 
network element has control over its state and the other network element 
may request changes and be notified when changes happen", but some 
client-server architectures (including most MMOGs) vest all control over 
state in the server element.  That is, a state message from the server is 
always an authoritative notification, and a state message from a client is 
always a provisional request.  In such an architecture, network elements 
get this semantics from their known roles, they don't need to get it from 
inside the messages.

jay

---

From: "Jay C. Weber" <[email-masked]>
Date: Fri, 24 Aug 2007 09:18:23 -0700

F)  The use of the
fieldId on the
SET message as a way to allow faster field references seemed to require
modification.  For one thing, it did not seem right that the name/id
association was being defined by the requesting network element rather
than the network element controlling the state.

It's really about this:  element A needs to specify a
<node,field> in a message to element B.  If A sends B a number of
such messages, it's worth setting up a shorthand for that pair.  Thus
my SWMP design was to add a message parameter to SET, a non-negative
integer fieldId, that when non-zero means "if I use this fieldId in the
future it means this <node,field> pair".  And I created a SETF
message that uses the fieldId.  Thus one SET message would be followed
by many SETF messages, the advantage being that SETF messages are much
shorter.

It doesn't matter what the architectural roles are of A and B, it's
just a bilateral mechanism to create a shorthand, and it makes sense to
me that the element that coins the <node,field> pair is the one
to coin the shorthand for it.

jay

--

Jay C. Weber, Ph.D.

CTO, Media Machines Inc.

650-279-2311

---

From: [email-masked]
Date: Fri, 24 Aug 2007 12:23:24 -0400

Jay:

I think you are right.  This one is mostly a matter of taste.  I tend to 
look for the CRUD (Create, Read, Update, and Delete) operators as soon as 
I see any state management.  So, I find it easier to understand the 
protocol or API when these operators are expicitly available.

To reiterate something I said before, I don't think one should equate 
message count with simplicity.  The two legitimate complexity concerns 
seem to me to be complexity for the implementation and complexity for the 
user.  Implementations can be simpler when different operations are 
clearly differentiated.  The user's comprehension is facilitated when 
overloading is avoided.

Having said all that, while I prefer differentiating SET and ADD, it is 
not a biggy for me.

jfp

08/24/2007 12:01 PM

To
field-creation semantics

[email-masked] wrote: 
C)  SET is overloaded as both a way to change and create (and probably 
remove) a Field.  I think it is clearer to separate these operations. This 
leads to an ADDFIELD, REMOVEFIELD, and a SETFIELD.  Then for clarity ADD 
and REMOVE need to become ADDNODE and REMOVENODE. 
It's true that setting a previously-nonexistent field had the side-effect 
of "creating" the field.  Or, one could think of it as all fields exist, 
but have undefined values until set.  This is usually the semantics of 
associative arrays, and has a useful simplicity, e.g., in web DOM and some 
XML apis.  I guess it's a matter of taste, but it is a way to keep the 
protocol simpler.

jay

---

From: [email-masked]
Date: Fri, 24 Aug 2007 12:41:12 -0400

Jay:

I understand your concern about having request-response style messaging. I 
am worried that it cannot be completely avoided.  Once we assume that 
there are multiple nodes to subscribe to, we face the possibility that it 
will be necessary to query the nodes to determine which one to subscribe 
to.   Moreover, if you saw my discussion of a swmp url, we might find it 
desirable to query a node for some information (ie, the URL of its static 
representation) prior to actually subscribing.

I do not feel that a query response capability in the protocol should be 
equated with an RPC mode of interaction.  The problem in RPC is not that 
the protocol messages are synchronous; they're not.  It is that the API 
for accessing the protocol is synchronous.  A listener or callback 
approach can deal with this.

I agree that a query facility might be problematic for a lossy transport 
so I would not recommend that it be used there.  Frankly, the SUBSCRIBE 
message is even more problematic for UDP if the sequence of state updates 
that ensue are critical.  My guess is that the decision of when to use TCP 
and when to use UDP for swmp will be a matter of some delicacy within an 
application.  Personally, I would probably use TCP for most things and 
only use UDP for streams of updates where the loss of one update is no big 
deal (eg, position updates.)  Indeed, one of the things I would like to do 
is subscribe on a TCP channel for updates that will occur on a UDP 
channel.  I don't think we have anticipated that yet.

jfp

08/24/2007 12:03 PM

To
[email-masked]
cc
[email-masked]
Subject
introducing RPC to an asynchronous protocol

[email-masked] wrote:
D)  I believe that swmp will need the full complement of CRUD (create, 
read, update, delete) operations.  I think the absence of read methods 
derived from the implicit subscription to all state.  Now, that one can 
subscribe to some, but not all of the state, I believe it will become 
desirable to request the values of unsubscribed state.  This prompted me 
to add a GETNODE and a GETFIELD request, which required GETNODEREPLY and 
GETFIELDREPLY messages to return the response. 
Interesting, but the danger here is "return the response".  There's a big 
advantage to resisting the introduction of RPC-style elements in a context 
of minimizing latency -- obviously RPC involves a round-trip of messaging. 
 Keeping SWMP asynchronous will keep it mapping simply and efficiently 
onto datagram transports.

I like the PUB-SUB suggestions you've made, especially because PUB-SUB can 
be designed to work well in an asynchronous protocol.

jay

---

From: "Tony Parisi" <[email-masked]>
Date: Fri, 24 Aug 2007 10:58:24 -0700

If we're talking about an either/or I prefer pub-sub to readback.

Tony

  _____  

From: Jay C. Weber [mailto:[email-masked]] 
Sent: Friday, August 24, 2007 9:04 AM
To: [email-masked]
Cc: [email-masked]
Subject: [SWMP] introducing RPC to an asynchronous protocol

D)  I believe that swmp will need the full complement of CRUD (create, read,
update, delete) operations.  I think the absence of read methods derived
from the implicit subscription to all state.  Now, that one can subscribe to
some, but not all of the state, I believe it will become desirable to
request the values of unsubscribed state.  This prompted me to add a GETNODE
and a GETFIELD request, which required GETNODEREPLY and GETFIELDREPLY
messages to return the response. 

Interesting, but the danger here is "return the response".  There's a big
advantage to resisting the introduction of RPC-style elements in a context
of minimizing latency -- obviously RPC involves a round-trip of messaging.
Keeping SWMP asynchronous will keep it mapping simply and efficiently onto
datagram transports.

jay

-- 
Jay C. Weber, Ph.D. 
CTO, Media Machines Inc. 
650-279-2311

---

From: "Tony Parisi" <[email-masked]>
Date: Fri, 24 Aug 2007 10:58:24 -0700

Jay

That's probably worth some clarifying language when we write the real SWMP
spec. Remember folks that all of this discussion is playing off of a short
white paper

Tony

  _____  

From: Jay C. Weber [mailto:[email-masked]] 
Sent: Friday, August 24, 2007 8:39 AM
To: [email-masked]
Cc: [email-masked]
Subject: [SWMP] semantic layers

Jon: there are many issues in your note so I will respond in pieces, so we
can discuss issues separately and without undue reading burden on the others
:-)

A)  As originally specified, swmp does not distinguish between requesting a
state change and being notified of a state change.  It tends to treat the
state sharing as largely a replication task with neither network element
having a controlling role over the state.  I think it is more realistic and
practical to assume that each network element has control over its state and
the other network element may request changes and be notified when changes
happen.

I agree that distinction is important.  The original SWMP doesn't take a
position on which elements have a controlling role, leaving that to the
semantics of the architecture.  My intent was to separate the two layers of
semantics, so that the protocol would be kept simple and be applicable to
many different architectures.

E.g., a peer-peer architecture would specify, as you say, that "each network
element has control over its state and the other network element may request
changes and be notified when changes happen", but some client-server
architectures (including most MMOGs) vest all control over state in the
server element.  That is, a state message from the server is always an
authoritative notification, and a state message from a client is always a
provisional request.  In such an architecture, network elements get this
semantics from their known roles, they don't need to get it from inside the
messages.

jay

-- 
Jay C. Weber, Ph.D. 
CTO, Media Machines Inc. 
650-279-2311

---

From: [email-masked]
Date: Wed, 29 Aug 2007 09:37:28 -0400

Jay:

I think I understand the mechanism and I understand that either side of 
the pairwise communication can establish the mapping of an ID to a 
<node,field>.

Perhaps it is a small thing, but in a situation in which one network 
element (say a server) manages the data, it would be helpful if it could 
use the same ID for all the other network elements seeking to use the 
data.  If the other network elements may establish the mapping, then it 
must keep independent mappings for each network element being served.  If, 
on the other hand, we can contrive the protocol, so that the network 
element managing the data establishes the ID mapping, then it could use 
the same mapping for all network elements seeking service.

jfp

"Jay C. Weber" <[email-masked]> wrote on 08/24/2007 12:18:23 PM:

> F)  The use of the fieldId on the SET message as a way to allow 
> faster field references seemed to require modification.  For one 
> thing, it did not seem right that the name/id association was being 
> defined by the requesting network element rather than the network 
> element controlling the state.
> It's really about this:  element A needs to specify a <node,field> 
> in a message to element B.  If A sends B a number of such messages, 
> it's worth setting up a shorthand for that pair.  Thus my SWMP 
> design was to add a message parameter to SET, a non-negative integer
> fieldId, that when non-zero means "if I use this fieldId in the 
> message that uses the fieldId.  Thus one SET message would be 
> followed by many SETF messages, the advantage being that SETF 
> messages are much shorter.
> 
> just a bilateral mechanism to create a shorthand, and it makes sense
> to me that the element that coins the <node,field> pair is the one

---

From: "Jay C. Weber" <[email-masked]>
Date: Wed, 29 Aug 2007 08:01:21 -0700

I think I understand the
mechanism and
I understand that either side of the pairwise communication can
establish
the mapping of an ID to a <node,field>.

Yes but as I defined it that mapping only applies in that one direction
of the communication.  E.g., element A tells element B that "I will use
the id '2' to represent the pair <node12,positionfield>", which
constrains the meaning of future messages from A, but does not say
anything about what field ids B will use in messages to A.

Perhaps it is a small
thing, but in
a situation in which one network element (say a server) manages the
data,
it would be helpful if it could use the same ID for all the other
network
elements seeking to use the data.  If the other network elements may
establish the mapping, then it must keep independent mappings for each
network element being served.  If, on the other hand, we can contrive
the protocol, so that the network element managing the data establishes
the ID mapping, then it could use the same mapping for all network
elements
seeking service.

The server in my current client/server architecture (and
implementation) does already use the same ID mapping for messages to
all its clients, possible because of this unidirectionality of field
ids.  This is indeed very convenient when blasting out an update to all
the clients, not having to customize field ids for each message.  (and
this is really important for an architecture that uses multicast.)

But you are right that my server maintains independent mappings for
each inbound message queue.  This requires some bookkeeping but is not
complicated, and it is not any more space inefficient in the typical
case where the clients are frequently changing distinct sets of nodes
and their fields -- e.g., where each client controls his/her avatar and
not others'.

The main advantages of this fieldid-definition-unidirectionality are
that it avoids architectural limitations (baking in a master-slave
relationship of fieldid-definition wouldn't be appropriate, say, for a
peer-to-peer architecture), race conditions (peers racing to be the
first to define a fieldid), or a centralized fieldid-definition service
(which involves race conditions and either architectural limitations or
a potential bottleneck).

jay

---

From: [email-masked]
Date: Wed, 29 Aug 2007 12:03:07 -0400

Jay:

I think the thing I missed was the unidirectionality of the mapping.

So each side gets to declare its own mapping and the other is obligated to 
keep track of that.  Servers can use the same id for everyone becasue they 
get to declare the id they'll use.  Can I declare a mapping on a reliable 
channel (TCP) and use it on an unreliable channel (UDP)?  That would be 
helpful, since the first use establishing the mapping should be protected 
from loss.

It seems a little complicated, but I am inclined to accept your arguments 
for the ease of implementation and the virtues of the approach in a 
peer-to-peer context.

Thanks for explaining how it works.

jfp

08/29/2007 11:01 AM

To
[email-masked]
cc
[email-masked]
Subject
Re: faster field messages

[email-masked] wrote: 
I think I understand the mechanism and I understand that either side of 
the pairwise communication can establish the mapping of an ID to a 
<node,field>. 
Yes but as I defined it that mapping only applies in that one direction of 
the communication.  E.g., element A tells element B that "I will use the 
id '2' to represent the pair <node12,positionfield>", which constrains the 
meaning of future messages from A, but does not say anything about what 
field ids B will use in messages to A.
Perhaps it is a small thing, but in a situation in which one network 
element (say a server) manages the data, it would be helpful if it could 
use the same ID for all the other network elements seeking to use the 
data.  If the other network elements may establish the mapping, then it 
must keep independent mappings for each network element being served.  If, 
on the other hand, we can contrive the protocol, so that the network 
element managing the data establishes the ID mapping, then it could use 
the same mapping for all network elements seeking service. 
The server in my current client/server architecture (and implementation) 
does already use the same ID mapping for messages to all its clients, 
possible because of this unidirectionality of field ids.  This is indeed 
very convenient when blasting out an update to all the clients, not having 
to customize field ids for each message.  (and this is really important 
for an architecture that uses multicast.)

But you are right that my server maintains independent mappings for each 
inbound message queue.  This requires some bookkeeping but is not 
complicated, and it is not any more space inefficient in the typical case 
where the clients are frequently changing distinct sets of nodes and their 
fields -- e.g., where each client controls his/her avatar and not others'.

The main advantages of this fieldid-definition-unidirectionality are that 
it avoids architectural limitations (baking in a master-slave relationship 
of fieldid-definition wouldn't be appropriate, say, for a peer-to-peer 
architecture), race conditions (peers racing to be the first to define a 
fieldid), or a centralized fieldid-definition service (which involves race 
conditions and either architectural limitations or a potential 
bottleneck).

jay

---

From: "Jay C. Weber" <[email-masked]>
Date: Wed, 29 Aug 2007 09:09:17 -0700

So each side gets to
declare its own
mapping and the other is obligated to keep track of that.  Servers
can use the same id for everyone becasue they get to declare the id
they'll
use.  Can I declare a mapping on a reliable channel (TCP) and use
it on an unreliable channel (UDP)?  That would be helpful, since the
first use establishing the mapping should be protected from loss.

Exactly the way I was thinking, the first message gets sent reliably
and enables a stream of very-low-latency, potentially-unreliable,
updates.

jay

---

From: [email-masked]
Date: Wed, 29 Aug 2007 14:38:51 -0400

Jay:

I have not been thinking about the whole issue of doing something on one 
channel and using it on another.  This will require careful thought, but 
it could be very important.

As I mentioned elsewhere 
(http://www1.ietf.org/mail-archive/web/swmp/current/msg00045.html) we 
might need to subscribe on a reliable channel for notifications that will 
be delivered on an unreliable channel.  This sort of semantic mixing of 
the multiple channels was not spelled out in the paper, nor is it 
addressed in my follow up.  (In fact, I assumed the channels were 
independent and could not use each other's information.)

We need to think this through.  It is likely to be difficult to get right. 
 Nevertheless, it might be exactly the sort of innovation that would make 
swmp invaluable.

jfp

"Jay C. Weber" <[email-masked]> wrote on 08/29/2007 12:09:17 PM:

> So each side gets to declare its own mapping and the other is 
> obligated to keep track of that.  Servers can use the same id for 
> everyone becasue they get to declare the id they'll use.  Can I 
> declare a mapping on a reliable channel (TCP) and use it on an 
> unreliable channel (UDP)?  That would be helpful, since the first 
> use establishing the mapping should be protected from loss. 

updates.

---

From: [email-masked]
Date: Wed, 29 Aug 2007 18:56:16 -0400

Tony:

I do not see why it would need to be either/or.

The decision to do pub/sub is not really an option.  The paper described 
an implicit pub-sub.  I am advocating that we be explicit.

The more difficult question is whether a pub-sub approach is sufficient 
for all needs.  Given all the traffic that ensues when a subscription 
takes place, it seems unwise to SUBSCRIBE simply to learn a value and then 
turn around and UNSUBSCRIBE once it is known.  If we can identify 
situations in which it is important to learn the value of a field in order 
to decide whether to SUBSCRIBE, then I think we will want the GET 
functionality.

Imagine, for example, that we have a server that is managing multiple 
shards.  We are connecting our client, but we want to subscribe to the 
shard that is least occupied or that a friend is already in.  In these 
cases, we might want to query the shards for their load value and 
subscribe accordingly.  Or, query the shards to find our friend and then 
subscribe accordingly.  To subscribe to each shard simply to find these 
values would cause excess load on the server, the client, and the network. 
 It is worth avoiding.

jfp

"Tony Parisi" <[email-masked]> wrote on 08/24/2007 01:58:24 PM:

> If we?re talking about an either/or I prefer pub-sub to readback.
> 
> Tony
> 
> 

> D)  I believe that swmp will need the full complement of CRUD 
> (create, read, update, delete) operations.  I think the absence of 
> read methods derived from the implicit subscription to all state. 
> Now, that one can subscribe to some, but not all of the state, I 
> believe it will become desirable to request the values of 
> unsubscribed state.  This prompted me to add a GETNODE and a 
> GETFIELD request, which required GETNODEREPLY and GETFIELDREPLY 
> Interesting, but the danger here is "return the response".  There's 
> a big advantage to resisting the introduction of RPC-style elements 
> in a context of minimizing latency -- obviously RPC involves a 
> round-trip of messaging.  Keeping SWMP asynchronous will keep it 
> mapping simply and efficiently onto datagram transports.
> 
> I like the PUB-SUB suggestions you've made, especially because PUB-
> SUB can be designed to work well in an asynchronous protocol.
> 
> jay
> -- 
> Jay C. Weber, Ph.D. 
> CTO, Media Machines Inc. 
> 650-279-2311

---

From: "Tony Parisi" <[email-masked]>
Date: Wed, 29 Aug 2007 22:28:52 -0700

John

Agreed

Tony

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, August 29, 2007 3:56 PM
To: Tony Parisi
Cc: 'Jay C. Weber'; [email-masked]
Subject: RE: [SWMP] introducing RPC to an asynchronous protocol

Tony: 

The decision to do pub/sub is not really an option.  The paper described an
implicit pub-sub.  I am advocating that we be explicit. 

The more difficult question is whether a pub-sub approach is sufficient for
all needs.  Given all the traffic that ensues when a subscription takes
place, it seems unwise to SUBSCRIBE simply to learn a value and then turn
around and UNSUBSCRIBE once it is known.  If we can identify situations in
which it is important to learn the value of a field in order to decide
whether to SUBSCRIBE, then I think we will want the GET functionality. 

Imagine, for example, that we have a server that is managing multiple
shards.  We are connecting our client, but we want to subscribe to the shard
that is least occupied or that a friend is already in.  In these cases, we
might want to query the shards for their load value and subscribe
accordingly.  Or, query the shards to find our friend and then subscribe
accordingly.  To subscribe to each shard simply to find these values would
cause excess load on the server, the client, and the network.  It is worth
avoiding. 

jfp

---

From: Roland Weber <[email-masked]>
Date: Fri, 31 Aug 2007 18:33:37 +0200

> keep track of that.

What are the limits, like a maximum number of mappings, or a
maximum guaranteed lifetime of mappings? Unlimited mappings
that each peer needs to keep track of open the gate for easy
DoS attacks. Negotiated limits with each peer would not allow
a server to use the same mappings for each client.
One approach would be that a peer advertises how many mappings
it is going to use, so that the partner can decide on whether
to accept that number or cancel the connection. Another is to
define a maximum number in the protocol, like 255 or 256. That
may be too restrictive, but allowing two bytes and more than
65000 mappings will trigger memory problems, in particular on
a server.

>From the paper (I've read it by now) I perceived it rather
as an ad hoc technique used to shrink the size of a group of
messages in an UDP packet. In that case, the lifetime of a
mapping could be restricted to the packet. But that doesn't
map to TCP connections, or your discussion of defining the
mappings on a separate channel.
In the extreme case of ad hoc, you'd have only one mapping
which is defined at the beginning of a sequence of messages
referring to the same node, and overwritten by the next
definition. Actually, that's not even a mapping anymore,
but an implicit argument.

cheers,
  Roland

---

From: Roland Weber <[email-masked]>
Date: Fri, 31 Aug 2007 19:05:16 +0200

Hi all,

I've read the paper[1] by now, and it answered some of
my questions while raising new ones.

A question that is answered is about tickets. They are
representing peers rather than connection, so a ticket
is sent once over the initial channel, then received
later over all side channels too. Sending an unmodifiable
ticket as an authentication token with every UDP packet
sounds somehow like HTTP basic auth. Once somebody has
intercepted the ticket, that entity can generate new
messages that will look genuine. Some hashing technique
including a secret value that is exchanged only once in
advance could improve on both security and message size,
but it's probably too early to discuss security now.

The paper mentions limited support for multicast, but
does not elaborate. There's some more background reading
I'll have to do, but for now I imagine that a multicast
channel is unidirectional, and typically from a server
to many clients. There are two problems with that:
- no HELLO message exchange, because a client can't
  send back (over that side channel)
- no client-specific ticket in the messages sent
I understand that multicast has a low priority here, but
maybe it is still useful to give it a thought occasionally.

Then there are the message IDs. In the paper, they are
per channel and used for UDP packets only. All messages
in a packet share the same message ID. In John's summary,
message IDs are suggested for two purposes:
  a) to identify requests in FAILNOTIFY
  b) as a replacement for timestamps in SUBSCRIBE
The former has the problem that a message ID as presented
in the paper is not unique for a request, and requests via
TCP will not even have a message ID. There is a huge gap
between the interpretations in the paper and the summary.
Did I miss some discussion on that?
The latter has the problem that it is impossible to map
message IDs to unique points in (virtual) time because
they are per-channel, non-persistent, and not unique even
on a single channel. In order to implement a mechanism like
"send all changes since my last login from this machine",
a server will need some kind of timestamp, probably based
on a virtual time in the model.

cheers,
  Roland

[1] www.mediamachines.com/hydra/swampweb3d2007.pdf

---

From: [email-masked]
Date: Fri, 31 Aug 2007 15:36:59 -0400

Roland:

I assumed that the IDs are valid for a session, i.e., the messages between 
the HELLO and the BYE.

I also assume that any network element wishing to use an ID must first 
send a SET message establishing the mapping for that node, which can be 
followed by later SETF messages that use the ID.

I assume that at any time a SET message may be issued to change the ID 
that is being used even if there have been prior SETF messages using an 
earlier ID.

I assume that if a network element cannot formulate a legitimate ID that 
SET messages may be used in lieu of a SETF message.  This would mean that 
a pre-established limit would be acceptable, if large enough to cover most 
situations.

I believe it is an ad hoc mechanism, but I assumed it was to make the 
processing more efficient.  I'm not sure whether the focus was on 
networking issues or lookup efficiency on the network elements.  I assume 
the technique was introduced because the X3D data model has within-node 
names for fields. 

jfp

> > So each side gets to declare its own mapping and the other is 
obligated to

---

From: Roland Weber <[email-masked]>
Date: Fri, 31 Aug 2007 22:29:26 +0200

Hello John,

> a pre-established limit would be acceptable, if large enough to cover most 

Let's take an example: a server is sending SET/SETF messages to clients.
Is the pre-established limit imposed by the protocol, or negotiated with
each client separately?
In the first case, the server can use the same mappings for all clients,
since they are all required to support that number of mappings. In that
case, the server can build the set of messages once and send it out to
all clients, wrapping it in a client-specific envelope. I believe that
was the idea, but on the other hand a protocol imposed limit reduces the
flexibility of the protocol.
In the second case, let's say that client 1 supports 100 mappings and
client 2 supports 300 mappings. Then the server has the option of main-
taining separate outgoing mappings for each client, or of only using the
smallest number supported. The separate mappings can at least be kept
overlapping, but they will require to build separate messages for the
clients. Using only the smallest number degrades potential performance
for all clients that support more.

> networking issues or lookup efficiency on the network elements.

The paper suggests it was introduced to reduce message size. If this
is handled ad hoc with a strictly limited lifetime of the mapping,
it is quite efficient. A network element realizes that the set of
messages to be sent can be efficiently encoded by defining a few
mappings, and does so. The receiver takes the mapping, processes the
messages, and forgets the mapping again. No problem.
But as soon as you're introducing mappings with a longer lifetime,
as was implied in your discussion, you raise the memory question.
The mapping moves from temporary memory (during message processing)
to session memory. In the example above, each client can define
independent mappings, and the server will have to store those somehow.
If there is no limit, a single malicious client can take down the
server simply by defining an ever-growing set of mappings.
If a limit is imposed by the protocol, the worst-case memory consumption
on the server will grow linearly with the number of clients. Negotiation
would allow the server to set a lower limit than the client, allowing
for efficient sending (with many mappings) while limiting the memory
consumption on the receiving side. But the price of negotiation is to
create separate messages for each client with a differing number of
supported mappings.

Jay says that maintaining per-client mappings on the server is not
complicated. That is surely true as long as the server has the memory
to spare. But what happens when the server has to refuse storing more
mappings in order to keep the memory consumption in check? Throwing
out old mappings is an option of course, but the client needs to be
told which mappings are available for message encoding and which can
no longer be used.

Jay, maybe you can tell us how you are handling this situation
in your implementation?

cheers,
  Roland

---

From: [email-masked]
Date: Fri, 31 Aug 2007 16:33:17 -0400

Roland:

My responses are mixed in.

jfp

> but it's probably too early to discuss security now.

I did not understand that about tickets.  The security concern seems 
legitimate.  The solution sounds sensible, especially because it will 
apply to all channels.  I agree that it might be too early to worry deeply 
about security, but it can't hurt to have it in mind.

> maybe it is still useful to give it a thought occasionally.

I share the impression that multicast was a bit of an afterthought in the 
paper.  Nevertheless, the sentiment to support it is a good one.  It 
sounds like we need to think more deeply about how that might happen.

> Did I miss some discussion on that?

No, you didn't miss any discussion on that.  My adoption of the message 
IDs to solve some of the problems I was encountering was rather "glib".  I 
did not understand that message IDs were per packet and not per message. I 
also did not understand that they were only used with UDP.  The paper did 
not anticipate using message IDs in this way because it does not support 
queries, failure notifications, or subscriptions with an indication of the 
relative completeness of the current state.  As I have mentioned 
elsewhere, I no longer believe that message IDs are a good idea for 
subscriptions.  I still think that failure notifications and queries will 
be needed.

> on a virtual time in the model.

I agree with your point about using message IDs on subscriptions.  We 
could just say that all subscriptions are followed by a full accounting of 
the state.  Or, if we want to manage the traffic better, we will need some 
notion of time to account for how far back the subscriber's state is 
valid.  If we can figure out how to use time in this fashion, it might 
decrease the traffic a lot.

---

From: Roland Weber <[email-masked]>
Date: Fri, 31 Aug 2007 22:55:52 +0200

Hi John,

> I did not understand that about tickets.

Tickets are used similar to session cookies. When a network
element X opens the initial channel to Y, it sends a message
"HELLO, I am X and here is your ticket YtoX for contacting me".
>From then on, Y is expected to use the ticket YtoX whenever it
sends a packet to X, on any UDP (side) channel. Likewise, X
gets a ticket XtoY in the HELLO message from Y.
There must be some mechanism to ensure that HELLO messages
exchanged on side channels use the same tickets as on the
main channel. Or else different HELLO messages could be used
for side channels, without tickets.

> As I have mentioned 
> subscriptions.

That was in a mail you didn't copy to the list, that's
why I came back on this topic.

> I still think that failure notifications and queries will 
> be needed.

They make a lot of sense to me.

> the state.

Good point. Not the first time that I am overlooking the
most simple solution to a problem :-)

> Or, if we want to manage the traffic better, we will need some 

Yes. It pulls in a lot of complexity though.

cheers,
  Roland

---

From: "Jay C. Weber" <[email-masked]>
Date: Fri, 31 Aug 2007 15:23:50 -0700

Roland Weber wrote:

Yes and tickets usually have an expiration time/date (a date is part of
the ticket and the whole thing is digitally-signed to prevent
tampering) in order to address the man-in-the-middle attacks to which
you alluded before.

jay

--

Jay C. Weber, Ph.D.

CTO, Media Machines Inc.

650-279-2311