What are "heartbearts" and how are they used in RTI Data Distribution Service 3.x?

Note: The following discussion applies to RTI Data Distribution Service 3.x only. (There is a separate FAQ for 4.x.) 

Heartbeats (HBs) are sent for one of two reasons: 

  • Every SendQueueSize/ HeartBeatsPerSendQueue issues, RTI Data Distribution Service will append a HB to the issue to request that it acknowledge issues. This is what is usually used to allow the publication to commit issues as they are received.
  • Every heartBeatTimeout seconds, RTI Data Distribution Service will send a HB. This is used to verify the connection to the reliable subscription in the absence of sending data. 

HBs are sent in two different ways: 

  • We send a certain number of heartBeatsPerSendQueue.
  • We send HBs at the heartBeatTimeout rate when the send queue is below the highWaterMark and at the fast_heartbeat_period rate when the send queue is full beyond the high_watermark. This allows the user better control over the send queue. 

The heartBeatTimeout is just a faster version that gets used when RTI Data Distribution Service hits the high_watermark, allowing the application to drop slow subscriptions. Note that almost any delay that causes RTI Data Distribution Service to hit the high_watermark will cause subscriptions to be dropped if fast mode is turned on. 

This method has the advantage of being more efficient in ACK mode. The application can choose to not ACK every packet but just ACK periodically (either based on the number of issues sent or the amount of time that has elapsed). Of course, the application always has the option to ACK everything if it wishes. 

If publicationProperties.heartBeatRetries number of HBs is not acknowledged by the subscription it will be marked as "stale", issues will no longer be saved for it in the send queue and the publication application will be notified of a NDDS_SUBSCRIPTION_DELETE event. The amount of time it takes a subscription to become stale depends on the publication settings. 

Subscriptions which have been marked as stale can be re-added to the publication in two ways:

  • If the subscription was not responding for less than the expiration time of its declaration (by default about 300 seconds) then the publication will still be attempting to send the subscription HB packets and the subscription will be "unstaled" as soon as an ack is received, generating a NDDS_SUBSCRIPTION_NEW event.
  • If the subscription was not responding for greater than that time, then the subscription will be added back when the publication application next receives declarations from the subscription application. By default this can take up to 72 seconds.