[x3d-public] X3D and VRML for multiuser worlds

Fri Jan 8 14:08:52 PST 2021

Dear Gina Lauren

Please find some feed back *inline*.

Generally, please do not judge too hard, I'm not a native speaker and still some of my wordings do not fit to the real intention.

Kind regards,
Christoph

------------------------------------------------------------------------
>You want to lock in your users. That's not the spirit of open source.

For once I was beginning to open up about the inner workings of a multiuser system, but surprisingly, you apparently don't want to hear about it. It is difficult to talk about open standards for a NSN if we can't refer to actual implementations. It's not like there are a lot of them around..
[CV]: I should not have written this. However, I was a little bit impatient, because I have been preaching for years and years that the protocol itself must be specified. It is not sufficient to specify the fields and the behaviour of the NetworkSensor node. Maybe I did not read your words sufficiently thoroughly, but I had the feeling that you want to omit the specification of the protocol.

Also, who said anything about open source being a requirement? I was actually volunteering closed source information for the benefit of an open standard. If you can't see that I was actually "giving" something to the community.. then perhaps I am wasting my time???
[CV]: Here I used "open source" and meant "open protocols", sorry, my mistake. And, yes, I also "gave" a lot. Using too much time for my hobbies, was one major reason, why my wife left us in 2015 (afterwards the SrrTrains v0.01 project fell into hibernation mode due to lack of resources).

Finally, if you would like to discuss an application layer protocol, maybe look into work that has been done in the past referred to as vrtp and x3dp. Not much, but a starting point. So far I have only heard vague comments about SCTP, UDP, etc. (see below)
[CV]: I am sure that many people have contributed many parts of the puzzle. Now we need somebody, who fits all together (that's not me, is it?)
------------------------------------------------------------------------

------------------------------------------------------------------------
> [CV]: I never suggested to specifiy the transport protocol (http, rtp,
> sctp, tcp, msrp, sip, xmpp, ........).

hhhmmm.. I'm confused, what is this about???
[CV]: Let's assume, we specify an "Application Layer Protocol" (let's call it ALP in the sense of a "working title"). Probably the ALP will consist of the definition of a few PDUs (e.g. in XML, JSON, YAML or similar syntax). Now we have to define, how the PDUs have to be transmitted over the network. Will they be sent as payload in http messages (in the body)? Will they be sent as payload in SIP messages (in the body)? Will they be sent directly over tcp connections?
To get historically: at the beginning of the IETF they had a great movement. You could get T-Shirts with the meme "IP over everything". IP should connect any network with any network, building the Inter-network. So they had to write one RFC for each L2 protocol in order to specify, how IP has to be transported over any L2 link/network.
I am dreaming of an "ALP over everything" movement.

------------------------------------------------------------------------

------------------------------------------------------------------------
>[CV]: SCTP and UDP are members of the TCP/IP protocol family. UDP is as
>old as TCP, just simpler. SCTP is younger. It tries to merge advantages
>of both TCP and UDP and was originally invented to transport SS7 protocols
>(SIGTRAN). SCTP supports 64k streams per association, what perfectly fits
>to our needs, imho

Why are you trying to lecture me about network protocols? And what is it exactly that you are saying or not saying, I find rather perplexing and fail to see the relevancy. Let's keep going...
[CV]: I thought you wrote "SCTP is not TCP/IP". I want to stress that SCTP actually IS TCP/IP
------------------------------------------------------------------------

------------------------------------------------------------------------
>[CV]: Actually I suggested to specifiy ONE AND ONLY ONE application layer protocol,

No-one is questioning this as far as I know. Isn't that precisely what we are trying to do?
Why are you augmenting this in my comments?

[CV]: (see above) Maybe I did not read your words sufficiently thoroughly, but I had the feeling that you want to omit the specification of the protocol.
------------------------------------------------------------------------

------------------------------------------------------------------------
>[CV]: The API (i.e Network Sensor) must be specified to run ONE content with ANY X3D Player.

Let's be careful here. The X3D player does not necessarily need to have agency over the application protocol. For example the X3Daemon client (sorry to bring it up) is entirely separate from the player other than for interpreting ECMAScripts and rendering the results to screen. IOW, the X3Daemon client can theoretically run in any X3D player, regardless of internal multiuser coding, as long as ECMAScript (JavaScript) is supported. This makes it very easy for authors to script avatar and object behaviors, since it provides direct access to X3D nodes. It is also a reason why we need to define a NetworkSensor node as part of the X3D standard.
[CV]: That's exactly what I am saying: you specified your X3Daemon client API, so a content that uses that API, can theoretically run with ANY X3D Player (that the X3Daemon client supports). If we specify a general Network Sensor API, then content can run with any X3D Player that supports the Network Sensor API.
However, if I use the X3Daemon Client API, then I MUST use the X3Daemon Server, because the protocol is proprietary. If the protocol was specified, then I could use ANY server with the X3Daemon Client. It's similar with BS Contact and BS Collaborate.
Most customers are very sensitive about getting locked in. No matter if open source or closed source. We (my employer) made this experience with railway operators, too.
------------------------------------------------------------------------

GL

________________________________________________________
* * * Interactive Multimedia - Internet Management * * *
* * Virtual Reality -- Application Programming * *
* 3D Net Productions 3dnetproductions.com *

> -----Original Message-----
> From: x3d-public [mailto:x3d-public-bounces at web3d.org] On Behalf Of
> Christoph Valentin
> Sent: Tuesday, January 5, 2021 7:06 PM
> To: X3D Graphics public mailing list
> Subject: Re: [x3d-public] X3D and VRML for multiuser worlds
>
> 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/NetworkSensorCo
> nnectionNodes.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-[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-[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[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-[http://web3d.org/mailman/listinfo/x3d-]
> public_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-[http://web3d.org/mailman/listinfo/x3d-]
> public_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-[http://web3d.org/mailman/listinfo/x3d-]
> public_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]