Open/active perpetually?

[Mike Campbell]

We have a vendor that states that their software requires the connection to always open.  They requested we contact Cloverleaf about this.  So, any ideas?  We are on 5.7 on AIX.  We are sending using the pdl-tcpip processing.  Is there a setting that we use to make the connection always open?  

Thanks.

Topic

[Jim Kosloskey]

Do you mean:

  Open connection

  Send message

  Close connection

With each message?

Or do you mean stay open (as long as no one closes the connection)?

If you mean the prior, then I think clicking the ‘Close after Write’ box on the ‘Data Options’ panel of the ‘PDL Options’ Dialogue will do that.

Here we prefer a TCP/IP connection be kept persistent (that is always open whether there are any messages or not.

Who is this vendor and what is the product?

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Mike Campbell]

They are wanting the connection to stay open whether or not messages are being sent.  The vendor is for a product called ‘CarePricer’ which is an Accuro application.

I’ll check with our communicaton/ftp folks on the actual tunnel that we are using.

[Jim Kosloskey]

Oh – are you using a VPN?

If so there are a number of posts regarding others issues with VPNs.

However, it is possible the VPN is closing the connection.

The default for Cloverleaf TCP/IP PDL is to be persistent (open until closed whether there are messages or not) so I think you have that set up correctly in Cloverleaf.

You may need to increase your keep-alives (see other posts) or the VPN admins may need to allow the connection to stay open.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Hope Rolens]

Jim,

in your response, you mentioned the Close After Write protocol option, and other posts involving problems with VPN’s.

We are receiving results from another Cloverleaf engine through a VPN, which closes the connection after 1 hour of inactivity.  The result is that our inbound thinks it’s still connected, while their outbound goes to Opening.  The administrators of the VPN are not willing to change the timeout. If Close After Write is checked on the outbound thread on the other engine, will that resolve the problem?

I haven’t seen it mentioned as a resolution in the other postings about VPN connection issues, so am wondering if it will work.  (Our other option is a script to periodically bounce the connection on our end, which seems to restore the connection)

Thanks,

Hope Schnelten

Hospital Sisters Health Systems

Springfield, Illinois

hschnelt@ccc.hshs.org

217-492-2268

[Charlie Bursell]

Since this is a server thread on your side your best option here is to use mult-server.  That way if the port is closed another will be be used

[Hope Rolens]

Hi Charlie,

I have read that using Muli-Server can solve this problem in some of the other posts.  However, I’m concerned that this will create a new connection but leave the “hung/stale” connection out there.  Am I thinking correctly about this?  Or, will Cloverleaf or the OS eventually time-out and close the previous TCP connection that was dropped by the vendor Firewall?

The vendor Firewall closes the connection after one hour of inactivity.  We only plan to receive one or two message per day on this connection, so I’m worried we have the potential of creating over 20 hung/stale TCP connections on our server each day.

Thanks,

[Charlie Bursell]

You may see some ports in a Close/Wait state but they will eventually timeout

[Chris Williams]

Another option is to set your keep-alive on the Cloverleaf boxes so that it is shorter than the timeout on the VPN.

[Hope Rolens]

Thanks Charlie and Chris,

we’re going to get with the vendor system’s Cloverleaf programmer and hash out the options.  

Hope

[Jim Kosloskey]

Hope,

The VPN is closing the conenction after inacivity – but not releasing the port – this is what is causing the issue.

In my opinion, the fault is with the VPN – it should release the port upon closing it.

Frequently altering the keep-alives can solve this issue but some VPN/Firewall admins configure their facilities to ignore packet level keep alives which makes that resolution useless. Moreover, if you encounter another VPN with a diferent timeout demand you may not be able to set the keep-alive timing to match all of the demands.

Charlie’s suggestion can work. There are some caveats here as well. Most of the time the default timeout for releasing a port left open combined with the frequency of reassignment of ports from the ephemeral range does not cause issues (this is what happens with multi-server and the condition you are experiencing) – however it can happen that you could exceed available ephemeral ports and I think this is much harder to troubleshoot.

Personally I think these admins need to justiify not releasing the ports.

Periodic stopping and starting the connection as server can also relieve the situation but might be overkill.

Others have suggested application keep-alives (‘dummy’ messages that both sides agree to). This might be accomplishable in your case because you are not exchanging durectly with an application. The othr Cloverleaf can create a ‘dummy’ message periodically (satisfying the brain-dead VPN) and you can kill it on your end. Personally, I don’t like the idea of sending any more message traffic across a connection than is necessary,

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Hope Rolens]

Thanks, Jim.  

I emailed the remote system’s network admin guy, to see if they can release the port.  We agree that the admins of the VPN/firewall should fix the problem, but cannot count on that happening.

We haven’t ruled out simply bouncing the thread via a ksh script scheduled in cron, or through a qdx alert.  But the other options will be discussed with the vendor, and we’ll settle on one.

thanks again to everyone who responded to this post.

Hope

[Author]

Replies