Shutting down a Socket should not set it to disconnected

[GSPP]

Calling Shutdown on a Socket will cause it to become disconnected which is incorrect. This can cause, for example, TcpClient.GetStream to fail on a half-open socket.

[davidsh]

What OS platform are you reproducing this bug? Windows and/or *Nix?

[stephentoub]

He's referring to code that's shared between them:
https://github.com/dotnet/corefx/blob/master/src/System.Net.Sockets/src/System/Net/Sockets/Socket.cs#L4212
and in the full framework:
http://referencesource.microsoft.com/#System/net/System/Net/Sockets/Socket.cs,5681

[davidsh]

So, this is not a bug, but a request for a behavior change to how the current Shutdown method works on a Socket. We would have to investigate that since it could break a lot of apps that depend on the current behavior. it might be better long term to have another overload for Shutdown that has the different (new) behavior. That would require an API contract revision.

[GSPP]

Some guy ran into this: http://stackoverflow.com/questions/36226535/half-closing-tcpclient I thought I'd report it.

I kind of doubt that someone depends on an exception being thrown here or on Connected returning false. This kind of problem is usually found during development because it seemingly breaks an otherwise working connection.

And people shove their code around until they have worked around that bug (hopefully removing any Connected checks that they should not be doing anyway!). At least that's how most socket code arises judging by what my eyes have to see on Stack Overflow daily :)

Indeed, the answer that was posted worked around the problem initially not realizing this is a bug. But people always notice so they don't depend on this behavior.

[GSPP]

Another question is whether GetStream should perform this check at all. Ideally, it would not and simply hand out the stream. The check does not accomplish anything since the condition can immediately become false right after checking. The check does not provide assurance. Rather, it provide a different and very rare non-deterministic failure mode for the same underlying cause. Also, this is a violation of separation of responsibilities. Again, I think nobody would depend on this behavior since a stream that is obtained through GetStream is usually being used right after that and a similar exception will occur.

The whole GetStream method is a design mistake. It should be an always working Stream property but this cannot be fixed now.

[davidsh]

cc: @CIPop

[CIPop]

@GSPP thanks for reporting!
Assigning to @himadrisarkar for triage / prioritization.

[karelz]

It looks like a reasonable thing to fix in .NET Core.
We will have to carefully review impact of the difference between platforms.

Question: How painful it is today for customers? What is value? (number of customers)

[GSPP]

Networking is a fundamental element of the .NET standard libraries. Especially with the world becoming more connected and distributed the core Socket API should be as reliable as possible. I'd make the case to fix this. It does not seem like an expensive fix to take.