Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add second output address/port specifically for UDP messages, distinct from OSC messages #54

Closed
wraybowling opened this issue Jan 29, 2020 · 13 comments

Comments

@wraybowling
Copy link

@wraybowling wraybowling commented Jan 29, 2020

Add IP/Port options for UDP messages (;)

@wraybowling wraybowling changed the title UDP UDP IP/Port Jan 29, 2020
@cancel

This comment has been minimized.

Copy link
Collaborator

@cancel cancel commented Jan 29, 2020

(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, a could be set as localhost:4912, and b could be mysynth:4913. This would avoid the hostname/port management issues, and also not allow someone to craft a file that controls where the data is being sent. But it still has the problems that it would make the initial setup of the UDP operator more complicated, and it also would require more complicated menu management from the user, in addition to a significant amount of men UI code being written for orca-c.

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.

@wraybowling

This comment has been minimized.

Copy link
Author

@wraybowling wraybowling commented Jan 29, 2020

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.

@cancel

This comment has been minimized.

Copy link
Collaborator

@cancel cancel commented Jan 29, 2020

OSC always sends to the same port. The OSC path/prefix stuff is part of the message datagram, not in the IP layer.

@cancel

This comment has been minimized.

Copy link
Collaborator

@cancel cancel commented Jan 29, 2020

Or wait, let me ask a question. When you say you want options for ; are you talking about being able to write the host and port in the ORCA program code, or by setting it through the menus? Because the way it was worded, I assumed the former.

@wraybowling

This comment has been minimized.

Copy link
Author

@wraybowling wraybowling commented Jan 29, 2020

I meant that in the menus you can set the OSC IP and Port, but not the UDP IP and Port. In OrcaJS, each can be set separately.

I didn’t mean to ask for it to be part of the programming field

@cancel

This comment has been minimized.

Copy link
Collaborator

@cancel cancel commented Jan 29, 2020

Oh, OK! Yeah, that is way easier to implement. Totally possible. I can add it today, I think.

@wraybowling

This comment has been minimized.

Copy link
Author

@wraybowling wraybowling commented Jan 29, 2020

Second time this week I've not given enough detail in a public repo issue. I'll try to do better next time. 🙇🏻‍♂️ Thanks!

@cancel

This comment has been minimized.

Copy link
Collaborator

@cancel cancel commented Jan 29, 2020

Actually, this is kind of tricky to implement, and will take a few hours. Do you actually need this feature, or are you just asking for it speculatively? What are you using it for?

@wraybowling

This comment has been minimized.

Copy link
Author

@wraybowling wraybowling commented Jan 29, 2020

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.

@cancel

This comment has been minimized.

Copy link
Collaborator

@cancel cancel commented Jan 29, 2020

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.

@cancel

This comment has been minimized.

Copy link
Collaborator

@cancel cancel commented Jan 29, 2020

Yeah, this will take a bit of restructuring of the menus to avoid duplicating a couple hundred lines of code. I don't know if it's worth it right now.

@cancel cancel changed the title UDP IP/Port Add second output address/port specifically for UDP messages, distinct from OSC messages Jan 29, 2020
@cancel

This comment has been minimized.

Copy link
Collaborator

@cancel cancel commented Jan 30, 2020

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.

@cancel cancel closed this Jan 30, 2020
@wraybowling

This comment has been minimized.

Copy link
Author

@wraybowling wraybowling commented Jan 30, 2020

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 ; UDP command in limbo where it can be used in Orca-C but without a clear understanding of how it works or where the messages are going. If OSC and UDP messages are going to the same IP and port, perhaps simply change the menu to read "UDP/OSC Output..."

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.