bug#22789: 25.1.50; In last master build https connections stop working

[Alain Schneble]

Eli Zaretskii <eliz@gnu.org> writes:

> I already tried increasing the limit, it doesn't help: the new limit
> is reached.  Interestingly, when the initial connection is made, for
> the page itself, the handshake completes within 10 attempts.  But the
> subsequent connections, presumably for images, don't succeed, for some
> reason.

Yes that's what I observed as well.  But also that GnuTLS returns -10
GNUTLS_E_INVALID_SESSION for some of the connections quite early.

Interestingly, I had the impression that it behaves better if the
subsequent handshakes are triggered only after the socket is connected.
But that may be by chance.  And could therefore be a red herring.

See patch:

>From 565ac4ce483faf65f2005b23bf806fff636f5cb1 Mon Sep 17 00:00:00 2001
From: Alain Schneble <a.s@realize.ch>
Date: Mon, 29 Feb 2016 23:37:41 +0100
Subject: [PATCH] Optimize GnuTLS handshake on async sockets

* src/process.c (wait_reading_process_output): start retrying GnuTLS
handshake only after async socket has properly connected.
---
 src/process.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/process.c b/src/process.c
index 85a4885..8aad8d3 100644
--- a/src/process.c
+++ b/src/process.c
@@ -4940,7 +4940,8 @@ wait_reading_process_output (intmax_t time_limit, int 
nsecs, int read_kbd,
 #ifdef HAVE_GNUTLS
                /* Continue TLS negotiation. */
                if (p->gnutls_initstage == GNUTLS_STAGE_HANDSHAKE_TRIED
-                   && p->is_non_blocking_client)
+                   && p->is_non_blocking_client
+                   && (fd_info[p->infd].flags & FILE_CONNECT) == 0)
                  {
                    gnutls_try_handshake (p);
                    p->gnutls_handshakes_tried++;
-- 
2.6.2.windows.1

>> But the point I tried to address is the following: /When/ shall we start
>> with the handshake "series" and start counting the number of tries (or
>> stopwatch)?  Don't you agree that with async sockets, it doesn't make
>> much sense to start it before the socket is connected?  So we could just
>> postpone it until then...  Otherwise, the number of handshake tries (or
>> time elapsed) durnig the "socket not yet connected" are subtracted from
>> the max number of tries (or timeout) granted.  Which I think is, well,
>> at least imprecise...
>
> I think we are looking in the wrong direction.  We need first to
> understand why the connection(s) to download the images don't work.
> Does anyone already have an idea why this happens?  If so, please
> describe that.

I must admit that I have holes in my mental model, and I'm still
observing flows at runtime which seem strange to me.  So yes, it may be
the wrong direction regarding the /issue/.  But I was not only referring
to the issue, but also to an optimization of the new async paths...

> There is also some disturbing signs in retrying GnuTLS handshake from
> wait_reading_process_output -- I'm not sure the way that function
> works, at least on Windows, is according to you expectations.  The
> while loop there doesn't really spin all the time, did you know that?
> Can you describe what you think should happen there for a connection
> whose GnuTLS handshake is not yet complete?

Hmm.  What I observed is that it stops if the Emacs window looses its
focus (and no other window messages are dispatched to the window).  If
it has focus, it gets called at least once per second.