-
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策略,仍然不会建立连接。当没有建立连接时,将不会在发布者和订阅之间传递消息。