Try to improve tls disconnect behavior where there are networking issues

This commit is contained in:
Richard Frith-Macdonald 2021-12-07 19:28:23 +00:00
parent 1c81bc1193
commit 40de7fa39a
3 changed files with 33 additions and 8 deletions

View file

@ -1,3 +1,11 @@
2021-12-07 Richard Frith-Macdonald <rfm@gnu.org>
* Source/GSTLS.m: (-disconnect:) try once if we are closing the TCP
connection, for up to 10 seconds if trying to keep it available.
* Source/NSFileHandle.m: (-sslDisconnect) operate in non-blocking
mode so that network issues should not cause a disconnect attempt
to hang. This should behave better on heavily loaded systems.
2021-11-23 Richard Frith-Macdonald <rfm@gnu.org>
* configure.ac: check for zlib before bfd

View file

@ -1592,26 +1592,36 @@ retrieve_callback(gnutls_session_t session,
if (YES == active || YES == handshake)
{
int result;
active = NO;
handshake = NO;
if (NO == reusable)
{
gnutls_bye(session, GNUTLS_SHUT_WR);
/* Since the connection is not reusable, we need only try once.
*/
result = gnutls_bye(session, GNUTLS_SHUT_WR);
}
else
{
int result;
NSTimeInterval start;
/* Attempting to do a clean shutdown on a reusable connection,
* so we keep retrying for a little while to let the other end
* close down cleanly.
*/
start = [NSDate timeIntervalSinceReferenceDate];
do
{
result = gnutls_bye(session, GNUTLS_SHUT_RDWR);
}
while (GNUTLS_E_AGAIN == result || GNUTLS_E_INTERRUPTED == result);
if (result < 0)
{
ok = NO;
}
while ((GNUTLS_E_AGAIN == result || GNUTLS_E_INTERRUPTED == result)
&& ([NSDate timeIntervalSinceReferenceDate] - start) < 10.0);
}
if (result < 0)
{
ok = NO;
}
}
if (YES == setup)
{

View file

@ -1034,7 +1034,14 @@ GSTLSHandlePush(gnutls_transport_ptr_t handle, const void *buffer, size_t len)
- (void) sslDisconnect
{
[self setNonBlocking: NO];
/* When disconnecting, since the TCP/IP connection is not going to be
* re-used, we can use non-blocking I/O and abandon the cleanup in the
* TLS layer if the I/O cannot complete immediately.
* We don't want to block because a network issue (or a failure at the
* remote end) could tie up this thread until the 5 minute TCP/IP
* keepalive expires.
*/
[self setNonBlocking: YES];
[session disconnect: NO];
}