No response at the end of a large file transfer

Question

I have completed a program to transfer all files and subdirectories of a ftp directory to a local directory. When I started doing testing I ran into a problem. It will transfer small files (< about 2 megs) all day long but hangs at the end of a large file transfer. Here are the logs:

DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 22 Mar 2006 09:26:27.380 : 230 User logged in, proceed.
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 22 Mar 2006 09:26:27.395 : ---> TYPE I
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 22 Mar 2006 09:26:27.958 : 200 Type set to I.
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 22 Mar 2006 09:26:27.958 : ---> SYST
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 22 Mar 2006 09:26:28.005 : 215 UNIX Type: L8
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 22 Mar 2006 09:26:28.020 : ---> PASV
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 22 Mar 2006 09:26:28.052 : 227 Entering Passive Mode (12,145,56,10,64,78)
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 22 Mar 2006 09:26:28.067 : ---> LIST corey
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 22 Mar 2006 09:26:28.270 : 150 Opening ASCII mode data connection for /bin/ls.
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 22 Mar 2006 09:26:28.442 : 226 Transfer complete.
DEBUG [EnterpriseDT.Net.Ftp.FTPClient] 22 Mar 2006 09:26:28.442 : Found 10 listing lines
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 22 Mar 2006 09:26:28.442 : ---> PASV
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 22 Mar 2006 09:26:28.974 : 227 Entering Passive Mode (12,145,56,10,64,79)
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 22 Mar 2006 09:26:28.974 : ---> LIST corey\release
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 22 Mar 2006 09:26:29.161 : 150 Opening ASCII mode data connection for /bin/ls.
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 22 Mar 2006 09:26:29.317 : 226 Transfer complete.
DEBUG [EnterpriseDT.Net.Ftp.FTPClient] 22 Mar 2006 09:26:29.317 : Found 8 listing lines
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 22 Mar 2006 09:26:29.333 : ---> SIZE corey\aaapfpro_win32.zip
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 22 Mar 2006 09:26:29.974 : 213 1311128
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 22 Mar 2006 09:26:29.974 : ---> PASV
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 22 Mar 2006 09:26:30.020 : 227 Entering Passive Mode (12,145,56,10,64,81)
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 22 Mar 2006 09:26:30.020 : ---> RETR corey\aaapfpro_win32.zip
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 22 Mar 2006 09:26:30.130 : 150 Opening BINARY mode data connection for aaapfpro_win32.zip (1311128 bytes).
DEBUG [EnterpriseDT.Net.Ftp.FTPClient] 22 Mar 2006 09:27:37.365 : Transferred 1311128 bytes from remote host
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 22 Mar 2006 09:27:37.365 : 226 Transfer complete.
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 22 Mar 2006 09:27:37.365 : ---> SIZE corey\aasmgr_157.zip
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 22 Mar 2006 09:27:38.068 : 213 3509150
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 22 Mar 2006 09:27:38.068 : ---> PASV
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 22 Mar 2006 09:27:38.115 : 227 Entering Passive Mode (12,145,56,10,64,163)
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 22 Mar 2006 09:27:38.115 : ---> RETR corey\aasmgr_157.zip
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 22 Mar 2006 09:27:38.224 : 150 Opening BINARY mode data connection for aasmgr_157.zip (3509150 bytes).
DEBUG [EnterpriseDT.Net.Ftp.FTPClient] 22 Mar 2006 09:31:19.429 : Transferred 3509150 bytes from remote host
The program '[868] FtpUpdate.exe' has exited with code 0 (0x0).

It transfers the first file no problem. But the "Transfer Complete" is never recieved while transferring the second file. We have no problems with the ftp site using other programs. Any suggestions?

Answer 1

It appears to only be happening with my system. Tried it on other systems and it is working fine. :?:

Answer 2

Can you use commandline FTP and type 'debug' before you do the transfer? Then post the messages here.

It appears to only be happening with my system. Tried it on other systems and it is working fine. :?:

Answer 3

I seem to be having exactly the same problem, i stepped through the code and apparently the system hangs in this function, on the line in bold, line 623 in file FTPControlSocket.cs:

internal virtual FTPReply ReadReply()
{
string line = reader.ReadLine();

...

There's no exception thrown, the code just stops working, no error, no crash, nothing, it just calls the function and then NOTHING happens. Any ideas?

Answer 4

Ok, it seems to be an issue with some FTP servers, I tried downloading the same file from the command prompt and found out that right after receiving a large file, I also receive a timedout error from the server. Somehow the edtFTPclient classes don't catch this last timeout message and wrongfully believe they are still connected. The ReadReply() function then messes up because it indefinetely waits for the ReadLine() function who is listening to a dead stream.
So I guess the CheckConnection() function needs to be changed.

Or at least, that's what I'm making of this problem so far... Hope this will help somebody.

Answer 5

Thanks for the info.

Does this error appear in the logfile? If so, could you post a snippet of the file? Also, what timeout error did you receive?

We'll see if we can fix this to throw an exception.

Ok, it seems to be an issue with some FTP servers, I tried downloading the same file from the command prompt and found out that right after receiving a large file, I also receive a timedout error from the server. Somehow the edtFTPclient classes don't catch this last timeout message and wrongfully believe they are still connected. The ReadReply() function then messes up because it indefinetely waits for the ReadLine() function who is listening to a dead stream.
So I guess the CheckConnection() function needs to be changed.

Or at least, that's what I'm making of this problem so far... Hope this will help somebody.

Answer 6

Hey there support2 :) Thanx a lot for replying, I'm in the middle of a deadline right now, so I can't supply you with that data right now. Next week I'll prepare a little app that'll spew out, hopefully, the right log entries. You'll hear from me then.