edtFTPNET Free - Upload File Errors

Question

I've been using the free version of edtFTP .NET to evaluate EnterpriseDT's product in the development of an FTP Client Application.

Using the FTPConnection class (as a Control added to the primary form in my VB.NET development) I can successfully establish a connection to the FTP Server, upload and download files.

I'm using ListView controls to present local and remote file lists to the user, which they can use to select 1 or >1 files to transfer. The Free version contains the .UploadFile method but no .UploadMultiple which I've seen asked about in other Forum posts, so when the user selects more than one file to upload the application iterates through them via For Each, performing some pre-transfer actions for each file, uploading the file, and performing post-transfer cleanup.

The FTP Server has a 15 minute timeout.

I can successfully upload 1 file of any size with no problem. I can successfully upload any number of files of small size with no problem.

My problem appears only when I'm uploading more than 1 file, and one of those files is very large (specifically: 50-70MB), and the transfer takes more than 15 minutes; what happens is that toward the end of the UploadFile operation the application throws an error that the FTPConnection is not yet connected to the server, and the operation can only be performed when the FTPConnection is connected. I can upload the exact same large file without any problems, if I upload it individually, and I can upload any number of smaller files without any problems.

Troubleshooting Performed:

I've used the BytesTransferred Event to return values for FTPConnection.IsConnected and .IsTransferring.
- First pass, both return True.
- Second pass, .IsConnected returns False and .IsTransferring returns True. This Second Pass on the event is actually happening within just a few seconds of the start of the Upload.
- I've tried using If-Then statements to run FTPConnection.Connect if .IsConnected is False.
- I've implemented both .InvokeFTPCommand and .InvokeSiteCommand in this Event procedure to send CRLF (FTP NoOp command outlined in RFC 959) in order to keep the connection alive during large transfers; because no matter what the .IsConnected changes to False, the .Invoke(X)Command methods throw errors that the FTPConnection is not connected on the Second Pass.
-* I've constructed the CRLF String the following ways, always with the same result.
-*1 VbCRLF constant where VBCRLF is supplied as the Command String to the Method.
-*2 chr(13) & chr(10) to return the ASCII characters CRLF, where chr(10) & chr(13) is supplied as the Command String to the Method.
-*3 Dim NoOp as String = VBCRLF (where NoOp is then supplied as the Command String to the Method)
-*4 Dim NoOp as String = chr(13) & chr(10) (where NoOp is supplied as the Command String)

I've placed messageboxes in the iterating code to identify where and when the error is appearing.
- When transferring multiple large files, the error appears before the .UploadFile operation is even completed, so it's happening on the large file without moving on to the next step in the For Each loop, which means that I can't use If-Then statements to reconnect.

I've set an Uploaded Event handler to see what's happening there.
- When I place a messagebox in this event, this event fires before the error occurs.
- When I place an If-Then statement in this event to check for .IsConnected and call on FTPConnection.Connect if False, it does not reconnect and it throws the error in the UploadFile procedure.

Any suggestions as to why this error is occurring on multiple large file transfers would be greatly appreciated, as well as any ideas as to what can be done to verify the connection, keep the connection alive, and/or reconnect on timeout during the transfer.

Thanks,

Andrew

Answer 1

Verifying the connection is hard - you can't always rely on IsConnected (which uses the underlying socket's similar method). If the other end goes away, you simply might not know about it.

It seems that the FTP server is not keeping the control connection alive when a large file is being transferred, which is often problematic.

The simplest solution is to immediately disconnect from the server when an exception is thrown, and then reconnect and resume the transfer if it is not completed.

Answer 2

Thanks for your prompt reply.

I've found that this works just fine if I simply use On Error Resume Next before the upload starts, but this method (and honestly your suggestion of disconnect/reconnect/resume, too) leaves a huge margin for unhandled error.

Any ideas at all as to why the FileUpload method would be generating exceptions only in this particular set of conditions, all other factors notwithstanding?

Answer 3

It isn't an ideal solution, but it is certainly a good idea to expect the occasional failed transfer with FTP and have code in place to recover and resume.

If you capture a log file at the Debug level and email it to us (support@...) we'll take a look to see if there are any clues to why this happens in these circumstances.