www.libssh2.org | Daily snapshots | Mailing list archive | Docs | Examples | github

Archive Index This month's Index

Subject: Re: libssh2_sftp_write blocks for about 3 minutes

Re: libssh2_sftp_write blocks for about 3 minutes

From: Will Cosgrove via libssh2-devel <libssh2-devel_at_cool.haxx.se>
Date: Fri, 24 Nov 2017 09:18:20 -0800

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

the libssh2 team