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

[Christoph Valentin]

> >>>>> 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.
> >
> > [Christoph:]
> > 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.
> >
> 
> Is this because BS Collaborate is peer-to-peer and you need client-server? The Controller is the server? Or does controller need to move from peer-to-peer? Is there a train analogy?

[Christoph:] BS Collaborate is a server. I hope I do not forget anything (if anybody from BM listening, please correct me :-) )

BS Collaborate is a server that provides at least following services:
   - login with user name and password
   - distribute events to all scene instances of a chat room
   - store and distribute states to all scene instances of a chat room
   - server side calculations of states (add_, mult_ and so on)
   - setting a state (set_ prefix)

I need one scene instance that is "responsible" for the state of an object, because the state is calculated by scripts in the client, not on the server and then set via "set_" prefix.
This scene instance I call "controller". Each object contains "controller" software, but it is only active in one scene instance.

Thus we have two kinds of servers/controllers.
   1) the Collaboration Server BS Collaborate, on a lower layer
   2) the "Controller" of each Network Sensor, in the <Script>s of the scene, on a higher layer

Please see following figure "Communication with one Network Sensor":

  sessionId = 14
  +----------------------+
  |            ------    |
  |           /con-  \   |
  |           |trol- |---+---------+
  |           \ler   /   |         |
  |     ------ ------    |         |
  |    /      \          |         |
  |    |client|          |         |
  |    \      /          |         |
  |     ------           |         |          sessionId = 66
  +-------+--------------+      ---+----      +-------------------+
          |                    /        \     |         ------    |
          |                   /          \    |        /      \   |
          +-------------------|          |----+--------|client|   |
                              |Collabora-|    |        \      /   |
                +-------------|tion Ser- |    |         ------    |
  sessionId = 5 |             \ ver      /    |                   |
  +-------------+--------+     \        /     |                   |
  |             |        |      --------      |                   |
  |             |        |                    |                   |
  |             |        |                    +-------------------+
  |             |        |
  |           ------     |
  |          /      \    |
  |          |client|    |
  |          \      /    |
  |           ------     |
  +----------------------+



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