FtpWebRequest and timeouts

FtpWebRequest and timeouts

• Klingon

  hi John,
  i've done some more debugging and i found out that the exception is happening at requestStream.Close();
  the GetResponse() method does not even get a chance to execute.  the code i'm using is from the "FtpSampleCS" sample application.  here is the exception stack trace which clearly shows it is happening from the Stream.Close method
  
  System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive.
     at System.Net.FtpWebRequest.SyncRequestCallback(Object obj)
     at System.Net.FtpWebRequest.RequestCallback(Object obj)
     at System.Net.CommandStream.Abort(Exception e)
     at System.Net.CommandStream.CheckContinuePipeline()
     at System.Net.FtpWebRequest.DataStreamClosed(CloseExState closeState)
     at System.Net.FtpDataStream.System.Net.ICloseEx.CloseEx(CloseExState closeSta
  te)
     at System.Net.FtpDataStream.Dispose(Boolean disposing)
     at System.IO.Stream.Close()
     at Microsoft.Samples.FtpSample.Program.Upload
  
  
  by the way, i tried setting both the Timeout and ReadWriteTimeout (and combinations of the two) to 30 minutes, but it did not change the exception.  the transfer takes about 7 mins. i'm trying it on several different FTP servers just for comparison. 
  
  

• rings777

  I have seen a problem like this once before and from what I remember we had them increase the FtpWebRequest.ReadWriteTimeout value to be something very large (at least for testing purposes). I can't be sure this is the same issue, but the person I worked with before was seeing this because the server was taking a very long time to process some of the data and by setting the ReadWriteTimeout to something large, we made sure that the client didn't give up on the server too soon.

  If you want to use the following app.exe.config file, you can get a trace of the problem and I would be happy to help you diagnose the problem. Send me (by e-mail) the System.Net.Trace.log file once you have it (please remove private information from the log first). For more information on tracing, see http://blogs.msdn.com/dgorti/archive/2005/09/18/471003.aspx

  < xml version="1.0" encoding="UTF-8" >

  <configuration>
  <system.diagnostics>
  <trace autoflush="true" />
  <sources>
  <source name="System.Net">
  <listeners>
  <add name="System.Net"/>
  </listeners>
  </source>
  <source name="System.Net.HttpListener">
  <listeners>
  <add name="System.Net"/>
  </listeners>
  </source>
  <source name="System.Net.Sockets">
  <listeners>
  <add name="System.Net"/>
  </listeners>
  </source>
  <source name="System.Net.Cache">
  <listeners>
  <add name="System.Net"/>
  </listeners>
  </source>
  </sources>
  <sharedListeners>
  <add
  name="System.Net"
  type="System.Diagnostics.TextWriterTraceListener"
  initializeData="System.Net.trace.log"
  traceOutputOptions = "DateTime"
  />
  </sharedListeners>
  <switches>
  <add name="System.Net" value="Verbose" />
  <add name="System.Net.Sockets" value="Verbose" />
  </switches>
  </system.diagnostics>
  </configuration>

  
  
  

• CraigH

  I could not resolve this issue so I purchased a commercial component (Rebex.Net)

  It seems that the Microsoft FTP server needs NOOP commands sent even while downloading a file. This prevents timeouts with large files. Rebex.net has an option KeepAliveDuringTransfer which will send NOOP. I have not had any issues when using this option. Here is my code:

  Code Snippet

  using Rebex.Net;

  ftpClient.Connect(Settings.FtpAddress);

  ftpClient.Login(Settings.FtpUserName, Settings.FtpPassword);

  ftpClient.Options = FtpOptions.KeepAliveDuringTransfer;
  ftpClient.KeepAliveDuringTransferInterval = 60; // will send a NOOP every 60 seconds
  
  ftpClient.GetFile(remotepath, filePath);

  
  
  

  
  

• Encaps

  I think that my previous suspicions were correct. You are sending a bunch of data and the server doesn't send any kind of response until you are completely done uploading the data. We post a receive on the control stream, but no response is sent back because the server is not done processing all the data. Looking at the code, the default value for ReadWriteTimeout on FtpWebRequest is 5 minutes. If the upload takes longer than that, you need to tweak the value of this property so that you don't get an error. I think that if you make the ReadWriteTimeout value larger than the time it takes to do the entire upload, you should see this problem go away.
  
  

• Tomas M.

  Try FtpWebRequest.Timeout = int.MaxVal;

  I hope you'll never face TimeOutException even it takes hours to upload/download some data.

  Best Regards,

  Rizwan aka RizwanSharp

  
  
  

• Nigel Watling

  Well why not set the timeout to something like 180*60*1000 milliseconds [ 3 minutes]. You don't want to assume anything when an
  exception occurs. I would rather not have the exception
  
  

• Leif902

  I am having the same problem using the FtpWebRequest sample code with .NET 1.1 and Microsoft FTP server. The timeout exception is being thrown.

  Did you guys resolve this

  
  

