[x3d-public] Fw: Tiny VPN for Use by Web3D Community (max. 10 connections at a time)
John Carlson
yottzumm at gmail.com
Tue Jan 26 06:35:31 PST 2021
QUIC can apparently do multicasting like this:
https://nodejs.org/api/quic.html#quic_net_createquicsocket_options
|"quicendpoint.addMembership(address, iface)|#
<https://nodejs.org/api/quic.html#quic_quicendpoint_addmembership_address_iface>
Added in: v15.0.0
* |address| <string>
<https://developer.mozilla.org/en-US/docs/Web/JavaScript/Data_structures#String_type>
* |iface| <string>
<https://developer.mozilla.org/en-US/docs/Web/JavaScript/Data_structures#String_type>
Tells the kernel to join a multicast group at the given
|multicastAddress| and |multicastInterface| using the
|IP_ADD_MEMBERSHIP| socket option. If the |multicastInterface| argument
is not specified, the operating system will choose one interface and
will add membership to it. To add membership to every available
interface, call |addMembership()| multiple times, once per interface."
Anyone want to write Node.js code? Christoph, can we do ALP across QUIC?
Thanks!
John
On 1/25/21 10:27 PM, John Carlson wrote:
>
> We can meet at 11am CST.
>
>
> I hope to have something in Xj3D by that time. We can plan possible
> enhancements to X_ITE (so that X_ITE nodes can become DIS senders and
> receivers). I haven't solved how to do SO_REUSEADDR or SO_REUSEPORT in
> JavaScript yet, and especially on a browser, although browsers use
> QUIC these days. It could be that HTTP or HTTPS over QUIC would be
> sufficient to carry ALP. I guess a lot of sites are doing video over
> HTTP (HTTPS?) these days.
>
>
> John
>
>
> On 1/25/21 9:37 PM, Christoph Valentin wrote:
>> Good Morning!
>> Congrats.
>> Just to be sure: Do you still want to do test session with 1 sender
>> and 2 receivers?
>> I could manage to be available next Saturday 18:00 - 24:00 Viennese time.
>> I entered the appointment to the VPN calendar, but /I'm not sure, if
>> the calendar is smart enough to display the time correctly for your
>> time zone. Could you check this? Thx/
>> /Christoph/
>> *Gesendet:* Montag, 25. Januar 2021 um 18:08 Uhr
>> *Von:* "John Carlson" <yottzumm at gmail.com>
>> *An:* "Christoph Valentin" <christoph.valentin at gmx.at>, "Don
>> Brutzman" <brutzman at nps.edu>, holger.seelig at yahoo.de
>> *Cc:* "X3D Graphics public mailing list" <x3d-public at web3d.org>
>> *Betreff:* Re: Fw: [x3d-public] Tiny VPN for Use by Web3D Community
>> (max. 10 connections at a time)
>>
>> I remember back in 1985-1986 when I was first doing networking, I ran
>> into this reusing the receiver port and address, but I had forgotten!
>>
>> Hurray!
>>
>> So that may be something to set up in the X3D browser!
>>
>> John
>>
>> On 1/25/21 7:01 PM, John Carlson wrote:
>>
>> Just when I give up, a google search works!
>>
>> udpSocket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
>>
>> Please make this chagne in the example receiver in
>> open-dis-python (I'll file an issue).
>>
>> This allows multiple receivers on the same machine, so we don't
>> really need a VPN to test, but I think I will continue testing.
>>
>> coderextreme at coderextreme-Kubuntu20:~/open-dis-python$ jobs
>> [1]- Running python3 examples/dis_receiver.py &
>> [2]+ Running python3 examples/dis_receiver.py &
>> coderextreme at coderextreme-Kubuntu20:~/open-dis-python$ !py
>> python3 examples/dis_sender.py
>> Sent EntityStatePdu. 144 bytes
>> Received EntityStatePdu. Id: 42, Location: 36.59999999462713
>> -121.9 1.00080256909132
>>
>> Received EntityStatePdu. Id: 42, Location: 36.59999999462713
>> -121.9 1.00080256909132
>>
>> VPN should be freed up shortly.
>>
>> John
>>
>> On 1/25/21 6:50 PM, John Carlson wrote:
>>
>> 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/20210126/d3570570/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ijgaodncfgpfeaek.png
Type: image/png
Size: 240041 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20210126/d3570570/attachment-0001.png>
More information about the x3d-public
mailing list