Auto-enable SO_REUSE_UNICASTPORT for ConnectEx #54903

antonfirsov · 2021-06-29T14:39:19Z

Fixes #48219.

Validation

https://gist.github.com/antonfirsov/ef27d1048dfb362cc19b2c0165dc0d7d

The test in the gist succeeds if and only if:

Being executed against code in the PR
The auto reuse port range is configured (Set-NetTCPSetting -SettingName InternetCustom -AutoReusePortRangeStartPort 40000 -AutoReusePortRangeNumberOfPorts 2000) and the PC is rebooted

Unfortunately, there is no way to implement an automatic test for this, because of the admin hackery required.

/cc @geoffkizer

ghost · 2021-06-29T14:39:24Z

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

Fixes #48219.

Validation

https://gist.github.com/antonfirsov/ef27d1048dfb362cc19b2c0165dc0d7d

The test in the gist succeeds if and only if:

Being executed against code in the PR
The auto reuse port range is configured (Set-NetTCPSetting -SettingName InternetCustom -AutoReusePortRangeStartPort 40000 -AutoReusePortRangeNumberOfPorts 2000) and the PC is rebooted

Unfortunately, there is no way to implement an automatic test for this, because of the admin hackery required.

/cc @geoffkizer

Author:	antonfirsov
Assignees:	-
Labels:	`area-System.Net.Sockets`
Milestone:	-

antonfirsov · 2021-06-29T14:43:37Z

src/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.Windows.cs

+                    sizeof(int));
+                return error == SocketError.Success;
+            }
+            catch { }


I used try-catch block because SocketProtocolSupportPal does the same:

runtime/src/libraries/Common/src/System/Net/SocketProtocolSupportPal.Windows.cs

Lines 18 to 38 in f3bad4f

private static bool IsSupported(AddressFamily af)

{

Interop.Winsock.EnsureInitialized();

IntPtr INVALID_SOCKET = (IntPtr)(-1);

IntPtr socket = INVALID_SOCKET;

try

{

socket = Interop.Winsock.WSASocketW(af, SocketType.Stream, 0, IntPtr.Zero, 0, (int)Interop.Winsock.SocketConstructorFlags.WSA_FLAG_NO_HANDLE_INHERIT);

return

socket != INVALID_SOCKET ||

(SocketError)Marshal.GetLastWin32Error() != SocketError.AddressFamilyNotSupported;

}

finally

{

if (socket != INVALID_SOCKET)

{

Interop.Winsock.closesocket(socket);

}

}

}

Don't know what can potentially throw here.

For native calls like this, usually the only thing that can throw is ObjectDisposedException if the SafeHandle is disposed. Maybe if it's invalid too.

That should never be the case here, but there's no harm in the try/catch just in case.

geoffkizer · 2021-07-01T19:22:10Z

What OS versions is this supported on?

An alternative approach would be to always set the option, but just ignore failure. That would save us from having to explicitly check up front whether it is supported.

Actually, now that I think about it... what will happen if the setsockopt call fails? Will that throw and fail the whole Connect? I wonder if we should just ignore failures here always.

antonfirsov · 2021-07-01T21:15:16Z

What OS versions is this supported on?

Windows 10+ and Windows 8 with "LDR servicing pack" whatever that means:
https://referencesource.microsoft.com/#System/net/System/Net/ServicePoint.cs,1326

Actually, now that I think about it... what will happen if the setsockopt call fails?

I assume Interop.Winsock.setsockopt will return WSAEINVAL without any further consequences. I can push a change here and see if the Win7/8 queues fail.

geoffkizer · 2021-07-01T21:57:33Z

I assume Interop.Winsock.setsockopt will return WSAEINVAL without any further consequences. I can push a change here and see if the Win7/8 queues fail.

As long as it doesn't fail the whole connection because some exception gets thrown, I think it's fine.

antonfirsov · 2021-07-02T12:27:46Z

/azp run runtime-libraries-coreclr outerloop

azure-pipelines · 2021-07-02T12:28:02Z

Azure Pipelines successfully started running 1 pipeline(s).

antonfirsov · 2021-07-02T16:18:30Z

The change seems to work, outerloop failures are unrelated, mostly cases of #54955. @geoffkizer can you take another look?

src/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.Windows.cs

stephentoub · 2021-07-02T21:19:08Z

src/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.Windows.cs

