Next week I am starting a project where I need to send OSC data from SC to somebody on the other side of Europe, and get OSC data back. I suspect it’s just a simple matter of using a
.sendMsg to the correct ip address, and conversely setting up an OSCFunc on my side to receive the data? Or are there any gotchas I should be aware of that will eat up most of my waking hours trying to solve?
where I need to send OSC data from SC to somebody on the other side of Europe, and get OSC data back
This only works if both your machines are publicly reachable. Usually, this is only true for web servers (on certain well defined ports, like 80 for HTTP), but not for regular client machines, as it would be a huge security risk.
Generally, there are 2 problems:
since IPv4 has a limited address space, most computers sit behind a NAT (Network address translation - Wikipedia) which translates your IP address and port number.
firewalls and NATs are configured to ignore unsolicited incoming traffic, meaning that you can’t receive messages from a remote destination without sending to it first.
Typically, peer-to-peer applications use some kind of NAT traversal (NAT traversal - Wikipedia), with hole punching (Hole punching (networking) - Wikipedia) being the most popular option. (Note, however, that it does not work with symmetric NATs!)
Actually, I have been working on the AOO library (cm / aoo · GitLab) which allows to send OSC messages and audio streams over the public internet, but I haven’t released the Supercollider part yet. I’m hoping to make a proper release till the end of this year.
In the meantime, you can try oscgroups (Ross Bencina » OSCgroups).
Thanks so much @Spacechild1, this is exactly the kind of stuff I was concerned about. Thanks, also, for the pointer to oscgroups. Will start looking into how I can run it on Arch!
Has anybody tried using a vpn service for this use-case? Is it feasible?
The way I would do this is to set up a web server instance and create a small program relaying the messages. OSCgroups looks good if it still works, otherwise you can write this server in whatever you’re comfortable with. The clients can then both connect to this server which is publicly available. (Hole punching, as Spacechild1 mentioned)
My suggestion, if you need to write your own relay is to use websockets over UDP for this since there are good, stable and easy-to-use libraries for it. I wrote a simple variant of this in Rust, but haven’t had time to bring it to a publishable state yet.
I haven’t tried using a VPN into a private network. I’d be interested to hear your results if you do try!
and create a small program relaying the messages.
Yes, I should have mentioned relay servers as an alternative to “true” peer-to-peer solutions. However, it means at least one person has to set up a webserver.
Sometimes relay is the only option, for example if one peer is behind a symmetric NAT - which makes traditional hole punching impossible (there are alternative solutions, like https://www.researchgate.net/publication/228411948_A_New_Method_for_Symmetric_NAT_Traversal_in_UDP_and_TCP, but they are not exactly trivial to implement)
Just to add to this already very informative thread:
I’ve done this using two ways: using a VPN and using a public server (running SC to relay messages).
I’ve done the VPN thing a long time ago, so I might be forgetting the details, but essentially I had access to a server where I set up my own vpn (OpenVPN I think?), which was non-trivial. But once that worked and once I had all the machines on the same vpn, sending OSC was really easy, the same as sending it on the local network. I vaguely remember that in the VPN setup there was an explicit setting whether the computers on the VPN should be able to send each other messages and of course I turned that on.
More recently, I used a computer with public IP to send OSC between other machines which were behind a NAT. I wrote a simple forwarder in SuperCollider, so this solution is viable if you have access to a machine with a public IP that can run SC, but all the “user” nodes can be behind a NAT.
Thanks a lot to all of you! Will start digging into this more seriously this week, and will keep a running update on the progress.
Today I finally got to try the VPN solution, using vpn.net, and it was indeed an incredibly easy process, allowing me to pass data back and forth between Europe and US as if it was all happening on my own local network (with a bit more latency, of course…)
check ->> GitHub - bgola/tcposcrouter. you need a server on internet for this. maybe there are some safety issues but it just works…