[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 20:27:30 PST 2021
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/20210125/11e6ba20/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/20210125/11e6ba20/attachment-0001.png>
More information about the x3d-public
mailing list