[x3d-public] X3D and VRML for multiuser worlds

Tue Jan 5 16:05:59 PST 2021

A last try.......

Gesendet: Dienstag, 05. Januar 2021 um 18:53 Uhr
Von: "GL" <info at 3dnetproductions.com>
An: "'X3D Graphics public mailing list'" <x3d-public at web3d.org>
Betreff: 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.
[CV]: I never suggested to specifiy the transport protocol (http, rtp, sctp, tcp, msrp, sip, xmpp, ........). Actually I suggested to specifiy ONE AND ONLY ONE application layer protocol, which should be defined OVER ANY TRANSPORT PROTOCOL.
My paper is a mixture: (1) some first thoughts about the ALP (2) define ALP over RTP (because I like RTP)

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
[CV]: actually you are right, if you mean the network protocol. You are not right, if you mean the application layer protocol. The ALP and the API are siblings, where both must be specified. The ALP must be specified to be able to run ONE server with ANY Client(what, if somebody likes to use your X3daemon server, but he don't want to use your X3D prototypes?). The API (i.e Network Sensor) must be specified to run ONE content with ANY X3D Player.

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?
[CV]: applauding

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.
[CV]: I would suggest to amend the definition of field names with some drawings abaout the message flows and some prosa

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.
[CV]: agree

There are currently two main implementations of the above that comes to mind: BS Collaborate and X3Daemon (do I forget something??).
[CV]: I think, Octaga had 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.
[CV]:agree + see above about some amendments

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  
[CV]: not to forget Jordi's request, we should also consider the server-less mode, as far as possible, useful, applicable 

________________________________________________________
* * * 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[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[mailto:christoph.valentin at gmx.at]
Sent: Monday, January 4, 2021 10:55 PM
To: Cecile Muller[mailto:contact at wildpeaks.fr]
Cc: X3D Graphics public mailing list[mailto: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[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[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[http://web3d.org/mailman/listinfo/x3d-public_web3d.org]