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

doug sanden highaspirations at hotmail.com
Wed Jan 8 09:58:54 PST 2014

> another two cent (I know, I am carrying coals to Newcastle)
No apologies necessary - we love your coal here.
> maybe starting with requirements:
> What could the requirements look like? (just a suggestion, not a proposal)
> a) A model can run in different MU scenes from different authors without change
> b) Usage of a scene can be restricted to subscribed scene users
> c) Usage of a model can be restricted to subscribed scene authors
> d) Usage of a model can be restricted to subscribed scene users
> e) A multiuser session can simultaneously run on different Web3D Browsers for different users
> f) ....and so on

When I was thinking about these different scenarios, I thought for different apps you'd want something different, or perhaps whoever starts a new empty world could decide and more flexible apps could pick up on it parametrically rather than hard coding it. I called it 'publish/subscribe policy'. I was thinking it wouldn't be 'secure' and enforced against intruders, but rather each peer/client would enforce the policy on itself. Lets say a peer publishes a content but without interactivity attribute. The subscribing client would still get the sensor nodes, but when rendering the scenegraph for that content, would check the content flag for interactivity and if false then don't allow the client avatar to click it.

You have scene and model and you mentioned modules before. So there are different possible granularities of publish/subscribe content aggregation. I was thinking of course granularity - content unit ~= web3d scene file - for easy coding in freewrl. But perhaps it could work like nested nodes in a scenegraph: each node inherits publish/subscribe attributes from parent node.

> regarding Synchronization:
> Maybe taking a step back and thinking "what would be, if we had no DIS, no Network Sensor"
> Option A) Avoid differences between single-user-scenes and multi-user-scenes

- a course-granularity content aggregation could apply publish/subscribe attributes to a scene-file-level aggregation, and the scenefile itself would look the same, except the code guts of the browser would get the attributes during subscription, at one-higher-level in the technology stack.
This would hide the details of synchronization which would mean they aren't a standard in the x3d scene description. So either different browsers wouldn't cooperate, or a separate standard for MU sync, publish/subscribe etc could be needed.

> Option B) Provide special means for multi-user-scenes
> ad A) X3D Time Sensor, Collision Detection, ..... maybe could be defined for "native" multi-user-mode
> ad B) use X3D DIS, network sensor, ..... maybe improve them

I don't have enough experience with MU to have ideas at this level - no neurons fire.

