From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alain Schneble Newsgroups: gmane.emacs.bugs Subject: bug#22789: 25.1.50; In last master build https connections stop working Date: Tue, 1 Mar 2016 00:13:04 +0100 Message-ID: <86povfnm9r.fsf@realize.ch> References: <864mcyo14y.fsf@Lenovo-PC.i-did-not-set--mail-host-address--so-tickle-me> <87d1rmxl65.fsf@gnus.org> <86povm6qeu.wl-j_l_domenech@yahoo.com> <83k2lugeym.fsf@gnu.org> <871t81wtyt.fsf@gnus.org> <87r3g1veqc.fsf@gnus.org> <86si0euizj.fsf@realize.ch> <871t7xhj7t.fsf@gnus.org> <86oab1vjm9.fsf@realize.ch> <86d1rhpvcq.fsf@realize.ch> <834mctbitq.fsf@gnu.org> <868u25p3m2.fsf@realize.ch> <83io18ahya.fsf@gnu.org> <86y4a3on6f.fsf@realize.ch> <87oaazg7fv.fsf@gnus.org> <86twkro0vr.fsf@realize.ch> <83d1rf8ifj.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Trace: ger.gmane.org 1456787720 25553 80.91.229.3 (29 Feb 2016 23:15:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 29 Feb 2016 23:15:20 +0000 (UTC) Cc: larsi@gnus.org, j_l_domenech@yahoo.com, 22789@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Mar 01 00:15:10 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aaX1y-0005p0-EN for geb-bug-gnu-emacs@m.gmane.org; Tue, 01 Mar 2016 00:15:10 +0100 Original-Received: from localhost ([::1]:39604 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aaX1x-00086l-Sc for geb-bug-gnu-emacs@m.gmane.org; Mon, 29 Feb 2016 18:15:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43441) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aaX1u-00084I-7h for bug-gnu-emacs@gnu.org; Mon, 29 Feb 2016 18:15:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aaX1q-0004yl-8E for bug-gnu-emacs@gnu.org; Mon, 29 Feb 2016 18:15:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:57155) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aaX1q-0004yU-4Y for bug-gnu-emacs@gnu.org; Mon, 29 Feb 2016 18:15:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aaX1p-0003L2-VB for bug-gnu-emacs@gnu.org; Mon, 29 Feb 2016 18:15:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alain Schneble Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 29 Feb 2016 23:15:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 22789-submit@debbugs.gnu.org id=B22789.145678765712764 (code B ref 22789); Mon, 29 Feb 2016 23:15:01 +0000 Original-Received: (at 22789) by debbugs.gnu.org; 29 Feb 2016 23:14:17 +0000 Original-Received: from localhost ([127.0.0.1]:54282 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aaX17-0003Jn-Ab for submit@debbugs.gnu.org; Mon, 29 Feb 2016 18:14:17 -0500 Original-Received: from clientmail.realize.ch ([46.140.89.53]:3676) by debbugs.gnu.org with smtp (Exim 4.84) (envelope-from ) id 1aaX14-0003JY-LO for 22789@debbugs.gnu.org; Mon, 29 Feb 2016 18:14:15 -0500 Original-Received: from rintintin.hq.realize.ch.lan.rit ([192.168.0.105]) by clientmail.realize.ch ; Tue, 1 Mar 2016 00:13:41 +0100 Original-Received: from MYNGB (192.168.250.224) by rintintin.hq.realize.ch.lan.rit (192.168.0.105) with Microsoft SMTP Server (TLS) id 15.0.516.32; Tue, 1 Mar 2016 00:13:11 +0100 In-Reply-To: <83d1rf8ifj.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 29 Feb 2016 20:45:04 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (windows-nt) X-ClientProxiedBy: rintintin.hq.realize.ch.lan.rit (192.168.0.105) To rintintin.hq.realize.ch.lan.rit (192.168.0.105) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:114178 Archived-At: --=-=-= Content-Type: text/plain Eli Zaretskii 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: --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename="0001-Optimize-GnuTLS-handshake-on-async-sockets.patch" Content-Description: Patch >From 565ac4ce483faf65f2005b23bf806fff636f5cb1 Mon Sep 17 00:00:00 2001 From: Alain Schneble 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 --=-=-= Content-Type: text/plain >> 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. --=-=-=--