[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 17:01:49 PST 2021
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/20210125/971962ae/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/971962ae/attachment-0001.png>
More information about the x3d-public
mailing list