<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>
<div>While I was waiting for further discussion about the topic, I felt free to add a new page to the WIKI at</div>
<div> </div>
<div><a href="https://github.com/christoph-v/spark/wiki/Operational-Paradigm-MMF">https://github.com/christoph-v/spark/wiki/Operational-Paradigm-MMF</a></div>
<div>
<div> </div>
<div> </div>
<div>This page explains a more sophisticated operational paradigm, where the native network sensor nodes are wrapped by some framework of X3D prototypes.</div>
<div> </div>
<div>Having fun with X3D</div>
<div> </div>
<div>P.S.: had a chance to attend Kamailio World Conference 2019 in Berlin last week. Could be an interesting building block of open source software for our needs, if we liked to use SIP for the signalling protocol of MU scenes.</div>
<div><a href="http://www.kamailio.org">http://www.kamailio.org</a></div>
<div> </div>
<div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div style="margin:0 0 10px 0;"><b>Gesendet:</b> Montag, 22. April 2019 um 09:21 Uhr<br/>
<b>Von:</b> "Christoph Valentin" <christoph.valentin@gmx.at><br/>
<b>An:</b> "x3d-publicweb3d.org" <x3d-public@web3d.org><br/>
<b>Betreff:</b> Re: [x3d-public] Fw: Question about MU and Network Sensor</div>
<div name="quoted-content">
<div style="font-family: Verdana;font-size: 12.0px;">
<div>Gina-Lauren, All
<div>
<div> </div>
<div>
<p><span style="font-size: 11.0pt;"><span style="font-family: Calibri , sans-serif;"><span style="color: rgb(31,73,125);">>>>>>>I was hoping you could provide code snippets showing an example of this implementation, as going through and dissecting your entire project to find it myself is a little out of reach time wise.</span></span></span></p>
<div>[Christoph:] Please find some information in the P.S. of this e-mail</div>
<div> </div>
<div>
<p><span style="font-size: 11.0pt;"><span style="font-family: Calibri , sans-serif;"><span style="color: rgb(31,73,125);">>>>>>>Specific implementations may have different goals and objectives, but I am not too concerned with that. I'd like us to focus on the network connection interface directly, in a way that it can be generalized and applicable to a wide range of applications. </span></span></span></p>
<div>[Christoph:] Since I have used the native Network Sensor of an X3D Player and the test version of the according server, I can only offer experience with the authoring "side of the coin". The networking "side of the coin" is new to me. Not wanting to say I would be afraid. We will manage this. However, help from some people here at the list, who already did such stuff, could be senseful.</div>
<div>First statement: when we look at the picture at <a href="https://github.com/christoph-v/spark/wiki/Operational-Paradigm" target="_blank">https://github.com/christoph-v/spark/wiki/Operational-Paradigm</a> , then we can split the "Networking discussion" into several "areas of interest"</div>
<ul>
<li>Networking Topics related to the HNSI (Concentration, Scheduling, Buffering, Routing, ......)</li>
<li>Networking Topics related to the NSI (login, avatars, chat, voice chat, ......)</li>
<li>Networking Topics related to the lower layers (server, application layer protocol, transport protocol, ......)</li>
</ul>
</div>
</div>
<div>Have a nice week</div>
<div>Christoph</div>
<div> </div>
<div>P.S.: here the code snippets from the SrrTrains v0.01 project (<a href="http://simulrr.sourceforge.net" target="_blank">simulrr.sourceforge.net</a>)</div>
<div> </div>
<div><span style="font-size: 11.0px;"><span style="font-family: Courier New , Courier , monospace;">1) Code Snippets from the main file (main_bscontact.x3d in directory "FrameMain")</span></span></div>
<div> </div>
<span style="font-size: 11.0px;"><span style="font-family: Courier New , Courier , monospace;">[...]</span></span>
<div>
<div><span style="font-size: 11.0px;"><span style="font-family: Courier New , Courier , monospace;"> <NetConnection DEF='Conn' address='"localhost"' port='12345' protocol='3' enabled='false' /></span></span></div>
<div><span style="font-size: 11.0px;"><span style="font-family: Courier New , Courier , monospace;">[...]</span></span></div>
</div>
<div><span style="font-size: 11.0px;"><span style="font-family: Courier New , Courier , monospace;">The "address" field must be set to the address (IP@ or FQDN) of the server, the "port" field must be set to the port of the server, before login of the user.</span></span></div>
<div> </div>
<div><span style="font-size: 11.0px;"><span style="font-family: Courier New , Courier , monospace;">[...]</span></span></div>
<div>
<div><span style="font-size: 11.0px;"><span style="font-family: Courier New , Courier , monospace;"> <BSCollaborate DEF='MU'><br/>
<NetConnection USE='Conn' containerField = 'connection'/><br/>
</BSCollaborate></span></span></div>
<div><span style="font-size: 11.0px;"><span style="font-family: Courier New , Courier , monospace;">[...]</span></span></div>
</div>
<div><span style="font-size: 11.0px;"><span style="font-family: Courier New , Courier , monospace;">The "tryLogin" field must receive the user credentials in order to login at the server and start the simulation</span></span></div>
<div> </div>
<div><span style="font-size: 11.0px;"><span style="font-family: Courier New , Courier , monospace;">[...]</span></span></div>
<div>
<div><span style="font-size: 11.0px;"><span style="font-family: Courier New , Courier , monospace;"> <!-- ******************************************************************** --><br/>
<!-- ******* Simple Scene Controller ******* --><br/>
<!-- ******* The Simple Scene Controller is the central part of ******* --><br/>
<!-- ******* the SMUOS Framework, which controls the basics of ******* --><br/>
<!-- ******* the simulation ******* --><br/>
<!-- ******************************************************************** --><br/>
<ProtoInstance DEF='SscBase' name='SscBase'><br/>
<fieldValue name='useConnection' value='Conn'/><br/>
<fieldValue name="mandatorySscBaseExtensions"><br/>
<ProtoInstance DEF="TrainManager" name="SrrControlTm"/><br/>
<ProtoInstance DEF="KeyManager" name="SscKeyManager"/><br/>
<ProtoInstance DEF="BeamerManager" name="SscBeamerManager"/><br/>
</fieldValue><br/>
</ProtoInstance></span></span></div>
<div><span style="font-size: 11.0px;"><span style="font-family: Courier New , Courier , monospace;">[...]</span></span></div>
<div><span style="font-size: 11.0px;"><span style="font-family: Courier New , Courier , monospace;">The field "useConnection" tells the SMUOS Framework, which "NetConnection" shall be used by the Network Sensors within the SMUOS Framework.</span></span></div>
<div><span style="font-size: 11.0px;"><span style="font-family: Courier New , Courier , monospace;">The field "mandatorySscBaseExtensions" registers 3rd party extensions of the SSC.</span></span></div>
<div> </div>
<div><span style="font-size: 11.0px;"><span style="font-family: Courier New , Courier , monospace;">[...]</span></span></div>
<div>
<div><span style="font-size: 11.0px;"><span style="font-family: Courier New , Courier , monospace;"> <!-- MU login and telling result to the Simple Scene Controller to trigger his initialization --><br/>
<ROUTE fromField='tryLogin' fromNode='SceneInterface' toField='tryLogin' toNode='MU'/><br/>
<ROUTE fromField='sessionId' fromNode='MU' toField='sessionId' toNode='SscBase'/><br/>
<ROUTE fromField='loginResult' fromNode='MU' toField='init' toNode='SscBase'/></span></span></div>
<div><span style="font-size: 11.0px;"><span style="font-family: Courier New , Courier , monospace;">[...]</span></span></div>
<div><span style="font-size: 11.0px;"><span style="font-family: Courier New , Courier , monospace;">The "sessionId" and the "loginResult" MUST be forwarded to the SSC in order to initialize the SMUOS Framework AFTER login</span></span></div>
<div> </div>
<div><span style="font-size: 11.0px;"><span style="font-family: Courier New , Courier , monospace;">[...]<br/>
<!-- The SMUOS Framework provides the possibility to generate avatar position relative to a local --><br/>
<!-- (animated) coordinate system --><br/>
<ROUTE fromField='reportOwnPosition' fromNode='SscBase' toField='userPos' toNode='MU'/><br/>
<ROUTE fromField='reportOwnRotation' fromNode='SscBase' toField='userOri' toNode='MU'/></span></span></div>
<div><span style="font-size: 11.0px;"><span style="font-family: Courier New , Courier , monospace;"> <!-- connecting BS Collaborate with the Chat HUD --><br/>
<ROUTE fromField='forwardMeSay' fromNode='SceneInterface' toField='meSay' toNode='MU'/><br/>
<ROUTE fromField='hasSaid' fromNode='MU' toField='receiveHasSaid' toNode='SceneInterface'/></span></span></div>
<div><span style="font-size: 11.0px;"><span style="font-family: Courier New , Courier , monospace;">[...]</span></span></div>
<div><span style="font-size: 11.0px;"><span style="font-family: Courier New , Courier , monospace;">The "SceneInterface" is a script node in the main file, whose fields are dedicated to be modified and or read via EAI/SAI</span></span></div>
<div> </div>
</div>
</div>
<div><span style="font-size: 11.0px;"><span style="font-family: Courier New , Courier , monospace;">2) Code Snippets from an NSAPI Prototype</span></span></div>
<div> </div>
<div><span style="font-size: 11.0px;"><span style="font-family: Courier New , Courier , monospace;">The SMUOS Framework puts prototypes around the native Network Sensors - the so called NSAPIs - Network Sensor APIs. This is due to several reasons:</span></span></div>
<div style="margin-left: 40.0px;"><span style="font-size: 11.0px;"><span style="font-family: Courier New , Courier , monospace;">a) the SMUOS Framework supports the NS of BS Contact and of Octaga Player and must hide the differences from the rest of the software (however, Octaga Support is currently dead code in the SMUOS Framework and is not tested currently due to effort reasons. Additionally, I heard a rumor that Instant Player had implemented the NS, too, would have to check)</span></span></div>
<div style="margin-left: 40.0px;"><span style="font-size: 11.0px;"><span style="font-family: Courier New , Courier , monospace;">b) adding SMUOS specific functionality to the native NS</span></span></div>
<div> </div>
<div><span style="font-size: 11.0px;"><span style="font-family: Courier New , Courier , monospace;">I have added the NSAPI of a network sensor that is used within the MIDAS Object "Binary Switch". This network sensor can transport two events from any scene instance to the controller scene instance.</span></span></div>
<ul>
<li><span style="font-size: 11.0px;"><span style="font-family: Courier New , Courier , monospace;">requesting to toggle the state of the switch</span></span></li>
<li><span style="font-size: 11.0px;"><span style="font-family: Courier New , Courier , monospace;">requesting to set the state of the switch (this event is not provided to the scene author, it is only available via the Console Interface)</span></span></li>
</ul>
<div><span style="font-size: 11.0px;"><span style="font-family: Courier New , Courier , monospace;">[...]</span></span></div>
<div>
<div><span style="font-size: 11.0px;"><span style="font-family: Courier New , Courier , monospace;"> <ProtoDeclare name='MoosSwitchANs'><br/>
<ProtoInterface><br/>
<!-- Common fields for the MASTER/DEP state machine --><br/>
<field accessType='outputOnly' name='sendLoaded' type='SFBool'/><br/>
<field accessType='inputOnly' name='receivePing' type='SFBool'/><br/>
<field accessType='outputOnly' name='sendPong' type='SFBool'/><br/>
<field accessType='inputOnly' name='receiveBasicInit' type='SFBool'/><br/>
<!-- Common fields for all SMUOS prototypes --><br/>
<field accessType='outputOnly' name='objType' type='SFString'/><br/>
<field accessType='outputOnly' name='version' type='SFFloat'/><br/>
<!-- Common fields for all MIDAS network sensors --><br/>
<field accessType='inputOutput' name='objId' type='SFString' value=''/><br/>
<field accessType='inputOutput' name='extObjId' type='SFString' value=''/><br/>
<field accessType='inputOutput' name='streamName' type='SFString' value=''/><br/>
<field accessType='inputOutput' name='streamNameSuffix' type='SFString' value=''/><br/>
<field accessType='inputOutput' name='streamNameUser' type='SFString' value=''/><br/>
<field accessType='inputOutput' name='universalObjectClass' type='SFNode' value='NULL'/><br/>
<field accessType='inputOutput' name='commParam' type='SFNode' value='NULL'/><br/>
<field accessType='inputOutput' name='modParam' type='SFNode' value='NULL'/><br/>
<field accessType='inputOnly' name='init' type='SFBool'/><br/>
<field accessType='outputOnly' name='initialized' type='SFInt32'/><br/>
<field accessType='inputOutput' name='iAmObCo' type='SFBool' value='false'/><br/>
<field accessType='inputOutput' name='enabled' type='SFBool' value="true"/><br/>
<!-- Specific fields for MoosSwitchANs --><br/>
<field accessType='inputOnly' name='evt_toggle' type='SFBool'/><br/>
<field accessType='outputOnly' name='toggle_evt' type='SFBool'/><br/>
<field accessType='inputOnly' name='evt_setState' type='SFBool'/><br/>
<field accessType='outputOnly' name='setState_evt' type='SFBool'/><br/>
</ProtoInterface><br/>
<ProtoBody></span></span></div>
<div><br/>
<span style="font-size: 11.0px;"><span style="font-family: Courier New , Courier , monospace;">[...]</span></span></div>
<div><span style="font-size: 11.0px;"><span style="font-family: Courier New , Courier , monospace;">The field "iAmObCo" indicates whether this scene instance takes the controller role for this network sensor or not, the fields "evt_toggle", "toggle_evt", "evt_setState", "setState_evt" are the fields that are used for the "Operational Use Case" of "client side calculations". The state itself is calculated in the controller instance of the MIDAS object ("iAmObCo" = true).</span></span></div>
</div>
<div> </div>
<div><span style="font-size: 11.0px;"><span style="font-family: Courier New , Courier , monospace;">[...]</span></span></div>
<div>
<div><span style="font-size: 11.0px;"><span style="font-family: Courier New , Courier , monospace;"><!-- ***************************************************************************** --><br/>
<!-- ****** Native Network Sensor ****** --><br/>
<!-- ****** ****** --><br/>
<!-- ****** - The native network sensor will be stored in this ****** --><br/>
<!-- ****** group, after it has been dynamically created ****** --><br/>
<!-- ****** ****** --><br/>
<!-- ***************************************************************************** --><br/>
<Group DEF='NsGroup'/></span></span></div>
<div><br/>
<span style="font-size: 11.0px;"><span style="font-family: Courier New , Courier , monospace;">[...]</span></span></div>
<div><span style="font-size: 11.0px;"><span style="font-family: Courier New , Courier , monospace;">This group will hold the native network sensor after creation</span></span></div>
<div> </div>
<div><span style="font-size: 11.0px;"><span style="font-family: Courier New , Courier , monospace;">[...]</span></span></div>
<div>
<div><span style="font-size: 11.0px;"><span style="font-family: Courier New , Courier , monospace;"> if (sensorInitialized)<br/>
{<br/>
tracerControl.freeTextDebug = new MFString ('network sensor is already initialized -> returning after initialization of tracer');<br/>
initialized = 2;<br/>
return;<br/>
}<br/>
var VrmlString = 'NetworkSensor {';<br/>
if (storedCommParam.browserIx == storedCommParam.blaxxunIx)<br/>
{<br/>
tracerControl.freeTextDebug = new MFString('trying to create Blaxxun EventStreamSensor node');<br/>
VrmlString = 'EventStreamSensor {connection USE ' + storedCommParam.useConnection + ' ';<br/>
}<br/>
else if (storedCommParam.browserIx == storedCommParam.octagaIx)<br/>
{<br/>
tracerControl.freeTextDebug = new MFString('trying to create Octaga NetworkSensor node');<br/>
VrmlString = 'NetworkSensor {';<br/>
}<br/>
VrmlString = VrmlString<br/>
+ 'eventIn SFBool evt_toggle '<br/>
+ 'eventOut SFBool toggle_evt '<br/>
+ 'eventIn SFBool evt_setState '<br/>
+ 'eventOut SFBool setState_evt '<br/>
+ '}';<br/>
tracerControl.freeTextDebug = new MFString('using VrmlString=' + VrmlString);<br/>
var createResult = false;<br/>
var NetwSens;<br/>
if (storedCommParam.browserIx == storedCommParam.blaxxunIx)<br/>
{<br/>
createResult = Browser.addVrmlFromString(VrmlString, nsGroup);<br/>
if (createResult)<br/>
{<br/>
NetwSens = nsGroup.children[0];<br/>
NetwSens.streamName = streamName;<br/>
}<br/>
}<br/>
else if (storedCommParam.browserIx == storedCommParam.octagaIx)<br/>
{<br/>
var temp = Browser.createVrmlFromString(VrmlString);<br/>
if (temp.length)<br/>
{<br/>
createResult = true;<br/>
NetwSens = temp[0];<br/>
NetwSens.connection = storedCommParam.connection;<br/>
NetwSens.networkSensorId = streamName;<br/>
}<br/>
}<br/>
if (createResult)<br/>
{<br/>
// yes, network sensor could be created<br/>
NetwSens.enabled = enabled;<br/>
Browser.addRoute(getScript,'distributeEnabled',NetwSens,'enabled');<br/>
Browser.addRoute(NetwSens,'initialized',getScript,'intd');<br/>
Browser.addRoute(NetwSens,'toggle_evt',getScript,'receiveToggle');<br/>
Browser.addRoute(getScript,'sendToggle',NetwSens,'evt_toggle');<br/>
Browser.addRoute(NetwSens,'setState_evt',getScript,'receiveSetState');<br/>
Browser.addRoute(getScript,'sendSetState',NetwSens,'evt_setState');<br/>
if (storedCommParam.browserIx == storedCommParam.octagaIx)<br/>
{<br/>
sensorInitialized = true;<br/>
}<br/>
tracerControl.startTimer = new MFString('NsInitTimer');<br/>
startTimer = timestamp;<br/>
}<br/>
else<br/>
{<br/>
tracerControl.freeTextInfo = new MFString ('NetworkSensor could not be created -> initialization failed');<br/>
initialized = 0;<br/>
}</span></span></div>
<div><span style="font-size: 11.0px;"><span style="font-family: Courier New , Courier , monospace;">[...]</span></span></div>
<div><span style="font-size: 11.0px;"><span style="font-family: Courier New , Courier , monospace;">Creation of the Network Sensor</span></span></div>
</div>
</div>
<div> </div>
<div style="margin: 10.0px 5.0px 5.0px 10.0px;padding: 10.0px 0 10.0px 10.0px;border-left: 2.0px solid rgb(195,217,229);">
<div style="margin: 0 0 10.0px 0;"><b>Gesendet:</b> Sonntag, 21. April 2019 um 21:30 Uhr<br/>
<b>Von:</b> "GL" <info@3dnetproductions.com><br/>
<b>An:</b> x3d-public@web3d.org<br/>
<b>Betreff:</b> Re: [x3d-public] Fw: Question about MU and Network Sensor</div>
<div>
<div>
<div class="Section1">
<p class="MsoNormal"><span style="font-size: 11.0pt;font-family: Calibri , sans-serif;color: rgb(31,73,125);">I was hoping you could provide code snippets showing an example of this implementation, as going through and dissecting your entire project to find it myself is a little out of reach time wise.</span></p>
<p class="MsoNormal"><span style="font-size: 11.0pt;font-family: Calibri , sans-serif;color: rgb(31,73,125);"> </span></p>
<p class="MsoNormal"><span style="font-size: 11.0pt;font-family: Calibri , sans-serif;color: rgb(31,73,125);">Buffering, as in consolidating events from the various NSs into a minimum number of connections, as opposed to initiating a connection every time an event calls for it. </span></p>
<p class="MsoNormal"><span style="font-size: 11.0pt;font-family: Calibri , sans-serif;color: rgb(31,73,125);"> </span></p>
<p class="MsoNormal"><span style="font-size: 11.0pt;font-family: Calibri , sans-serif;color: rgb(31,73,125);">I talked about the two sides of a coin, but you may or may not have visibility to another aspect of what a NetworkSensorNode is; namely the browser side or, the client side of the client-server relationship. The NetworkSensorNode is the interface between the scene and the network, and if we only looked at scene authoring, then we'd be completely missing out on the network side, which is really what's important here.</span></p>
<p class="MsoNormal"><span style="font-size: 11.0pt;font-family: Calibri , sans-serif;color: rgb(31,73,125);"> </span></p>
<p class="MsoNormal"><span style="font-size: 11.0pt;font-family: Calibri , sans-serif;color: rgb(31,73,125);">Specific implementations may have different goals and objectives, but I am not too concerned with that. I'd like us to focus on the network connection interface directly, in a way that it can be generalized and applicable to a wide range of applications. </span></p>
<p class="MsoNormal"><span style="font-size: 11.0pt;font-family: Calibri , sans-serif;color: rgb(31,73,125);"> </span></p>
<p class="MsoNormal"><span style="font-size: 11.0pt;font-family: Calibri , sans-serif;color: rgb(31,73,125);">GL </span></p>
<p class="MsoNormal"><span style="font-size: 11.0pt;font-family: Calibri , sans-serif;color: rgb(31,73,125);"> </span></p>
<div>
<div style="border: none;border-top: solid rgb(181,196,223) 1.0pt;padding: 3.0pt 0.0in 0.0in 0.0in;">
<p class="MsoNormal"><b><span style="font-size: 10.0pt;font-family: Tahoma , sans-serif;">From:</span></b><span style="font-size: 10.0pt;font-family: Tahoma , sans-serif;"> x3d-public [mailto:x3d-public-bounces@web3d.org] <b>On Behalf Of </b>Christoph Valentin<br/>
<b>Sent:</b> Sunday, April 21, 2019 2:46 PM<br/>
<b>To:</b> x3d-public@web3d.org<br/>
<b>Subject:</b> Re: [x3d-public] Fw: Question about MU and Network Sensor</span></p>
</div>
</div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">>>>>> However, once you do buffer events in order to manage connections, then the perceived benefit of placing NetworkSensors inside models may become moot, though perhaps under specific scenarios an author may elect to use that approach. Have you tried such an implementation?<br/>
<br/>
<br/>
I did not understand the issue with the buffering ?????? Is it about the HNSI?<br/>
--<br/>
Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.</p>
</div>
<div>
<p class="MsoNormal">Am 21.04.19, 19:59, Christoph Valentin <christoph.valentin@gmx.at> schrieb:</p>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size: 7.0pt;font-family: Verdana , sans-serif;">>>> Have you tried such an implementation?</span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 7.0pt;font-family: Verdana , sans-serif;"> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 7.0pt;font-family: Verdana , sans-serif;">Yes</span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 7.0pt;font-family: Verdana , sans-serif;"><a href="http://simulrr.sourceforge.net" target="_blank">http://simulrr.sourceforge.net</a></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size: 7.0pt;font-family: Verdana , sans-serif;"> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 7.0pt;font-family: Verdana , sans-serif;"> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 7.0pt;font-family: Verdana , sans-serif;">>>> I do not really see how it simplifies authoring, as models portability would also be impeded.</span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 7.0pt;font-family: Verdana , sans-serif;">If it's agreed as an ISO standard, the portability would even be increased, avoiding museum like 3D models</span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 7.0pt;font-family: Verdana , sans-serif;"> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 7.0pt;font-family: Verdana , sans-serif;"> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 7.0pt;font-family: Verdana , sans-serif;">>>>Perhaps a specific example would help.</span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size: 7.0pt;font-family: Verdana , sans-serif;"><a href="http://simulrr.sourceforge.net" target="_blank">http://simulrr.sourceforge.net</a></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 7.0pt;font-family: Verdana , sans-serif;"> </span></p>
</div>
</div>
<div style="border: none;border-left: solid rgb(195,217,229) 1.5pt;padding: 0.0in 0.0in 0.0in 6.0pt;margin-left: 6.0pt;margin-top: 6.0pt;margin-right: 3.0pt;margin-bottom: 3.0pt;">
<div style="margin-bottom: 6.0pt;">
<p class="MsoNormal"><b><span style="font-size: 7.0pt;font-family: Verdana , sans-serif;">Gesendet:</span></b><span style="font-size: 7.0pt;font-family: Verdana , sans-serif;"> Sonntag, 21. April 2019 um 19:13 Uhr<br/>
<b>Von:</b> "GL" <info@3dnetproductions.com><br/>
<b>An:</b> "'x3d-publicweb3d.org'" <x3d-public@web3d.org><br/>
<b>Betreff:</b> Re: [x3d-public] Fw: Question about MU and Network Sensor</span></p>
</div>
<div>
<p class="MsoNormal"><br/>
<span style="font-size: 7.0pt;font-family: Verdana , sans-serif;">Absolutely. In its most basic form: X3DNetworkSensorNode = Connection + NetworkSensor(s)<br/>
<br/>
You are essentially asking if it is ok to separate the two sides of a coin,<br/>
and "bury/hide" one side into models. I get that. The problem becomes one of connection instantiation. Unless you have in place a mechanism for buffering events, the NetworkSensors will keep on instantiating connections. However, once you do buffer events in order to manage connections, then the perceived benefit of placing NetworkSensors inside models may become moot, though perhaps under specific scenarios an author may elect to use that approach. Have you tried such an implementation? I do not really see how it simplifies authoring, as models portability would also be impeded. Perhaps a specific example would help.<br/>
<br/>
GL<br/>
<br/>
<br/>
<br/>
From: x3d-public [mailto:x3d-public-bounces@web3d.org] On Behalf Of Christoph Valentin<br/>
Sent: Sunday, April 21, 2019 6:08 AM<br/>
To: x3d-publicweb3d.org<br/>
Subject: [x3d-public] Fw: Question about MU and Network Sensor<br/>
<br/>
I have not yet answered the part of the example about entering the car and driving away........<br/>
<br/>
Let's first discuss the basics, OK? :-)<br/>
<br/>
Gesendet: Sonntag, 21. April 2019 um 11:47 Uhr<br/>
Von: "Christoph Valentin" <christoph.valentin@gmx.at><br/>
An: "x3d-publicweb3d.org" <x3d-public@web3d.org><br/>
Betreff: Re: [x3d-public] Question about MU and Network Sensor<br/>
Gina-Lauren, All<br/>
<br/>
To stick to your example: No, I am not suggesting that. You are bringing two things together that are not related to each other.<br/>
<br/>
1. Having Network Sensors "buried" within models<br/>
2. Each Network Sensor using their own network connection<br/>
<br/>
These two things are not related with each other. If you had had a look to my drawing, you would have seen the network connection is maintained by the "Network Sensor Infrastructure" and all "Network Sensor"s use the same connection, using the "Hidden Network Sensor Interface" (HNSI).<br/>
<br/>
Getting back to the example:<br/>
<br/>
The hat of the avatar and the bag he is carrying are two examples of models that don't need any synchronization. Given the hat and the bag are rigid bodies, they are just rendered relative to the hand of the avatar and relative to the head of the avatar.<br/>
<br/>
The avatar has to care for the synchronization of the position of his hand and of his head (and therefore of the bag and of the hat).<br/>
<br/>
The car and its doors, the steering and the drive, are a perfect example for what I mean, on the other hand. In my humble opinion, the model of the car should already contain all environment sensors (e.g. a touch sensor for each door) and all network sensors for the synchronization of the car (of its doors, steering and drive).<br/>
<br/>
The surrounding scene should as little as possible be affected by the following facts<br/>
• it is a car, that is attached to the scene<br/>
• the car is MU capable<br/>
• the specific type of the car (racing car, offroad car, ......)<br/>
<br/>
So let me rephrase my question to x3d-public:<br/>
a) Is it OK to require from each Network Sensor implementation to use a HNSI for the connection of all Network Sensors to the Network Sensor Infrastructure, in order to ENABLE burying of network sensors within models?<br/>
b) Is it OK, to ALLOW model authors to bury their Network Sensors within their models without bothering scene authors too much?<br/>
<br/>
One detail: we are using the term "network connection". This term is poorly specified, but I think we can agree to use it, as long as we define we are meaning one of the following things:<br/>
• TCP connection<br/>
• SCTP association<br/>
• SIP dialog<br/>
• .......and so on<br/>
<br/>
All the best<br/>
Christoph<br/>
<br/>
Gesendet: Sonntag, 21. April 2019 um 07:25 Uhr<br/>
Von: "GL" <info@3dnetproductions.com><br/>
An: "'x3d-publicweb3d.org'" <x3d-public@web3d.org><br/>
Betreff: Re: [x3d-public] Question about MU and Network Sensor<br/>
Christoph,<br/>
<br/>
Let's say for example that you have an avatar wearing a hat and carrying a bag. That avatar opens a car door, gets in and drives away.<br/>
<br/>
Are you suggesting that the avatar, the hat, the bag, the car door and the car itself should all have a separate NS within and make each their own connection to the server? It is feasible, but unless I am missing something from this reasoning, my take on it would be that the server would get overloaded rather quickly, resulting from all of the extra connections. So in other words, instead of being able to handle say 50 avatars per machine, now we'd have only 10 (in this example), since each model would have to synchronize via their own connection. Also, network latency could cause the hat to fall behind or the car door to get ahead of the car and everything.<br/>
<br/>
Like I've mentioned before, I could see something this working somewhat better with Java3D (though I haven't touched it in years), but with X3D it brings up questions to my mind. So to answer your question, IMO it is better to have fewer connections and pack as much info into them as possible. But assuming that you'd want to do it anyway, the models would still work and interact with the scene as specified (however we're getting into other considerations here that exceed the context of this post).<br/>
<br/>
GL<br/>
<br/>
From: x3d-public [mailto:x3d-public-bounces@web3d.org] On Behalf Of Christoph Valentin<br/>
Sent: Saturday, April 20, 2019 12:26 PM<br/>
To: x3d-publicweb3d.org<br/>
Subject: [x3d-public] Question about MU and Network Sensor<br/>
<br/>
Dear all,<br/>
<br/>
Am trying to figure out one detail about the highly discussed "Network Sensor".<br/>
<br/>
Have now explained the "operational paradigm" of the network sensor, as I think to understand, at our SP-ARK WIKI:<br/>
<br/>
<a href="https://github.com/christoph-v/spark/wiki/Operational-Paradigm" target="_blank">https://github.com/christoph-v/spark/wiki/Operational-Paradigm</a><br/>
<br/>
If you follow that link, you will find I am trying to use my own words in order to describe the well-known. This is not only due to the fact that I have got a fatal tendence to invent the wheel another time and another time, it it also due to Copyright considerations.<br/>
<br/>
If you follow the link, then you will find my impression the interface of the Network Sensor is twofold.<br/>
<br/>
First there is the what-I-call CNSI (Common Network Sensor Interface).<br/>
<br/>
Second there is the what-I-call SNSI (Specific Network Sensor Interface).<br/>
<br/>
Now getting to the point: is it acceptable to require the SNSI MUST remain WITHIN the model? Is it allowed to have it affecting the "master scene"?<br/>
<br/>
I think this is an important question, otherwise I wouldn't bother you.<br/>
<br/>
All the best<br/>
<br/>
Christoph<br/>
<br/>
P.S.: Currently the WIKI has got only two pages, the home page is <a href="https://github.com/christoph-v/spark/wiki" target="_blank">https://github.com/christoph-v/spark/wiki</a><br/>
<br/>
<br/>
_______________________________________________<br/>
x3d-public mailing list<br/>
x3d-public@web3d.org<br/>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br/>
<br/>
<br/>
_______________________________________________<br/>
x3d-public mailing list<br/>
x3d-public@web3d.org<br/>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a></span></p>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal">_______________________________________________ x3d-public mailing list x3d-public@web3d.org <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a></p>
</div>
</div>
_______________________________________________ x3d-public mailing list x3d-public@web3d.org <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a></div>
</div>
</div>
</div>
</div>
</div>
_______________________________________________ x3d-public mailing list x3d-public@web3d.org <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a></div>
</div>
</div>
</div></div></body></html>