RE: [SWMP] Introducing pub-sub

[[e-mail]]

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" <[e-mail]> 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
> 
> 
> 
> 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 
> 

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