Broken or Closed Connections

TCP and TLS connections do not always report an error if the connection is broken. When an application is in a blocking read, waiting for a message to arrive, TCP does not always interrupt the blocking read to inform the application that the connection is broken. Normally, an error is reported if a connection no longer exists and an application tries to write to it. This behavior can lead to problems in the Uniface Router, because it does not actively check the existence of the clients or servers.

The Uniface Router assumes that clients and servers that have not explicitly disconnected are still available, and that network connections are valid. Its message protocol is to read a message from the client and write the message to a server. In the absence of a message from a client, it does not detect whether a client connection is still valid. It detects that a server is no longer available only when it tries to write a message to it.

Strategies for Dealing with Broken Connections

Depending on your application there may be different ways to ensure connections are available.You can:

• Using ProcScript in your application, call the UROUTMON API operation UROUTER_DOYOUHAVE() to explicitly check if a server or client with a specific UST is available. For more information, see UROUTER_DOYOUHAVE .
• Have the Uniface Router send existence check messages to verify connections. In this case, you need to find a balance between detecting broken connections in a timely manner and degrading performance with frequent checks.

  When using this approach, you should also consider charges that may be imposed by a network provider. Some providers drop the physical network connection when it is idle and do not charge for it. Periodically sending messages could keep the network active and so increase charges.

  • You can instruct the Uniface Router to check all client connections using the $NET_TIMEOUTuec or vfy settings in the Uniface Router assignment file. For more information, see $NET_TIMEOUT.
  • To selectively define which client connections are checked, you can specify the /uec or /vfy options in a path definitions in the client's assignment file. For more information, see [PATHS], /uec, and /vfy .

    Depending on the type of client connection, the uec and the vfy options provide more control over sending the existence check message. The vfy option only sends the message over a client connection that has a DNP registration, whereas the uec option makes no such distinction. For more information, see Broken DNP Connection in Clients.

  • It is also possible to specify that individual groups of servers should receive existence check messages by specifying /uec in the UST definition on the [SERVERS] section in the Uniface Router assignment file. For more information, see /uec.