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

doug sanden highaspirations at hotmail.com
Mon Jan 6 06:23:33 PST 2014


>
> Would be curious to know about interest in Network Sensor (aka Event Stream Sensor).
>
> I know the work on Network Sensor is currently stopped (at least in Web3D consortium).
>
> On the other hand I know Sven-Erik has posted some mails about defining a communication protocol for Network Sensor.
>
> I know Don cares for DIS.
>
> I know the product BS Collaborate from Bitmanagement.
>
> And I know Octaga player did support / supports Network Sensor, but Octaga Collaboration Server is not / was not available as a product.
>
> Did I miss something?


If you're using a conventional browser plugin with SAI, I suspect you can ajax back to home base:
client scenegraph -> SAI registered event listener -> html Script node javascript -> ajax POST/GET -> server app -> sockets -> stateful server-side scenegraph server -> sockets -> server app -> ajax response -> html script node callback -> SAI -> client scenegraph

I first saw the ajax technique with a Flux example online, IIRC Toni's Flux/Vivaty went on to become an online multiuser role playing game.

I've done small reound-trip tests recently except not with x3d end points:
- node.js web server app with express package. 
- jQuery helper in html for $.ajax js function which cleans up the browser-specific ajax syntax
- .cpp stateful server: I run this first, and my node.js app is a sockets client of it.

Nodejs is 'asynchronous' meaning it can be doing other things while you prepare a response in your stateful server. So the client request and server response can be separated by hours. And this means instead of a network sensor, you can have a callback in client javascript waiting for any news from home base.

(freewrl had MVIP -a multi-user server of some sort I think it used EAI- but it was never advertised, no docs, no download link, I never saw it run.) 		 	   		  


More information about the X3D-Public mailing list