On Wed, May 05, 2010 at 03:12:00PM -0500, Nicolas Williams wrote:
> On Wed, May 05, 2010 at 01:05:57PM -0700, Garrett D'Amore wrote:
> > >>>What happens when a socket in FIN_WAIT2 is close()d, or a process exits
> > >>>and a socket is closed and ends up in FIN_WAIT2? If the FIN_WAIT2 timer
> > >>>is set to 2^31, what happens?
> > >>
> > >>making it clearer than I was able to do.
> > >Note: that's the only issue I can imagine. The other timers' being
> > >configurable obviously create no such problems.
> >
> > Ok, I confess that the plethora of TCP related timer values are not
> > something I have good familiarity with -- my concern was that
> > resources associated with a socket would outlive the handle by which
> > they were accounted (the associated open file).
>
> The FIN-WAIT-2 timer is the only one that could, because it's the only
> one that relates to lingering resources (or TCP connection states where
> a socket/pcb could remotely linger). It may be the case that the socket
> wouldn't linger without the process lingering, but I don't know that.
A bit of reasearch indicates that this is a protential problem, at least
on Linux land, and almost certainly on Solaris land as well. Linux has
two tunables related to the FIN-WAIT-2 state:
"
tcp_fin_timeout [like the one proposed here -Nico]
Time to hold socket in state FIN-WAIT-2, if it was closed by our
side. Peer can be broken and never close its side, or even died
unexpectedly. Default value is 60sec. Usual value used in 2.2 was
180 seconds, you may restore it, but remember that if your machine
is even underloaded WEB server, you risk to overflow memory with
kilotons of dead sockets, FIN-WAIT-2 sockets are less dangerous than
FIN-WAIT-1, because they eat maximum 1.5K of memory, but they tend
to live longer. Cf. tcp_max_orphans.
"
and
"
tcp_max_orphans [max number of sockets lingering in FIN-WAIT-* -Nico]
Maximal number of TCP sockets not attached to any user file handle,
held by system. If this number is exceeded orphaned connections are
reset immediately and warning is printed. This limit exists only to
prevent simple DoS attacks, you _must_ not rely on this or lower the
limit artificially, but rather increase it (probably, after
increasing installed memory), if network conditions require more
than default value, and tune network services to linger and kill
such states more aggressively. Let me remind you again: each orphan
eats up to 64K of unswappable memory.
"
Sounds like we might want an equivalent to tcp_max_orphans... Also,
allowing the FIN-WAIT-2 timer to get set to ridiculously large numbers
of seconds strikes me as a bad idea, at least without a tcp_max_orphans.
Nico
--
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org
