TcpClient SocketException with timeout after 20s no matter what

Question

I'd like to wait for a slow response from a client with TcpClient but get a timeout after about 20s no matter how I configure it. This is my attempt:

using (var client = new TcpClient { ReceiveTimeout = 9999999, SendTimeout = 9999999 })
{
    await client.ConnectAsync(ip, port);
    using (var stream = client.GetStream())
    {
        // Some quick read/writes happen here via the stream with stream.Write() and stream.Read(), successfully.

        // Now the remote host is calculating something long and will reply if finished. This throws the below exception however instead of waiting for >20s.
        var bytesRead = await stream.ReadAsync(new byte[8], 0, 8);
    }
}

The exception is an IOException:

Unable to read data from the transport connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

...which contains a SocketException inside:

A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond

SocketErrorCode is TimedOut.

The 20s seems to be an OS default on Windows but isn't it possible to override it from managed code by interacting with TcpClient? Or how can I wait for the response otherwise?

I've also tried the old-style BeginRead-EndRead way and the same happens on EndRead. The problem is also not caused by Windows Firewall or Defender.

Answer 1

It turns out that the remote host wasn't responding in a timely manner, hence the problem. Let me elaborate, and though this will be a solution very specific to my case maybe it will be useful for others too.

The real issue wasn't a timeout per se, as the exception indicated, but rather what exceptions thrown on subsequent Read() calls have shown: "An existing connection was forcibly closed by the remote host"

The remote host wasn't purposely closing the connection. Rather what happened is that when it was slow to respond it was actually so busy that it wasn't processing any TCP traffic either. While the local host wasn't explicitly sending anything while waiting for a response this still was an issue: the local host tried to send ACKs for previous transmissions of the remote host. Since these couldn't be delivered the local host determined that the remote host "forcibly closed" the connection.

I got the clue from looking at the traffic with Wireshark (always good to try to look at what's beneath the surface instead of guessing around): it was apparent that while the remote host was busy it showed complete radio silence. At the same time Wireshark showed retransmission attempts carried out by the local host, indicating that this is behind the issue.

Thus the solution couldn't be implemented on the local host either, the behavior of the remote host needed to be changed.