FTP upload using .NET

Question

I am writing a code to upload a zip file to an ftp server. Surprisingly the code works fine for small files, but with bigger files I end up in problem. I am using Stream object and I have noted that my code is getting stuck while trying to close the Stream (only for big files). The code runs fine if I do not close the Stream (even for big files). Does anyone see any logic in why this is happening. And if I don't close the stream is it possible that I might end up in problem in future.

Code extract:

FtpWebRequest reqFTP = (FtpWebRequest)FtpWebRequest.Create(new Uri(@"ftp://" + ftpServerIP + @"/" + fileInf.Name));
Stream strm = reqFTP.GetRequestStream();

The code stops responding (when the upload file is big) at:

strm.Close();

There is no exception as this part is within try-catch.

I don't know how to get a stack trace.

Answer 1

I don't know specifically what error you're getting when closing the stream, but in our application, we do a lot of large file uploads (videos and images). Here's how we write to our FTP stream:

request.KeepAlive = false; // This eliminated some of our stream closing problems

using (Stream stream = request.GetRequestStream())
{
    stream.Write(file.Data, 0, file.Data.Length);
}

I thought that doing a using block would effectively do the Close call on its own, but maybe it also performs other necessary cleanup. Also notice I turned off the FTP keepalives, which caused us problems in some of the third-party FTP sites we uploaded to.

You really should look at the specific exception you're receiving rather than swallowing all exceptions. The error message will most-likely tell you what's wrong. The most common problems we encountered had to do with active vs. passive mode and the keepalives.

Edit:

To discover what was really going on when we had FTP issues with CDNs (and it happens way too frequently), we sometimes had to turn tracing on in our application. See this link for details on how to enable tracing. Another option is to use a tool like Wireshark to sniff the conversation between your application and the FTP server. If you can see what's going in in the FTP protocol, you'll have a much better chance of resolving the issue.

Answer 2

It might be worth a shot in trying out the Open Source FTP component from here... I have tried using FtpWebRequest and my experience of using that was negative...slow, times out, because quite naturally, the FtpWebRequest works through port 80 instead of the native port 21...the situation changed quite dramatically when I used this FTP component, more versatile and powerful...

Edit: As Jacob pointed out my obvious error and my illogical view of the FtpWebRequest class which lead me to believe something funky and weird was going on, and that it was somehow doing something via HTTP ... Well Jacob must have a point...a classic case of bad naming convention within the Framework... Thanks Jacob!

Hope this helps, Best regards, Tom.