[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:08:56 PST 2021
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/20210125/684db516/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/684db516/attachment-0001.png>
More information about the x3d-public
mailing list