Does MsQuic always set's SO_REUSEADDR?

[Beatle95]

Hello, I have a test case where is 2 threads and in each of them I do something like that:

1. Create UDP listener
2. Receive 1 packet at this listener
3. Close socket
4. Start MsQuic listener

But sometimes (pretty often, but not always) one ListenerStart for one of the listeners fails with error WSAEADDRINUSE. I tried to replace creation of MsQuic listener with simple UDP listener (just closing old socket, and then creating and binding new one) and it succeeds only if SO_REUSEADDR socket option is set.
So, is it possible to set this option for MsQuic listeners?

[nibanks]

Possibly. So you've tried it out and it fixes your problems? Mind sending a PR with that to see how our CI fairs?

[Beatle95]

I haven't tried to modify this inside the library, I just replaced creation of MsQuic listener with creation of simple UDP listener (just to check if problem corresponds to SO_REUSEADDR option). And with this option set to TRUE it works ok. I will try to modify listener creation routines inside MsQuic tomorrow to check if it works in my case.

[Beatle95]

Strange, but adding setsockopt(SocketProc->Socket, SOL_SOCKET, SO_REUSEADDR, ...) to listener socket initialization (datapath_winuser.c, CxPlatSocketCreateUdp(...)) will result in error on bind(...) call: WSAEOPNOTSUPP. Can't find any information about what may cause this.

[Beatle95]

Actually I have discovered that error in my case happens on WSAIoctl(SocketProc->Socket, SIO_ACQUIRE_PORT_RESERVATION...) call, even if SO_REUSEADDR was set. I don't know how to fix this.

[Beatle95]

I have found what caused this problem. The thing I have programmed is the DLL. I have discovered, that another DLL from this app is using QProcess class of Qt library version 5.7.1. I have checked sources of Qt and discovered that this class actually starts process with bInheritHandles set to TRUE. When I manually have reset this value to FALSE all issues were gone.

It is obvious that the issue was caused by the following: one of UDP socket handles was inherited by child process and that process didn't let socket handle to be closed, until that process stop.

So there is nothing wrong with MsQuic itself.

[nibanks]

Interesting! Thanks for the follow up!