Re: new wifi connection = nntp timeout = Emacs restart?

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Robert Pluim <rpluim@gmail.com> writes:
>
>> I see this too. Every time I try to look at it, itʼs an issue
>> somewhere deep in Emacs' networking code where itʼs trying to read
>> from the network and failing, but not failing enough that it gets an
>> error or a timeout. And then Real Life™ 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?