Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Add second output address/port specifically for UDP messages, distinct from OSC messages #54
(For future readers of this read: skip this comment. It's based on a misunderstanding.)
There are two reasons why this is problematic to implement.
The first reason is that sending data over sockets, on POSIX, requires opening the port and acquiring the resource. And when you are done with it, you need to close it. A program can only open a limited number of these, (though in practice the number is large), and the operation to open and close and take a significant amount of time. Sometimes a few microseconds, sometimes several seconds, depending on the environment and what's configured and networking conditions.
Because ORCA documents are self-modifying programs, it's possible to change the port every frame. And there is no limit to the rate at which ORCA can run -- you can make ORCA-C run at hundreds of millions of operations per second. This makes it impractical to dynamically manage the ports being used. It's true that a type of port pooling system could be implemented, but this would require a significant amount of code, likely at least several hundreds of lines.
It would also be possible to run out of ports, or reach a limit. It also would likely cause timing problems.
As for the IP, this is even more difficult. Hostname and IP resolution can and regularly does take multiple seconds to resolve. There is also a resource limit to the number of these you can resolve, as they occupy memory. So it's like the same problem as with the port number, but even worse.
The second reason to not implement this is security. Being able to write arbitrary UDP data over a socket is a risk. If users were trading ORCA files around, it could be possible to craft a file which sends some series of commands over UDP to known hosts+ports to cause problems. For example, some web browser in development mode can be remotely controlled by packets. You could also do things like attempt to restart or wipe consumer routers on common NAT gateway IPs, or interfere with X11 under Linux.
This feature is complicated, very difficult to implement, likely poses security/safety problems, and seems impractical or non-useful to most users. If someone wants to write it, they can, but I would not accept it into the this repo's codebase without some very strong argument that I'm unable to think of right now. I would not implement this feature myself.
A more limited version of this feature could be useful. You could assign aliases to single characters. For example,
Because of the amount of work involved with implement even the second version of this feature--likely several weeks or a month, making it the most complicated feature in orca-c other than the VM itself--I won't be implementing this myself. I would considering accepting it as a feature by pull request if someone else were to write it, but only if the code were high-quality.
Whoa. Heavy. Thanks for all the detail. I think this is all worth talking about sooner rather than later though. At present, I assumed that enabling UDP messages would borrow what is already in place for OSC messages and would simply add options in the menu for what IP and port you want to use. Beyond that, just like OSC, it's up to the end user to understand the implications of that.
Now we're getting into the bigger picture. i'll respond later with suggestions.
I don't need it immediately. I was looking at Aioi as a way to send messages to more specific OSC routes, and it makes use of the UDP feature. There are other ways of making it happen. My alternative plan was to write my own binary or python script, but then I thought it better to collaborate on an existing open source project. Whatever we land on might not be perfect for me, but I'll feel better having chipped in.
Maybe this would be better for you? https://github.com/ETCLabs/OSCRouter ? Or just using PureData?
If your goal is flexible one-to-many routing instead of specifically OSC to A and UDP to B, I'm not sure if it's a good idea to immediately add split OSC and UDP sockets in orca-c, because it will make the orca-c code larger and more complicated, and I don't know how many people would use it.
orca-c is designed to be hackable, so I'm wary of adding one-off features for specific users unless there is something really cool or compelling. Speculative feature requests are hard to justify if they also add significant complexity to the code.
Well, let me try hacking on it for an hour and see how messy it gets.
OK. We talked about this for a bit and decided not to implement it, for now. The reason is just to keep complexity and line count down. It's not a bad feature, but I don't think it's worth the trade-off. It only adds handling for one additional specific scenario (single OSC plus single UDP destinations and that aren't the same), but at the cost of having to add the code required to juggle multiple network fds and handle multiple failures, and add more to the menus and config files.
And the more general kind of solution, some kind of internal routing system, I think is just too much to add to orca-c right now. It's supposed to be a bit of a minimalist tool and easy to tinker with and hack on. We kind of assumed that if you have this kind of routing complexity, you can set up your own OSC or UDP thing to split up and re-route messages.
We could revisit this in the future if something else comes up which requires handling multiple outgoing UDP fds.
That is A-OK with me. While Aioi was built as a companion application, I felt like it was a little weird to be using the UDP feature the way it does. You're right that if there's going to be an intermediary application, it may as well just make use of the MIDI/OSC messages that work clean & simple. I'm glad we talked about it anyway, though. Thanks :)
However, it does leave the