Our Products:   CompleteFTP  edtFTPnet/Free  edtFTPnet/PRO  edtFTPj/Free  edtFTPj/PRO
0 votes
3.6k views
in .NET FTP by (500 points)
As you know, I was having some issues with my FTP transfers. I have now moved to a new hosting service so I have now discovered a new set of problems. It seems that the FTP server closes the connection as soon as the upload of a file succeeds. I'm not sure if it does it as well if the upload fails but I won't worry about that for the moment. I verified this behavior by simply using the command line FTP in Windows. It looks like what actually happens is that the transfer finishes and the server doesn't respond to that event. The connection eventually times out and is closed. Is this something that you have seen before?

Here's the log of one of these transfers:
DEBUG [FTPClient] 8 Jun 2011 11:36:59.618 : Connecting to 206.188.192.163:21
DEBUG [HostNameResolver] 8 Jun 2011 11:36:59.618 : Resolving 206.188.192.163
DEBUG [HostNameResolver] 8 Jun 2011 11:36:59.618 : 206.188.192.163 resolved to 206.188.192.163
INFO [BaseSocket] 8 Jun 2011 11:36:59.618 : Connecting to 206.188.192.163:21 with timeout 45000 ms
DEBUG [FTPControlSocket] 8 Jun 2011 11:36:59.728 : Setting socket timeout=45000
INFO [FTPControlSocket] 8 Jun 2011 11:36:59.728 : Command encoding=System.Text.SBCSCodePageEncoding
DEBUG [FTPControlSocket] 8 Jun 2011 11:36:59.728 : StrictReturnCodes=False
DEBUG [FTPControlSocket] 8 Jun 2011 11:36:59.821 : 220 (vsFTPd 2.2.2)
DEBUG [FTPConnection] 8 Jun 2011 11:36:59.821 : Connected to 206.188.192.163 (instance=3)
DEBUG [FTPControlSocket] 8 Jun 2011 11:36:59.821 : ---> USER lwirbtrials
DEBUG [FTPControlSocket] 8 Jun 2011 11:36:59.915 : 331 Please specify the password.
DEBUG [FTPControlSocket] 8 Jun 2011 11:36:59.915 : ---> PASS ********
DEBUG [FTPControlSocket] 8 Jun 2011 11:37:00.024 : 230 Login successful.
DEBUG [FTPConnection] 8 Jun 2011 11:37:00.024 : Successfully logged in
DEBUG [FTPControlSocket] 8 Jun 2011 11:37:00.024 : ---> FEAT
DEBUG [FTPControlSocket] 8 Jun 2011 11:37:00.118 : 211-Features:
DEBUG [FTPControlSocket] 8 Jun 2011 11:37:00.430 : EPRT
DEBUG [FTPControlSocket] 8 Jun 2011 11:37:00.430 : EPSV
DEBUG [FTPControlSocket] 8 Jun 2011 11:37:00.430 : MDTM
DEBUG [FTPControlSocket] 8 Jun 2011 11:37:00.430 : PASV
DEBUG [FTPControlSocket] 8 Jun 2011 11:37:00.430 : REST STREAM
DEBUG [FTPControlSocket] 8 Jun 2011 11:37:00.430 : SIZE
DEBUG [FTPControlSocket] 8 Jun 2011 11:37:00.430 : TVFS
DEBUG [FTPControlSocket] 8 Jun 2011 11:37:00.430 : UTF8
DEBUG [FTPControlSocket] 8 Jun 2011 11:37:00.430 : 211 End
DEBUG [FTPControlSocket] 8 Jun 2011 11:37:00.430 : ---> TYPE I
DEBUG [FTPControlSocket] 8 Jun 2011 11:37:00.523 : 200 Switching to Binary mode.
DEBUG [FTPControlSocket] 8 Jun 2011 11:37:00.523 : ---> PWD
DEBUG [FTPControlSocket] 8 Jun 2011 11:37:00.617 : 257 "/"
DEBUG [FTPControlSocket] 8 Jun 2011 11:37:00.617 : NewActiveDataSocket(0)
DEBUG [FTPControlSocket] 8 Jun 2011 11:37:00.617 : ---> PORT 192,168,11,107,194,21
DEBUG [FTPControlSocket] 8 Jun 2011 11:37:00.710 : 200 PORT command successful. Consider using PASV.
DEBUG [FTPControlSocket] 8 Jun 2011 11:37:00.710 : ---> STOR 001210VEACHA.zip
DEBUG [FTPControlSocket] 8 Jun 2011 11:37:00.898 : 150 Ok to send data.
DEBUG [FTPActiveDataSocket] 8 Jun 2011 11:37:00.898 : AcceptConnection() succeeded
DEBUG [FTPClient] 8 Jun 2011 11:37:09.072 : Closing source stream
DEBUG [FTPClient] 8 Jun 2011 11:37:09.072 : Transferred 5537569 bytes to remote host
ERROR [FTPControlSocket] 8 Jun 2011 11:37:54.593 : Read failed ('' read so far)
WARN [FTPClient] 8 Jun 2011 11:37:54.593 : ReadReply failedI verif
WARN [FTPClient] 8 Jun 2011 11:37:54.593 : EnterpriseDT.Net.Ftp.ControlChannelIOException: 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.
WARN [FTPClient] 8 Jun 2011 11:37:54.593 : at EnterpriseDT.Net.Ftp.FTPControlSocket.ReadLine()
WARN [FTPClient] 8 Jun 2011 11:37:54.593 : at EnterpriseDT.Net.Ftp.FTPControlSocket.ReadReply()
WARN [FTPClient] 8 Jun 2011 11:37:54.593 : at EnterpriseDT.Net.Ftp.FTPClient.ValidateTransfer()
DEBUG [FTPConnection] 8 Jun 2011 11:37:54.593 : GetLastWriteTime(001210VEACHA.zip)
WARN [FTPConnection] 8 Jun 2011 11:37:54.593 : Could not retrieve modified-time of file 001210VEACHA.zip - -1 The FTP client has not yet connected to the server. The requested action cannot be performed until after a connection has been established.
DEBUG [FTPConnection] 8 Jun 2011 11:37:54.593 : Closing connection (instance=3)
DEBUG [FTPConnection] 8 Jun 2011 11:37:54.593 : Closing connection (instance=3)

