Jim Hofmeister wrote:
> Re: Connection Assurance Timeout w/telnet server.
>
> The Fix/Enhancement is in for telnet connections to timeout when a TCP
> connection is broken - in the same manor NS-VT connections are dropped
> when a PC is powered down as an example.

Hmmm... so the connection assurance (a.k.a. TCP keepalive) protocol is
specific to individual services?  (Light bulb appears over my head)...

> This fix follows the standard approach of using the configured CA
> Timeout in NMMGR:
>
> Path:  NETXPORT.GPROT.TCP
> [600  ]   Connection Assurance Interval (Secs)
> [4  ]     Maximum Connection Assurance Retransmissions
>
> With the above default configuration, a session logon will drop in 40
> minutes if the TCP connection is not responsive.

If I recall correctly, if the above scenario happens on a NS/VT session
it causes a logoff and a VT error 42 (Recall recent and past discussion
of mysterious VTERRs aborting sessions).

Then there were the cases of long FTP sessions aborting...

Then we have the Image/SQL notes about lowering the timeout value to,
say, 60 seconds so that hung ODBC sessions (possibly holding locks)
timeout within a reasonable period of time.  This makes the timers more
sensitive.

If you are on a busy network, particularly across one or more routers,
switches, or bridges; it is possible for the keepalive packet to be
"dropped" by the router/switch/bridge.

If things "work as designed" it takes <max-retransmissions> consecutive
failures to abort a connection.  I wonder if the "retransmit counter" is
really being reset after a successful keepalive request?  It would
explain a lot of curious network problems I've experienced or heard
about over the years specific to MPE.

Jeff Kell <[log in to unmask]>