RTPS (Real Time Publish Subscribe) is a spec that describes a pub/sub based messaging system and wire protocol. It can run on any transport capable of delivering datagrams (delimited, uncorrupted packets), so UDP is a good fit.
An RTPS system consists of a network of participants (there is no master node). A participant is a grouping of topic publications and subscriptions - it usually corresponds one to one with a process.
A topic corresponds to a type of data in the system - ie, a telemetry message, a button press, or a status update. RTPS does not specify the data format used by topics. Each topic is identified by a type, which indicates the data type of the payload, and a name, which can distinguish multiple topics of the same type. Topic type and name are represented as strings.
Publishers write data to topics and subscribers read data from topics. Importantly, publishers are decoupled from subscribers - the publisher is not required to know who's listening, which means subscribers can flexibly be added and removed without bothering a publisher.
A topic may have 0 or more publishers, and 0 or more subscribers (though must have at least one pub or sub to exist in the first place).
Any participant can publish or subscribe to a topic.
Subscribers can register for updates on topics they're interested in, and tune the manner in which messages will be delivered to them via options that RTPS calls QoS settings. QoS settings are applied individually for each subscriber to a topic.
Some examples:
- Time Based Filter - specify the rate at which a subscriber is interested in updates. If a publisher is writing data more often, it will be down sampled.
- Reliability - specify whether messages should be delivered reliably (via retries, with an optional timeout), or best effort. Importantly, the retry behavior:
- allows for improved control of delivery over a wireless link, compared with TCP
- allows other packets to be interleaved with the delivery of retries, meaning not everything is blocked by the delivery of a single message
- History - specify the number of messages that should be retained after having been sent. Can be helpful to allow late joining participants to 'catch up'.
- Durability - specify whether messages are stored in RAM, on disk, or some other level of persistence.
There are a few more options that are generally less critical for most applications, and not all options are equally supported in all implementations, but you can read more here.
RTPS is typically a good fit for real-time data transfer, but not ideal in all cases. It may not make sense for video streaming, and for file transfer, for instance, as those cases are well supported by existing tools.
Also, RTPS does not specify a pattern for request-response interactions (ie, RPCs), which can be useful in cases in which an explicit ACK is required between a single sender and a single receiver. There is an existing proposal to provide this functionality on top of RTPS, so we may integrate that to provide a solution for these kinds of use cases.