The Question is:
Running UCX v4.2 ECO2. We have a problem where client PCs are connecting to
DMQ via TCPIP. They sporadically disconnect..
Sniffer analysis shows that the Alpha, in the middle of an established
connection, will have correct sequence and acknowledgement numbers, and a
couple of frames later, has decremented both numbers by one. The PC doesn't
respond to this and locks..
Is there ever a valid reason why TCP SEQ and ACK numbers should decrement ?
If so, is there an RFC reference that I can see...
It seems to me that this is a bug with UCX.. Thanks
The Answer is :
Whose TCP implementation is running on the PCs? Microsoft's?
The best RFC reference the OpenVMS Wizard is aware of is in RFC 1122.
Search for the string "Keep-alive", but do remember that this RFC is
a little dated.
RFC1122, 18.104.22.168 TCP Keep-Alives
Some TCP implementations, however, have included a
keep-alive mechanism. To confirm that an idle
connection is still active, these implementations send
a probe segment designed to elicit a response from the
peer TCP. Such a segment generally contains SEG.SEQ =
SND.NXT-1 and may or may not contain one garbage octet
of data. Note that on a quiet connection SND.NXT =
RCV.NXT, so that this SEG.SEQ will be outside the
window. Therefore, the probe causes the receiver to
return an acknowledgment segment, confirming that the
connection is still live. If the peer has dropped the
connection due to a network partition or a crash, it
will respond with a RST instead of an acknowledgment
Upgrading to TCP/IP Services V5.0 would give you more options. Also,
remember that you could always just disable keepalive, presuming you
have control over the application.