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 2301 invoked from network); 30 Apr 2020 17:39:08 -0000 Received: from lists1.math.uh.edu (129.7.128.208) by inbox.vuxu.org with ESMTPUTF8; 30 Apr 2020 17:39:08 -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 1jUD9M-0001Zi-72; Thu, 30 Apr 2020 12:39:04 -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 1jUD9J-0001Wy-9F for ding@lists.math.uh.edu; Thu, 30 Apr 2020 12:39:01 -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 1jUD9H-0002Eu-Tr for ding@lists.math.uh.edu; Thu, 30 Apr 2020 12:39:01 -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=obvQf9IYWmP82MuGpFfNFXrf5UT0lAqKNUCBydISCms=; b=cpq5dBXuOYSmbhrxxU2Jx9HZ69 1dHEcJAaASDoIS7HT/gLgX8MB8mHRqgaOC1O4mbaGtNbwJLmkV+5umk9FcUiyeAh4SXfJp4TNYzsI Wb0DnZ4EGLIyJ2nUT96SX/e4eh1p8OEo/Wq3Eh1e8Y9su2P5seUFeNE4ravkGu5gSx7g=; 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 1jUD9B-0005fM-HF; Thu, 30 Apr 2020 19:38:55 +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 56F85FA028; Thu, 30 Apr 2020 17:38:50 +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:38:48 -0700 In-Reply-To: <87a72t35ng.fsf@gnus.org> (Lars Ingebrigtsen's message of "Thu, 30 Apr 2020 07:26:59 +0200") Message-ID: <87sggkeuvr.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. > > 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 I suppose this could also be sent every ten minutes or so on an idle timer, quietly closing the imap connection if we don't get a response. Ie faking a keepalive. That could ultimately reduce network traffic, right?