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.