Gnus development mailing list
 help / color / mirror / Atom feed
From: Greg Troxel <gdt@work.lexort.com>
To: Lars Magne Ingebrigtsen <larsi@gnus.org>
Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  ding@gnus.org
Subject: Re: [gnus git]  branch master updated: n0-17-27-g43f8466 =1= nntp.el (nntp-open-connection): Set TCP keepalive option.
Date: Tue, 10 May 2011 08:06:54 -0400	[thread overview]
Message-ID: <smuy62ehi8x.fsf@linuxpal.mit.edu> (raw)
In-Reply-To: <m3ei47pju5.fsf@quimbies.gnus.org> (Lars Magne Ingebrigtsen's message of "Tue, 10 May 2011 00:53:06 +0200")

[-- Attachment #1: Type: text/plain, Size: 2066 bytes --]


Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

>> +      (when (and (fboundp 'set-network-process-option)
>> +                 (eq (process-type process) 'network))
>> + ;; Use TCP-keepalive so that connections that pass through a NAT
>> router
>> +        ;; don't hang when left idle.
>> +        (set-network-process-option process :keepalive t))
>
> I don't necessarily disagree with this patch, but I'm wondering what the
> use case is.
>
> Keepalive is usually useful (on the client side) if you have a protocol
> where you're just sitting sleeping on a socket.  If the server dies,
> you'll never get a TCP RST, so the keepalive option will ensure you get
> that RST after a while.
>
> However, the NNTP protocol isn't like that.  You send a command and you
> get a response.  If you send a command to a server, and it doesn't
> recognise you because you've changed IP address or whatever, it'll send
> you a RST.

I've seen a misguided firewall  that breaks TCP connections after a
while, and seen it cause trouble with gnus/nntp.  Basically:

  gnus opens connection to server (across firewall)

  time passes
  
  gnus sends data on the tcp connection

  firewall drops the data

  nothing else happens until the tcp connection times out


In this particular case it's a firewall only, not NAT, but it's
basically the same issue.


> So the NNTP protocol doesn't seem like something that would need a
> TCP keepalive option.  But I might be misthinking the use case.

I think you're assuming that the sender will discover the brokenness
promptly.  In the absence of broken middleboxes, that might be true.
But then we wouldn't need keepalives at all.

> (And, besides, if nntp.el needs keepalive, doesn't all network
> connections need it?)

That is a fair point.

Another approach would be to have gnus have a timer so that it tears
down news connections after some period of inactivity, like perhaps
600s.  It seems that perhaps a gnus left idle for hours shouldn't have
any open connections.

[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]

  parent reply	other threads:[~2011-05-10 12:06 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <E1QJYrH-0001ys-1x@quimby.gnus.org>
2011-05-09 22:53 ` Lars Magne Ingebrigtsen
2011-05-10  1:01   ` Stefan Monnier
2011-05-10  1:07     ` Stefan Monnier
2011-05-30 20:14       ` Lars Magne Ingebrigtsen
2011-05-30 20:17     ` Lars Magne Ingebrigtsen
2011-05-10  5:30   ` David Engster
2011-05-10 13:46     ` Stefan Monnier
2011-05-10 14:19       ` David Engster
2011-05-11  8:57         ` David Engster
2011-05-11 17:59     ` David Engster
2011-05-10 12:06   ` Greg Troxel [this message]
2011-05-10 12:23     ` Antoine Levitt
2011-05-10 13:07       ` Richard Riley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=smuy62ehi8x.fsf@linuxpal.mit.edu \
    --to=gdt@work.lexort.com \
    --cc=ding@gnus.org \
    --cc=larsi@gnus.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).