Workstation keep-alive and connectivity failure detection

Question

Dear all,
I intend to automatically detect network failures from my workstation client and have it attempt to reconnect to the server on its own.
Browsing the documentation for related information I saw the keep-alive option. If I understood correctly you can have the workstation generate periodic keep-alive messages to the server and if these are not acknowledged, all subsequent ATMI calls will fail with TPESYSTEM.
My doubts regarding this are the following:
1) Is there some dummy ATMI function I can invoke periodically to check for a disconnection? Otherwise network failures might go by unnoticed if there are periods where my WSC doesn't require to communicate with the server.
2) Once I get a TPESYSTEM failure, is there some way to programatically discriminate if the cause is a network disconnection? It is a pretty generic error after all.
3) Once all ATMI functions start failing due to keep-alive detecting a network failure, can the system recover on its own? or must I reconnect to the server? What I mean is, maybe some keep alive messages where lost, the system passes to the 'disconnected' state, but then the K.A. messages keep being generated and upon correct acknowledgement of these, subsequent ATMI calls will stop failing.
4) Does the WSC go to 'disconnected' state after the first unanswered keep alive message? or is there some sort of tolerance like, say, 'If N messages in a row are not answered then assume the connection to be dead'.
I'm sorry if it was too long a post, but neither searching the documentation nor this forum clarified any of these issues for me.
Many thanks for your attention.
Regards.

Answer 1

Cacho,
1. I assume that you're talking about the WSL CLOPT option "-K
{client|handler|both|none}", which causes periodic keepalive messages to be
sent. When this option is used, there is no need for the WSC to perform any
periodic operations to keep the network connection alive.
However, if you are worried that the network might suffer a transient
failure and you want to perform your first ATMI call after an extended
period of inactivity as quickly as possible without waiting for another
tpinit(), you may want to perform periodic dummy operations so that you can
reissue the tpinit() if needed as soon as the network connection is
restored.
One option is to make a tpcall() to the ".TMIB" service with an FML32 buffer
where TA_OPERATION is set to "GET" and the other fields are set to retrieve
some system attribute. There is an example of how to call .TMIB at the end
of the TM_MIB(5) manual page. You would want to perform a GET operation
rather than the SET operation shown in that example.
Another option is to write a null service in one of your application servers
which just calls tpreturn() and have your client make periodic cals to that
service.
Calling a verb such as tpalloc() or tpconvert() would not be sufficient,
since these calls do not result in any network traffic.
2. The tperrordetail() function is available in newer releases of Tuxedo to
provide additional information about certain Tuxedo errors. When a
workstation client is disconnected, tperrordetail(0) will return TPED_TERM.
3. If there is a network failure, workstation clients must call tpinit() to
reauthenticate to the system. This is necessary for security reasons.
4. The keepalive option is passed down to the underlying network provider
and Tuxedo has no further involvement with keepalive once it informs the
network of this option. For Sockets the option passed is SO_KEEPALIVE; you
can do a web search on SO_KEEPALIVE to see exactly how the network treats
keepalive messages on your particular platform.
Ed
<Cacho Nakamura> wrote in message news:[email protected]...
Dear all,
I intend to automatically detect network failures from my workstation client
and have it attempt to reconnect to the server on its own.
Browsing the documentation for related information I saw the keep-alive
option. If I understood correctly you can have the workstation generate
periodic keep-alive messages to the server and if these are not
acknowledged, all subsequent ATMI calls will fail with TPESYSTEM.
My doubts regarding this are the following:
1) Is there some dummy ATMI function I can invoke periodically to check for
a disconnection? Otherwise network failures might go by unnoticed if there
are periods where my WSC doesn't require to communicate with the server.
2) Once I get a TPESYSTEM failure, is there some way to programatically
discriminate if the cause is a network disconnection? It is a pretty generic
error after all.
3) Once all ATMI functions start failing due to keep-alive detecting a
network failure, can the system recover on its own? or must I reconnect to
the server? What I mean is, maybe some keep alive messages where lost, the
system passes to the 'disconnected' state, but then the K.A. messages keep
being generated and upon correct acknowledgement of these, subsequent ATMI
calls will stop failing.
4) Does the WSC go to 'disconnected' state after the first unanswered keep
alive message? or is there some sort of tolerance like, say, 'If N messages
in a row are not answered then assume the connection to be dead'.
I'm sorry if it was too long a post, but neither searching the documentation
nor this forum clarified any of these issues for me.
Many thanks for your attention.
Regards.