Re: Keeping A Specific TCP/IP Port Alive

The only way I see this working is sending some data over the line to keep
the firewall from ending the connection.

I had a similar issue writing my application that allows you to run an
XMPP/Jabber client on the System i. There is a specific ping stream to
send from client/server to client/server that is used to keep the
connection alive.

You will probably need to do the same thing. If two machines are connect,
check their idle time and after so many seconds, do some sort of ping type
request to keep the idle time down. This would need to be programmed into
the client and/or server application.

Brad
www.bvstools.com


On Mon, Sep 16, 2013 at 11:19 AM, jklipa <jklipa@xxxxxxxxx> wrote:

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
--
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.