[X3D-Public] interest in network sensor / client based server software

[Christoph Valentin]

>>Each object in the simulation is managing it's synchronisation with other instances of itself. Only user interaction need to be shared on the global layer (local -> global).

 [Christoph:] it's similar in Simple Multiuser Scenes, however, each object defines one instance that is "responsible" for the shared state (but the shared state is stored in each instance and on the collaboration server persistently). If the instance "responsible" for the state gets lost, another instance takes over the responsibility.

 [Eric] Looks like my Token system. Now, what will be triggering a state change ?, most of the time, it's user interaction; If not, it may be a timed event (or functionally time bound)  thet doesn't have to be shared, for it can be produced locally.  In your scheme, this means: getting event from interaction, conveying it to the application where the 'responsible instance' lies, then propagates to all: distributed server approach, unless all 'responsible are living on the same application. In the latter case, the application load balancing may inply lag on the server app. Why do you need a 'responsible' ? or, put it all the way round, why wouldn't any instance be responsible of propagating user interaction ?

[Christoph:] As an example, I have got a "key container" object (an X3D prototype), which provides e.g. input field "takeKey" (SFString) and output field "containedKeys" (MFString). "takeKey" may happen in any scene instance, but access to "containedKeys" must be coordinated "centrally" (in the "responsible" instance), such that only one avatar gets the key, key must be deleted from the shared state immediately, when "takeKey" arrives at the "responsible" instance.
The "key container" prototype wraps a networks sensor, which is used for all requests and for distribution of the shared state.