Re: [SWMP] My understanding so far

["Jay C. Weber" <[e-mail]>]

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

[e-mail] 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" rel="nofollow">http://www.mediamachines.com/hydra/swampweb3d2007.pdf identified in an earlier message. (http://www1.ietf.org/mail-archive/web/swmp/current/msg00010.html" rel="nofollow">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
[e-mail]
https://www1.ietf.org/mailman/listinfo/swmp" rel="nofollow">https://www1.ietf.org/mailman/listinfo/swmp
  

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

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