On Tue, 17 Feb 2009, Patrik Thunström wrote:

> For now, the only protocol I'm using for transfers is SFTP, together with
> the curl_easy-interface, so I cannot say if this "issue" is affecting other
> protocols too. I've got the picture that this issue is not affecting the
> multi-interface by reading the mailing list archive.

We've recently done some SFTP related changes and improvements to libcurl and
libssh2 so it is very important what specific versions of these libs you're
using. Anything before libcurl 7.19.3 with libssh2 1.0 is known to have flaws.
Of course I'm not claiming that pair doesn't have it selection of flaws too,
but earlier versions had even more! ;-)

> What I'm suspicious about is the performance when downloading multiple files
> from the same SFTP connection. The transfer itself is nice and fast, but for
> each of the transfers I noticed there seemed to be a fixed delay in between
> transferring the next file. Tracking it down I found out that there is a
> constant timeout value given at line 1856 of Transfer.c, set at 1000ms.

That sounds like a bug. If nothing happens for 1000ms then it shouldn't make
much difference if it tries to continue or not. If it _does_ continue after
just having waited for 1000ms then surely the wait was pointless.

> Further analyzing the source code makes it look to me like it is
> unconditionally awaiting the constant timeout, to ensure that the sockets
> are ready before trying to do any transfer.

No it doesn't. It waits for action on the socket, with a timeout at 1000ms so
it can run timer stuff at least once every 1000ms. So if there is action on
the socket it should continue immediately.

-- 
  / daniel.haxx.se