[x3d-public] X3D and VRML for multiuser worlds

Tue Jan 5 19:18:08 PST 2021

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 <mailto:info at 3dnetproductions.com> 
Sent: Tuesday, January 5, 2021 11:53 AM
To: X3D Graphics public mailing <mailto:x3d-public at web3d.org>  list
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 <mailto:christoph.valentin at gmx.at>  Valentin
Sent: Monday, January 4, 2021 10:55 PM
To: Cecile Muller <mailto:contact at wildpeaks.fr> 
Cc: X3D Graphics public mailing <mailto:x3d-public at web3d.org>  list
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20210105/8830f52c/attachment-0001.html>