RE: [SWMP] Introducing pub-sub

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

Hi John

 

Sounds reasonable to me.

 

For the uninitiated: can you elaborate on why we wouldn't want to do this
via multiple ports?

 

Thanks

Tony

 

 

  _____  

From: [e-mail] [mailto:[e-mail]] 
Sent: Friday, July 06, 2007 1:14 PM
To: Jay C. Weber
Cc: [e-mail]
Subject: [SWMP] Introducing pub-sub

 


Jay: 

OK, I understand what you are doing with Hello.  I don't see a big problem
with using it to activate the sending of latecomer information, but you are
overloading its purpose a little.  It would be cleaner to use Hello for
session establishment and a separate Subscribe message to activate latecomer
sends.  Given the austere nature of swamp right now, this seems like
overkill, but I do not think you can avoid it. 

As you indicate, swamp has an implicit subscription to all the state that a
network element has to support.  My guess is that we will not want that in
the general case.  We will definitely want to ensure that one server can
offer state sharing for multiple contexts (eg multiple pieces of the virtual
world, sometimes called shards).  We will not want to do this via multiple
ports, so the context of sharing will need to be brought into the protocol.
This will permit clients to indicate the shard that they need to learn
about. 

As a first approximation, we might say that a network element (client) can
issue a Subscribe request and indicate which node is of interest.  This
would establish a subscription to the state associated with that node and
any under it in the tree.  Once we accept that the nodes need not be X3D
nodes, but may be more general, then it is easy to imagine that each X3D
model would be rooted in a Shard node, with each of those under a ROOT node.
A subscription to this shard node would indicate which piece of the world
one wants to learn about and would cause the appropriate latecomer messages
to be sent. 

It is a small step to suggest that one network element might want more than
one such subscription.  For example, I might want to know about the shard I
am in and the shard I am about to enter.  This means I will want two
subscriptions and, in general, I will want to be able to have an arbitrary
number of subscriptions at one time.  Of course, if I can create
subscriptions, then I will need to be able to get rid of them.  For this, I
will want an Unsubscribe message (presumably indicating the node I am no
longer interested in.) 

With this approach, we might imagine the virtual world broken into square
tiles or shards.  I would subscribe to the tile I am in and the eight that
surround me.  As I move from tile to tile, I would drop and add
subscriptions as needed. 

If this makes sense, then you can see that Hello will need to let go of its
subscription role and swmp will need to add Subscribe and Unsubscribe
messages. 

jfp 

"Jay C. Weber" <[e-mail]> wrote on 06/26/2007 01:34:43 PM:

> [e-mail] wrote: 
> 4)  It sounds like you are saying that latecomer support is in your 
> code even though it is not obvious how to do it based on the paper. 
> Does that mean there is a get request in your implemented protocol? 
> 
> [e-mail] replies 
> In the client/server architecture we implemented, when a client 
> connects to the server and sends a Hello message, the server 
> responds with a Hello message followed by a series of set messages 
> containing latecomer state data.  So there is no explicit get 
> request, unless you want to consider Hello to subsume the semantics 
> "send me latecomer data".
> 
> Generalizing this issue a little, pub-sub requests are implicit in 
> our system.  Our applications and supporting architectures don't 
> need explicit pub-subs, but I can imagine some uses for pub-sub 
> messages, maybe we should add them to SWMP.
> 
> jay
> 

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