Tony Mountifield

Now that the `sudo` workaround has been merged in #3223, I have done a build with CodeQL on the main MacOS instead of on the legacy MacOS, and it worked...

> I like the proposal and support this approach. Thanks! I used your RPC server as a template for the connection handler. > I kinda wonder if it’s possible for...

> What's the disadvantage of trying to connect via TCP first? I couldn't think of a compatible way to associate a subsequent UDP audio stream with a TCP connection that...

> > I couldn't think of a compatible way to associate a subsequent UDP audio stream with a TCP connection that was made first. > > Seems like that's a...

> It sounds pretty good. I'd be inclined only to move explicitly those messages we know cause problems. However, the "infrastructure" should be there to support other messages. Yes, I...

> OK, assuming that the TCP keepalive is longer than the Jamulus UDP audio "keep alive" time for a channel, we'd just need to ensure that part of channel clean...

Well at the very least, the server will close its end of the TCP socket and set `CChannel::pTcpSocket` to `nullptr`. This would fall back to the UDP-only situation as per...

As I have been thinking about the design of this, and conducting a few protocol experiments, I have found some significant issues that we need to solve, concerning the interaction...

> If the Client initiates the Directory server list request over UDP and gets back an initial "CLM_TCP" response (with some token), it could then follow up with the TCP...

> I don't think solution 1 is feasible since NATs behave as they want. 2. seems more promising. Yes, I agree. Solution 1 was my first thought, and I was...