RTserver GMD Considerations

How GMD Works in RTserver

RTserver does not keep any GMD information in files. The publishing RTclient has full responsibility for maintaining a persistent copy of the message. This speeds up and simplifies GMD, as only the publishing process performs the majority of disk file operations. If RTserver crashes and restarts, the publishing RTclient can resend the messages from its GMD area.

When an RTclient publishes the first message using GMD to a subject, RTserver starts collecting subject subscription information from the appropriate other RTservers to accurately track GMD accounting. This increases the scalability of publish-subscribe GMD due to the fact that only the relevant RTservers dynamically exchange GMD information. The RTclient API function TipcSrvSubjectGmdInit can also be used to manually initialize GMD accounting for a subject to which messages will be published. The RTserver option Gmd_Publish_Timeout specifies the amount of time RTserver continues to maintain GMD accounting for a subject that has not been recently published to with GMD; when this timeout is reached, the inter-RTserver GMD information is no longer accumulated.

RTserver does keep GMD information in memory, although not the same way as a memory-only GMD area. When a direct RTclient sends a message with GMD, the RTserver creates a record containing:

RTserver then routes the message normally by sending a copy of the message to all appropriate direct RTclients and RTservers. As the subscribing RTclients receive, process, and acknowledge the message, they send GMD_ACK messages, which are routed back to the original RTserver.

When the original RTserver receives an acknowledgment, it removes the receiving RTclient from the list of expected receivers and adds it to the list of successes. If failures occur, such as an expected receiver RTclient, whose Server_Disconnect_Mode option is set to gmd_failure, disconnects without acknowledging the message, the failed RTclient is moved from expected list to the failed list, and a GMD_NACK message is sent to the original RTclient publisher. The publishing RTclient receives the GMD_NACK message, then builds and processes a GMD_FAILURE message to notify the program of an asynchronous GMD failure.

By keeping the original GMD message in memory, RTserver can easily and quickly resend the message to reconnecting warm RTclients without having to notify or wait for the original publishing RTclient. This speeds up recovery and also ensures that the reconnecting warm RTclient receives the old messages first before receiving any new messages. RTserver also uses the list of expected receivers to prevent resends from going to RTclients that start subscribing to the subject after the original message was sent.

If RTserver receives a GMD_DELETE message, it destroys the in-memory GMD record about the message, effectively terminating GMD for the message (or at least terminating resending of the message). If RTserver receives a GMD_STATUS_CALL message, it constructs and returns a GMD_STATUS_RESULT message containing the lists of successful, failed, and pending subscribers.

When RTserver receives enough acknowledgment messages (one in the case of T_IPC_DELIVERY_SOME and all of them in the case of T_IPC_DELIVERY_ALL), RTserver destroys the in-memory GMD record about the message and sends a GMD_ACK message to the original RTclient that sent the message. This simplifies GMD for the publisher, which does not have to track multiple acknowledgments.

Configuring RTserver for GMD

To configure an RTserver for GMD, set the GMD-related options in the RTserver startup command file or using a CONTROL message. If you want to use the default configuration, you do not need to reset the options from their default values. These are the GMD options for RTserver:

For more information on these options, see Chapter 8, Options Reference.