The Real-Time Publish-Subscribe (RTPS) communications model was developed to address these limitations of PS. RTPS adds publication and subscription timing parameters and properties so the developer can control the different types of data flows and achieve their application s performance and reliability goals.

Each publication is characterized by four parameters: topic, type, strength and persistence. The topic is the label that identifies each data flow. The type describes the data format. The strength indicates a publisher s weight relative to other publishers of the same topic. The persistence indicates how long each publication issue is valid. Next figure illustrates how a subscriber arbitrates among publications using the strength and persistence properties.

Fault tolerant applications use redundant publishers sending publications with the same topic to ensure continuous operation. Subscribers arbitrate among the publications on an issue-by-issue basis based on the strength and persistence of each issue.

When there are multiple publishers sending the same publication, the subscriber accepts the issue if its strength is greater than the last-received issue or if the last issue s persistence has expired. Typically, a publisher that sends issues with a period of length T will set its persistence to some time Tp where Tp > T. Thus, while the strongest publisher is functional, its issues will take precedence over publication issues of lesser strength. Should the strongest publisher stop sending issues (willingly or due to a failure), other publisher(s) sending issues for the same publication will take over after Tp elapses. This mechanism establishes an inherently robust, quasi-stateless communications channel between the then-strongest publisher of a publication and all its subscribers.

Subscriptions are identified by four parameters: topic, type, minimum separation and deadline. The topic the label that identifies the data flow, and type describes the data format (same as the publication properties). Minimum separation defines a period during which no new issues are accepted for that subscription. The deadline specifies how long the subscriber is willing to wait for the next issue. Next figure illustrates the use of these parameters.

Once the subscriber has received an issue, it will not receive another issue for at least the minimum separation time. If a new issue does not arrive by the deadline, the application is notified.

The minimum separation protects a slow subscriber against publishers that are publishing too fast. The deadline provides a guaranteed wait time that can be used to take appropriate action in case of communication delays.

Publish-subscribe can support a variety of message delivery reliability models, not all of which are suitable to real-time applications. The RTPS reliability model recognizes that the optimal balance between time determinism and data-delivery reliability varies between real-time applications, and often among different subscriptions within the same application. For example, signal subscribers will want only the most up-to-date issues and will not care about missed issues. Command subscribers, on the other hand, must get every issue in sequence. Therefore, RTPS provides a mechanism for the application to customize the determinism versus reliability trade-off on a per subscription basis. The RTPS determinism vs. reliability model is subscriber-driven. Publishers simply send publication issues. However, to provide message delivery reliability, publishers must be prepared to resend missed issues to subscriptions that require reliable delivery. The RTPS reliability model uses publication buffers publisher and subscriber and retries to ensure that subscribers who need each issue receive them in the proper sequence. In addition, the publisher applies sequence number to each publication issue. The publisher uses the publication buffer to store history of the most recently sent issues. The subscriber uses its publication buffer to cache the most recently received issues. The subscriber acknowledges issues received in order and sends a request for the missing issue when the most recent issue s sequence number out of order. The publisher responds by sending the missed update again. Publishers remove an issue from their history buffers in two cases: the issue has been acknowledged by all reliable subscribers or the publisher overflows the history buffer space. Flow control can be implemented by setting high and low watermarks for the buffer. These publication-specific parameters let the publisher balance the subscribers need for issues against its need to maintain a set publication rate.