I verified that the file was transferred completely (the number of bytes is correct) by downloading the file and verifying that it is intact (it is). So apparently the transfer is succeeding but since the connection gets closed the EDT library can't verify the transfer and it throws an exception.

So my question is, is this unusual behavior for a server? And, what is the best way to handle this situation?

2 Answers

0 votes
by (500 points)
OK, I found a work-around for this problem. Here's the code I use to deal with it:
               try {
                  uploadSucceded = true;
                  ftp.UploadStream(stream, zipFile);
               } catch (EnterpriseDT.Net.Ftp.ControlChannelIOException) {
                  // we seem to have a problem with the server - it
                  // closes the connection after the transfer succeeds
                  // so if we get here, then check the file size to see
                  // if it transferred completely and if so then declare
                  // success and move to the next file
                  try {
                     TRACE("Control Channel Exception: verifying file size", 1);
                     if (ftp.IsConnected) {
                        ftp.Close();
                     }
                     ftp.Connect();
                     remoteFileSize = ftp.GetSize(zipFile);
                     if (remoteFileSize == localFileSize) {
                        TRACE("Control Channel Exception: file sizes match", 1);
                        uploadSucceded = true;
                     } else {
                        TRACE("Control Channel Exception: attempting resume", 1);
                        ftp.ResumeTransfer();
                        ftp.UploadStream(stream, zipFile, true);
                     }
                  } catch (Exception ex) {
                     uploadSucceded = false;
                     xferStatus = TransferStatus.UploadFail;
                     ftpErrMsg = ex.Message;
                     TRACE("FTP resume exception : " + ftpErrMsg, 1);
                  }
               } catch (Exception ex) {
                  // if we have an exception, then the upload failed
                  uploadSucceded = false;
                  xferStatus = TransferStatus.UploadFail;
                  ftpErrMsg = ex.Message;
                  TRACE("FTP upload exception : " + ftpErrMsg, 1);
               }

I need a lot more testing but this seems to work around this problem.
0 votes
by (220 points)
Thanks Daveinca

This is exactly the same problem I am having! I'm glad I'm not the only one.

I'll implement your workaround but I'd love to know why the server is not responding and fix that issue.
Have you discovered if this causes any memory problems or file lock problems given the connection is automatically dumped?

As an aside, it seems to be that there is a 50Mb file limit cut-off for when this succeeds vs when it fails :? (at least on my server)

Categories

...