• Liu Xiong

  I am also having this problem, did you ever find a solution for it

  I noticed hat if I keep looping on the requeststream.close error, it will eventually close and not raise an error. The problem is that when that happens, the getresponse does not work anymore.

  Regards,

  Eduardo

  
  
  

• Best Ordinary Man

  Are there any updates on this issue

  I'm using .Net 2.0 with the same results as 'Tim_Mackey' and have set large timeout values, turn on/off both 'KeepAlive' and 'UsePassive'.

  ftpRequest.ReadWriteTimeout = 1000 * 1200 '>>>>> (1200 seconds = 20 minutes)

  ftpRequest.Timeout = 1000 * 1200 '>>>>> (1200 seconds = 20 minutes)

  ftpRequest.KeepAlive = True

  ftpRequest.UsePassive = False

  File sizes of 500 KB are no issue but testing with files of size 7 MB fails every time. I'm assuming, as the rest of you, that this is related to the period of time to deliver the file and not the size of it. On the same machine, I can transfer (upload/put) the same file or much larger files to the same destination/credentials using the command-line FTP (takes less than 10 minutes so not exceeding the 20 minutes set for the timeouts above).

  The .Net framework is certainly easy to use and I've been please with my 1 month of experience using it so far but this seems to be an issue that has existed for a while. Any guidance to resolve would be greatly appreciated.

  
  

• lordhed

  Tim,

  I didn't get your e-mail. I have e-mailed you. Please reply to the e-mail and CC my hotmail account (included in the e-mail I sent you).

  Thanks.

  
  
  

• Varun Sood

  hi jon. i emailed you a sample application emailed. if anyone is reading this thread, i have found that the problem occurs on FileZilla server build 9.12 on Windows Server 2003, and Microsoft IIS Ftp Server on XP Pro sp2, but not a Unix FTP server.
  
  

• Lynn_global

  hi Durgaprasad
  you are right, exceptions are bad...
  but i don't want to set a massive timeout because then if there is a connection failure, it takes 3 minutes for you to know about it. there's nothing wrong with the server, or the connection, it's just uploading a large file that takes 10 mins or whatever.
  by the way, your calculation reads 180 minutes ! i only mention this in case you have used this code in your applications by mistake.
  
  thanks
  tim
  
  

• bsports3

  hi,
  thanks for the info on tracing, i didn't know you could do this. since the file transfer is actually successful i suspect that the timeout happens just because the upload took 10 minutes or whatever, even though bytes were continuously being transferred. i would prefer if the timeout was based on inactivity on the connection rather than "when was the last time you started a transfer"
  
  here is the end of my log trace. the first few lines are the end of the data transfer, then it closes the socket, and then calls receive, and then the timeout. this doesn't happen with other FTP software (e.g. FileZilla) connecting to the same server.
  
  System.Net.Sockets Verbose: 0 : [3312] 000003E0 : 54 9B B9 F6 55 6D 33 DF-51 14 7B 39 8A 77 14 AF : T...Um3.Q.{9.w..
  DateTime=2006-02-22T12:46:58.4375000Z
  System.Net.Sockets Verbose: 0 : [3312] 000003F0 : 13 82 29 E3 48 42 12 21-9F 50 42 A8 22 6C 20 6C : ..).HB.!.PB."l l
  DateTime=2006-02-22T12:46:58.4375000Z
  System.Net.Sockets Verbose: 0 : [3312] Exiting Socket#52307948::Send() -> 57190#57190
  DateTime=2006-02-22T12:46:58.4375000Z
  System.Net.Sockets Verbose: 0 : [3312] Socket#52307948::Dispose()
  DateTime=2006-02-22T12:46:58.4375000Z
  System.Net.Sockets Verbose: 0 : [3312] Socket#17653682::Receive()
  DateTime=2006-02-22T12:46:58.4375000Z
  System.Net.Sockets Error: 0 : [3312] Exception in the Socket#17653682::Receive - 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
  DateTime=2006-02-22T12:48:38.9375000Z
  System.Net.Sockets Verbose: 0 : [3312] Exiting Socket#17653682::Receive() -> 0#0
  DateTime=2006-02-22T12:48:38.9375000Z
  System.Net.Sockets Verbose: 0 : [3312] Socket#17653682::Dispose()
  DateTime=2006-02-22T12:48:38.9687500Z
  System.Net Information: 0 : [3312] FtpWebRequest#35320229::(Releasing FTP connection#42194754.)
  DateTime=2006-02-22T12:48:38.9687500Z
  
  i can post a link to download the entire log file, if it is relevant, 5mb in size.
  
  thanks very much
  tim
  
  

• Patrick MCCormick

  Do you have a simplified repro I can take a look at If yes, please e-mail it to me.
  
  
• FtpWebRequest and timeouts