Allow sending and receiving messages over the same UDP socket

[nsowen]

This extension addresses the following issue: #40

That allows bi-directional communication to my Behringer X32 console. Explanation:

1. A JavaOSC Client application uses e.g. IP address 192.168.0.1 with UDP port 1234 as local port, and IP address 192.168.0.2 with UDP port 10023 as remote port on the X32
2. Once X32 receives the packet on port 10023, the response will immediately sent back to the exact sender, that means 192.168.0.1:1234
3. JavaOSC must then read from the exact same socket the it used for sending. Otherwise the datagram will not be accessible by JavaOSC.

With the original implementation, it was of couse possible to use the same input UDP port as the output UDP port, but unfortunately, at least on OSX, it is not possible to create two UDP sockets for sending and receiving on the same port. Therefore I extended the OSCPortOut to accept a "Transport" object in its constructor, which can be retrieved from the OSCPortIn object. Additionally, UDPTransport had to be changed to use two ByteBuffers, one for sending, the other one for receiving. Otherwise we will corrupt receive/response data on the fly. This should not make any issues, as the

var out = new OSCPortOut(new OSCSerializerAndParserBuilder(), new InetSocketAddress("x32-ip", 10023));
var in = new OSCPortIn(out.getTransport());
in.startListening();
out.send(new OSCMessage("/info"));

At least this PR works for me since for a few months now. Hope it will meet the quality standards. Please let me know!

[hoijui]

Hey, sorry @nsowen !
For some reason, I did not get noticed about stuff going on in this repo.
Will review ...

[hoijui]

Would a NullPointerException not be more appropriate?

[hoijui]

No must, and I see it is the same in the other methods, which is probably why you did it this way, but I' rather do this as this.transport = transport;, vs choosing arbitrary different names for the two variables.
As said.. leaving it this way is totally fine too.

[hoijui]

(... same here)

[hoijui]

looking good!

[Britaliope]

@nsowen any plans on updating this MR and if not, would you mind if I take over to resolve conflicts and close review comments ?

Also, i think a OSCPortIn constructor similar to the one you implemented but that set the default listeners (instead of taking them as argument) might be useful

[hannesa2]

If @nsowen will be active in the next few hours, all is fine, but otherwise @Britaliope please do it !