[x3d-public] X3D and VRML for multiuser worlds
GPU Group
gpugroup at gmail.com
Tue Jan 5 20:16:46 PST 2021
i implemented DIS in freewrl. Here;s a thought from my fuzzy memory:
There are 2 kinds of messages
A the kind where wait for confirmation and resend if packet dropped, and
multiple packet messages
- great for complex messages sent just once, like creating a new avatar, or
removing an avatar
B the single packet with no confirmation signal
- great for repeating messages like avatar position updates, can drop a
packet and nothing bad happens
- great for broadcasting
DIS uses B type. And it's awkward for complex and one-time messages
Ideally both types would be supported for different uses
-Doug
On Tue, Jan 5, 2021 at 8:19 PM GL <info at 3dnetproductions.com> wrote:
> A few days ago I suggested we look back to DIS because I do respect that
> body of work.
>
>
>
> While very war-games centric, I believe that we can take from it the
> general ideas and possibly even some of the specific fields and make that
> part of a more common network sensor node. By that I mean something that
> can be applicable to a wider variety of applications and also have
> dedicated support for HAnim.
>
>
>
> There can remain the question whether it should use binary PDUs or encoded
> URLs, but why not accept each as valid by integrating them both into the
> standard.
>
>
>
> I also do not explicitly object or condone the use of flexible fields at
> this point, though it does seem like a sensible consideration to disallow
> it from a security point of view, because it can be in fact far too easy to
> inject malicious code into a MU data stream without the proper measures in
> place. GL
>
>
>
>
>
>
>
> *From:* x3d-public [mailto:x3d-public-bounces at web3d.org] *On Behalf Of *John
> Carlson
> *Sent:* Tuesday, January 5, 2021 7:07 PM
> *To:* X3D Graphics public mailing list
> *Subject:* Re: [x3d-public] X3D and VRML for multiuser worlds
>
>
>
> I think the last time we brought this up, there was some issue about
> fields shouldn’t be flexible in the network protocol, because it would be
> too difficult to write virus or intrusion rules for scanning the packets.
> I think we’re back to the DIS standard. Please state your objections to
> DIS, perhaps we can work on the DIS standard?
>
>
>
> John
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
> *From: *GL <info at 3dnetproductions.com>
> *Sent: *Tuesday, January 5, 2021 11:53 AM
> *To: *X3D Graphics public mailing list <x3d-public at web3d.org>
> *Subject: *Re: [x3d-public] X3D and VRML for multiuser worlds
>
>
>
> Now that's more like it. Thanks for the link John.
>
>
>
> I do not know why people are discussing the use of different network
> protocols for client-server connections, when HTTP on TCP works just fine
> for our purpose. This is not where the bottleneck is, the kernel is. Plus,
> HTTP is already supported with most operating systems, that in addition to
> the fact that we are here to discuss X3D, not network protocols. The same
> can largely apply to client-client connections.
>
>
>
> When I express a desire for standardizing a NetworkSensor node, it has in
> fact little to do with the underlying network protocol. What I wish to
> standardize is the node itself. So let's see what we have so far as per
>
>
>
>
> https://www.web3d.org/x3d/content/examples/Basic/Networking/NetworkSensorConnectionNodes.html
>
>
> 9.4.4 Connection
>
> Connection: X3DNetworkSensorNode {
>
> SFBool [in,out] enabled TRUE
>
> SFNode [in,out] metadata NULL [X3DMetadataObject]
>
> SFBool [out] isActive FALSE
>
> MFString [in,out] url ["x3dp://localhost:80/"]
>
> SFInt32 [in] protocol 0 [0,65535]
>
> SFTime [in,out] timeOut 0
>
> SFBool [in] secure TRUE
>
> }
>
> *9.4.5 NetworkSensor*
>
> NetworkSensor : X3DNetworkSensorNode {
>
> SFBool [in,out] enabled TRUE
>
> SFNode [in,out] metadata NULL [X3DMetadataObject]
>
> SFBool [out] isActive
>
> SFNode [in out] connection NULL [Connection node only]
>
> SFString [in] httpRequest ""
>
> MFString [out] httpResponse NULL
>
> SFString [] channelId ""
>
> # And any number of:
>
> fieldType [in] fieldName
>
> fieldType [in,out] fieldName
>
> fieldType [out] fieldName
>
> fieldType [] fieldName
>
> }
>
>
>
> As you can see, this is rather incomplete, more like just the skeleton of
> a node. Can we not build from here where it matters as far as X3D
> standards? And forget about lower protocol layers for a moment, especially
> that ideally X3D should be able to run on top of different internet/network
> protocols?
>
>
>
> If you really want to understand how MU works, this is where it begins,
> and defining the field names would be a very good start.
>
>
>
> The above page states that "a proper implementation requires native
> X3D-player support and a full Prototype-based implementation is not
> possible.", which is only partially correct, since X3Daemon is such an
> implementation, at least when it comes to section 9.4.5. X3Daemon relies on
> the X3D player for 9.4.4 because it is readily available, but there are no
> reason why anyone couldn't make their own implementation. The section 9.4.4
> is also probably where the line should be drawn as far as X3D's
> jurisdiction concerning network protocols.
>
>
>
> There are currently two main implementations of the above that comes to
> mind: BS Collaborate and X3Daemon (do I forget something??).
>
>
>
> We should probably need to reconcile, add or change the field names and
> the types in order to finalize this standard.
>
> I do not see much more that we need. After being stuck here for over a
> decade, I am still not sure why.
>
>
>
> The above is required if we want to standardize connections across both
> clients and servers, regardless of protocols. That is what will allow world
> objects and avatars to work as intended for using the same type
> definitions, field names and parameters. This would facilitate connections
> between worlds, and potentially let avatars travel around them. An avatar
> made for one world would work in a different one, a world made for one
> server would work with a different server, clients could talk to any others
> (providing listeners and response capabilities are built-in), and so on… GL
>
>
>
>
>
>
> ________________________________________________________
>
> * * * Interactive Multimedia - Internet Management * * *
>
> * * Virtual Reality -- Application Programming * *
>
> * 3D Net Productions 3dnetproductions.com *
>
>
>
>
>
>
>
>
>
> *From:* x3d-public [mailto:x3d-public-bounces at web3d.org] *On Behalf Of *John
> Carlson
> *Sent:* Tuesday, January 5, 2021 12:38 AM
> *To:* Christoph Valentin; Cecile Muller
> *Cc:* X3D Graphics public mailing list
> *Subject:* Re: [x3d-public] X3D and VRML for multiuser worlds
>
>
>
> I discovered this recently. It may assist you in your efforts for highly
> scalable systems:
>
>
>
>
> http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html
>
>
> In other words, you’re not limited to 16-bits worth of TCP ports on one
> server.
>
>
>
> My guess is they use multiple IP addresses (IPv6?) on a single server, but
> I’m not sure.
>
>
>
> If anyone does this, let us know how it goes.
>
>
>
> John
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
> *From: *Christoph Valentin <christoph.valentin at gmx.at>
> *Sent: *Monday, January 4, 2021 10:55 PM
> *To: *Cecile Muller <contact at wildpeaks.fr>
> *Cc: *X3D Graphics public mailing list <x3d-public at web3d.org>
> *Subject: *Re: [x3d-public] X3D and VRML for multiuser worlds
>
>
>
> Hi,
>
>
>
> Isn't MQTT the protocol of the IoT?
>
>
>
> It needs a broker, doesn't it?
>
>
>
> Just being curious.
>
>
>
> KR,
>
> Christoph
>
>
>
>
>
>
>
>
>
> Gesendet: Dienstag, 05. Januar 2021 um 05:25 Uhr
>
> Von: "Cecile Muller" <contact at wildpeaks.fr>
>
> An: "X3D Graphics public mailing list" <x3d-public at web3d.org>
>
> Betreff: Re: [x3d-public] X3D and VRML for multiuser worlds
>
>
>
> Good morning (and happy new year !),
>
>
>
>
>
> If you want to build something multi-users, nowadays I'd recommend MQTT:
> it's not specific to 3D,
>
> so you'd still need to create the application on top of it, but you could
> reach both applications and webapps
>
> with it (it can even run on low-end devices), and it's a proper documented
> standard.
>
> Mosquitto on a small linux server is enough to get started,
>
> or you could use something like PubNub to not worry about scaling the
> backend.
>
>
>
>
>
> See you,
>
> Cecile_______________________________________________ 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
>
>
>
>
> _______________________________________________
> 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/20210105/7a9b981f/attachment-0001.html>
More information about the x3d-public
mailing list