feature request: allow ofxOscReceiver to send messages (from the same port it receives)

One thing that is sometimes limiting about the ofxOscSender/Receiver classes (when trying to implement an OSC client/server model), is that each side involved in a networking exchange needs to know the other side's address/port beforehand. It would be convenient to be able to open an ofxOscReceiver, serving a specific port, and have it reply to whatever clients make requests. At the same time, it'd be nice to be able to write a client such that it only needs to know the server's address/port, but the server doesn't need to know anything about the client (e.g. doesn't need to know beforehand what port to reply to). The client simply makes a request (says "hello") to the server, and the server gets the reply port from the endpoint of the incoming message. But when the client has separate ofxOscSender and Receiver (as must be the case now), then each of these will have a different port -- client messages received by the server show the port of the client's sender, and replies back to that same port wouldn't be seen by its receiver. The server needs to know the client's receiver port -- so why not make it the same as the sender port (in cases when this is desired?).

I made a fix (for my own use) for this problem. If you're interested, you can see it here: https://github.com/totalgee/openFrameworks/commit/b56f913d1dcc78d449be47ff23201a38dc206a4e

In summary: I added a sendMessageTo() method on ofxOscReceiver. This means a receiver listens for incoming messages (as usual), but also send messages from the same socket (which means they will show up on the receiving end with the same port number). The ofxOscReceiver is also not tied to send to a single address/port; it can send to different endpoints on the fly. This functionality is supported by the underlying oscpack library (well, by sockets themselves), but it's not exposed in oF.

With my change, you can do (in setup()):

mReceiver.setup(57003);

and receive messages as usual, in your update() method (using mReceiver.getNextMessage()). But then, you can also do:

mReceiver.sendMessageTo(message, "127.0.0.1", 54321);

I can submit a pull request with this basic functionality, but isn't a full solution. I thought I'd submit an issue here because it's still useful, to get some feedback on whether this is of general interest. A "proper" fix might move appendMessage() to a helper file, so it could be shared by both ofxOscReceiver and ofxOscSender. And, probably we'd want to implement ofxOscReceiver::sendBundleTo(), and maybe a sendParameterTo() method (I don't know about this new parameter-syncing stuff). If we're doing all that, perhaps it would make more sense to create a totally new ofxOscSenderReceiver class, or else a base class from which both sender and receiver could inherit, to avoid code duplication. Unfortunately, I don't have time to do those at the moment. So my changes could be taken as-is, or else just used to give you the idea of what I'm talking about…

Start with the ofxOscReceiver and ofxOscSender entry points described in the issue, then review the linked openFrameworks commit and the underlying oscpack support. Compare the proposed sendMessageTo behavior with the possible shared helper, bundle, parameter, or combined-class designs. Done requires an agreed API that lets a receiver send from its listening socket to arbitrary endpoints.