You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've built curl 7.87.0 with libssh 0.10.4 for sftp support and I'm trying to download a 30 MiB file with a relatively slow bandwith of ~ 10 Mbit/s.
The update rate of the progress meter is then something like once every 4 seconds.
(To someone who doesn't know what's going on, the download appears to be stalling at first. No progress at all until ~ 6.5 MiB are transfered.)
It works fine when curl is built with libssh2. (Progress meter updates at least once every second.)
When looking into this I came to the conclusion, that the sftp transfer with libssh is done in blocking mode.
That means the do-while loop in readwrite_data() (lib/transfer.c) runs until maxloops are exceeded. So depending on buffer size, there would be no updating on the progress meter for a long time.
Is there any specific reason why libssh is used in blocking mode for this?
Curl seems to prefer nonblocking mode in general.
I tried to fix this by adding sftp_file_set_nonblocking(sshc->sftp_file) after sftp_open() and as far as I can tell this works without a problem. (No thorough testing done yet, though.)
The text was updated successfully, but these errors were encountered:
What I remember is that the libssh2 backend was supporting async but libssh not at the time. As I didn't know how the libssh async/non-blocking mode will work (when developed) the curl code was modeled similar to libssh2. I do not know if libssh today supports non-blocking mode for sftp transfers.
I found the post on the libssh mailing list, that is refering SCP, which I have not looked at yet.
For SFTP, I'm quite certain that it works. (for reading)
Looking at the Curl_read() calls on downloads, the behaviour is similar to libssh2 now.
This is the patch I used (diff to current master):