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/HeartBeatsPerSendQueueissues, 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 
heartBeatTimeoutseconds, 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 
heartBeatTimeoutrate when the send queue is below thehighWaterMarkand at thefast_heartbeat_periodrate when the send queue is full beyond thehigh_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_NEWevent. - 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.