Print

Print


Brad,

I like the idea of supporting more arbitrary peer-to-peer connections.  
My concept would only support a fully connected set of peers.  Spanning 
trees may be a good example to think about in terms of how that could be 
allowed by the specification.  In addition to peer connections, it may 
be necessary that peer to peer messages contain additional meta-data for 
routing.


Thanks,
Keith

On 09/20/2018 03:44 PM, Brad Dillman wrote:
> Upon further thought, I'm not that excited about spanning tree. There 
> might be better alternatives. But I do think it would be valuable to 
> allow arbitrary peer-to-peer connections, for reliability, etc.
>
> On Thu, 20 Sep 2018 at 14:14 Brad Dillman <[log in to unmask] 
> <mailto:[log in to unmask]>> wrote:
>
>     Not bad, I have some responses.
>
>     a) I think if we specified a message to implement the Spanning
>     Tree Algorithm for peer connections, it would simplify things a
>     lot. You could just connected any server to any other server, and
>     they'd figure it out, and eliminate loops and recirculating
>     messages. Then 4) would become send messages to client connections
>     (children) and peer connections which are part of the spanning
>     tree. (BTW spanning tree is widely used for ethernet switching for
>     just this purpose)
>
>     b) Suppose a client connected to server A sends an update for
>     object X. Does server A create a new object X, or send the update
>     over peer connections to update the already existing object X on
>     server B? In order to know which, server A must know object X
>     exists on a peer (but might not care which peer, since you want to
>     forward the update message to all peers and all of their clients
>     anyway). Currently, when a client successfully connects to a
>     server the server sends the current state of all of it's objects.
>     So now, as a client when I connect to connected peer servers, I'd
>     expect the current state of all objects on all servers (all
>     subject to subscription and filtering the client set in the
>     connection message of course). So maybe the server caches some
>     info about objects it gets after a peer connection; then it could
>     use that when another peer connects to it?
>
>     c) The problem in b) must be solved when server are disconnected,
>     too. The local server would have to send ObjectDeleted messages to
>     all clients for all of the objects no longer accessible. You might
>     (probably) have to rebuild the spanning tree to know which objects
>     are still reachable through the new tree, and which aren't. [e.g.
>     servers might have multiple or redundant paths detected and
>     disabled by the spanning tree during initial connection, but now
>     due to a disconnection those paths are enabled and become part of
>     the new tree.]
>
>     d) Aggregating subscriptions looks like a very difficult technical
>     problem, but I suggest it doesn't matter to the standard. If peer
>     connections support the same subscription and filtering as the
>     clients, then a server implementation could just subscribe to
>     everything without filters; a more sophisticated server could try
>     to optimize the peer subscription and filtering.Â
>
>     My position on this whole endeavor remains: it's difficult but
>     worth doing, and worth doing right.
>
>
>
>
>
>     On Thu, 20 Sep 2018 at 12:10 Keith Snively <[log in to unmask]
>     <mailto:[log in to unmask]>> wrote:
>
>         Brad,
>
>         I think this may not be terribly difficult for connecting
>         WebLVC servers.
>
>         To support a single layer (as opposed to hierarchical network)
>         of WebLVC
>         servers, we would need to identify Peer connections as you
>         point out.Â
>         At a high level, we then need the following rules:
>
>         1) Applications connect to a single WebLVC server as a Child
>         (standard)
>         connections.
>         2) WebLVC servers connect to zero or more other WebLVC servers
>         as a Peer
>         connection.
>         3) Messages from Child connections are sent to all other Child
>         and Peer
>         connections.
>         4) Messages from Peer connections are sent to all Child
>         connections, but
>         NOT to Peer connections.
>         5) A WebLVC server manages Objects created on Child
>         connections, but NOT
>         on Peer connections.
>         6) A WebLVC server subscribes to messages on Peer connections by
>         aggregating all Child connection subscriptions.
>
>         Of course there are details to work out, especially with #6,
>         but this
>         should be basically whats required to federate WebLVC servers.
>
>         Thanks,
>         Keith
>
>         On 09/20/2018 11:29 AM, Brad Dillman wrote:
>         > I'm not suggesting this for v1.0 of the spec., but I was
>         thinking about Cloud-based Modelling and Simulation over on
>         the CBMS discussions. And I think WebLVC could be of
>         particular benefit as a proxy to an anonymous or uncertain
>         cloud, where from the outside as a cloud client, you don't
>         know what's inside the cloud or how it's built or if it uses
>         DIS, HLA, TENA, DDS etc. or any and all combinations of those.
>         >
>         > The problem comes when connecting 2 clouds into a single
>         simulation. That would imply connecting 2 or more WebLVC
>         servers as peers, assuming each acted as a proxy to some
>         implementation. I don't think we can currently do this as-is.
>         And it hasn't been a priority for the v1.0 spec.
>         >
>         > But because I see solving the peer-to-peer WebLVC server
>         connection problem has some value, I'm more interested to
>         discuss it.
>         >
>         > The first 2 ideas I had were:
>         > a) during connection, identify the connection as
>         peer-to-peer rather than client-server; then let the server
>         interpret incoming messages differently for peer-to-peer
>         connections.
>         > b) instead let peers connect normally, but use new message
>         properties to indicate AttributeUpdates, ObjectDeleted and
>         Interaction messages should be interpreted differently than
>         they would be normally for clients.
>         >
>         > I think this is a complicated problem to solve, trying to
>         decide if there are copies of objects on each server not, how
>         multiple peers (say 3+) work, etc. Way too complicated for
>         v1.0. But it might be a valuable contribution to CBMS.
>         >
>         >
>         ########################################################################
>         >
>         > To unsubscribe from the SAC-PDG-WEBLVC list, click the
>         following link:
>         >
>         https://discussions.sisostds.org/index.htm?SUBED1=SAC-PDG-WEBLVC&A=1
>
>         ########################################################################
>
>         To unsubscribe from the SAC-PDG-WEBLVC list, click the
>         following link:
>         https://discussions.sisostds.org/index.htm?SUBED1=SAC-PDG-WEBLVC&A=1
>
>
> ------------------------------------------------------------------------
>
> To unsubscribe from the SAC-PDG-WEBLVC list, click the following link:
> https://discussions.sisostds.org/index.htm?SUBED1=SAC-PDG-WEBLVC&A=1
>


########################################################################

To unsubscribe from the SAC-PDG-WEBLVC list, click the following link:
https://discussions.sisostds.org/index.htm?SUBED1=SAC-PDG-WEBLVC&A=1