I’m trying to listen to incoming OSC messages on a specific port using
OSCReceiver, but also use that same port to send outgoing messages using
OSCSender. I achieved this in the past, not sure that was the most elegant way, by binding the socket and having its
SO_REUSEADDR option set to
1. But, as far as I can tell, this is currently not possible using JUCE’s OSC API. Is that right? At least not without changing things how
OSCSender::Pimpl goes about dealing with its
DatagramSocket. Am I missing something or it only supports binding ephemeral ports?
Yes you are right. This is currently not possible in JUCE. Maybe you can do a pull-request with the necessary changes.
I hacked my way through this, just as I did when I had to achieve this last time (using a different library).
I did wonder how I’d expose that through the current API though. So far I’m thinking IoC and having the
OSCReceiver getting the socket to be used injected maybe the cleanest way. Or possibly have dedicated API for this use case (i.e. specify the port to bind in
OSCSender and internally setting the
SO_REUSEADDR option on both sockets). wdyt?
I’ll take a concrete stab at these and see how things feel from an API consumer perspective and shall open a PR to discuss this further then.
In any case, thanks for confirming I wasn’t missing anything!
Hi @alexs, this thread is quite old but I am facing the same problem. I need to -at least- know which local port the
DatagramSocket owned by the
OSCSender has been assigned, or better I could specify my own port to be used. I am considering making my own hack too… how did you solve it?
In case someone is interested, here’s my hack for getting the local port bound to an OSCSender and for specifying a port to be used.
oscsender_localport.patch.txt (3.9 KB)
My solution doesn’t really work, even if I
setEnablePortReuse(true) on both the
DatagramSockets owned by the
OSCSender and the
OSCReceiver. I am not able to receive reply packets, even though WireShark shows that they are actually entering my PC and I have bound the OSCReceiver to the same port assigned to the OSCSender.
Is the only solution sharing the same
DatagramSocket between the Sender and the Receiver? This would require some rework of both classes.
I’m not sure if i understand right, but what you want to achieve is sending OSC to a specific port and receiving the message in the same app by binding a receiver to this same port ?
If that’s it, i didn’t have problems doing that, you can check the app here : http://benjamin.kuperberg.fr/chataigne/
just create an OSC Module and set the receive and send port to the same value, then in the “command tester” panel below you can try to send a command and see it received.
The code is here :
The specific case at hand is this one: the Behringer X18 digital mixer is always on IP 192.168.1.1 (in the network created by its internal access point) and listens on port 10024.
When some device sends it an OSC requests, the X18 replies to the IP of the sender, and to the port where the sender sent its request from. These information are taken from the UDP packet header. A
juce::OSCSender would have sent its OSC message to the X18 by creating a
juce::DatagramSocket connected to the remote IP 192.168.1.1, to the remote port 10024, and this socket would be bound to a local port chosen by the OS (because
OSCSender::Pimpl passes 0 to
DatagramSocket::bindToPort()). So, we can’t open a
juce::OSCReceiver on the port where the X18 will reply, because we don’t know it.
The patch I sent yesterday adds control over the local port of an
OSCSender. Now I can open an
OSCReceiver on a matching port. Still, replies enter my PC (WireShark captures them, and the ports are correct on both the request from the Juce app and the reply from the X18, that is they are symmetrical), but my
OSCReceiver doesn’t receive them. @benkuper, I don’t think it’s the same scenario as yours: you don’t tamper with the local port of the Sender as I do. You are actually sending from port X (assigned by the OS) to port A, and reading from port A. On the other hand, I have a socket open for writing on local port X and remote port 10024, and another for reading on local port X.
Yeah sorry for the misunderstanding, i get it now. Even if it seems convenient, it’s actually very uncommon when using the OSC protocol to answer on the port from the UDP packet header… anyway,good luck with that one !
It may be interesting to have an OSCSenderReceiver class that would allow for both, and that way you don’t have to deal with 2 sockets binding the same port, but only one doing both ?
Glad to know I am not the only one who hit this problem with the Juce OSC classes. I have the exact problem trying to communicate with the X32. The console replies (can see it in Wireshark) but no packet is seen by the OSCReceiver.