[x3d-public] A note on standardization.

[doug sanden]

If you have a land line with modem, and you modem has a no-ip setting, then you can host your 'game server' at home by registering a (free) sub domain at noip.com and steering your modem to it. This will allow your modem to update noip when it's dynamic ip changes.
-doug

From: highaspirations at hotmail.com
To: x3d-public at web3d.org
Date: Mon, 27 Apr 2015 20:55:00 -0600
Subject: Re: [x3d-public] A note on standardization.




Sai allows you to change a scene from ouside, and register callbacks on scene events. If all the web3d browsers support sai, then the networking could be done outside the web3d browsers.
Besides nodejs and php, python looks easy to do a socket server (when I google python socket server I see cute programs). You could configure the server to introduce peers for peer2peer, or keep the server in the middle of the communications.
The dis node uses udp which can broadcast but isn't guaranteed to deliver - its good for single packet ephemeral updates such as mouse coordinates. If you miss one mouse update no problem. For guaranteed delivery tcp should be used, such as sai type updates.
X3dom can send an ajax request for an update to the server, which can stall reply until there is news. As soon as it gets the reply x3dom can ask for the next update. More precisely something just outside x3dom would do this, equivalent to sai.
Going the other direction, when a client has news, it should send it to a different port on the server, so a client can be sending and receiving at the same time. This simplifies your code.
-doug

> From: christoph.valentin at gmx.at
> To: ALONZOTG at verizon.net
> Date: Tue, 28 Apr 2015 02:15:04 +0200
> CC: x3d-public at web3d.org
> Subject: Re: [x3d-public] A note on standardization.
> 
> Gesendet: Dienstag, 28. April 2015 um 00:41 Uhr
> Von: "Alan Grimes" <ALONZOTG at verizon.net>
> An: "Christoph Valentin" <christoph.valentin at gmx.at>
> Cc: "x3d-public at web3d.org" <x3d-public at web3d.org>
> Betreff: Re: Aw: [x3d-public] A note on standardization.
> Christoph Valentin wrote:
> > [Christoph:] I'm not sure if I'm aware of the whole 3D universe, but according to my knowledge there are at least two standards that stick to declarative 3D principles: X3D and X3DOM.
> > When I use the term "Web3D Browser", I mean "anything that sticks to declarative 3D principles according to Web3D Consortium".
> > My dream is to have concurrent Web3D Browsers in one and the same multiuser session (sharing the same state).
> > I.e.: Users "Alice", "Bob" and "Charlie" are meeting in a scene. "Alice" uses X3DOM within Mozilla, "Bob" uses "X3DOM" within IE and "Charlie" uses Octaga Player.
> > In this case, at least the communication protocol must be standardized, better having the interface standardized, too (i.e. the network sensor), to ease the automatic translation of models for use within different Web3D Browsers.
> > I think, a minimum of standardization is necessary, if we want to achieve this goal.
> 
> Okay, the way I see that happening is by means of an intermediary
> server. I think I saw a standard called "DIS: Distributed Interractive
> Simulation" or something, The client would be relatively thin, just a
> graphics terminal to a simulation run, or synchronized by a server which
> may be linked through DIS to a broader network of servers.
> 
> The main issue is being able to write client scripting code that can
> dynamically update the scene displayed based on external events and be
> able to detect user interactions with the local presentation and relay
> those updates back to the server. This functionality will be necessarily
> built into the web browser, all other functionality can be done with
> Jquery or other existing standards, ie a simple re-use of existing
> dynamic web page technology.
> 
> [Christoph:]
> Good point. I'm still not sure on which horse I should bet (also depends on the application).
> When I started my railway simulation experiments, I had a look at the "DIS" component of X3D.
> Please correct me, if I'm wrong, but in my humble opinion, the DIS component is more specialized
> than the network sensor. From looking at the specification in the X3D standard, I decided, it would 
> not be easy to use it for 1-dimensional movement "along the track" of a railway.
> The network sensor, on the other hand, was more general, what means, I had to do more implementation
> work to use it in my scene.
> Another issue: afaik, the DIS "protocol" (PDU definitions) is specified by the IEEE, where the network sensor is still open to standardize the protocol at the IETF (IETF is more "open" than IEEE)
> Looking forward to the answers of the community
> 
> --
> IQ is a measure of how stupid you feel.
> 
> Powers are not rights.
>  
> 
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
 		 	   		  

_______________________________________________
x3d-public mailing list
x3d-public at web3d.org
http://web3d.org/mailman/listinfo/x3d-public_web3d.org 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20150427/ceb8754e/attachment-0001.html>