Print

Print


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