RTI Connext DDS Micro
Version 2.4.6
|
<<cert>> Specifies whether it is allowed for multiple DDS_DataWriter (s) to write the same instance of the data and if so, how these modifications should be arbitrated. More...
#include <dds_c_infrastructure.h>
Data Fields | |
DDS_OwnershipQosPolicyKind | kind |
The kind of ownership. More... | |
<<cert>> Specifies whether it is allowed for multiple DDS_DataWriter (s) to write the same instance of the data and if so, how these modifications should be arbitrated.
This policy controls whether RTI Connext Micro allows multiple DDS_DataWriter objects to update the same instance (identified by DDS_Topic + key) of a data type. There are two kinds of owner selected by the setting of the kind:
SHARED and EXCLUSIVE.
DDS_SHARED_OWNERSHIP_QOS indicates that RTI Connext Micro does not enforce unique ownership for each instance. In this case, multiple writers can update the same data type instance. The subscriber to the DDS_Topic will be able to access modifications from all DDS_DataWriter objects, subject to the settings of other QoS that may filter particular samples (e.g. the HISTORY policy). In any case there is no "filtering" of modifications made based on the identity of the DDS_DataWriter that causes the modification.
DDS_EXCLUSIVE_OWNERSHIP_QOS indicates that each instance of a data type can only be modified by one DDS_DataWriter. In other words, at any point in time a single DDS_DataWriter owns each instance and is the only one whose modifications will be visible to the DDS_DataReader objects. The owner is determined by selecting the DDS_DataWriter with the highest value of the DDS_OwnershipStrengthQosPolicy::value that is currently alive as defined by the LIVELINESS policy and has not violated its DEADLINE contract with regards to the data-instance. Ownership can therefore change as a result of:
The value of the DDS_OwnershipQosPolicyKind offered must exactly match the one requested or else they are considered incompatible.
It is expected that users may use DDS to set up redundant systems where multiple DDS_DataWriter entities are "capable" of writing the same instance. In this situation, the DDS_DataWriter entities are configured such that:
This determination is reasonably simple when the data is being written periodically at some rate. The DDS_DataWriter simply states its offered DDS_DeadlineQosPolicy (maximum interval between updates) and the DDS_DataReader automatically monitors that the DDS_DataWriter indeed updates the instance at least once per DDS_DeadlineQosPolicy::period. If the deadline is missed, the DDS_DataReader considers the DDS_DataWriter "not alive" and automatically gives ownership to the next highest-strength DDS_DataWriter that is alive.
The case where the DDS_DataWriter is not writing data periodically is also a very important use-case. Since the instance is not being updated at any fixed period, the "deadline" mechanism cannot be used to determine ownership. The liveliness solves this situation. Ownership is maintained while the DDS_DataWriter is "alive" and for the DDS_DataWriter to be alive it must fulfill its DDS_LivelinessQosPolicy contract. The different means to renew liveliness (automatic, manual) combined by the implied renewal each time data is written handle the three conditions above [crash], [connectivity loss], and [application fault]. Note that to handle [application fault], LIVELINESS must be DDS_MANUAL_BY_TOPIC_LIVELINESS_QOS. The DDS_DataWriter can retain ownership by periodically writing data or else calling assert_liveliness if it has no data to write. Alternatively if only protection against [crash] or [connectivity loss] is desired, it is sufficient that some task on the DDS_DataWriter process periodically writes data . However, this scenario requires that the DDS_DataReader knows what instances are being "written" by the DDS_DataWriter. That is the only way that the DDS_DataReader deduces the ownership of specific instances from the fact that the DDS_DataWriter is still "alive".
There are applications that are designed in such a way that their correct operation requires some minimal topological connectivity, that is, the writer needs to have a minimum number of readers or alternatively the reader must have a minimum number of writers. A common scenario is that the application does not start doing its logic until it knows that some specific writers have the minimum configured readers (e.g the alarm monitor is up). A more common scenario is that the application logic will wait until some writers appear that can provide some needed source of information (e.g. the raw sensor data that must be processed). Furthermore, once the application is running it is a requirement that this minimal connectivity (from the source of the data) is monitored and the application informed if it is ever lost. For the case where data is being written periodically, the DDS_DeadlineQosPolicy and the on_deadline_missed listener provides the notification. The case where data is not periodically updated requires the use of the DDS_LivelinessQosPolicy to detect whether the "connectivity" has been lost, and the notification is provided by means of DDS_NOT_ALIVE_NO_WRITERS_INSTANCE_STATE. In terms of the required mechanisms, the scenario is very similar to the case of maintaining ownership. In both cases, the reader needs to know whether a writer is still "managing the current value of an instance" even though it is not continually writing it and this knowledge requires the writer to keep its liveliness. For a DDS_Topic with DDS_EXCLUSIVE_OWNERSHIP_QOS, if the current owner of an instance disposes it, the readers accessing the instance will see the instance_state as being "DISPOSED" and not see the values being written by the weaker writer (even after the stronger one has disposed the instance). This is because the DDS_DataWriter that owns the instance is saying that the instance no longer exists (e.g. the master of the database is saying that a record has been deleted) and thus the readers should see it as such.
DDS_OwnershipQosPolicyKind DDS_OwnershipQosPolicy::kind |
The kind of ownership.
[default] DDS_SHARED_OWNERSHIP_QOS