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

doug sanden highaspirations at hotmail.com
Thu Jan 9 06:35:00 PST 2014

SU issues
You have a lot going on. Some of it isn't MU per-se. If you want to compose trains of train cars via 'module' protos, or you want to pick up and carry something, or be carried by something, that can be worked out in single-user SU mode.
Q. How do you pick up and carry something, or attach one thing to another? Is there GrabSensor / GrabSocket node types?

MBMU - Multiple-Browser, Multiple-User
And when we've been talking about MU we've been implying that there are 2
 processes / 2 web3dbrowser instances running on one or more computers, 
requiring network communication and scenegraph synchronization between 

SBMU - Single Browser, Multiple-User 
(is this what you mean by native multiuser?)
This is the game-Console-like scenario where a single process/single webbrowser could be made to support multiple users:
- multiple windows showing the same scene from a different camera/avatar (not unlike cave or stereo rendering)
- multiple input devices each with an ID, and associated with a window/avatar
- each window/viewer/viewpoint is navigated by a different input device

That would break the x3d specs which talk about viewer, user and avatar 1:1:1 as a singleton in the scene:

Q. what would need to change to support SBMU?
- internal to the browser:
-- multiple viewer/avatar instances
-- multiple input devices with IDs, associate each 1:1 with a viewer/avatar instance
- navigationinfo (associate 1:1 with viewer)
- Sensors ie proximity, touch, grab sensor - extend to tell which avatar it's sensing
(it might be handy to have an Avatar node type, that combines a few things like NavigationInfo, ProximitySensor, GrabSocket(?), currentlyBoundViewpoint, Presentation)

Then after getting this SBMU working with your train scenes, whatever is leftover would probably be network stuff.

>>> another two cent (I know, I am carrying coals to Newcastle)
>> No apologies necessary - we love your coal here.
> [Christoph:] Thank you, that's inspiring to me :-)
>>> 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.
> [Christoph:] This way, the publisher of the content must rely on the Browser enforcing the policy. If I were a publisher, I would probably trust the server that manages my content, but I would never trust any browser.
> Maybe better: Modifying the content on server side and downloading only the features of the content that are approved by the policy
>> 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.
> [Christoph:] A few words about "modules", as I defined them in the experimental SMUOS Framework.
> A module is "something" that provides a minimum interface (specified fields) and that contains
> and initializes an instance of the "Module Coordinator" (X3D prototype)
> The Module Coordinator coordinates all MIDAS Objects of a module
> a) I came to the idea of modules, because model railroads are sometimes built by modules, too.
> Each module can be provided by a different person and sometimes the model railroaders gather and
> plug there modules together.
> b) Same idea here: each module from a different author, modules can be "plugged" together by person
> who provides the overall scene to their users.
> c) Person, who provides the overall scene to their users, has to set "moduleName".
> d) Models contain MIDAS Objects for instrumenting the functionality (e.g. steering of a car)
> e) MIDAS Objects contain Network Sensors
> f) stream Name of Network Sensor (necessary for identification on the net) is derived from
> moduleName + objectId
> g) A scene is restricted to the "MMF-paradigm" (model / module / frame)
> scene 1:1 frame 1:N module 1:N model
> h) future idea (not yet implemented) "Moving Modules":
> enable modules being parts of models
> scene 1:1 frame 1:N module 1:N model 1:N module 1:N model 1:N module 1:N model ad inf.
> this future idea necessary for train ferries, turntables, "model railroad in the model railroad"
>>> 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.
> [Christoph:] I would prefer option B, not only because I already did it this way, but because this option leaves more freedom to the scene author / model author (on the other hand, it's not "easy-to-use")

More information about the X3D-Public mailing list