Subject: [SWMP] Introducing pub-sub

From: [email-masked]
Date: Fri, 6 Jul 2007 16:14:08 -0400

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" <[email-masked]> wrote on 06/26/2007 01:34:43 PM:

> [email-masked] 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? 
>
> [email-masked] 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/swmp

---

From: "Tony Parisi" <[email-masked]>
Date: Fri, 6 Jul 2007 13:24:37 -0700

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: [email-masked] [mailto:[email-masked]] 
Sent: Friday, July 06, 2007 1:14 PM
To: Jay C. Weber
Cc: [email-masked]
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.) 

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

---

From: [email-masked]
Date: Fri, 6 Jul 2007 18:50:54 -0400

Tony:

Well the truth is you caught me.  I was shooting from the hip when I said 
that we should not use multiple ports.  I was writing about Subscribe and 
it occurred to me that one could use multiple ports.  It seemed like a bad 
idea on the face of it, but I didn't really think it through any deeper 
than that.

Having confessed the truth, let me see if I can ferret out some of the 
reasons this seems like a bad idea.  My guess is that there are others 
watching this list who understand networking better than I who will speak 
with more authority.  Until they speak up, let's see what I can come up 
with.

I guess the main reason is that I do not believe that ports come for free. 
 There is a large numbering space, but I assume the active ports actually 
consume some amount of OS resources.  I am less familiar with UDP, but I 
believe this is true for TCP.  If we wanted a server to support a hundred 
shards using TCP, we would be listening on one hundred ports and then 
shunting any client that connected over to a separate active port.  With n 
active clients we would be consuming 100 + n ports.  Or, in general, m + n 
ports, if m is the number of shards.

I am old enough to remember when we had a restricted number of ports, but 
these days it is possible that m+n does not seem like such a burden. Let's 
look a little deeper and ask whether there are any other costs.

One other cost is the cost of publishing so many well known ports.  If we 
register these in the name servers, then we are adding a lot of entries 
for a rather specialized purpose.  If we do not register them, then we 
will probably have to augment the protocol with a "name-service-like" 
function that allows one well-known port to redirect activity to the other 
ports.  This seems a rather awkward arrangement for something that is 
easily handled within the protocol.

Finally, there is the cost of creating and tearing down sessions as we 
move from port to port.  This seems an unnecessary burden on our server 
and our protocol.  It is even worse if we consider that authentication is 
typically tied to the session and would now be occurring over and over as 
we try to navigate from shard to shard.

I wasn't sure when I started this, but I think I convinced myself that my 
first instincts were right.

Hope that helps.

jfp

> "Tony Parisi" <[email-masked]> wrote on 07/06/2007 04:24:37 
PM:
>
> 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
> 
> 
> 
> 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 
>

---

From: "Sven-Erik Tiberg" <[email-masked]>
Date: Fri, 20 Jul 2007 23:52:40 +0200

Hi.
 
Plan to set up a SWMP -server on a newly installed fedora core 6 mashine.
and use the tips on http://community.mediamachines.com/comments.php?DiscussionID=336&page=1#Item_0
Any tips where to find the source.
 
/BG
Sven-Erik Tiberg.