Default ResponseReadTimeout should not be infinite

Sep 21, 2012 at 1:40 AM

I have run into problems that were causing the FTP component to hang.  I managed to get a memory dump and from that a stack trace of the blocked thread and it turned out that it was failing to receive a reply on the initial connection.

Stack Trace:
DomainBoundILStubClass.IL_STUB_PInvoke(IntPtr, Byte*, Int32, System.Net.Sockets.SocketFlags)
System.Net.UnsafeNclNativeMethods+OSSOCK.recv(IntPtr, Byte*, Int32, System.Net.Sockets.SocketFlags)
System.Net.Sockets.Socket.Receive(Byte[], Int32, Int32, System.Net.Sockets.SocketFlags, System.Net.Sockets.SocketError ByRef)
System.Net.Sockets.Socket.Receive(Byte[], Int32, Int32, System.Net.Sockets.SocketFlags)
System.Net.Sockets.NetworkStream.Read(Byte[], Int32, Int32)
System.IO.StreamReader.ReadBuffer()
System.IO.StreamReader.ReadLine()
System.Net.FtpClient.FtpControlConnection.ReadLine()
System.Net.FtpClient.FtpControlConnection.GetReply()
System.Net.FtpClient.FtpControlConnection.OnInitalizedConnection(System.Net.FtpClient.FtpChannel)
System.Net.FtpClient.FtpChannel.OnConnectionReady()
System.Net.FtpClient.FtpChannel.Connect()
System.Net.FtpClient.FtpClient.Connect(System.String, System.String)
System.Net.FtpClient.FtpClient.Connect(System.String, System.String, System.String)

My workaround here was simply to set a ResponseReadTimeout > 0, but it strikes me a bit dangerous to set the default to zero (infinate timeout) or even to provide a way to set an infinite timeout at all for something as unreliable as network traffic.

My $0.02

Eamon

Coordinator
Sep 25, 2012 at 2:28 PM

I've changed the various timeouts to 15 seconds by default which I think reflects today's high speed connections pretty well. Mobile device developer's may want to use a higher timeout.