From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 1680 invoked from network); 30 Apr 2020 17:35:11 -0000 Received: from lists1.math.uh.edu (129.7.128.208) by inbox.vuxu.org with ESMTPUTF8; 30 Apr 2020 17:35:11 -0000 Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by lists1.math.uh.edu with smtp (Exim 4.92.3) (envelope-from ) id 1jUD4t-0001TV-5S; Thu, 30 Apr 2020 12:34:27 -0500 Received: from mx1.math.uh.edu ([129.7.128.32]) by lists1.math.uh.edu with esmtps (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jUD4o-0001Qg-QK for ding@lists.math.uh.edu; Thu, 30 Apr 2020 12:34:22 -0500 Received: from quimby.gnus.org ([95.216.78.240]) by mx1.math.uh.edu with esmtps (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jUD4n-0002Cz-CY for ding@lists.math.uh.edu; Thu, 30 Apr 2020 12:34:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :In-Reply-To:Date:References:Subject:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=4skLoDOsxhL/4Oj1Aw3Ip0PoUe9O3hKkQxee2oivong=; b=XUdiThBmBODCuogTmlgP+Fsh/W CKIJfS/oNaJqCIKMr11T1NWtbZSOpGCRYRnmnAiWC6LaOXEicVApOlX/hD42HenSokbCsBARMZ+n9 eLG79UH+dzu3U/lSnlF/r4K5HYB0AQGwqlwXwFH5N7GwrI5Uf9T8/sb5Udbhj0tCpjPQ=; Received: from ericabrahamsen.net ([52.70.2.18] helo=mail.ericabrahamsen.net) by quimby.gnus.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jUD4c-0005dC-0E; Thu, 30 Apr 2020 19:34:16 +0200 Received: from localhost (c-73-254-86-141.hsd1.wa.comcast.net [73.254.86.141]) (Authenticated sender: eric@ericabrahamsen.net) by mail.ericabrahamsen.net (Postfix) with ESMTPSA id 16B68FA028; Thu, 30 Apr 2020 17:34:06 +0000 (UTC) From: Eric Abrahamsen To: Lars Ingebrigtsen Cc: Robert Pluim , Christian Barthel , ding@gnus.org Subject: Re: new wifi connection = nntp timeout = Emacs restart? References: <87sgh3coxn.fsf@ericabrahamsen.net> <87o8rogew7.fsf@barthel.ch> <87zhb7mlf0.fsf@ericabrahamsen.net> <87a72t35ng.fsf@gnus.org> Date: Thu, 30 Apr 2020 10:34:05 -0700 In-Reply-To: <87a72t35ng.fsf@gnus.org> (Lars Ingebrigtsen's message of "Thu, 30 Apr 2020 07:26:59 +0200") Message-ID: <87wo5wev3m.fsf@ericabrahamsen.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-ID: Precedence: bulk Lars Ingebrigtsen writes: > Robert Pluim writes: > >> I see this too. Every time I try to look at it, it=CA=BCs an issue >> somewhere deep in Emacs' networking code where it=CA=BCs trying to read >> from the network and failing, but not failing enough that it gets an >> error or a timeout. And then Real Life=E2=84=A2 intervenes and I *have* = to get >> Gnus working again. > > Yeah, it's a really annoying problem, and unfortunately there is no > general solution we can use. Sometimes network connections just "go > away", and when you try to use a long-lived connection, you just don't > get a response back. Thanks for this background! Later I opened bug#40748, and in doing so discovered that the actual problem was in the DNS lookup: (error "news.gmane.io/nntp Temporary failure in name resol...") Or at least, it was being reported as such. Does that change your assessment at all? Or is it what you'd expect? > This is commonly due to wifi (IP changes or not), but I've also > experienced it with some horrible routers. > > The problem is that there is no one-solution-fits-all for all the > network protocols that Emacs supports. > > IRC has this solved -- they use keepalive packets, and if Emacs doesn't > get one from the server, it reconnects. Easy peasy. > > NNTP and IMAP doesn't have anything like that, so nntp.el and nnimap.el > should be clever and reconnect if we send a command and get no response > back. > > However -- I've seen IMAP servers that take half a minute to give a > response to a simple RESYNC command. (Rearranging its index server > side, I think it was.) > > So you can't just put a 1-second timeout on all commands, either. > > But I've been pondering whether it would make sense for IMAP to always > send an NOOP command before any other commands, because IMAP is a > streaming protocol. > > So instead of > > 1 QRESYNC foo > > we'd send > > 1 NOOP > 2 QRESYNC foo > > and if we don't get a response to the NOOP within a very short time > (even if the QRESYNC takes a long time), then we know that something is > wrong and we should reconnect. > > NNTP has no such a thing, I think...