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

[Lars Ingebrigtsen <larsi@gnus.org>]

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

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...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no