Runtime: Plumb cancellation into Socket's implementation

[stephentoub]

dotnet/runtime#22919 adds public API to Socket types that accept CancellationToken. We can implement the APIs to just do an upfront check, but the real value is when cancellation is plumbed through to support canceling the actual I/O. This issue represents doing that work.

[toady]

Just a note for whoever resolves this:
NetworkStream.ReadAsync(byte[], int, int, CancellationToken)
is missing CancellationToken argument to underlying Socket.ReceiveAsync, yet it is present in
NetworkStream.ReadAsync(Memory<byte>, CancellationToken)

[WinCPP]

Hi @stephentoub further to our discussion in dotnet/corefx#25511 (here), I could pass down the CancellationToken all the way to SocketEventAsyncArgs.DoOperationReceive (here). However if my understanding is correct, this code area not being based on async-await pattern, it is not able to leverage CancellationToken. Hence I tried to convert it to async following async-all-the-way-(up) paradigm and I hit the interface function 'System.Net.Sockets.Socket.ReceiveAsync` (here) which needs to be made async as well, breaking the ApiCompat. And that tells me I'm not doing it in a correct way.

Would you like to see the code? Appreciate your inputs / hints on this one. Thanks!

[WinCPP]

Oh I just noticed, dotnet/runtime#23138 is also no more up-for-grabs :-) ... So should I be working on something else...? Thanks!

[Clockwork-Muse]

(I'm the wrong Stephen, but...)

My first assumption is going to be that you're going to end up with different methods - a Task-returning async method likely won't take the SocketEventAsyncArgs type, instead preferring to manage the relevant info via the async state machine (or at least pretend to for callers). One thing I would have taken as an indication of this is the definition of the extension methods in dotnet/runtime#22919 .

Now, you're probably still going to want to use/manage a SocketEventAsyncArgs under the covers, if you can; the async state machine represents extra overhead, especially in situations where the operations may have already completed. TcpClient does something similar, if memory serves. This likely means you'll end up calling DoOperationReceive, but I haven't been in the code enough to definitively state what you need.

[karelz]

We won't be able to address this in 2.1, moving to Future.

[spiritedfang]

What might be the ETA for fixing this issue?

[GSPP]

Adding two related issues:

• https://github.com/dotnet/corefx/issues/5749 Add a clean way to cancel a long-running Socket operation (e.g. accept or connect)
• https://github.com/dotnet/corefx/issues/9698 Add reliable timeouts to socket operations