NAT timeouts driving me crazy
Andrew Nesbit
minutes), I cannot adjust.
So when my nntp and nnimap connections time out, everything just
hangs. C-g C-g successfully cancels the requested operation; then I
go to the server buffer, close all servers (an operation which also
must be prodded with C-g C-g), and then reopen them. Having to do
this many times a day became tiresome pretty quickly. It also
concerns me a little that all these abnormally dropped connections
could cause some loss of data or marks.
(BTW, just how robust is Gnus when it comes to protecting the
integrity of the user's mail and other data, e.g. marks, cache?)
So I did a bit of a search on Google, and I found a suggestion by Kai
suggesting to adjust the Gnus source to check how long a connection
has been idle whenever for whenever traffic is to go out over that
connection, and close and reopen if necessary. Sounds like a good
idea, except that I'm not proficient enough with Elisp to implement
this, although I hope to delve into it in detail over the next couple
of months.
Therefore, I'm hoping that somebody else has been able to work around
this problem (in any way), and if so, could they please let me know.
Thanks.
Andrew.
Ted Zlatanov
> So when my nntp and nnimap connections time out, everything just
> hangs. C-g C-g successfully cancels the requested operation; then I
> go to the server buffer, close all servers (an operation which also
> must be prodded with C-g C-g), and then reopen them. Having to do
> this many times a day became tiresome pretty quickly. It also
> concerns me a little that all these abnormally dropped connections
> could cause some loss of data or marks.
This seems like a good use for the asynchronous IMAP group article
counts update code that Simon Josefsson said might be a good idea
(translation: we'd all like it, but it's a lot of work :) Basically
Gnus through nnimap would refresh the article counts in the
background instead of synchronously on 'g'. While we can work around
your specific problem as you described, I think the asynchronous code
would be much better as a general solution.
> (BTW, just how robust is Gnus when it comes to protecting the
> integrity of the user's mail and other data, e.g. marks, cache?)
Not at all AFAIK. You can set up an encrypted filesystem, though (at
least Linux supports it). I tried it and the speed was terrible, but
it works.
Ted
Andrew Nesbit
> On Wed, 01 Oct 2003, alne...@optushome.com.au wrote:
>
>> So when my nntp and nnimap connections time out, everything just
>> hangs.
[snip]
> This seems like a good use for the asynchronous IMAP group article
> counts update code that Simon Josefsson said might be a good idea
> (translation: we'd all like it, but it's a lot of work :) Basically
> Gnus through nnimap would refresh the article counts in the
> background instead of synchronously on 'g'. While we can work around
> your specific problem as you described, I think the asynchronous code
> would be much better as a general solution.
Something like this really would be wonderful. But would it solve the
problem of NAT timeouts in general, i.e., for (non-nnimap) backends
that keep persistent connections open been which may be inactive for a
while?
Andrew.
Ted Zlatanov
The code should be generic - that is, it wouldn't be imap.el that
updated the article counts, but Gnus that told each active backend "go
update the article counts in the background". I am pretty sure
that's the better approach. Each backend can then provide the update
function if it wants to.
Given such an implementation, Gnus would help your NAT timeouts, but
of course in a roundabout way that may not work all the time. It's
just not easy to affect NAT timeouts from user software, the best it
can do is generate traffic on that connection.
Ted