Implement Socket.DisconnectAsync and related changes #46903

geoffkizer · 2021-01-13T07:04:22Z

(1) Harmonize Disconnect tests using SocketTestHelper and bring them back to inner loop, and add some additional tests
(2) Implement new Task-based DisconnectAsync API using SAEA under the covers
(3) Reimplement existing BeginDisconnect/EndDisconnect APIs on top of Task-based async DisconnectAsync API

Fixes #1608
Contributes to #43935
Contributes to #43845

@antonfirsov @wfurt @scalablecory @stephentoub @dotnet/ncl

dotnet-issue-labeler · 2021-01-13T07:04:27Z

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

ghost · 2021-01-13T07:04:28Z

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

Issue Details

(1) Harmonize Disconnect tests using SocketTestHelper and bring them back to inner loop, and add some additional tests
(2) Implement new Task-based DisconnectAsync API using SAEA under the covers
(3) Reimplement existing BeginDisconnect/EndDisconnect APIs on top of Task-based async DisconnectAsync API

Fixes #1608
Contributes to #43935
Contributes to #43845

@antonfirsov @wfurt @scalablecory @stephentoub @dotnet/ncl

Author:	geoffkizer
Assignees:	-
Labels:	`area-System.Net.Sockets`, `new-api-needs-documentation`
Milestone:	-

antonfirsov · 2021-01-13T16:29:31Z

src/libraries/System.Net.Sockets/tests/FunctionalTests/DisconnectTest.cs

+                        // Note that the new connect operation must be asynchronous
+                        // (why? I'm not sure, but that's the way it works currently)


If this is expected behavior, I guess it should be documented. Do we know someone who understands this better?

I don't know. We seem to be enforcing this limitation ourselves, though I don't know if it's because DisconnectEx does not support it, or for some other (possibly legacy and no longer relevant) reason.

I skimmed the DisconnectEx docs on MSDN and didn't see anything that seemed relevant here.

I'm inclined to leave this as is currently and file a separate issue to investigate further. Sound reasonable?

Makes sense to me, since the question is not strictly related to the PR.

I added an issue here: #47206

antonfirsov · 2021-01-13T16:40:15Z

src/libraries/System.Net.Sockets/tests/FunctionalTests/DisconnectTest.cs


        [Theory]
        [InlineData(true)]
        [InlineData(false)]
-        [OuterLoop("https://github.com/dotnet/runtime/issues/18406")]
-        public void Disconnect_Success(bool reuseSocket)
+        public async Task Disconnect_Success(bool reuseSocket)


I think we also need to investigate / test Disconnect behavior during pending operations.

I tried to add a test for that, and discovered an inconsistency across OS-es:

