Bug - UDP port conflict when hosting multiple processes on same windows VM

Unity Services
,
1

Hi I just wanted to report an issue I found (and maybe have patched around).
I’ve built a system where I run multple instances of anUnreal client on the same VM. Each is joined to a different online multiplayer session and each run an AI camera to ‘broadcast’ the scene out to a PixelStreaming system that feed directly into a CDN that can be viewed by any number of non-participating users. Capturing the Vivox voip has been an issue:

  1. I had to intercept all the audio data and inject into the Unreal AudioMixer - fixed.
  2. [THE BUG] the multiple instances would interfere with each other such that sometimes when a client would start up and join a channel, an existing client (completely different windows process) would lose connection with Vivox.

Using sysinterals procmon64 I discovered that the second process would start using the same UDP port as the first one. e.g. Process1 might be send/recieve on port 18000 - and stay there, Process 2 starts and uses 23000, but also sends and polls 18000 - which seems to kill Process 1’s communication.

My work around (as of yesterday) is to change VivoxNativeSdk::ConnectorCreate to set minimum_port and maximum_port to distince ranges based on the process instance number.

I would love any feedback on if this is a ‘proper’ solution or if you have a better way to operate multiple processes on the same PC.
Thanks,
DR

2

Hi Dave,

This improper port selection is a known issue on Windows only which has already been fixed in the Unreal SDK release 5.19.0.unr.0 (corresponding Core release is 5.19.0 and Unity package is 15.1.190000-pre.1). The recommended solution is to update to the latest SDK version.

That said, if you’re not able to update at this time for whatever reason, your workaround is a sound one, and similar to what we recommended to affected customers in the interim before the fix was released. In fact, my recollection is that setting any custom port range in ConnectorCreate would result in an alternate code path that avoided the issue, without having to introduce extra logic to subvide into smaller ranges by process number. If that logic is already working well for you, it can’t hurt, but no workaround should be necessary when using release versions 5.19.0.unr.0 going forward.

Cheers,

3

Thanks for the quick response.
I tried 5.19 when it was released (not for this issue, but just as a matter of course to get the newer version). The problem is that 5.19 (and 5.17 if I remember correctly) breaks the volume control on Quest headsets. To be clear the volume rocker switch on the underside of the headset doesn’t work with that SDK.

If there is an upcoming update that fixes that then we will move forward immediatley.

Thanks again!
DR