>> Gesendet: Mittwoch, 08. Januar 2014 um 14:59 Uhr
>> Von: "doug sanden" <highaspirations at hotmail.com>
>> An: "x3d-public at web3d.org" <x3d-public at web3d.org>
>> Betreff: Re: [X3D-Public] interest in network sensor / client based server software
>> The idea of technology layers/stacks -analogous to communication protocol- along with a paradigm like publish-subscribe might be slick:
>> World catalog/search/publish/subscribe
>> world {[geoOrigin], policies for publish, subscribe}
>> content catalog/search/publish/subscribe
>> content
>> content attributes publishable/subscribable:
>> - persistence {publisher session, shared, [persistent?]}
>> - interaction {publisherOnly, transferable, shared}
>> - synchronization {yes,no}
>> - possession of movable {yes,no}
>> If something isn't published, then it's local-client only.
>> If an attribute on content isn't published, a subscriber can't subscribe to it - no permission.
>> An app would implement publish/subscribe policies or inherit from a World, depending on the application.
>> Content - I'm thinking of some kind of group or aggregation, so policies could be applied to the aggregation. Perhaps content is like a separate x3dscene and the browser would render a mashup of all the content it subscribes to perhaps different scenegraph renderers for each content type ie GIS, X3D, smoke/weather, or several content subscriptions in one format like x3d, but all in separate scenegraphs as scenes. Or perhaps X3DLayer would/could be extended with publish/subscribe attributes.
>> The above would clear up some of the entity/relationship list. But then I haven't articulated the hard technical details about how synchronization is implemented, or how a movable singleton in one content/layer interacts with the avatar, or things in another content layer.
>>> How was it done with TCP/IP and with the Internet?
>>> a) Taking the nucleus of the most important functions (TCP/IP) and stand for it
>>> b) require only essential functions from the lower layer (that's why Ethernet succeeded, because it was the most simple one, and it was sufficient for TCP/IP)
>>> c) and enable a rich culture of upper layers, competing and compelling
>>> In my humble opinion.
>>> ad a) What is the absolute minimum the Web3D standards MUST define for successful, compatible, standardized MU Environments (e.g. regarding re-use of models)
>>> ad b) Nowadays it's clear, that TCP/IP SHOULD be used as lower layer?
>>> ad c) OK, Web3D provides OPEN standards, so far no problem
>>> Have fun
>>> Christoph
>>> Gesendet: Dienstag, 07. Januar 2014 um 18:05 Uhr
>>> Von: "doug sanden" <highaspirations at hotmail.com>
>>> An: "x3d-public at web3d.org" <x3d-public at web3d.org>
>>> Betreff: Re: [X3D-Public] interest in network sensor / client based server software
>>> Q. based on experience with legacy design architecture, if you were starting from a clean slate, would you change the design and if so what would you do to either a) simplify and/or b) make more general?
>>> more..
>>> I'm getting confused with all the entities, attributes and relationships in a MU system.
>>> And I'm wondering if there's something left to develop in VR. I work with some C code (freewrl) which is due for a refactoring, and wondering if there's something that could be factored in. But for freewrl code it would need to be 'slick' - architecturally expansive enough but in simple ways, so incrementally some MU features could be added as needed without awkward workarounds.
>>> What I'm hearing is layers, network semephores. verbs, nouns.
>>> There needs to be ways to express:
>>> A. geometric parenting of singleton objects ie a key in a hand, multiple keys in hand, an avatar on a moving train, multiple avatars on a moving train, an avatar carrying an avatar
>>> B. persistence
>>> -- session objects - the avatar and its clothes, some if its things disappear when user logs out
>>> -- user objects - persists for a user, but disappear if a user quits for good
>>> -- shared objects - persist until all share-owners quit for good
>>> -- world objects - persist until world is deleted, even if no users, or someone with permission to remove world objects removes them
>>> C. permissions
>>> -- permission to carry/take/geometrically parent?
>>> -- permission to interact ie with sensors - ie train engineer vs passenger, or pilot/copilot scenarios where permission may be no,yes,shared-with-others
>>> D. private/public/subscribe - not all content is shown in all clients - may be geographically, conceptually filtered. In client/server arrangements, there may be local-only content that never goes to the server - never published. In peer2peer, there may be separate publish/subscribe attributes on each peer for each object or object grouping.
>>> E. ways to group objects to make it more convenient to apply some of the above
>>> F. scenegraph synchronization
>>>> In my implementation, the avatar that took the key is the owner, and
>>>> it's reflected in the scenegraph: the key isn't on the door lock
>>>> anymore, it's in the hand of the owner, and moves with the owner. No one
>>>> but the owner may open the door, unless someone steals the key to the guy.
>>>> This is possible, and options are open, let's call owner Avatar A and
>>>> the stealer Avatar B:
>>>> - the guy AvatarA owning the key is an avatar, then it's own AI is
>>>> 'unplugged' and incoming messages *at semantic level* is output to the
>>>> user in charge "From, AvatarB, TAKE, zeKey" obviously this answer here
>>>> would be a boolean, so the message would be presented with a yes/no
>>>> option. User chooses ....
>>>> - the guy AvatarA owning the key is a robot, and AvatarB is an avatar:
>>>> we take for granted that B knows better and he actually grabs the key
>>>> (in the scenegraph, the node is now under AvatarB.
>>>> - Robot/Robot unlikely to happen, or it is scripted in the scenario or
>>>> handled by external AI and the outcome is known
>>>> - Avatar/Avatar: In the AvatarA screen, "From, AvatarB, TAKE, zeKey" is
>>>> answered, and the answer triggers the action. Eventually, an avatar may
>>>> fight another, or we have plenty of revolvers, guns, rifles,... that may
>>>> be available around for 'taking' and 'using' if problem can't find a
>>>> easy outcome.
>>>> I don't need a responsible here. All -mobile- objects may be taken,
>>>> used, released etc ... their position in the scenegraph tells about
>>>> their owner or availability. Classicaly, messages are exchanged between
>>>> objects upon 'grabing' and each object 'grabber' and 'grabee', 'owner'
>>>> and 'stealer' (parents if in scenegraph/container if not) may 'discuss'
>>>> locally (in the instances where user interaction is taking place), and
>>>> result is shared globally.
>>>> Note that I don't have a message 'takeKey' , but simply a Take, with
>>>> parameters' messageFrom, messageTo, typeBoolean'. This is a lot different.
>>>> Eric.
>>>> Le 07/01/2014 15:15, Christoph Valentin a écrit :
>>>>>>> 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.
>>> _______________________________________________ X3D-Public mailing list X3D-Public at web3d.org http://web3d.org/mailman/listinfo/x3d-public_web3d.org[http://web3d.org/mailman/listinfo/x3d-public_web3d.org]_______________________________________________ X3D-Public mailing list X3D-Public at web3d.org http://web3d.org/mailman/listinfo/x3d-public_web3d.org[http://web3d.org/mailman/listinfo/x3d-public_web3d.org]
>> _______________________________________________
>> X3D-Public mailing list
>> X3D-Public at web3d.org
>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org

More information about the X3D-Public mailing list