- History
- Keep last: only store up to N samples, configurable via the queue depth option.
- Keep all: store all samples, subject to the configured resource limits of the underlying middleware.
- Depth
- Queue size: only honored if the “history” policy was set to “keep last”.
- Reliability
- Best effort: attempt to deliver samples, but may lose them if the network is not robust.
- Reliable: guarantee that samples are delivered, may retry multiple times.
- Durability
- Transient local: the publisher becomes responsible for persisting samples for “late-joining” subscriptions.
- Volatile: no attempt is made to persist samples.
- Deadline
- Duration: the expected maximum amount of time between subsequent messages being published to a topic
- Lifespan
- Duration: the maximum amount of time between the publishing and the reception of a message without the message being considered stale or expired (expired messages are silently dropped and are effectively never received).
- Liveliness
- Automatic: the system will consider all of the node’s publishers to be alive for another “lease duration” when any one of its publishers has published a message.
- Manual by topic: the system will consider the publisher to be alive for another “lease duration” if it manually asserts that it is still alive (via a call to the publisher API).
- Lease Duration
- Duration: the maximum period of time a publisher has to indicate that it is alive before the system considers it to have lost liveliness (losing liveliness could be an indication of a failure).
The following tables show the compatibility of the different policy settings and the result:
Compatibility of reliability QoS policies:
| Publisher | Subscription | Compatible |
|---|---|---|
| Best effort | Best effort | Yes |
| Best effort | Reliable | No |
| Reliable | Best effort | Yes |
| Reliable | Reliable | Yes |
Compatibility of durability QoS policies:
| Publisher | Subscription | Compatible |
|---|---|---|
| Volatile | Volatile | Yes |
| Volatile | Transient local | No |
| Transient local | Volatile | Yes |
| Transient local | Transient local | Yes |
Compatibility of deadline QoS policies:
Assume x and y are arbitrary valid duration values.
| Publisher | Subscription | Compatible |
|---|---|---|
| Default | Default | Yes |
| Default | x | No |
| x | Default | Yes |
| x | x | Yes |
| x | y (where y > x) | Yes |
| x | y (where y < x) | No |
Compatibility of liveliness QoS policies:
| Publisher | Subscription | Compatible |
|---|---|---|
| Automatic | Automatic | Yes |
| Automatic | Manual by topic | No |
| Manual by topic | Automatic | Yes |
| Manual by topic | Manual by topic | Yes |
Compatibility of lease duration QoS policies:
Assume x and y are arbitrary valid duration values.
| Publisher | Subscription | Compatible |
|---|---|---|
| Default | Default | Yes |
| Default | x | No |
| x | Default | Yes |
| x | x | Yes |
| x | y (where y > x) | Yes |
| x | y (where y < x) | No |
为了建立连接，所有影响兼容性的策略都必须是兼容的。例如，即使请求和提供的QoS配置文件对具有兼容的可靠性QoS策略，但它们具有不兼容的持久性QoS策略，仍然不会建立连接。当没有建立连接时，将不会在发布者和订阅之间传递消息。