On Mon, Jul 18, 2005 at 10:36:23AM +0200, Gonzalo wrote:
> Sorry to bother you again with this problem. I have changed my test
> proofs to see if your suggestions were right, and the majority of the
> time was lost in the command transmission (connection, authentication,
> directory change...) instead of file transfer. I prepared a test were I
> have to download a 30 Mb file, and the results were exactly the same.
> Instead of the 30 Kbps that I can reach using the command-line FTP
> client, what I have are 3 Kbps using my FTP client built using cURL. I
> have tried to debug the library, but I am not an expert and I have no
> idea where the file transfer window is negotiated. I have tried several
> cURL options of the manual, but the results were exactly the same. Can
> you (or any other) give me any advice?

First, make sure you're using the latest curl version because there were
some improvements in ftp in recent versions. Next, use the -v option to look
at the commands sent by curl to the server. You may find that some aren't
needed (e.g. EPSV if the server doesn't support it). Use the appropriate
curl option to disable those commands (e.g. CURLOPT_FTP_USE_EPSV for EPSV)
to reduce the time on that option. There may be some commands that you'll
need to hack the curl source to eliminate (the initial PWD and TYPE probably
fit into that category). Be sure you know what you're doing, though, because
they are sent for a reason.

Once you trim those commands to a minimum, you should find that curl's
performance at least matches that of the command-line client.

>>> Dan

-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved