Re: TCPIP Default keep alive question
- From: chrismason@xxxxxxxxxxxx (Chris Mason)
- Date: 2 Jun 2009 08:39:04 -0700
Eileen
Did you mean to alert us to the possibility that the *partner* TCP application
may be using its own TCP keepalive service? Also that a "firewall" could be
operating its own keepalive mechanism so that either partner could be subject
to a keepalive regime although neither had actually requested one?
All that is certainly handy to know.
Since Vic is talking about a "programming interface", he is posting in the IBM-
MAIN list and he refers to TSO NETSTAT it's certain he is talking about the
Communications Server IP component. That being so, I have pointed out how
he can control - through the sockets API - the TCP keepalive service in the IP
node with about which he would appear to be most concerned.
However, it's true we haven't been told what he really wants to do and we
can only guess based on the detailed query.
Chris Mason
On Tue, 2 Jun 2009 08:40:12 -0400, Barkow, Eileen
<EBarkow@xxxxxxxxxxxxx> wrote:
Note that applications can set and override the keep-alive values.
We just spent 6 months resolving a problem with keep-alive timeouts and
it turned out that an application running on a Windows server was
setting the values and overriding TCP/IP and firewall settings (another
place where they set keep-alive). Mainframe applications can also set
the value.
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@xxxxxxxxxxx] On
Behalf Of Chris Mason
Sent: Tuesday, June 02, 2009 7:32 AM
To: IBM-MAIN@xxxxxxxxxxx
Subject: Re: TCPIP Default keep alive question
Vic
The best list to use for questions concerning the Communications Server
IP
component (even the Communications Server SNA component given that
Enterprise Extender is so often the subject) is the IBMTCP-L list:
For IBMTCP-L subscribe / signoff / archive access instructions,
send email to LISTSERV@xxxxxxxxxxxxx with the message: INFO IBMTCP-L
-
Your precise answer is at the end of the post.
If there were such an API, it would be one of the options of either the
getsockopt() call or the getibmsockopt() call and the equivalent in
languages
other than C.
You may be aware that the matter of TCP keep-alive is not quite as
straightforward as it might be. To be sure I cover the topic correctly -
as best
I can - I'll quote what is said in the CS IP Configuration Reference
regarding
the value in which you are interested, the one that shows up in the
NETSTAT
CONFIG output as DefaultKeepALive specified by the PROFILE TCPCONFIG
statement INTERVAL parameter:
<quote>
INTERVAL default_keepalive_interval
The default TCP keepalive interval for applications that enable the
SO_KEEPALIVE socket option and do not override the interval using the
TCP_KEEPALIVE socket option. The range is 0 - 35 791 minutes, and the
default is 120. A value of 0 disables the keepalive function, so that
sockets
for which SO_KEEPALIVE is specified do not perform TCP keepalive. In
this
case, sockets specifying a specific interval using TCP_KEEPALIVE
continue to
send keepalive probes.
TCP keepalive probes end TCP connections after a period of inactivity.
TCP
keepalive is disabled by default for a connection, but can be enabled by
issuing the SO_KEEPALIVE or TCP_KEEPALIVE socket options. The
TCP_KEEPALIVE socket option enables the application to specify the
keepalive
probe interval, while the SO_KEEPALIVE socket option uses
default_keepalive_interval as the interval.
After the interval has expired, TCP sends a single keepalive probe to
the peer.
If the TCP_KEEPALIVE socket option is not used to specify the probe
interval,
a total of ten probes are then sent at 75-second intervals if no
response is
received from the peer. If no response has been received 75 seconds
after
the last probe, the connection is reset. If TCP_KEEPALIVE is used to
specify
the keepalive probe interval, the number of probes and the interval
between
the probes might differ depending on the interval specified.
</quote>
It was only after I read the last sentence that I realised the topic was
even
more complicated than I had initially supposed!
OK, INTERVAL sets a node-wide "keepalive" interval for those TCP sockets
which have decided to call upon the "keepalive" service by requesting it
by
means of the setsockopt() SO_KEEPALIVE option. The default is for the
service to be disabled. The value of the SO_KEEPALIVE option can be
obtained
by means of the getsockopt() call.
Note that, even if the program requests that the service is enabled, it
can
effectively be disabled on a node-wide basis, by setting "0" as the
value for
the INTERVAL parameter.
But there is also the TCP_KEEPALIVE option of the setsockopt() and
getsockopt() calls. This requests the service and sets a value for the
interval.
Moreover it sets up a regime for conducting the keepalive testing should
it be
called upon - that's the unexpected complication in that last sentence!
<quote>
TCP_KEEPALIVE
Use this option to set or determine whether a socket-specific timeout
value
(in seconds) is to be used in place of a configuration-specific value
whenever
keep alive timing is active for that socket. When activated, the socket-
specified timer value remains in effect until respecified by SETSOCKOPT
or
until the socket is closed. See the z/OS Communications Server: IP
Programmer's Guide and Reference for more information about the socket
option parameters.
</quote>
The "configuration-specific value" is the value of the INTERVAL
parameter
when the service is enabled using the SO_KEEPALIVE option rather than
the
TCP_KEEPALIVE option.
For reasons best known to the manual authors the section you need now to
consult for the specifics of how the TCP_KEEPALIVE option works is
tucked
away as the last section of the last chapter of the CS IP Programmer's
Guide
and Reference manual!
When you have read this section you may decide that the TCP_KEEPALIVE
option better satisfies your needs that the mechanism associated with
the
PROFILE TCPCONFIG statement INTERVAL parameter and the SO_KEEPALIVE
option.
-
Finally, to answer your question, I am not aware of an easy-to-use API
which
yields the value configured on the PROFILE TCPCONFIG statement INTERVAL
parameter. It is possible to extract the value as an SNMP manager
accessing
the MIB variable ibmMvsTcpKeepAliveTimer, 1.3.6.1.4.1.2.6.19.2.2.2.4. If
there's an easier way, I hope someone will jump in with the answer. I
suspect
some technique able to extract the value from the output of the NETSTAT
CONFIG output might be the easiest.
Chris Mason
On Mon, 1 Jun 2009 12:16:28 -0500, Vic Petrone <vxp@xxxxxxxx> wrote:
Is there a programming interface to extract the DefaultKeepALive valuethat
is
stored the TCP Configuration Table?
This is the same value that the TSO NETSTAT CONFIG command displays.
Thanks,
Vic
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
.
- Follow-Ups:
- Re: TCPIP Default keep alive question
- From: Barkow, Eileen
- Re: TCPIP Default keep alive question
- Prev by Date: INFOZIP >2Gb
- Next by Date: Re: INFOZIP >2Gb
- Previous by thread: Re: TCPIP Default keep alive question
- Next by thread: Re: TCPIP Default keep alive question
- Index(es):
Relevant Pages
|
