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

Christoph Valentin christoph.valentin at gmx.at
Mon Jan 6 09:34:14 PST 2014

> >>> I think you'd need to 'know your content'
> >
> > That's exactly the point of BS Collaborate / Network Sensor (which I use).
> >
> > The server is very simple and very general. The server does NOT need to know the content of the scene.
> >
> > The complexity is hidden in the <Script> nodes in the scene ( in the what I call "client based server software" ).
> >
> I suppose it also captures sensor node outputs - so the event-cascade can be replicated on all clients.

[Christoph:] That's the basic idea of Network Sensor (as far as I understand it), yes. In a single-user-scene you have two nodes A and B (A might be a sensor node) and a route A --> B. In a multi-user-scene you squeeze a Network sensor in between A and B:  A (any scene) ---> NS ---> B (all scenes)

>  I gather you can still have different content in each client?> I see different avatar. But what about sensor nodes and scripts? Lets say you have a massive multiplayer online RailRoad game MMORRG. You probably don't want the entire scenegraph replicated in every client. Just what's in the vicinity. So some scripts and sensors will be in just a few clients.

[Christoph:] in my software I denote the "parts of the scene" as "modules" and "models". Modules may be "unloaded", "loaded but inactive" or "active" (all of these categories are local categories, e.g. a module can be "unloaded" in one scene instance, "loaded but inactive" in another scene instance and "active" in a third scene instance).
Models can be contained in modules (thinking of not only "tiles", but a kind of "interactive tiles", i.e. "modules with contained interactive models").
Currently I'm re-designing what I call "dynamic models" (which are not contained in modules).

> > Btw.: I had already a multiplayer model of a locomotive in 2010. However, I decided to do a re-design of the software, which is still ongoing (wasn't the optimal decision, probably, but I preferred quality over speed of the project). http://youtu.be/bHBwXmMfF1c
> >
> Oh. OK. Nice work.
> So what doesn't BS Collaborate do? I couldn't understand your docs. 		 	   		  

For my "client based server software" I need to use the "set_" prefix. Only one scene instance should use the "set_" prefix at a time (otherwise the behaviour would be unpredictable). In my nomenclature: The CBSS is active in only one scene instance. This scene instance I denote as "controller" of the NS.

I use a heuristic arbitration mechanism to define the controller role (would probably not work in an MMORPG environment). Would be better to have "network semaphores" natively supported by the NS.
This is, what I describe in the paper "Controller Roles / Network Semaphores" (2013-08-23) on http://smuos.sourceforge.net/docu

> _______________________________________________
> 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