[x3d-public] X3D and VRML for multiuser worlds
John Carlson
yottzumm at gmail.com
Thu Jan 21 22:38:33 PST 2021
I am now prepared to have a "client" of your UDP DIS server at
hoststar.at. I need things like address and port, per X3D PDU nodes.
If there is ssh information for reaching your server network, let me
know. This is my preferred method. I do not believe I need special
permission except for perhaps a new user account.
I've never really used a VPN, and will probably need instructions. My
experience with VPN varies "not very useful" and "OMG, my friends are
going to steal my files."
John
On 1/10/21 11:28 PM, Christoph Valentin wrote:
> If everything works fine (and if I've understood correctly), then you
> can do tests with multicast IP transport, although you are
> geographically separated.
>
> That's what I would like to try basically
>
> --
> Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail
> gesendet.
> Am 11.01.21, 05:11 schrieb John Carlson <yottzumm at gmail.com>:
>
> My friends have asked me to set up a VPN on my machine in the
> past. I don't really see the value of a VPN.
>
> On Sun, Jan 10, 2021 at 7:03 PM Christoph Valentin
> <christoph.valentin at gmx.at <mailto:christoph.valentin at gmx.at>> wrote:
>
> What I am going to try is to setup a VPN with OpenVPN and my
> vServer at hoststar.at <http://hoststar.at>, so we can do a
> test session with DIS (hopefully).
> *Gesendet:* Sonntag, 10. Januar 2021 um 23:13 Uhr
> *Von:* "John Carlson" <yottzumm at gmail.com
> <mailto:yottzumm at gmail.com>>
> *An:* "Christoph Valentin" <christoph.valentin at gmx.at
> <mailto:christoph.valentin at gmx.at>>
> *Cc:* "X3D Graphics public mailing list" <x3d-public at web3d.org
> <mailto:x3d-public at web3d.org>>
> *Betreff:* Re: [x3d-public] X3D and VRML for multiuser worlds
> What I was going to do is try to get DIS from GitHub and DIS
> from X_ITE to talk to each other.
> John
> On Sun, Jan 10, 2021 at 1:08 PM Christoph Valentin
> <christoph.valentin at gmx.at <mailto:christoph.valentin at gmx.at>>
> wrote:
>
> ok
>
> let me repeat your proposal:
>
> >>>>> Of the published work available in that regard, we
> have BS Collaborate, DIS, and the Draft X3D Specification
> for NetworkSensor. I think the first step would be to take
> these, see what they have in common, and go from there for
> deeper analyses.
>
> I think everybody agrees.
>
> So what would be the very first step (before the first
> step)? Assign responsibilities? Create a Wiki? Ask for
> official decision? Just do it? Who? What? When? Create an
> official backlog? Use the S&P-ARK?
>
> kind regards
> Christoph
>
> --
> Diese Nachricht wurde von meinem Android Mobiltelefon mit
> GMX Mail gesendet.
> Am 09.01.21, 07:40 schrieb Christoph Valentin
> <christoph.valentin at gmx.at
> <mailto:christoph.valentin at gmx.at>>:
>
> Not much,
> 1) It's another use case, which has proven it's
> usefulness during SrrTrains v0.01:
> - Customized Client Side Calculations
> ( sent to x3d-public in January 2014:
> https://areasharpa.files.wordpress.com/2018/04/smuos_03_sema_2018_04_27.pdf
> <https://areasharpa.files.wordpress.com/2018/04/smuos_03_sema_2018_04_27.pdf>
> )
> 2) And an idea (which is not yet settled).
> - idea is to have two levels of identification:
> identify the sensor by "streamName" +
> "networkSensorId"
> (BS Collaborate: only "streamName"
> Octaga: only "networkSensorId")
> 1) the stream = the model = the real
> life entity e.g. "car"
> 2) the sensor nodes themselves e.g.
> "steering", "motor", "doors"
> *Gesendet:* Samstag, 09. Januar 2021 um 03:59 Uhr
> *Von:* "GL" <info at 3dnetproductions.com
> <mailto:info at 3dnetproductions.com>>
> *An:* "'X3D Graphics public mailing list'"
> <x3d-public at web3d.org <mailto:x3d-public at web3d.org>>
> *Betreff:* Re: [x3d-public] X3D and VRML for multiuser
> worlds
>
> I am not sure what results you are referring to. Did I
> miss something?
>
> *From:*x3d-public [mailto:x3d-public-bounces at web3d.org
> <mailto:x3d-public-bounces at web3d.org>] *On Behalf Of
> *Christoph Valentin
> *Sent:* Friday, January 8, 2021 9:21 PM
> *To:* 'X3D Graphics public mailing list'
> *Subject:* Re: [x3d-public] Re: X3D and VRML for
> multiuser worlds
>
> so basically you want to ignore my results?
>
> --
> Diese Nachricht wurde von meinem Android Mobiltelefon
> mit GMX Mail gesendet.
>
> Am 09.01.21, 01:07 schrieb GL
> <info at 3dnetproductions.com
> <mailto:info at 3dnetproductions.com>>:
>
> Christoph,
>
> Thank you for the clarifications and your general
> dedication. I believe that little
> misunderstandings should be addressed before they
> snowball into bigger misconceptions.
>
>
>
> > If we specify a general Network Sensor API, then
> content can run
> > with any X3D Player that supports the Network
> Sensor API.
>
> If you read again my last paragraph, I try to make
> a distinction between a multiuser client and a X3D
> player. In other words, the player is not
> necessarily the client. It appears to be a common
> misconception that the X3D player must also be the
> MU client, while in truth it really doesn't have
> to. For the reasons previously stated, I tend to
> prefer that the player does not in fact act as the
> client.
>
>
> > However, if I use the X3Daemon Client API, then
> I MUST use the X3Daemon
> > Server, because the protocol is proprietary.
>
>
> That is precisely why I am here. I do NOT want the
> application protocol to be proprietary. And the
> fact that we still don't have a standard keeps me
> from moving forward, because any development
> efforts I make may someday have to be rewritten
> once we do have a standard. IOW, I am not a big
> fan of reworking systems. I'd rather use open
> standards as early in the process as possible to
> facilitate interoperability later.
>
>
> > If the protocol was specified, then I could use ANY
> > server with the X3Daemon Client.
>
>
> Ideally, systems could interoperate, though there
> are other factors to consider. For example avatars
> must login to authenticate their identity and
> assets, consisting of information that may or may
> not be available to a third party server. But yes,
> you get the general idea.
>
>
>
>
> > It is not sufficient to specify the
> > fields and the behaviour of the NetworkSensor
> node. ...,
> > but I had the feeling that you want to
> > omit the specification of the protocol.
>
>
> Read again, I was referring specifically to
> network protocols. Still, at this early stage, I
> feel it may be a little premature to get too
> involved with an application protocol, that until
> we get a better grasp of what the requirements
> will be. For this reason, I am of the opinion that
> fields and events should be specified first. Just
> so that we have something to build upon.
>
> Of the published work available in that regard, we
> have BS Collaborate, DIS, and the Draft X3D
> Specification for NetworkSensor. I think the first
> step would be to take these, see what they have in
> common, and go from there for deeper analyses.
>
> Once we have that settled, IMO, only then should
> we turn to discuss an application layer protocol
> and its ramifications. GL
>
>
>
> > -----Original Message-----
> > From: x3d-public
> [mailto:x3d-public-bounces at web3d.org
> <mailto:x3d-public-bounces at web3d.org>] On Behalf Of
> > Christoph Valentin
> > Sent: Friday, January 8, 2021 5:09 PM
> > To: X3D Graphics public mailing list
> > Subject: Re: [x3d-public] X3D and VRML for
> multiuser worlds
> >
> > 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
> <http://3dnetproductions.com> *
> >
> >
>
>
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org <mailto: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
> <mailto: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
> <mailto: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 <mailto:x3d-public at web3d.org>
> http://web3d.org/mailman/listinfo/x3d-public_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/20210122/d40a3d68/attachment-0001.html>
More information about the x3d-public
mailing list