George > http://support.attachmate.com/techdocs/2353.html
This is my analysis of the Attachmate web page - with corrections - and the mechanisms to which it refers are described in footnotes: <précis> - It introduces the so-called "keepalive" idea both at the TCP level[1] and the application (TN3270) level[2]. - It mentions that both the server *and* the client side can operate the "keepalive" function. <comment> The web page fails to expand on mentioning that "both the server *and* the client side can operate the "keepalive" function" by stating that both the server *and* the client side will need to operate the "keepalive" function for the purposes of flushing one end of a TCP connection out of the supporting system and freeing resources, the client side in order to flush out the TCP connection on the client side and the server side in order to flush out the TCP connection on the server side when the TCP connection is broken. The web page fails to mention that the "keepalive" function truly justifies its name only when there are firewalls present. Another clarification not at all addressed in the web page is the following: - When the mechanism operates at the level of TCP (the more "official" "keepalive") and a failure needs to be assumed, TCP logic clearly can go through the processing necessary to flush the control blocks supporting the connection instance. It then presents the application with an error code through the relevant socket, typically an outstanding "receive"-like call, or it stimulates the application to issue a "receive"-like call so that the error can be presented. ETIMEDOUT is a possible error code. - When the mechanism operates at the level of the application (the less "official" "keepalive") and a failure needs to be assumed, the application simply issues a close() call on the affected socket. TCP will then resolve the situation according to its usual procedures which can involve giving up on an unresponsive peer. </comment> - As noted in the first point, and in the comments above, the web page emphasises the possibility to operate a "keepalive" mechanism at the level of TCP or the application, TN3270 in this case. -- It is noted that the z/OS Communications Server IP TN3270E server program can invoke a mechanism to check that the TN3270 client continues to be able to communicate. This is purely a TN3270 protocol. It is stated that there is *no* equivalent mechanism in the Attachmate implementation. -- It is now noted that the z/OS Communications Server IP component provides the formal TCP protocol "keepalive" function and that, presumably, all the flavours of Windows on which the Attachmate would be expected to run these days - 2000, XP and Vista (no 7!) judging from the Microsoft "knowledge base" references, also provide the formal TCP protocol "keepalive" function. - Given that the TN3270E server has its own means to operate an equivalent of the "keepalive" function, the TN3270E program does not cause the TCP "keepalive" mechanism to operate, bearing in mind that, for a "keepalive" function to be used for the TCP connections associated with a particular application, a sockets API call must be used. - Since there is no equivalent of the "keepalive" function provided by the Attachmate application logic, it is necessary to cause the Windows TCP "keepalive" to be invoked. <comment> The so-called "keepalive" function performs two functions these days: 1. It flushes out TCP - and application - control blocks associated with a TCP connection which is no longer viable. - In order to be effective in the server, the server must operate the mechanism. - In order to be effective in the client, the client must operate the mechanism. In other words the two ends of the TCP connection need to operate independently to deal with the case where there has been a failure in the IP network. 2. It satisfies the traffic frequency monitoring of a firewall. In order to be effective for the whole TCP connection, it is necessary *only* that either the server *or* the client operate the mechanism. Obviously either end of the TCP connection can provide the necessary traffic even if it is only "dummy" traffic. Thus, for example, if is needed only to perform function 2, this task can be performed using the mechanism associated with the TIMEMARK statement with a suitable value assigned to the SCANINTERVAL statement. </comment> - The rest of the web page explains how to invoke the Windows "keepalive" function - and what parameter values to set in order to define how it operates. - Change KeepAlive=No to KeepAlive=Yes in the [Connections] section of the Attachmate EDP text file. - Although it is rather unlikely, if the default values for the relevant registry parameters are satisfactory, changing the Attachmate parameter is all that needs to be done. - Edit the Windows Registry to adjust the following two (Vista) or three (2000 or XP) parameters as necessary: -- KeepAliveTime, default 7,200,000 milliseconds (2 hours) -- KeepAliveInterval, default 1000 milliseconds (1 second) -- TcpMaxRetransmissions, default 5 <comment> Yes, it's confusing, isn't it? The Communications Server IP TCPCONFIG statement INTERVAL parameter is equivalent to the KeepAliveTime, not the KeepAliveInteval! Ho-hum, IBM and Microsoft at odds for the umpteenth time! Contrary to the Wikipedia article supposedly on this topic - which is mainly oriented to describing an application "keepalive" for HTTP - and this Attachmate web page, in the case of Windows Vista, the TcpMaxDataRetransmissions parameter is *not* used as a number of retransmissions for the "keepalive" packets. In the case of Windows Vista, the number of retransmissions for the "keepalive" packets is a constant 10. The "knowledge base" reference provided so kindly on the Attachmate web page can be consulted for confirmation. </comment> </précis> Chris Mason - [1] TCP level keepalive http://tools.ietf.org/html/rfc1122#page-101 Request for Comments: 1122 October 1989 Requirements for Internet Hosts -- Communication Layers 4. TRANSPORT PROTOCOLS 4.2 TRANSMISSION CONTROL PROTOCOL -- TCP 4.2.3 SPECIFIC ISSUES 4.2.3.6 TCP Keep-Alives Implementors MAY include "keep-alives" in their TCP implementations, although this practice is not universally accepted. If keep-alives are included, the application MUST be able to turn them on or off for each TCP connection, and they MUST default to off. Keep-alive packets MUST only be sent when no data or acknowledgement packets have been received for the connection within an interval. This interval MUST be configurable and MUST default to no less than two hours. It is extremely important to remember that ACK segments that contain no data are not reliably transmitted by TCP. Consequently, if a keep-alive mechanism is implemented it MUST NOT interpret failure to respond to any specific probe as a dead connection. An implementation SHOULD send a keep-alive segment with no data; however, it MAY be configurable to send a keep-alive segment containing one garbage octet, for compatibility with erroneous TCP implementations. DISCUSSION: A "keep-alive" mechanism periodically probes the other end of a connection when the connection is otherwise idle, even when there is no data to be sent. The TCP specification does not include a keep-alive mechanism because it could: (1) cause perfectly good connections to break during transient Internet failures; (2) consume unnecessary bandwidth ("if no one is using the connection, who cares if it is still good?"); and (3) cost money for an Internet path that charges for packets. 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. Unfortunately, some misbehaved TCP implementations fail to respond to a segment with SEG.SEQ = SND.NXT-1 unless the segment contains data. Alternatively, an implementation could determine whether a peer responded correctly to keep-alive packets with no garbage data octet. A TCP keep-alive mechanism should only be invoked in server applications that might otherwise hang indefinitely and consume resources unnecessarily if a client crashes or aborts a connection during a network failure. - [2] TN3270E keepalive http://tools.ietf.org/html/rfc2355#page-32 Request for Comments: 2355 June 1998 TN3270 Enhancements 13. Implementation Guidelines 13.3 A "Keep-alive" Mechanism In many environments, it is very helpful to have in place a mechanism that allows timely notification of the loss of a 3270 session. TN3270E does not require that any form of keep-alive mechanism be employed by either clients or servers, but implementors wishing to support such a mechanism should consider the following guidelines. There are at least three possible means of providing a keep-alive mechanism in TN3270E: the TCP Keepalive, the Telnet IAC NOP command [8], and the Telnet DO TIMING-MARK option [9]. Each method has its advantages and disadvantages. It is recommended that TN3270E clients and servers that support keep-alives should support all three methods, and that both sides should always respond to TIMING-MARKs. Note that both clients and servers could be configured to "actively" implement keep-alives. That is, both sides could send a TIMING-MARK or a NOP or issue a TCP Keepalive in order to determine whether or not the partner is still alive. Alternatively, network administrators may wish to configure only one side to send keep-alives; in this case, the other side would be a "passive" participant which simply responds to the keep-alives it receives. Implementors who want their code to be capable of being an "active" keep- alive participant should make their client or server configurable so that administrators can set which, if any, keep-alive mechanism should be employed, and how often it should be used. Upon failure of a session on which keep-alives are used, both parties should make the proper notifications. A client should give the user some indication of the failure, such as an error code in the Operator Information Area of the screen. A server should notify the host application that the session has been terminated, for example by sending an UNBIND with type CLEANUP in an SNA environment. - On Thu, 27 Jan 2011 07:58:57 -0500, George Rodriguez <[email protected]> wrote: >Good Morning Chris, > >Here's the link to the Attachmate tech-note: > >http://support.attachmate.com/techdocs/2353.html > ><http://support.attachmate.com/techdocs/2353.html> > ... >I appreciate everyone's help on this issue. Chris, after you the the >tech-note from Attachmate, let me know if you think I'm not going resolve my >timeout problem... > >Thanks. . . >* >* >*George Rodriguez* ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
