From: Pan K via libssh2-devel <libssh2-devel_at_cool.haxx.se>
Date: Tue, 05 Dec 2017 16:29:15 +0000

Since the undesirable behaviour is the high CPU usage when the socket is not available, would not running the SFTP transfer in non-blocking mode help?

The high CPU usage is from looping on socket read without any kind of wait, effectively using 100% of a CPU constantly trying to read from a dead socket.

In blocking mode, the read loop is in libssh2 like you mentioned but in non-blocking mode it is application controlled, so you can add your own sleeps (or use an event loop and co-operative sockets) to avoid it.

25.11.2017, 01:32, "Peter Stuge" <peter@stuge.se>:

Jerome Zimmermann wrote:
Subsequently, TCP Retransmission packets are sent.
The used operating systems tries this for three minutes.
When this time is elapsed the TCP socket connection is closed.
So, the TCP socket is during this three minutes in the connection state,
although there is no physical connection.

I am not an TCP/IP expert, but is there in general a way to
identify such a situation ?

"in general" doesn't fit so well in that sentence.

Most OSes (even Windows! :) allows the TCP stack to be tuned, but
there is no portable API to do so. You are on your own.

It is worth considering here, that libssh2 does not create the
socket, but you do, before you pass the socket to libssh2.

This means that you have a good opportunity to tune the socket as
desired, before you pass it to libssh2.

But also keep in mind, that if you tune the TCP stack to be too
aggressive, your connection will also be torn down by random
intermittent network issues possibly far outside your control.

//Peter
_______________________________________________
libssh2-devel https://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel

_______________________________________________
libssh2-devel https://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2017-12-05

Re: libssh2_sftp_write blocks for about 3 minutes