Re: [SWMP] My understanding so far

[Roland Weber <[e-mail]>]

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

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