Add OSCUDPServer Port Reuse

[dsmurfin]

Adds support for UDP port reuse (SO_REUSEPORT) for OSCUDPServer, using isPortReuseEnabled.

This adds partity with OSCUDPClient and is a useful addition when implementors wish to have multiple servers sharing a port on the same machine.

[Copilot]

Pull request overview

This PR adds UDP port reuse functionality (SO_REUSEPORT) to OSCUDPServer, bringing it to feature parity with OSCUDPClient. This enables multiple server instances to share the same port on a single machine, which is useful for distributed or multi-process OSC applications.

Key changes:

• Added isPortReuseEnabled property and initializer parameter to OSCUDPServer
• Integrated port reuse configuration into the server startup flow
• Documentation matches the existing pattern from OSCUDPClient

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[orchetect]

Dumb question perhaps, but does UDP port reuse on Apple (BSD) systems actually work in practice?

I remember a while back when building out these classes that after doing a fair bit of research there were some issues preventing it from actually functioning as expected. Either it failed silently, or it did nothing, or it had the behavior of the OS distributing incoming packets between sockets bound to the same port instead of delivering a copy to each socket (ie: multicast).

[dsmurfin]

There are no dumb questions!

The answer is it's complicated... and in fact they've broken it with Network.framework which I've had a radar in for 3 years, and which is still unresolved.

The rules for BSD/POSIX are:

Both sockets bind successfully - no errors

Localhost/unicast - only received by socket 1
Broadcast (either flavor) - received by both sockets
Multicast - Received by both sockets

Broadcast and multicast are both pretty common in our industry, so I think this is a valid use case. Maybe we could add some clarification in the comments?

I have a sample project to demonstrate from my report if that's helpful?

[orchetect]

Maybe that's what was lodged in the back of my brain from a few years ago - I had mixed success with Network.framework (and Swift-NIO is more involved than I wanted to deal with) so CocoaAsyncSocket was a good middle-ground choice. Again, don't recall what the results of my own testing was a while back with port reuse but I feel like there was a reason I didn't add it to the UDP server class. But if it works, by all means let's throw it in.

(There's many options for a socks layer, including a couple recommendations from a recent PR submitter who is using OSCKitCore on Linux, since CocoaAsyncSocket is Apple platform-centric. Perhaps Swift package traits could be used in future to offer a choice of socks while maintaining the same high-level OSC classes/API. Just means implementing it.)

For the newcomers it might be a nice idea to toss in a little blurb in the inline documentation briefly explaining the ideal conditions for port reuse and what things to watch out for because it can be a mystifying subject. I love to to do that kind of thing as a self-reminder any way, because I easily forget stuff 6 months later when my head is living in other codebases and often rely on my own documentation down the line. What do you think?

I'm not sure it merits adding an additional example project to the repo if it's straightforward enough to document it.

[dsmurfin]

I have updated the comments as discussed. In the initializer, I've only called out broadcast, because the library does not currently support multicast subscriptions. I have covered this in the comment on the variable however for future info.