TCP Port becomes unusable

[Volker Halle]

Randy S.,

the most detailled information on TCPIP sockets you can probably get is from

SDA> tcpip sho dev/debug/full

When researching similar symptoms, I came across a discussion in:

http://forums.devx.com/showthread.php?t=37492

There is a concept of 'lingering' sockets, which stay around 'for some time'...

Don't know if this help, but I had not heard about that before.

Volker.

[Wim Van den Wyngaert]

In my notes I read that not REUSEADR will close the connection after about 2 minutes.

**
Q>How is a TCP connection terminated ?
--------------------------------------
Either side can send a FIN package. The one sending the FIN is doing the active
close. After the FIN, no more data can be sent. The other side can however
continue to send data (called half close). E.g. rsh will close the input
channel for the server when all commands are passed. The FIN must be acked.

If the 2nd FIN is not received by the active closer, the line will be broken
after 75 seconds of iddleness (most versions).

Q>What is 2MSL ?
----------------
When the "close connection" second FIN is received, an ACK is given and the
line closed. Before closing however, we must wait and see if the ACK arrived
well. Since there is no ACK for an ACK, the only thing that can happen is that
the FIN is sent again and we must ACK again. This continues until both sides
timeout. The timeout is after 2 times the MSL (about 2 minutes).

Only sockets that set the options "REUSEADR" don't bother about the 2MSL. All
known services use this option but many programs don't.
**

Wim

[Jon Pinkley · Accepted solution]

This thread from comp.os.vms discusses the same problem.

http://groups.google.com/group/comp.os.vms/browse_thread/thread/fa0e2ceafcae5c16/647cf29c9353d611?lnk=st&q=#647cf29c9353d611

If that link doesn't work, use a search for "Problem with UCX QIOW IO$_SETMODE Options".

It does seem to be to to a programming error, but more likely a programming error in the TCPIP stack than the application.

Here's the meat of the thread,

"The trick is that, with the QIO interface, you must not specify all
parameters in one call because it seems that they are processed in an
unsuitable sequence. The BG: driver processes them starting with p1, next
p2, p3 and so on, whatever was not passed as zero. This means that parameter
p3 which is used to bind the socket to a specific port is processed _before_
parameter p5 which is used to set socket options. Therefore, because the
UCX$_REUSEADDR option isn't yet set at the time parameter p3 is processed,
the binding fails with SS$_DUPLNAM."

I've also attached the complete response as a text file.

[Randy W. Suhrbier]

Thanks for the great information Jon! I have forwarded it to our vendor for comments. Based on the observed behavior I suspect they are combining the QIO's.

I feel that the problem of never being able to reuse the port is a TCPIP bug. Maybe changing the QIO's will allow us to avoid it.

Randy S.