Kris Jurka <books@ejurka.com> writes:
> I'm not much of an expert on TCP, so could you give me a little more
> background on this? I've duplicated the behavior you describe and I
> believe your fix is correct, but I'd like to understand this better.
> First why is this a problem, the CLOSE_WAIT entries disappear rather
> quickly. Second the number of CLOSE_WAIT items is nothing compared to the
> number of TIME_WAIT entries, why aren't they a problem?
I think CLOSE_WAIT means that the kernel knows the far end has closed
the connection, but it's not yet been able to tell the local client so
(the vice-versa case may be called this too, not sure). This state can
persist indefinitely if the client is uncooperative. TIME_WAIT is a
short-lived state; the connection will be forgotten completely after the
timeout, which I think is order-of-a-minute. (TIME_WAIT exists only so
that the kernel remembers what to do with any delayed packets that may
arrive from the far end.)
Bottom line is that CLOSE_WAIT means that a client bug is keeping the
kernel from freeing resources. You don't want to see that.
regards, tom lane