From: knitti (knittigmail.com)
Date: Wed Dec 12 2007 - 15:42:23 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On 12/12/07, Daniel Ouellet <danielpresscom.net> wrote:
> net.inet.tcp.keepidle
> net.inet.tcp.keepinittime
> net.inet.tcp.keepintvl
> net.inet.tcp.rstppslimit
> net.inet.tcp.synbucketlimit
> net.inet.tcp.syncachelimit

nope, shoudn't apply, unless my TCP knowledge is wrong or there
is a bug, which makes it affecting it unintentional

> >> My point with PF here was that it would reduce the possible numbers of
> >> close_wait state you could possibly see in the first place, witch is one
> >> of the original goal of the question.
> >
> > Why?
>
> OK, I could be wrong and I am sure someone with a huge stick will hit me
> with it if I say something stupid, and/or there might be something I am
> overlooking or not understanding fully, witch is sure possible as well. (;>
>
> But if httpd received a fake connection that do not do the full
> handshake, isn't it there a socket open and/or use by httpd for that
> fake connection anyway. Meaning it tries to communicate with that fake
> source and can't and eventually will close and (that's where may be I am
> failing here) will end up in close_wait may be?

no fake connections involved, CLOSE_WAIT is a state _after_ having a
fully established connection

> Or, are you saying that the ONLY possible way a socket end up in
> close_wait state is ONLY when and ONLY possible if it was fully open
> properly in the first place? If so, then I stand corrected and I was/am
> wrong about that part of my suggestions. So, is it the case then?

Yes. Random example:
http://www4.informatik.uni-erlangen.de/Projects/JX/Projects/TCP/tcpstate.html

--knitti

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]