Keeping A Specific TCP/IP Port Alive

Greetings,

Keep Alive APPC over TCP/IP - iSeries Connections Crossing a Firewall

There is a potential problem that can adversely affect communication sessions between 
AS/400s within Our network and AS/400s outside of Our network. What I’m hoping 
to find is a way to keep a connection alive to a specific “target” port across a firewall. 
(Because I’m old school, I’m going to refer to our iSeries boxes as AS/400’s for nostalgic 
purposes. The earliest O/S version we’re running is V5R4M0.) There are several AS/400s 
inside and outside our network that we need to communicate with on a daily basis...

Problem definition
This problem occurs when a specific set of circumstances are encountered.
1.)    An AS/400 (source) server inside Our network firewall attempts to communicate 
with an AS/400 (target) server that lives outside Our network firewall. For example, 
source server A attempts to connect with target server Z. Or vice versa.
2.)    More than one communication link is ‘established’ between the source/target systems.
3.)    One or more of the existing connections have been idle so long they have exceeded 
the firewall-imposed timeout and are essentially ‘walking dead’ connections which cannot be revived.
4.)    The source system requires more than one simultaneous connection to the target system.

Scenario
(This is my understanding of how things work, I could be wrong...)

Whenever an AS/400 attempts to connect with another AS/400
via TCP/IP, the operating system (O/S) will check to see if any existing idle
connections are available for use. By design, the O/S will preserve any
successful connection instead of destroying a connection once the communication
session has ended. Presumably, it is less expensive for the O/S to recycle an
existing idle connection than it is to establish a new connection. While this
schema works well when the two systems are within the same network, it can
become a problem when the two systems are on opposite sides of one or more
firewalls. A TCP/IP connection that crosses a firewall and remains idle for too
long can become unusable. These connections are essentially ‘walking dead’
(zombies, if you will). The problem is that the AS/400 O/S staunchly refuses to
destroy a TCP/IP connection once it has been successfully established. At the
same time, the firewall has closed that port based on its own internal time-out
settings. 

When the O/S receives a request for a communication link
with any system, it will first ascertain whether any existing idle connections
are available to satisfy the request. The system will grab the first available
existing, idle connection it finds instead of creating a new connection from
scratch. The developer has no control over which communication session is used.
So, in the scenario described above, if the O/S happens to grab a “zombie”
connection, there is no exception error given, the communication session simply
hangs while the O/S persistently attempts to revive the connection.

The calling program waits for a connection that will never
activate because the O/S has selected a ‘zombie’ as the first available idle
connection. The O/S does not recognize that this connection will never be
revived. Still the O/S persists in trying to revive it. The O/S has no way of
knowing the firewall has closed the port. It believes this is still a viable
connection.

What I’m hoping to find is a way to keep a connection alive
to a specific target port. 

Neither PING nor APING allow you to specify a port… In the
scenario described above, using APING would only keep the first connection
alive… What I’m hoping will work is some sort of UDP PING (if such a thing
exists) where you can specify the target port… That, used in conjunction with
the "NETSTAT *CNN" QtocLstNetCnn
API, would provide a list of connections and allow us to keep alive all
of our idle communication sessions between our AS/400s where they cross a
firewall.

Does anyone know how to perform a ping-like request using
UDP/IP instead of TCP/IP…?

Failing this course of action, we will probably just have to
kill all connections that have been idle > some number of milliseconds.

I welcome comments and questions.

Thank you.
Jeff K.
jklipa at yahoo
--