Sending and receiving on the same port

[Show-vars]

I do not understand why the maintainer removed the ability to use one local port for receiving and sending simultaneously. This problem has already occurred before (#5 and #17) but after big code updates this problem appeared again. This imposes big restrictions on the using of this library.

The main problem is a splitting OSCPort into two independent classes OSCPortIn and OSCPortOut that uses different instances of DatagramChannel. Using socket option SO_REUSEADDR seems not to solve this issue.

Originally I was trying to write a small app that communicates with my Behringer X32 mixer. That one always send response to the same port from which requests are sent.

I had to completely rewrite these main classes. Actually, I could open the pull request but since my changes greatly affect the core of the library, I decided to limit only with new issue.

[hoijui]

It is because the maintainer does not use the library himself, and there was no unit test to use that constructor, for example one to test sending and receiving on the same port, because the maintainer did not think about writing one.
So I call you, brothers and sisters, let us pray to the almighty maintainer, for he may send his blessings upon us, in the form of new code, including such a constructor again, plus a unit test using it.
amen.
.. please feel free to open a pull request. there is no hurt in it, whether accepted or not, if you have already written it anyway. in the worst case, it may motivate the maintainer, and speed up his work a bit by allowing him to copy some code.

[hoijui]

I just saw, that OSCPortOut contains a single noteworthy method only: public void send(final OSCPacket packet)
Therefore, what do you (@Show-vars @daveyarwood ) think about merging OSCPort, OSCPortOut extends OSCPort and OSCPortIn extends OSCPort together into a single class OSCPort?
That would solve this issue, and would probably also fit better into prorammers minds, as Javas own socket and channel code does not separate in and out code into separate classes either.

[daveyarwood]

That sounds reasonable to me, but I think we might need to support the use case where you only need to send or you only need to receive.

In other words, if I initialize an OSCPort and use it to send messages (and I don't plan to receive messages), I don't want to inadvertently be affected by any messages that might be sent to the same port for whatever reason. I'm not sure, per se, if there would be any issues like that, but it's worth considering.

[hoijui]

Ahh yeah...
The only possible situation where I could imagine there might be a problem, is when I first only want to send, but later start receiving. I don't know what will happen in that case, if the socket was receiving content before I started listening. will that data still be in the (OS) buffer and be interpreted? or will the buffer be cleared when I start listening? also, which one do we want? can we do anything about this? and somewhat related but not limited to these questions: what happens if we start listening in the middle of a packet?
Somehow I think, all these issues are related to lower level OSI layers then we are directly dealing with, so ... in the end, we probably don't have to worry about any of this.

[astellingwerf]

@hoijui, can you give an update on the status of this issue? I can't get my integration on the Behringer X32 to work: I send a message, and see in Wireshark that the server responds back over UDP, but there's no way for me to get the message.

[Show-vars]

@astellingwerf I don't know how correct it will be to write it here but I want to share my own implementation used in my personal project: overstream-osc. This is a module that used to communicate with my X32 mixing console. It has two implementations for NIO (with no dependencies) and Netty. Honestly there is one big problem: tighter integration with the local fameless app framework, which currently is unlikely to be useful to someone.

[hoijui]

@astellingwerf
hmmm ... I did not work on this. I am also not sure what the best way would be to solve this. one way that comes to mind (regarding the sate on the tcp-support branch): remove all constructors of OSCPortIn and OSCPortOut, and add a single one, taking a Transport object, and make the Transport implementations have constructors that take Sockets.
An other option would be to use internal caching of sockets, so if one with same local and remote is requested, it re-uses the already existing one.

@Show-vars
I am not quite sure what you are saying...
your library is tightly integrated with some other software, and because of that, it is not useful to the general public?
btw, feel free to create a one-line summary of your project (including link) in markdown, to be added in the README in a Similar Projects section.

[hoijui]

@astellingwerf, realistically, I am not going to have time for this any time soon

[Burtan]

I'm also interested in this, did we agree about any solution yet? I could help with some code maybe.

[Burtan]

What about an additional class OSCPortInOut that combines the functionality of OSCPortIn and OSCPortOut

[Burtan]

One more thing, while I also have trouble receiving data from X32 Behringer (which sends data on the same port you send data to it), I can control Reaper bidirectionally using the same port for input and output.

[Burtan]

Ok, I think we can close this issue. Taking the same port for incoming and outgoing messages works. To make X32 work, you have to create the Output port with the local socket you want to receive messages to.

[Burtan]

Ok, one more thing. Having an OscPortIn and OscPortOut with same same port number seems to be OS dependent, if it works or not.