speed

Question

I've just been trying this out in a simple Windows Forms app, and my code is running very slowly. The code is basically:

ftp = new FTPClient("server");
ftp.ConnectMode = FTPConnectMode.PASV;
ftp.Login("username","password");

DateTime t2 = DateTime.Now;
ftp.Chdir(rootDir);
DateTime t3 = DateTime.Now;
string[] dir = ftp.Dir();
dir = ftp.Dir();
DateTime t4 = DateTime.Now;

From looking at the values of t2-t4, the login and chdir(folder) command both seem to be zippy, but a dir() command is taking 8-9 seconds. Am I doing something wrong? Are there API tweaks I'm missing? Regular FTP clients are running at normal speed.

Thanks.

Answer 1

You could try active mode - perhaps there's some problem with PASV on your server and other clients are using active. You can check by setting debug on a commandline client. Or hack FTPCLient and put some timestamps in there to find out where the delay is actually occurring.

I've just been trying this out in a simple Windows Forms app, and my code is running very slowly. The code is basically:

ftp = new FTPClient("server");
ftp.ConnectMode = FTPConnectMode.PASV;
ftp.Login("username","password");

DateTime t2 = DateTime.Now;
ftp.Chdir(rootDir);
DateTime t3 = DateTime.Now;
string[] dir = ftp.Dir();
dir = ftp.Dir();
DateTime t4 = DateTime.Now;

From looking at the values of t2-t4, the login and chdir(folder) command both seem to be zippy, but a dir() command is taking 8-9 seconds. Am I doing something wrong? Are there API tweaks I'm missing? Regular FTP clients are running at normal speed.

Thanks.

Answer 2

Hi,

It turned out that the line taking the time was this:

IPHostEntry remoteHostEntry = Dns.Resolve(ipAddress);

Every call to Dir() was constructing a socket, and every socket creation was constructing this IPHostEntry. So I moved the DNS resolution to the FTPControlSocket constructor, and stored the entry there (which seems to make sense, since FTPControlSockets are linked to a single host).

And now I'm wondering why the Dir() call is creating a new socket each time - why can't I create the socket once and cache it? Is there some feature of FTP that makes this a bad idea?

Answer 3

Thanks for the info - we might move the resolve to the constructor for the next release.

Re why a new socket is being created every time - take a look at http://www.enterprisedt.com/general/doc ... erview.pdf

Basically, in FTP all data is transferred over transient connections that are closed once the data for an operation has been transmitted. So you can't cache the socket. The control connection (control data is sent over a different TCP connection) *is* maintained for an entire session.

Hi,

It turned out that the line taking the time was this:

IPHostEntry remoteHostEntry = Dns.Resolve(ipAddress);

Every call to Dir() was constructing a socket, and every socket creation was constructing this IPHostEntry. So I moved the DNS resolution to the FTPControlSocket constructor, and stored the entry there (which seems to make sense, since FTPControlSockets are linked to a single host).

And now I'm wondering why the Dir() call is creating a new socket each time - why can't I create the socket once and cache it? Is there some feature of FTP that makes this a bad idea?

Answer 4

Hi,

It turned out that the line taking the time was this:

IPHostEntry remoteHostEntry = Dns.Resolve(ipAddress);

Every call to Dir() was constructing a socket, and every socket creation was constructing this IPHostEntry. So I moved the DNS resolution to the FTPControlSocket constructor, and stored the entry there (which seems to make sense, since FTPControlSockets are linked to a single host).

Hi Ewan,
I did the same thing a few months ago and posted the changes (and submitted 'em to Bruce). Hopefully they'll be in the new lib.

-Matt

Answer 5

We haven't lost any submissions, and want to release a new version of edtFTPnet ASAP. Unfortunately we have been spending all of our time on edtFTPj & edtFTPj/SSL development.

Good news is that the many changes made in edtFTPj will be ported over to edtFTPnet, so ultimately lots of new features are coming. It might take a little while to do them all, so they won't be in one release, but they are coming.

Hi,

It turned out that the line taking the time was this:

IPHostEntry remoteHostEntry = Dns.Resolve(ipAddress);

Every call to Dir() was constructing a socket, and every socket creation was constructing this IPHostEntry. So I moved the DNS resolution to the FTPControlSocket constructor, and stored the entry there (which seems to make sense, since FTPControlSockets are linked to a single host).

Hi Ewan,
I did the same thing a few months ago and posted the changes (and submitted 'em to Bruce). Hopefully they'll be in the new lib.

-Matt