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.Zimmermann_at_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 <peter_at_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
Received on 2017-11-24