Description: ------------ In the same php process, suppose I connect to a socket server on port A, and then init another object and connect to a server on port B. If I close the socket on port B before port A, I get this netstat behavior for port A during the run: tcp 0 0 localhost:9099 localhost:58275 ESTABLISHED tcp 0 0 localhost:58275 localhost:9099 ESTABLISHED tcp 0 0 localhost:9099 localhost:58275 CLOSE_WAIT tcp 0 0 localhost:58275 localhost:9099 FIN_WAIT2 tcp 0 0 localhost:58275 localhost:9099 TIME_WAIT But if I close the socket on port A before B, I get this netstat behavior for port A during the run: tcp 0 0 localhost:43684 localhost:9559 ESTABLISHED tcp 0 0 localhost:9559 localhost:43684 ESTABLISHED tcp 0 0 localhost:9099 localhost:49145 FIN_WAIT2 tcp 1 0 localhost:49145 localhost:9099 CLOSE_WAIT tcp 0 0 localhost:9099 localhost:49145 TIME_WAIT Note how things are flipped with these cases. I am not sure if this is an issue with net_socket, but I'm hoping that you all can help me figure out the solution, as the problem does present itself when using the net_socket package. The reason why this is an issue is b/c the 2nd scenario causes the system to be in a TIME_WAIT state on port A after closing the php process, and the 1st scenario doesn't. Being in a TIME_WAIT state means that a socket server cannot bind to that port (that is, unless the server has the reuse address flag set to true), so scenario 2 has to wait a few minutes for the TIME_WAIT to disappear while scenario 1 doesn't. All of this b/c I changed the order in which the sockets were disconnected. If each of these connections are independent (which, at first pass, I would think that they are), why would there be an order dependence on when they are destructed? Also, this happens for N socket connections on a single process. The only way to keep the TIME_WAIT state from happening is to close the sockets in the reverse order they were constructed. Thanks very much for any help/info you are willing to give for this issue, -Clayton

I wonder if the many extra socket_* calls in PR #16 (https://github.com/pear/Net_Socket/pull/16) might fix/mitigate this behavior...