[Theory] [InlineData(true)] [InlineData(false)] public async Task Disconnect_DuringPendingReceive_Success(bool reuseSocket) { IPEndPoint loopback = new IPEndPoint(IPAddress.Loopback, 0); using (var server1 = SocketTestServer.SocketTestServerFactory(SocketImplementationType.Async, loopback)) { using (Socket client = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp)) { await ConnectAsync(client, server1.EndPoint); Assert.True(client.Connected); var pendingReceive = client.ReceiveAsync(new byte[32], SocketFlags.None); await DisconnectAsync(client, reuseSocket); Assert.False(client.Connected); // On Windows we receive 0 bytes: int bytesReceived = await pendingReceive; Assert.Equal(0, bytesReceived); // On Linux, SocketException will be thrown: // await Assert.ThrowsAsync<SocketException>(() => pendingReceive); // "operation cancelled" } } }

Huh. How does that compare to doing Shutdown or Close with a pending operation?

BTW, we have existing tests for Shutdown/Close with pending operations, right? Do you know where these are?

The only related tests I was able to find are in SendReceive: Receive0ByteReturns_WhenPeerDisconnects, TcpReceiveSendGetsCanceledByDispose, behavior seems to differ.

I thought @tmds added some tests related to shutdown and/or close with pending operations, back when he made a big change to cleanup/improve the close logic in general. @tmds?

There are CanceledByDispose tests for Receive, Send, Accept, Connect and SendFile. You can search CanceledByDispose to find them. You can search CanceledByDispose to find them.

Thanks, that's what I was thinking of. I'll look at those.

stephentoub · 2021-01-14T20:08:23Z

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

@@ -1164,37 +1175,30 @@ private unsafe SocketError FinishOperationConnect()
        private void CompleteCore()
        {
            _strongThisRef.Value = null; // null out this reference from the overlapped so this isn't kept alive artificially
-            if (_singleBufferHandleState != SingleBufferHandleState.None)
+


You decided that making CompleteCore inlineable wasn't worthwhile?

No, I just haven't fixed it yet

stephentoub · 2021-01-14T20:15:01Z

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

+                new AwaitableSocketAsyncEventArgs(this, isReceiveForCaching: false);
+
+            saea.DisconnectReuseSocket = reuseSocket;
+            saea.WrapExceptionsForNetworkStream = false;


I was about to comment that this line shouldn't be necessary, but I see from the implementation that it is, which makes me think we should also be setting this here:

runtime/src/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.Tasks.cs

Line 111 in d776e5b

It's super rare that it would be an issue, as it would require disconnecting and then reconnecting the same socket, end up using the same args instance that was previously used via NetworkStream, and hit a failure condition as part of the connect... and even then the impact would just be the wrong exception message. But, still, probably worth fixing.

stephentoub · 2021-01-14T20:16:09Z

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

+            {
+                Debug.Assert(Volatile.Read(ref _continuation) == null, $"Expected null continuation to indicate reserved for use");
+
+                // TODO: Cancellation token handling


Is this still a "todo"?

stephentoub · 2021-01-14T20:18:13Z

src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEventArgs.Unix.cs

@@ -93,7 +93,7 @@ internal unsafe SocketError DoOperationConnect(Socket socket, SafeSocketHandle h
            return socketError;
        }

-        internal SocketError DoOperationDisconnect(Socket socket, SafeSocketHandle handle)
+        internal SocketError DoOperationDisconnect(Socket socket, SafeSocketHandle handle, CancellationToken cancellationToken)


Do we check for cancellation anywhere up until this point? If not, since the token isn't used by the implementation, it might be worth polling the token once here and returning an appropriate cancellation error before proceeding to do the disconnect.

There is a test for this -- Disconnect_Precanceled_ThrowsOperationCanceledException -- and it's passing, so we must be checking the cancellation token somewhere in all this.

tmds · 2021-01-20T07:44:30Z

@geoffkizer I don't mind this API getting added, though I'm not sure when it should be used.

Linux doesn't have the concept of async disconnect of a socket.
If you want to know your peer has received (and processed!) something, the application protocol should send a confirmation message.
What is DisconnectAsync meant for?

antonfirsov

One recommendation, otherwise looks good.

Bit worried about the lack of tests for the in-flight cancellation case on Windows, but I guess there is no way to implement them in a reliable way.

antonfirsov · 2021-01-20T11:45:02Z

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

+            if (_singleBufferHandleState == SingleBufferHandleState.InProcess)
+            {
+                RegisterToCancelPendingIO(overlapped, cancellationToken); // must happen before we change state to Set to avoid race conditions
+                _singleBufferHandleState = SingleBufferHandleState.Set;


Probably not an issue, but that this will lead to _singleBufferHandle.Dispose() in Complete.

Also note that after these changes, the only semantical difference between ProcessIOCPResult and ProcessIOCPResultWithSingleBufferHandle is the pinning of the handle. Isn't it worth to dedupe that code at this point?

Yeah, it is. I am trying to clean this up, but it's a little tricky at points...

geoffkizer · 2021-01-20T20:34:22Z

@tmds This is really just an API completion issue. We have sync Disconnect, we have Begin/End disconnect, we have DisconnectAsync(SocketAsyncEventArgs). This PR is just to add a Task-based version.

I expect it to be used very rarely.

geoffkizer · 2021-02-16T20:20:34Z

Closing this issue for now since I am not actively working on it. Waiting to figure out how to manage the cancellation state properly and consistently across operations.

Geoffrey Kizer added 13 commits January 12, 2021 20:16

refactor and improve disconnect tests

7d0317b

add new DisconnectAsync overload to ref

eee6bce

(first cut) add Task-based DisconnectAsync (no cancellation support)

e449462

actually add tests

a241a34

add Disconnect_Precanceled_ThrowsOperationCanceledException

37fbe72

wire up cancellation handling

ced46c4

fix unix

6dd79d0

fix assert

1b43a74

hackety hack -- disable cancellation at the lowest level

59b3474

remap APM to Task

1214a54

delete DisconnectOverlappedAsyncResult

c04ffc3

delete DisconnectOverlappedAsyncResult

35f6e76

fix cancellation handling and _singleBufferHandleState handling

d776e5b

dotnet-issue-labeler bot added area-System.Net.Sockets new-api-needs-documentation labels Jan 13, 2021

geoffkizer added this to the 6.0.0 milestone Jan 13, 2021

antonfirsov reviewed Jan 13, 2021

View reviewed changes

stephentoub reviewed Jan 14, 2021

View reviewed changes

antonfirsov reviewed Jan 20, 2021

View reviewed changes

antonfirsov mentioned this pull request Jan 21, 2021

Add new Task-based socket methods for UDP and reimplement existing ones using SocketAsyncEventArgs #47229

Merged

karelz assigned geoffkizer Feb 10, 2021

geoffkizer closed this Feb 16, 2021

ghost locked as resolved and limited conversation to collaborators Mar 18, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Implement Socket.DisconnectAsync and related changes #46903

Implement Socket.DisconnectAsync and related changes #46903

geoffkizer commented Jan 13, 2021

dotnet-issue-labeler bot commented Jan 13, 2021

ghost commented Jan 13, 2021

antonfirsov Jan 13, 2021

geoffkizer Jan 13, 2021

antonfirsov Jan 14, 2021

geoffkizer Jan 20, 2021

antonfirsov Jan 13, 2021

geoffkizer Jan 13, 2021

antonfirsov Jan 14, 2021

geoffkizer Jan 14, 2021

tmds Jan 14, 2021 •

edited

Loading

geoffkizer Jan 14, 2021

stephentoub Jan 14, 2021

geoffkizer Jan 14, 2021

stephentoub Jan 14, 2021 •

edited

Loading

stephentoub Jan 14, 2021

geoffkizer Jan 14, 2021

stephentoub Jan 14, 2021

geoffkizer Jan 14, 2021

tmds commented Jan 20, 2021

antonfirsov left a comment

antonfirsov Jan 20, 2021

geoffkizer Jan 20, 2021

geoffkizer commented Jan 20, 2021

geoffkizer commented Feb 16, 2021

		// Note that the new connect operation must be asynchronous
		// (why? I'm not sure, but that's the way it works currently)

Implement Socket.DisconnectAsync and related changes #46903

Implement Socket.DisconnectAsync and related changes #46903

Conversation

geoffkizer commented Jan 13, 2021

dotnet-issue-labeler bot commented Jan 13, 2021

ghost commented Jan 13, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tmds Jan 14, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stephentoub Jan 14, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tmds commented Jan 20, 2021

antonfirsov left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

geoffkizer commented Jan 20, 2021

geoffkizer commented Feb 16, 2021

tmds Jan 14, 2021 •

edited

Loading

stephentoub Jan 14, 2021 •

edited

Loading