You should be getting a sigpipe signal (if you register for it) once the OS determines the socket has been broken. However, that will likely come after the timeout.
There is no way I know of at the socket level to determine if the user physically unplugs a connection before a timeout. Some client OS' will notify you if this happens, but that would be above where libssh2 works. If I unplug my cable on macOS select() will wait using 0% CPU. So this behavior you're seeing likely requires tuning on your specific OS as Peter mentioned. Will > On Nov 24, 2017, at 5:11 AM, Jerome Zimmermann > <jerome.zimmerm...@ipetronik.com> wrote: > > Hello again, > >> Examining the return value of select() reveals that the socket is always >> ready for reading or writing even when the physical connection is no longer >> available. >> Further, I verified the socket state with getsockopt() and connect(). >> But the socket is always in the "connect"-state. > > In the case when the physical cable is removed the application (client) does > no > longer get an acknowledged for the transmitted data packets (from the server). > > 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 ? > >> The libssh2 remains in the libssh2_sftp_write function. >> More precise, the second do while loop of the BLOCK_ADJUST macro. >> Here, function libssh2_wait_socket always returns 0. > > I have the possibility to reduce this "blocking" time with > function libssh2_session_set_timeout as with the retransmission timeout > from the operating system. > >> Is there a way to identify such a "broken connection" to break >> earlier the loop and so avoid a CPU load of 100% ? > > However, the problem with the high CPU load of 100% still remains. > > Is it possible to handle this issue in the libssh2 ? > > Best regards > Jerome > > > Impressum/Imprint: https://www.ipetronik.com/impressum > > > >>>> Peter Stuge <pe...@stuge.se> 21.11.2017 14:17 >>> > Jerome Zimmermann wrote: >> the socket is always ready for reading or writing even when the >> physical connection is no longer available. > > That's a good find, it's the key point. > > >> Is there a way to identify such a "broken connection" to break >> earlier the loop and so avoid a CPU load of 100% ? > > There probably is, but not in the application. This is a TCP stack > tunable, so you have to study what your operating system allows you > to configure. > > > //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 _______________________________________________ libssh2-devel https://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
