lkml.org 
[lkml]   [2004]   [Jul]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: The dreadful CLOSE_WAIT
    Hi Markus :)

* Markus Schaber <schabios@logi-track.com> dixit:
> > I know, that's the only 'harm' a CLOSE_WAIT timeout will have,
> > but anyway I don't see any point in having a permanent CLOSE_WAIT
> > state. The other end is not there, it has sent us a FIN.
> Yes, but it may still want to read.

I know, now I understand.

> > Well, it may be an idea ;) Anyway if you have, let's say, a
> > maximum of 10 connections in your server, and I do 10 wget+C-c, you
> > no longer have a running server. The kernel should not allow that. A
> > timeout of 3600 seconds seems very reasonable, or somethink like
> > that, am I wrong?
> Well, when the other side is really dead, then connection keepalive
> should detect that (when enabled), by either timeout or getting a reset
> packet.

But this must be enabled in the application, am I wrong? using
SO_KEEPALIVE. Can it be enabled using sysctl or the like.

Thanks for the information. When I saw the transitions, I thought
that the server got the FIN after the client died, but obviously it
can get it when the client doesn a half-close, and I didn't think of
it. Thanks, Markus :)

Now, is there any sysctl that enables a keepalive for this kind
of connections (dead remote end, local in CLOSE_WAIT) for all
connections?

Raúl Núñez de Arenas Coronado

--
Linux Registered User 88736
http://www.pleyades.net & http://raul.pleyades.net/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:04    [W:0.058 / U:0.444 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site