title: Is a FIN_WAIT2 state ever due to a close-connection initiator?
body: <p>I'm doing a bit of POSIX socket programming and am running into a problem. I've wrote an application that uses nonblocking sockets. Because I'm currently developing a client against a server that is in develop, bad application level messages occasionally get sent. When this happens, my only way to recover is to completely re-establish a connection to force the communication to a known state.</p>
  
  <p>I reset the connection by issuing a POSIX "close()" on the non-blocking socket. I then request a new a socket and re-establish connection.</p>
  
  <p>However, one thing I've discovered is that all of resets lead to a "FIN_WAIT2" on the old connections. When running a netstat command, there are a ton of FIN_WAIT2 that have no PIDs associated with them (I guess these are considered orphaned and could try a kernel connection timeout?).</p>
  
  <p>Anyways, I'm curious why all of these old connections are stacking up in the netstat. I've done a bit of reading up on TCP states, and it seems that the FIN_WAIT2 I'm seeing is due to the server (i.e. not the closing initiator in my case) isn't responding with a message that it successfully closed. Why is this?</p>
  
  <p>Is a FIN_WAIT2 typically associated with a bug in the non-close initiator side? Or is it possible that I'm doing something in my application that prevents the FIN message from being received? Does the fact I'm using non-blocking sockets have anything to do with it?</p>