OSCReceiver binding to a port always return true even if port is already taken


#1

When using an OSCReceiver and doing

bool result = receiver.connect(localPort);

this result variable is always true, even if the port is already taken by another app.
This is very inconvenient because there is no way to know properly if there’s been a problem with the binding, and since the methods returns this variable, we actually would expect it to return the real state :slight_smile:


#2

I’ve not used the OSCReceiver class, but ‘true’ is returned only if the low level binding succeeds. Looking at the OSCReceiver code shows it uses a DatagramSocket, which calls makeReusable which sets the SO_REUSEADDR option on the socket, which allows multiple binds to the same port.


#3

Yes i looked at it and i don’t know why it returns true when it clearly doesn’t work.
For the makeReusable function, i think that it allows other bindings to the same port if juce binds it first, but since i’m trying to bind a port already bound by another app that didn’t make the port reusable, the port is already locked and the OSCReceiver silently fails to bind it, the result being no OSCMessage is received but there is no way to know it at binding time.


#4

My point was, the success is predicated on the success of the underlying call to the OS’s bind(). If that isn’t doing the correct thing, then how can JUCE do anything else? OSCReceiver::connectToPort returns false if the call to socket->bindToPort fails, otherwise true. DatagramSocket::bindToPort returns true if the call to bindToSocket succeeds. and bindToSocket simply returns the return value of ::bind.


#5

Yeah i saw that, what’s weird is that any other library throw an error when trying to bind a busy port, so there is a way to know, right ? Of course the way it’s done in juce seems to be the most logical one, but maybe we could find a way to know if it’s busy before trying to bind it ?


#6

I just realized that it may be possible that the options JUCE uses when opening the port may be where the issue lies. Is there another toolkit (such as QT), or open source project, that does the right thing? If so, one could compare the code to see what is done differently.


#7

ofxOsc (using lib oscpack) may be of help on this one, line 227


#8

You can link to a specific line by clicking on the line number and copying the URL, or adding #L227 to the end of the URL manually.


#10

I can’t spot anything obviously different. Does ofxOsc behave differently?

Does commenting out SocketHelpers::makeReusable (handle); in the DatagramSocket constructor change things?


#11

Thanks, i knew it was possible but didn’t have time to search :slight_smile:
I don’t use ofx anymore, i hope to have some time next week to check that but i saw some issues on github talking about crashes when trying to bind a busy port, it has been fixed since then but it seems that there is a different behavior when the port is already bound and not reusable.
I’ll try to check when i get time, what i know for sure is the UnityOSC library written in C# throws an exception when this occurs, as well as the oscP5 library written in Java.