How can I avoid tcp ports being left open, (& unavailable) under HP-UX 11?

[Daavid Turnbull]

On four occasions now I have observed one of our core applications terminating and leaving its socket "in use". Further attempt to open it return error 226 (address in use).

I have successfully used the method described in thread:

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0xbe06a22d6d27d5118fef0090279cd0f9,00.html

to free it up.


What I would really like to know is what causes the tcp/ip port to get blocked and more particularly what can be done to avoid this happening in the future?

The problem seems to occur when multiple users are using a socket on the same port for an extended period and over the network. Today's blockage probably occurred when I was retrieving data in Japan from the lab in Australia at the same time as somebody was also retrieving the data from Singapore.

Attached is the code fragment that handles the socket connection.

[Steven Gillard_2]

What state is the socket in after the application terminates? You can use netstat -an to find out.

Note that socket connections remain in the TIME_WAIT state for a period of time (4 minutes by default I think) after the socket has been closed. If you try to bind() to a port that still has TIME_WAIT sockets you will get the 'address already in use' error. After the 4 minutes pass things are ok again.

You can use the setsockopt() call with the SO_REUSEADDR option to force the application to bind to this port even though the TIME_WAIT sockets still exist.
This can be a little dangerous because it also allows you to bind to sockets that are still used by other processes in the LISTEN state.

Regards,
Steve

[Ron Kinner]

Echoing Steve's question but with a slight difference. Was the port stuck in FIN_WAIT_2? This indicates a problem on the other end. The other end owes you a final FIN packet and the default timeout on this is either 2 hours or eternity depending on your OS.

Winnt boxes are known to have a flaw in their tcp/ip code which closes their socket before the final FIN packet has been acknowledged. They send it and assume it has been received by the other end when they should retransmit it if they don't get an ack back. There is a fix for that but you have to beg MS support for it.

Ron

[Daavid Turnbull]

Yes the port stuck in FIN_WAIT_2.

Yes the boxes at the other end of the socket are Winnt.

I groped the MSDN Knowledge base and found the problem described in Q166186. They indicate that it is fixed in the latest US Service Packs for NT 3.51&4.0/Server and Workstation without the specifics. I have some more digging to do. The machine I suspect is the culprit is running NT 4.0 Server Sp4. The KB article is dated April 16, 2000

I am also responsible for the code at the Winnt end. The code at the Winnt end looks moderately clean but there is some potential for being a little more draconian in closing the socket following errors.

Thank-you for a well targeted response.

[Ron Kinner · Accepted solution]

That's the wrong Microsoft article.

Try:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;q254930

Expect you really should upgrade to SP6a before installing the patch. We installed it on our SP6a systems and it works fine. No idea what it will do on SP4.

Just call Microsoft support and explain that you have the problem from Q254930 before you give them your credit card number and they will email you the solution without charging you. I remember there was a password involved somewhere.

Ron