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:
[log in to unmask]">
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]> 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]> 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