On Thu, 9 Aug 2018, Daniel Jeliński via curl-library wrote:

> There's no way for curl/libssh2 to put more than 16 KB on the wire. It's
> right there in libssh2 docs [1]: [libssh2_sftp_write] will return a positive
> number as soon as the first packet is acknowledged from the server.

That's incorrect. libssh2 sends off many separate packets at the same time (if
given the opportunity) and will return data as soon as the *first* packet is
acked, so if you keep sending large data buffers there will be more
outstanding and you can get much faster speeds.

> Since sftp packets are up to 32 KB, and curl is using 16KB send buffer, the
> buffer always fits in one packet and the function always waits for
> acknowledgement before returning. So your transfer rate will never exceed 16
> KB / ping.

Yes, and I've actually explained this architecture issue on this list many
times before. SFTP is a rather particular protocol, and libssh2's API for it
isn't ideal which makes curl suffer. (I blogged about it once over here:
https://daniel.haxx.se/blog/2010/12/08/making-sftp-transfers-fast/)

> It seems relatively easy to change the procedure to get rid of this
> write-through semantics. Not sure if the project is still actively
> maintained though, its mailing list [2] looks very quiet.

It's active allright (as opposed to dead) but during periods not a lot of
things happen. Mostly just because of a lack of developers (and partly because
I can't really keep up being a good maintainer of it)...

> I didn't check curl with libssh backend, it may be worth a try.

It may! I haven't looked into the libssh SFTP specifics for a long time.
Hopefully they've solved these challenges better!

-- 
  / daniel.haxx.se

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2018-08-09