HP OpenVMS Systems

TCP/IP sequence number oddities?

» close window

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, 4.2.3.6  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
    segment.
 
 
  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.
 

  

     

     
answer written or last revised on ( 29-FEB-2000 )
     
» close window