Multiple call to ListenStart with the same port should fail #2666
Replies: 1 comment 3 replies
-
|
Thats actually something we need to update in the documentation. The current behavior is expected, and not something we can solve on all platforms. In order to use per processor sockets for performance reasons, we have to turn on some flags at the socket level (SO_REUSEPORT on linux, and SIO_CPU_AFFINITY on windows). Both of these flags make it so UDP ports can be shared, however both operating systems implement this as shared across processes, and not just shared across threads. So with those flags enabled, the OS will successfully let us open a socket on a shared port from multiple process. However, on both os's, these duplicate ports across processes are kind of broken, and don't work as expected. On windows, we have a solution, however we've had to delay it due to a bug in windows itself. On linux, we don't know of a solution to reserve a port with SO_RESUEPORT set to only be used by a single process. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, thanks for your answer. |
Beta Was this translation helpful? Give feedback.
-
|
Disabling that flag would require some pretty major changes to the code base, and yes would result in performance issues, especially on server side. We don't have a solid ETA. The windows patches should be out by this point, we're just waiting for the CI machines to have the fix. What version of Windows are you using? |
Beta Was this translation helpful? Give feedback.
-
|
Ok, thanks ! Édition: Windows 10 Entreprise |
Beta Was this translation helpful? Give feedback.
-
About the ListenStart function documentation: https://github.com/microsoft/msquic/blob/main/docs/api/ListenerStart.md
"If another application is already listening on the same UDP port as an MsQuic application, despite being a different address family, the MsQuic application will fail to use that port, and ListenerStart will fail."
In my tests, this is not working as described in this documentation.
I have two cases. The first one is a unit test which runs two servers. The first server will bind to the port 30000 and the call to ListenStart will succeed. The second server will try to bind to the same port and the call to ListenStart will fail.
So, everything is working as expected.
The issue is that if I try to do the same thing but which each server running in its own application/process, ListenStart will succeed for both server and that's sounds to be a bug in my opinion.
Any ideas ?
Thanks !
Beta Was this translation helpful? Give feedback.
All reactions