+        {
+            // By enabling SO_REUSE_UNICASTPORT, we defer actual port allocation until the ConnectEx call,
+            // so it can bind to ports from the Windows auto-reuse port range, if configured by an admin.
+            // The socket option is supported on Windows 10+, we are ignoring the SocketError in case setsockopt fails.


Is there any test we could/should write to help validate this?

The problem is, it requires an opt-in registry setting.

What about a test that just validates we've configured the socket as best we can? e.g. that we've set SO_REUSE_UNICASTPORT by default?

Yeah, that seems worthwhile. @antonfirsov can we add this?

Makes sense, will do.

This reverts commit 3195abe.

antonfirsov · 2021-07-06T12:35:38Z

@geoffkizer @stephentoub I attempted to add the test, but looks like SO_REUSE_UNICASTPORT won't even roundtrip if AutoReusePortRangeStartPort and AutoReusePortRangeNumberOfPorts isn't configured.

What I learned from this experiment is that some of the CI machines actually have the unicast port range configured, so in theory we could test the feature. Unfortunately, the only documented way I was able to find to query these properties is the Get-NetTCPSetting PowerShell command which we probably don't want to run from tests.

Looks like we already faced the same issue back in #15888. I deleted the tests for now, and suggest to merge the change as-is.

PS: We could maybe test it by checking if SO_REUSE_UNICASTPORT roundtrips, but I prefer to not go down that road with the CI right before a 2 weeks vacation, maybe we can open a separate issue if you think it's something worth to try :)

geoffkizer · 2021-07-06T21:50:00Z

Seems reasonable. Let's merge this as is.

antonfirsov · 2021-07-07T15:17:39Z

/azp run runtime-libraries-coreclr outerloop

azure-pipelines · 2021-07-07T15:17:54Z

Azure Pipelines successfully started running 1 pipeline(s).

antonfirsov · 2021-07-08T00:08:53Z

CI failures are unrelated, outerloop fails with instances of #54955 most of the time.

auto-enable SO_REUSE_UNICASTPORT

dbd65ac

dotnet-issue-labeler bot added the area-System.Net.Sockets label Jun 29, 2021

antonfirsov commented Jun 29, 2021

View reviewed changes

karelz assigned geoffkizer Jun 29, 2021

geoffkizer approved these changes Jul 1, 2021

View reviewed changes

always attempt enabling the port

ce3e4a0

geoffkizer reviewed Jul 2, 2021

View reviewed changes

src/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.Windows.cs Outdated Show resolved Hide resolved

geoffkizer approved these changes Jul 2, 2021

View reviewed changes

stephentoub reviewed Jul 2, 2021

View reviewed changes

stephentoub approved these changes Jul 2, 2021

View reviewed changes

antonfirsov added 3 commits July 5, 2021 17:27

add ConnectAsync_Enables_ReuseUnicastPort

3195abe

delete leftover code in comments

c5dd223

Revert "add ConnectAsync_Enables_ReuseUnicastPort"

557de56

This reverts commit 3195abe.

antonfirsov merged commit 30d770d into dotnet:main Jul 8, 2021

karelz added this to the 6.0.0 milestone Jul 15, 2021

This was referenced Jul 22, 2021

Test failure System.Net.Security.Tests.SslStreamNetworkStreamTest.SslStream_NetworkStream_Renegotiation_Succeeds #52096

Closed

[WinHttpHandler] Long running test: ResponseHeadersRead_SynchronizationContextNotUsedByHandler on Win7/Win8 #54034

Closed

ghost locked as resolved and limited conversation to collaborators Aug 14, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Auto-enable SO_REUSE_UNICASTPORT for ConnectEx #54903

Auto-enable SO_REUSE_UNICASTPORT for ConnectEx #54903

antonfirsov commented Jun 29, 2021

ghost commented Jun 29, 2021

Validation

antonfirsov Jun 29, 2021

geoffkizer Jul 1, 2021

geoffkizer commented Jul 1, 2021

antonfirsov commented Jul 1, 2021

geoffkizer commented Jul 1, 2021

antonfirsov commented Jul 2, 2021

azure-pipelines bot commented Jul 2, 2021

antonfirsov commented Jul 2, 2021

stephentoub Jul 2, 2021

geoffkizer Jul 2, 2021

stephentoub Jul 2, 2021

geoffkizer Jul 2, 2021

antonfirsov Jul 3, 2021

antonfirsov commented Jul 6, 2021 •

edited

Loading

geoffkizer commented Jul 6, 2021

antonfirsov commented Jul 7, 2021

azure-pipelines bot commented Jul 7, 2021

antonfirsov commented Jul 8, 2021

	private static bool IsSupported(AddressFamily af)
	{
	Interop.Winsock.EnsureInitialized();

	IntPtr INVALID_SOCKET = (IntPtr)(-1);
	IntPtr socket = INVALID_SOCKET;
	try
	{
	socket = Interop.Winsock.WSASocketW(af, SocketType.Stream, 0, IntPtr.Zero, 0, (int)Interop.Winsock.SocketConstructorFlags.WSA_FLAG_NO_HANDLE_INHERIT);
	return
	socket != INVALID_SOCKET \|\|
	(SocketError)Marshal.GetLastWin32Error() != SocketError.AddressFamilyNotSupported;
	}
	finally
	{
	if (socket != INVALID_SOCKET)
	{
	Interop.Winsock.closesocket(socket);
	}
	}
	}

Auto-enable SO_REUSE_UNICASTPORT for ConnectEx #54903

Auto-enable SO_REUSE_UNICASTPORT for ConnectEx #54903

Conversation

antonfirsov commented Jun 29, 2021

Validation

ghost commented Jun 29, 2021

Validation

antonfirsov Jun 29, 2021

Choose a reason for hiding this comment

geoffkizer Jul 1, 2021

Choose a reason for hiding this comment

geoffkizer commented Jul 1, 2021

antonfirsov commented Jul 1, 2021

geoffkizer commented Jul 1, 2021

antonfirsov commented Jul 2, 2021

azure-pipelines bot commented Jul 2, 2021

antonfirsov commented Jul 2, 2021

stephentoub Jul 2, 2021

Choose a reason for hiding this comment

geoffkizer Jul 2, 2021

Choose a reason for hiding this comment

stephentoub Jul 2, 2021

Choose a reason for hiding this comment

geoffkizer Jul 2, 2021

Choose a reason for hiding this comment

antonfirsov Jul 3, 2021

Choose a reason for hiding this comment

antonfirsov commented Jul 6, 2021 • edited Loading

geoffkizer commented Jul 6, 2021

antonfirsov commented Jul 7, 2021

azure-pipelines bot commented Jul 7, 2021

antonfirsov commented Jul 8, 2021

antonfirsov commented Jul 6, 2021 •

edited

Loading