On 12/12/07, Daniel Ouellet <[EMAIL PROTECTED]> 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
