[x3d-public] Fw: Tiny VPN for Use by Web3D Community (max. 10 connections at a time)
John Carlson
yottzumm at gmail.com
Mon Jan 25 16:50:26 PST 2021
I did not have luck running 2 receivers on the same machine. Perhaps I
am missing something?
John
On 1/25/21 6:32 PM, John Carlson wrote:
>
> Voila!
>
> $ netstat -gn|grep tun0
> tun0 1 224.0.0.1
> tun0 1 ff02::1
> tun0 1 ff01::1
>
>
> Please schedule a time and add me to the participants list so we can
> test the multicast (2 receivers, one sender).
>
> I will test to see if I can run 2 receivers on one host,with 224.0.0.1
>
> John
>
> On 1/25/21 6:27 PM, John Carlson wrote:
>>
>> netstat -g looks useful for determining multicast addresses.
>>
>> John
>>
>> On 1/25/21 6:11 PM, John Carlson wrote:
>>>
>>> I figured out how to translate into English!
>>>
>>>
>>> John
>>>
>>> On 1/25/21 6:08 PM, John Carlson wrote:
>>>>
>>>> Ah, no VPN required!
>>>>
>>>>
>>>> John
>>>>
>>>>
>>>> On 1/25/21 5:33 PM, John Carlson wrote:
>>>>
>>>>> Okay, so I have to schedule on a calender when to use VPN, but
>>>>> first I have to get on VPN
>>>>>
>>>>> I got to the calendar. Is there some way to translate to English?
>>>>>
>>>>> This is the point where you steal my files? It always seems to
>>>>> happen with VPN.
>>>>>
>>>>> On 1/25/21 5:08 PM, Christoph Valentin wrote:
>>>>>> Hi John,
>>>>>> You can access the VPN's calendar directly at the experimental
>>>>>> owncloud web interface at my vServer:
>>>>>> (owncloud is a framework mainly for file sharing, but also has
>>>>>> calendar and contacts via WebDav)
>>>>>> URL https://lc-soc-lc.at/owncloud <http://lc-soc-lc.at/owncloud>
>>>>>> user name vpncal
>>>>>> password X3D4
>>>>>> All the best
>>>>>> Christoph
>>>>>> *Gesendet:* Sonntag, 24. Januar 2021 um 15:35 Uhr
>>>>>> *Von:* "Christoph Valentin" <christoph.valentin at gmx.at>
>>>>>> *An:* "John Carlson" <yottzumm at gmail.com>
>>>>>> *Cc:* "X3D Graphics public mailing list" <x3d-public at web3d.org>
>>>>>> *Betreff:* [x3d-public] Fw: Tiny VPN for Use by Web3D Community
>>>>>> (max. 10 connections at a time)
>>>>>> John,
>>>>>> Please *expect some maintenance work (short interruptions) next
>>>>>> week Saturday (30th January).*
>>>>>> I have now *defined an online calendar for the VPN*, to avoid
>>>>>> flooding the mailing list.
>>>>>> The calendar can be *easily integrated with the calendar on your
>>>>>> Android phone* (see the green entry below!!!).
>>>>>> Probably it is possible to integrate it with any smartphone (it
>>>>>> uses the WebDav standard), but I haven't tried.
>>>>>> Installation instructions:
>>>>>> 1) Install DAVx5 on your Android smartphone (available at F-Droid)
>>>>>> 2) Create new DAVx5 account "vpncal at lc-soc-lc.at"
>>>>>> - URL:
>>>>>> https://lc-soc-lc.at/owncloud/remote.php/dav/calendars/vpncal/personal/
>>>>>> <https://lc-soc-lc.at/owncloud/remote.php/dav/calendars/vpncal/personal/>
>>>>>> - user: vpncal
>>>>>> - pw: X3D4
>>>>>> 3) Enable and trigger the synchronization of WebCal
>>>>>> 4) Go to "Calendar" App: make sure the "personal" calendar is
>>>>>> activated for display
>>>>>> The installation instructions will be available at
>>>>>> https://lc-soc-lc.at/experimental
>>>>>> <https://lc-soc-lc.at/experimental> soon.
>>>>>> If you have set the synchronization correctly, then it should be
>>>>>> possible for you to make calendar entries, too (e.g. test
>>>>>> sessions, where you need more than 2 connections, or some
>>>>>> specific multicast address).
>>>>>> KR
>>>>>> Christoph
>>>>>> *Gesendet:* Samstag, 23. Januar 2021 um 14:11 Uhr
>>>>>> *Von:* "Christoph Valentin" <christoph.valentin at gmx.at>
>>>>>> *An:* "X3D Graphics public mailing list" <x3d-public at web3d.org>
>>>>>> *Betreff:* [x3d-public] Tiny VPN for Use by Web3D Community (max.
>>>>>> 10 connections at a time)
>>>>>> Hi John, Gina Lauren, Jordi, and all interested in multiuser
>>>>>> Being very curious to get to know, whether the "server-less mode"
>>>>>> could really work, I was thinking about what could I contribute?
>>>>>> I have got this tiny vServer at hoststar.at (hosted at some cloud
>>>>>> in Germany), where I could implement a VPN for "server-less
>>>>>> experiments".
>>>>>> Voilá
>>>>>> So, if you have a Windows 10 client, then what you can do:
>>>>>> 1) Install OpenVPN Connect software (community edition) -
>>>>>> https://openvpn.net/community-downloads/
>>>>>> <https://openvpn.net/community-downloads/>
>>>>>>
>>>>>> 2) Unzip the config.zip from attachment into C:\Program
>>>>>> Files\OpenVPN\config
>>>>>> 3) Start OpenVPN Client
>>>>>> 4) Connect
>>>>>> 5) Now your client is a multihomed host with an additional
>>>>>> network interface at 172.27.224.0/19
>>>>>> 6) The network 172.27.224.0/19 is an island. Only people, who
>>>>>> receive this e-mail, can connect.
>>>>>> What is missing:
>>>>>> a) a proof that multicast addresses work on the VPN
>>>>>> b) an online calendar to coordinate the multicast sessions at the
>>>>>> VPN-> I will provide this on request.
>>>>>> KR,
>>>>>> Christoph
>>>>>>
>>>>>>
>>>>>>
>>>>>> Gesendet: Samstag, 23. Januar 2021 um 01:34 Uhr
>>>>>> Von: "Christoph Valentin" <christoph.valentin at gmx.at>
>>>>>> An: "John Carlson" <yottzumm at gmail.com>
>>>>>> Cc: "X3D Graphics public mailing list" <x3d-public at web3d.org>
>>>>>> Betreff: Re: [x3d-public] X3D and VRML for multiuser worlds
>>>>>> Hi John,
>>>>>>
>>>>>> Currently having two issues:
>>>>>>
>>>>>> 1) can test the VPN only with two Windows clients -> you have to
>>>>>> create your own experience with the Linux client
>>>>>> 2) still have to make the VPN permanent -> now the VPN has to be
>>>>>> restarted manually after server restart.
>>>>>>
>>>>>> Pls. expect final answer by Saturday evening, CET.
>>>>>>
>>>>>> My plan:
>>>>>>
>>>>>> I will publish (at a hidden place):
>>>>>>
>>>>>> a) example configuration from Windows OpenVPN Connect client
>>>>>> b) ca-yeti.crt self-signed root certificate, which you have to trust
>>>>>> c) x3d-public.key private key for the Web3D community (not really
>>>>>> private)
>>>>>> d) x3d-public.crt certificate for the Web3D community (signed by
>>>>>> yeti -> my server will let you in)
>>>>>> e) ta.key additional symmetric key (must be identical on client
>>>>>> and server)
>>>>>>
>>>>>> Physical restriction: max. 10 connections at the same time,
>>>>>> dynamic IP addresses from a private IPv4 range (172.27.224.0/19).
>>>>>>
>>>>>> The VPN will be an island - the server will not route that
>>>>>> subnet, unless from one client to the others (hopefully including
>>>>>> multicast packets - not yet tested).
>>>>>>
>>>>>> KR
>>>>>> Christoph
>>>>>>
>>>>>>
>>>>>>
>>>>>> Gesendet: Freitag, 22. Januar 2021 um 07:38 Uhr
>>>>>> Von: "John Carlson" <yottzumm at gmail.com>
>>>>>> An: "Christoph Valentin" <christoph.valentin at gmx.at>
>>>>>> Cc: "X3D Graphics public mailing list" <x3d-public at web3d.org>
>>>>>> Betreff: Re: [x3d-public] X3D and VRML for multiuser worlds
>>>>>> 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>[mailto: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 <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>[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>][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>[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
>>>>>> <http://3dnetproductions.com>[http://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>[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_______________________________________________>[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_______________________________________________>[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>[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>[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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20210125/d2567ac3/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kmlcjddfiimgjacf.png
Type: image/png
Size: 240041 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20210125/d2567ac3/attachment-0001.png>
More information about the x3d-public
mailing list