[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:32:42 PST 2021
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/9422225e/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/9422225e/attachment-0001.png>
More information about the x3d-public
mailing list