From 161c603e7156855857ffaa072816481f1228660a Mon Sep 17 00:00:00 2001 From: Miaofei Date: Thu, 7 May 2020 10:14:46 -0700 Subject: [PATCH 1/5] update about QoS settings wiki page Signed-off-by: Miaofei --- .../About-Quality-of-Service-Settings.rst | 285 ++++++++++++++---- 1 file changed, 231 insertions(+), 54 deletions(-) diff --git a/source/Concepts/About-Quality-of-Service-Settings.rst b/source/Concepts/About-Quality-of-Service-Settings.rst index 4e35b10ef8f..c6cd7c0591c 100644 --- a/source/Concepts/About-Quality-of-Service-Settings.rst +++ b/source/Concepts/About-Quality-of-Service-Settings.rst @@ -5,58 +5,79 @@ About Quality of Service settings ================================= + Overview -------- ROS 2 offers a rich variety of Quality of Service (QoS) policies that allow you to tune communication between nodes. With the right set of Quality of Service policies, ROS 2 can be as reliable as TCP or as best-effort as UDP, with many, many possible states in between. -Unlike ROS 1, which primarily only supported TCP, ROS 2 benefits from the flexibility of the underlying DDS transport in environments with lossy wireless networks where a "best effort" policy would be more suitable, or in real-time computing systems where the right Quality of Service profile is needed to meet deadlines. +Unlike ROS 1, which primarily only supported TCP, ROS 2 benefits from the flexibility of the underlying DDS transport in environments with lossy wireless networks where a “best effort” policy would be more suitable, or in real-time computing systems where the right Quality of Service profile is needed to meet deadlines. -A set of QoS "policies" combine to form a QoS "profile". -Given the complexity of choosing the correct QoS policies for a given scenario, ROS 2 provides a set of predefined QoS profiles for common usecases (e.g. sensor data). -At the same time, users are given the flexibility to control specific profiles of the QoS policies. +A set of QoS “policies” combine to form a QoS “profile”. +Given the complexity of choosing the correct QoS policies for a given scenario, ROS 2 provides a set of predefined QoS profiles for common use cases (e.g. sensor data). +At the same time, developers are given the flexibility to control specific policies of the QoS profiles. -QoS profiles can be specified for publishers, subscribers, service servers and clients. +QoS profiles can be specified for publishers, subscriptions, service servers and clients. A QoS profile can be applied independently to each instance of the aforementioned entities, but if different profiles are used, it is possible that they will not connect. + QoS policies ------------ The base QoS profile currently includes settings for the following policies: - * 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. + * *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 - * Size of the queue: only honored if used together with “keep last”. + * *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. + * *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" subscribers. - * Volatile: no attempt is made to persist samples. + * *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). -For each of the policies there is also the option of “system default”, which uses the default of the underlying middleware which may be defined via DDS vendor tools (e.g. XML configuration files). -DDS itself has a wider range of policies that can be configured. -These policies have been exposed because of their similarity to features in ROS 1; it is possible that in the future more policies will be exposed in ROS 2. +* 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 node*: the system will consider all of the node’s publishers to be alive for another “lease duration” when any one of the node’s publishers manually asserts that it is still alive (via a call to the publisher API). + * *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). + +For each of the policies that is not a duration, there is also the option of “system default”, which uses the default of the underlying middleware. +For each of the policies that is a duration, there also exists a “default” option that means the duration is unspecified, which the underlying middleware will usually interpret as an infinitely long duration. Comparison to ROS 1 ^^^^^^^^^^^^^^^^^^^ -The history and depth policies in ROS 2 combine to provide functionality akin to the queue size in ROS 1. +The “history” and “depth” policies in ROS 2 combine to provide functionality akin to the queue size in ROS 1. -The reliability policy in ROS 2 is akin to the use of either UDPROS (only in ``roscpp``\ ) for "best effort", or TCPROS (ROS 1 default) for reliable. +The “reliability” policy in ROS 2 is akin to the use of either UDPROS (only in roscpp) for “best effort”, or TCPROS (ROS 1 default) for “reliable”. Note however that even the reliable policy in ROS 2 is implemented using UDP, which allows for multicasting if appropriate. -The durability policy combined with a depth of 1 provides functionality similar to that of "latching" subscribers. +The “durability” policy combined with a depth of 1 provides functionality similar to that of “latching” subscribers. +The remaining policies in ROS 2 are not akin to anything that is available in ROS 1, meaning that ROS 2 is more featureful than ROS 1 in this respect. +It is possible that in the future, even more QoS policies will be available in ROS 2. + QoS profiles ------------ @@ -64,25 +85,25 @@ QoS profiles Profiles allow developers to focus on their applications without worrying about every QoS setting possible. A QoS profile defines a set of policies that are expected to go well together for a particular use case. -The currently-defined QoS profiles are: - +The currently defined QoS profiles are: -* Default QoS settings for publishers and subscribers +* Default QoS settings for publishers and subscriptions - In order to make the transition from ROS 1 to ROS 2, exercising a similar network behavior is desirable. - By default, publishers and subscribers are reliable in ROS 2, have volatile durability, and "keep last" history. + In order to make the transition from ROS 1 to ROS 2 easier, exercising a similar network behavior is desirable. + By default, publishers and subscriptions in ROS 2 have “keep last” for history with a queue size of 10, “reliable” for reliability, “volatile” for durability, and “system default” for liveliness. + Deadline, lifespan, and lease durations are also all set to “default”. * Services - In the same vein as publishers and subscribers, services are reliable. + In the same vein as publishers and subscriptions, services are reliable. It is especially important for services to use volatile durability, as otherwise service servers that re-start may receive outdated requests. While the client is protected from receiving multiple responses, the server is not protected from side-effects of receiving the outdated requests. * Sensor data - For sensor data, in most cases it's more important to receive readings in a timely fashion, rather than ensuring that all of them arrive. + For sensor data, in most cases it’s more important to receive readings in a timely fashion, rather than ensuring that all of them arrive. That is, developers want the latest samples as soon as they are captured, at the expense of maybe losing some. - For that reason the sensor data profile uses best effort reliability and a smaller queue depth. + For that reason the sensor data profile uses best effort reliability and a smaller queue size. * Parameters @@ -91,36 +112,64 @@ The currently-defined QoS profiles are: * System default - This uses the RMW implementation's default values for all of the policies. + This uses the RMW implementation’s default values for all of the policies. Different RMW implementations may have different defaults. -`Click here `__ for the specific policies in use for the above profiles. +`Click here `__ for the specific policies in use for the above profiles. The settings in these profiles are subject to further tweaks, based on the feedback from the community. -While ROS 2 provides some QoS profiles for common use cases, the use of policies that are defined in DDS allows ROS users to take advantage of the vast knowledge base of existing DDS documentation for configuring QoS profiles for their specific use case. QoS compatibilities ------------------- -**Note:** This section refers to publisher and subscribers but the content applies to service servers and clients in the same manner. +**Note:** This section refers to publisher and subscriptions but the content applies to service servers and clients in the same manner. + +QoS profiles may be configured for publishers and subscriptions independently. +A connection between a publisher and a subscription is only made if the pair has compatible QoS profiles. -QoS profiles may be configured for publishers and subscribers independently. -A connection between a publisher and a subscriber is only made if the pair has compatible QoS profiles. -QoS profile compatibility is determined based on a "Request vs Offerer" model, wherein connections are only made if the requested policy of the subscriber is not more stringent than the that of the publisher. -The less strict of the two policies will be the one used for the connection. +QoS profile compatibility is determined based on a “Request vs Offered” model. +Subscriptions *request* a QoS profile that is the “minimum quality” that it is willing to accept, and publishers *offer* a QoS profile that is the “maximum quality” that it is able to provide. + +Connections are only made if the every policy of the requested QoS profile is not more stringent than that of the offered QoS profile. +The less strict of the two policies will be the one used for the connection, and it is referred to as the “actual QoS” policy. -The QoS policies exposed in ROS 2 that affect compatibility are the durability and reliability policies. The following tables show the compatibility of the different policy settings and the result: -*Compatibility of QoS durability profiles:* +*Compatibility of reliability QoS policies:* .. list-table:: :header-rows: 1 * - Publisher - - Subscriber + - Subscription - Connection - - Result + - Actual QoS Policy + * - Best effort + - Best effort + - Yes + - Best effort + * - Best effort + - Reliable + - No + - - + * - Reliable + - Best effort + - Yes + - Best effort + * - Reliable + - Reliable + - Yes + - Reliable + +*Compatibility of durability QoS policies:* + +.. list-table:: + :header-rows: 1 + + * - Publisher + - Subscription + - Connection + - Actual QoS Policy * - Volatile - Volatile - Yes @@ -138,33 +187,161 @@ The following tables show the compatibility of the different policy settings and - Yes - Transient local +*Compatibility of deadline QoS policies:* + +.. list-table:: + :header-rows: 1 + + * - Publisher + - Subscription + - Connection + - Actual QoS Policy + * - Default + - Default + - Yes + - Infinite + * - Default + - *x* + - No + - - + * - *x* + - Default + - Yes + - *x* + * - *x* + - *x* + - Yes + - *x* + * - *x* + - *y* (where *y* > *x*) + - Yes + - *y* + * - *x* + - *y* (where *y* < *x*) + - No + - - -*Compatibility of QoS reliability profiles:* +*Compatibility of liveliness QoS policies:* .. list-table:: :header-rows: 1 * - Publisher - - Subscriber + - Subscription - Connection - - Result - * - Best effort - - Best effort + - Actual QoS Policy + * - Automatic + - Automatic - Yes - - Best effort - * - Best effort - - Reliable + - Automatic + * - Automatic + - Manual by node - No - - - * - Reliable - - Best effort + * - Automatic + - Manual by topic + - No + - - + * - Manual by node + - Automatic - Yes - - Best effort - * - Reliable - - Reliable + - Automatic + * - Manual by node + - Manual by node - Yes - - Reliable + - Manual by node + * - Manual by node + - Manual by topic + - No + - - + * - Manual by topic + - Automatic + - Yes + - Automatic + * - Manual by topic + - Manual by node + - Yes + - Manual by node + * - Manual by topic + - Manual by topic + - Yes + - Manual by topic +*Compatibility of lease duration QoS policies:* + +.. list-table:: + :header-rows: 1 + + * - Publisher + - Subscription + - Connection + - Actual QoS Policy + * - Default + - Default + - Yes + - Infinite + * - Default + - *x* + - No + - - + * - *x* + - Default + - Yes + - *x* + * - *x* + - *x* + - Yes + - *x* + * - *x* + - *y* (where *y* > *x*) + - Yes + - *y* + * - *x* + - *y* (where *y* < *x*) + - No + - - In order for a connection to be made, all of the policies that affect compatibility must be compatible. -That is, even if a publisher-subscriber pair has compatible reliability QoS profiles, if they have incompatible durability QoS profiles a connection will not be made, and vice-versa. +That is for example, even if a requested and offered QoS profile pair has compatible reliability QoS policies, but they have incompatible durability QoS policies, a connection will still not be made. + +When connections are not made, no messages will be passed between the publisher and subscription. +There are mechanisms to detect this situation, which will be covered in a later section below. + +Comparison to ROS 1 +^^^^^^^^^^^^^^^^^^^ + +Historically in ROS 1, any publisher and subscriber with the same message type on the same topic would be connected. +The possibility of incompatible requested and offered QoS profiles is something new to be aware of when using ROS 2. + + +QoS events +---------- + +Some QoS policies have possible events related to them. +Developers may provide each publisher and subscription callback functions that are triggered by these QoS events and handle them in a way they see fit, similar to how messages received on a topic are handled. + +The following are the possible QoS events that developers may subscribe to: + +* Offered deadline missed + + The publisher did not publish a message within the expected duration that was set out by the actual deadline QoS policy. + +* Requested deadline missed + + The subscription did not receive a message within the expected duration that was set out by the actual deadline QoS policy. + +* Liveliness lost + + The publisher has failed to indicate its liveliness within the lease duration. + +* Liveliness changed + + The subscription has noticed that one or more publishers on the topic that it is subscribed to has failed to indicate their liveliness within the lease duration. + +* Offered incompatible QoS + + The publisher has encountered a subscription on the same topic that is requesting a QoS profile that the offered QoS profile cannot satisfy, resulting in no connection between the publisher and that subscription. + +* Requested incompatible QoS + + The subscription has encountered a publisher on the same topic that is offering a QoS profile that does not satisfy the requested QoS profile, resulting in no connection between the subscription and that publisher. From 4fa3eb722954f3a741c0b4e5ac1410219db3e8e9 Mon Sep 17 00:00:00 2001 From: Miaofei Date: Thu, 7 May 2020 10:23:41 -0700 Subject: [PATCH 2/5] fix minor formatting mistake Signed-off-by: Miaofei --- source/Concepts/About-Quality-of-Service-Settings.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/Concepts/About-Quality-of-Service-Settings.rst b/source/Concepts/About-Quality-of-Service-Settings.rst index c6cd7c0591c..82989de4008 100644 --- a/source/Concepts/About-Quality-of-Service-Settings.rst +++ b/source/Concepts/About-Quality-of-Service-Settings.rst @@ -71,7 +71,7 @@ Comparison to ROS 1 The “history” and “depth” policies in ROS 2 combine to provide functionality akin to the queue size in ROS 1. -The “reliability” policy in ROS 2 is akin to the use of either UDPROS (only in roscpp) for “best effort”, or TCPROS (ROS 1 default) for “reliable”. +The “reliability” policy in ROS 2 is akin to the use of either UDPROS (only in ``roscpp``) for “best effort”, or TCPROS (ROS 1 default) for “reliable”. Note however that even the reliable policy in ROS 2 is implemented using UDP, which allows for multicasting if appropriate. The “durability” policy combined with a depth of 1 provides functionality similar to that of “latching” subscribers. From ebd5e9dbcff04610d3677d1a26cf4f4ac9e6178d Mon Sep 17 00:00:00 2001 From: Miaofei Date: Fri, 8 May 2020 11:25:16 -0700 Subject: [PATCH 3/5] address PR comments Signed-off-by: Miaofei --- .../About-Quality-of-Service-Settings.rst | 76 ++++++++++--------- 1 file changed, 41 insertions(+), 35 deletions(-) diff --git a/source/Concepts/About-Quality-of-Service-Settings.rst b/source/Concepts/About-Quality-of-Service-Settings.rst index 82989de4008..e324e1ff3fa 100644 --- a/source/Concepts/About-Quality-of-Service-Settings.rst +++ b/source/Concepts/About-Quality-of-Service-Settings.rst @@ -74,7 +74,7 @@ The “history” and “depth” policies in ROS 2 combine to provide functiona The “reliability” policy in ROS 2 is akin to the use of either UDPROS (only in ``roscpp``) for “best effort”, or TCPROS (ROS 1 default) for “reliable”. Note however that even the reliable policy in ROS 2 is implemented using UDP, which allows for multicasting if appropriate. -The “durability” policy combined with a depth of 1 provides functionality similar to that of “latching” subscribers. +The “durability” policy “transient local”, combined with any depth, provides functionality similar to that of “latching” publishers. The remaining policies in ROS 2 are not akin to anything that is available in ROS 1, meaning that ROS 2 is more featureful than ROS 1 in this respect. It is possible that in the future, even more QoS policies will be available in ROS 2. @@ -130,8 +130,8 @@ A connection between a publisher and a subscription is only made if the pair has QoS profile compatibility is determined based on a “Request vs Offered” model. Subscriptions *request* a QoS profile that is the “minimum quality” that it is willing to accept, and publishers *offer* a QoS profile that is the “maximum quality” that it is able to provide. -Connections are only made if the every policy of the requested QoS profile is not more stringent than that of the offered QoS profile. -The less strict of the two policies will be the one used for the connection, and it is referred to as the “actual QoS” policy. +Connections are only made if every policy of the requested QoS profile is not more stringent than that of the offered QoS profile. +The requested QoS profile, if compatible with the offered QoS profile, will be the resulting QoS profile of the connection. The following tables show the compatibility of the different policy settings and the result: @@ -142,8 +142,8 @@ The following tables show the compatibility of the different policy settings and * - Publisher - Subscription - - Connection - - Actual QoS Policy + - Compatible + - Connection Result * - Best effort - Best effort - Yes @@ -151,7 +151,7 @@ The following tables show the compatibility of the different policy settings and * - Best effort - Reliable - No - - - + - * - Reliable - Best effort - Yes @@ -168,8 +168,8 @@ The following tables show the compatibility of the different policy settings and * - Publisher - Subscription - - Connection - - Actual QoS Policy + - Compatible + - Connection Result * - Volatile - Volatile - Yes @@ -177,7 +177,7 @@ The following tables show the compatibility of the different policy settings and * - Volatile - Transient local - No - - - + - * - Transient local - Volatile - Yes @@ -189,13 +189,15 @@ The following tables show the compatibility of the different policy settings and *Compatibility of deadline QoS policies:* + Assume *x* and *y* are arbitrary valid duration values. + .. list-table:: :header-rows: 1 * - Publisher - Subscription - - Connection - - Actual QoS Policy + - Compatible + - Connection Result * - Default - Default - Yes @@ -203,7 +205,7 @@ The following tables show the compatibility of the different policy settings and * - Default - *x* - No - - - + - * - *x* - Default - Yes @@ -219,7 +221,7 @@ The following tables show the compatibility of the different policy settings and * - *x* - *y* (where *y* < *x*) - No - - - + - *Compatibility of liveliness QoS policies:* @@ -228,8 +230,8 @@ The following tables show the compatibility of the different policy settings and * - Publisher - Subscription - - Connection - - Actual QoS Policy + - Compatible + - Connection Result * - Automatic - Automatic - Yes @@ -237,11 +239,11 @@ The following tables show the compatibility of the different policy settings and * - Automatic - Manual by node - No - - - + - * - Automatic - Manual by topic - No - - - + - * - Manual by node - Automatic - Yes @@ -253,7 +255,7 @@ The following tables show the compatibility of the different policy settings and * - Manual by node - Manual by topic - No - - - + - * - Manual by topic - Automatic - Yes @@ -269,13 +271,15 @@ The following tables show the compatibility of the different policy settings and *Compatibility of lease duration QoS policies:* + Assume *x* and *y* are arbitrary valid duration values. + .. list-table:: :header-rows: 1 * - Publisher - Subscription - - Connection - - Actual QoS Policy + - Compatible + - Connection Result * - Default - Default - Yes @@ -283,7 +287,7 @@ The following tables show the compatibility of the different policy settings and * - Default - *x* - No - - - + - * - *x* - Default - Yes @@ -299,13 +303,13 @@ The following tables show the compatibility of the different policy settings and * - *x* - *y* (where *y* < *x*) - No - - - + - In order for a connection to be made, all of the policies that affect compatibility must be compatible. -That is for example, even if a requested and offered QoS profile pair has compatible reliability QoS policies, but they have incompatible durability QoS policies, a connection will still not be made. +For example, even if a requested and offered QoS profile pair has compatible reliability QoS policies, but they have incompatible durability QoS policies, a connection will still not be made. When connections are not made, no messages will be passed between the publisher and subscription. -There are mechanisms to detect this situation, which will be covered in a later section below. +There are mechanisms to detect this situation, which will be covered in a later section. Comparison to ROS 1 ^^^^^^^^^^^^^^^^^^^ @@ -318,30 +322,32 @@ QoS events ---------- Some QoS policies have possible events related to them. -Developers may provide each publisher and subscription callback functions that are triggered by these QoS events and handle them in a way they see fit, similar to how messages received on a topic are handled. +Developers may provide each publisher and subscription with callback functions that are triggered by these QoS events and handle them in a way they see fit, similar to how messages received on a topic are handled. -The following are the possible QoS events that developers may subscribe to: +Developers may subscribe to the following QoS events that are associated with a publisher: * Offered deadline missed - The publisher did not publish a message within the expected duration that was set out by the actual deadline QoS policy. - -* Requested deadline missed - - The subscription did not receive a message within the expected duration that was set out by the actual deadline QoS policy. + The publisher has not published a message within the expected duration that was set out by the deadline QoS policy. * Liveliness lost The publisher has failed to indicate its liveliness within the lease duration. -* Liveliness changed - - The subscription has noticed that one or more publishers on the topic that it is subscribed to has failed to indicate their liveliness within the lease duration. - * Offered incompatible QoS The publisher has encountered a subscription on the same topic that is requesting a QoS profile that the offered QoS profile cannot satisfy, resulting in no connection between the publisher and that subscription. +Developers may subscribe to the following QoS events that are associated with a subscription: + +* Requested deadline missed + + The subscription has not received a message within the expected duration that was set out by the deadline QoS policy. + +* Liveliness changed + + The subscription has noticed that one or more publishers on the subscribed topic has failed to indicate their liveliness within the lease duration. + * Requested incompatible QoS The subscription has encountered a publisher on the same topic that is offering a QoS profile that does not satisfy the requested QoS profile, resulting in no connection between the subscription and that publisher. From 6207af02fc6f3a9a43ba6ae951f641a45ccb90b2 Mon Sep 17 00:00:00 2001 From: Miaofei Date: Mon, 11 May 2020 14:14:05 -0700 Subject: [PATCH 4/5] remove mentions of "qos profile of the connection" Signed-off-by: Miaofei --- .../About-Quality-of-Service-Settings.rst | 38 +------------------ 1 file changed, 2 insertions(+), 36 deletions(-) diff --git a/source/Concepts/About-Quality-of-Service-Settings.rst b/source/Concepts/About-Quality-of-Service-Settings.rst index e324e1ff3fa..31c49c3d8a5 100644 --- a/source/Concepts/About-Quality-of-Service-Settings.rst +++ b/source/Concepts/About-Quality-of-Service-Settings.rst @@ -129,9 +129,9 @@ A connection between a publisher and a subscription is only made if the pair has QoS profile compatibility is determined based on a “Request vs Offered” model. Subscriptions *request* a QoS profile that is the “minimum quality” that it is willing to accept, and publishers *offer* a QoS profile that is the “maximum quality” that it is able to provide. - Connections are only made if every policy of the requested QoS profile is not more stringent than that of the offered QoS profile. -The requested QoS profile, if compatible with the offered QoS profile, will be the resulting QoS profile of the connection. +Multiple subscriptions can be connected to a single publisher simultaneously even if their requested QoS profiles are different. +The compatibility between a publisher and a subscription is unaffected by the presence of other publishers and subscriptions. The following tables show the compatibility of the different policy settings and the result: @@ -143,23 +143,18 @@ The following tables show the compatibility of the different policy settings and * - Publisher - Subscription - Compatible - - Connection Result * - Best effort - Best effort - Yes - - Best effort * - Best effort - Reliable - No - - * - Reliable - Best effort - Yes - - Best effort * - Reliable - Reliable - Yes - - Reliable *Compatibility of durability QoS policies:* @@ -169,23 +164,18 @@ The following tables show the compatibility of the different policy settings and * - Publisher - Subscription - Compatible - - Connection Result * - Volatile - Volatile - Yes - - Volatile * - Volatile - Transient local - No - - * - Transient local - Volatile - Yes - - Volatile * - Transient local - Transient local - Yes - - Transient local *Compatibility of deadline QoS policies:* @@ -197,31 +187,24 @@ The following tables show the compatibility of the different policy settings and * - Publisher - Subscription - Compatible - - Connection Result * - Default - Default - Yes - - Infinite * - Default - *x* - No - - * - *x* - Default - Yes - - *x* * - *x* - *x* - Yes - - *x* * - *x* - *y* (where *y* > *x*) - Yes - - *y* * - *x* - *y* (where *y* < *x*) - No - - *Compatibility of liveliness QoS policies:* @@ -231,43 +214,33 @@ The following tables show the compatibility of the different policy settings and * - Publisher - Subscription - Compatible - - Connection Result * - Automatic - Automatic - Yes - - Automatic * - Automatic - Manual by node - No - - * - Automatic - Manual by topic - No - - * - Manual by node - Automatic - Yes - - Automatic * - Manual by node - Manual by node - Yes - - Manual by node * - Manual by node - Manual by topic - No - - * - Manual by topic - Automatic - Yes - - Automatic * - Manual by topic - Manual by node - Yes - - Manual by node * - Manual by topic - Manual by topic - Yes - - Manual by topic *Compatibility of lease duration QoS policies:* @@ -279,31 +252,24 @@ The following tables show the compatibility of the different policy settings and * - Publisher - Subscription - Compatible - - Connection Result * - Default - Default - Yes - - Infinite * - Default - *x* - No - - * - *x* - Default - Yes - - *x* * - *x* - *x* - Yes - - *x* * - *x* - *y* (where *y* > *x*) - Yes - - *y* * - *x* - *y* (where *y* < *x*) - No - - In order for a connection to be made, all of the policies that affect compatibility must be compatible. For example, even if a requested and offered QoS profile pair has compatible reliability QoS policies, but they have incompatible durability QoS policies, a connection will still not be made. From 5009047e73f0fffb8e3bbd4aa2895a8beb161b15 Mon Sep 17 00:00:00 2001 From: Miaofei Date: Mon, 11 May 2020 14:22:59 -0700 Subject: [PATCH 5/5] remove mentions of "manual by node" Signed-off-by: Miaofei --- .../About-Quality-of-Service-Settings.rst | 16 ---------------- 1 file changed, 16 deletions(-) diff --git a/source/Concepts/About-Quality-of-Service-Settings.rst b/source/Concepts/About-Quality-of-Service-Settings.rst index 31c49c3d8a5..560dae5d717 100644 --- a/source/Concepts/About-Quality-of-Service-Settings.rst +++ b/source/Concepts/About-Quality-of-Service-Settings.rst @@ -56,7 +56,6 @@ The base QoS profile currently includes settings for the following policies: * 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 node*: the system will consider all of the node’s publishers to be alive for another “lease duration” when any one of the node’s publishers manually asserts that it is still alive (via a call to the publisher API). * *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 @@ -217,27 +216,12 @@ The following tables show the compatibility of the different policy settings and * - Automatic - Automatic - Yes - * - Automatic - - Manual by node - - No * - Automatic - Manual by topic - No - * - Manual by node - - Automatic - - Yes - * - Manual by node - - Manual by node - - Yes - * - Manual by node - - Manual by topic - - No * - Manual by topic - Automatic - Yes - * - Manual by topic - - Manual by node - - Yes * - Manual by topic - Manual by topic - Yes