Resolution:
If an RTclient never processes incoming messages, in other words the RTclient is a "pure" publisher with no  TipcSrvMainLoop,then the RTclient cannot be monitored nor will it be able to process keep alive messages.
"Ghost clients" are created when the machine running a "pure publisher" RTclient crashes or disconnects from the network. Since prior to SS5.5.5 all keep_alive responsibility for the connection initiated from the client the RTserver would  not know that the client was gone (thus the name "ghost client") until it attempted to send a message to the missing client, which of course it would not do if the client was a 'pure publisher'. If the client attempts to re-connect before the RTserver has discovered that the client is gone, then the client is denied access with the error message T_ERR_SRV_ACCESS_DENIED. Client name </_XXXXX_NNNN> is not unique.

In SmartSockets 5.5r5 server-to-client keep-alive messages were added to allow the RTserver to 'discover' lost clients whether they were 'pure publishers' or not.

One of several pre5.5.5 workarounds for this problem, was to make sure that every client received periodic messages;
If publishing RTclient_0 can subscribe to some subject, say /time_feed, and another RTclient can  publish on /time_feed at a user defined interval, then the RTserver will be aware of the connection status of the RTclient_0. (in other words if *all* clients subscribe to a "heartbeat" message, then RTserver will be forced to try and send the heartbeats to every client and will therefore discover any lost clients when it tries to send them the heartbeat)

In SmartSockets 5.5.5  two new RTserver  options were added. Client_Read_Timeout and Client_Keep_Alive_Timeout. These options work in a similar fashion to the RTclient options Server_Read_Timeout and Server_Keep_Alive_Timeout, and cause the RTserver to send a keep_alive message to any client that it has not received a message from in a timely fashion.

By default the client_read_timeout option in the RTserver is disabled (set to 0.0). This means that only the  client is responsible for determining if its connection to RTserver is lost. In this disabled state RTserver will only discover a lost client connection when it attempts to write a message to the client. If you wish to enable the client_read_timeout then set its value to something greater than 0.0. The behavior of your system will depend on how the value of Client_Read_Timeout
in the RTserver compares to the Server_Read_Timeout in a given client.

* If the value of Client_Read_Timeout is smaller than the client's Server_Read_Timeout then the RTserver will
always be the first to discover the loss and will issue a keep_alive to the client. When the client receives
the keep_alive from the RTserver it will reset its Server_Read_Timeout counter and therefore will never
activate unless the connection to RTserver is truely lost.

* If the value of the Client_Read_Timeout is larger then the client's Server_Read_Timeout then the client be
the first to discover the loss and will issue a keep_alive to the RTserver. When the RTserver receives the
keep_alive from the client it will reset its Client_Read_Timeout counter and therefore it will never activate
unless the connection to the client is truly lost.

Given that a single RTserver may have hundreds of clients that it is managing it is not a good design to
burden the RTserver with the additional messaging and computation required for discovering the possibility
of lost clients and it is therefore recommended that the Client_Read_Timeout in the RTserver be greater than
the Server_Read_Timeout in the RTclient. In fact to be absolutely sure that the client takes responsibility
for dicovering system failures in most cases we recommend that the Client_Read_Timeout in the RTserver should
be greater than the sum of the Server_Read_Timeout and the Server_Keep_Alive_Timeout in the client. By using
this setting the RTserver is only responsible for discovering a lost client after the client has completely
exhausted all of its timeouts for making the discovery first.

You can capture the error in RTclient with the following code:
if (!TipcSrvCreate(T_IPC_SRV_CONN_FULL)) {
     if (T_ERR_ACCESS_DENIED == TutErrNumGet() ) {
        TutOut("The client has tried to connect with the Unique_Subject
<%s> which is already in use.\n",
                    TutOptionGetStr( TutOptionLookup("Unique_Subject") ) );
    }
}

What is a Ghost RTclient? T_ERR_SRV_ACCESS_DENIED. Client name /_XXXXX_NNNN is not unique. error 504: server denied access.