Resolution:
RTclient drops its connection to RTserver when the network is heavily loaded because it takes so long for traffic to pass between RTserver and RTclient that RTclient mistakenly interprets this as RTserver or the network connection failing. In the case of RTserver or network failure, RTclient drops the connection and tries again to reconnect.

To increase RTclient's tolerance for traffic-related delays, increase the RTclient options Server_Read_Timeout and Server_Write_Timeout. There are no hard-and-fast rules,  you will need to experiment to find the values that are appropriate to your particular network and traffic flow.

The process by which RTclient determines a connection is failed is straightforward. If more than Server_Read_Timeout has passed since a message has been received from RTserver, RTclient will issue a KEEP_ALIVE_CALL to determine if the connection is still intact. If RTclient does not get a response from RTserver within the time specified by Server_Keep_Alive_Timeout, RTclient assumes a network failure has taken place. RTclient then invokes its error callback which disconnects from RTserver and attempts to reconnect. On very heavily loaded networks, this can result in a pathological situation. If RTserver is very busy, RTclient may try to re-establish its connection even before RTserver has recognized that RTclient has terminated. If RTclient attempts a re-connection with the same Unique_Subject, RTserver will detect a unique name conflict and disallow the connection.

Increasing the Server_*_Timeout options will allow RTclient to be more tolerant of network latency, but it will also means that it will take longer for RTclient to recognize legitimate network failures.

NOTE: The Server_Write_timeout gets triggered when the client calls TipcSrvFlush()