[x3d-public] X3D and VRML for multiuser worlds
GL
info at 3dnetproductions.com
Fri Jan 8 12:00:27 PST 2021
Christoph Valentin wrote:
>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..
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???
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 never suggested to specifiy the transport protocol (http, rtp,
> sctp, tcp, msrp, sip, xmpp, ........).
hhhmmm.. I'm confused, what is this about???
>[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]: 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]: 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.
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-
> 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]
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
More information about the x3d-public
mailing list