Status Kinds

Kinds of communication status. More...

Classes
class	dds::core::status::StatusMask
	A std::bitset (list) of statuses. More...
class	dds::core::status::InconsistentTopicStatus
	Information about the status dds::core::status::StatusMask::inconsistent_topic() More...
class	dds::core::status::SampleLostStatus
	Information about the status dds::core::status::StatusMask::sample_lost() More...
class	dds::core::status::SampleRejectedStatus
	Information about the status dds::core::status::StatusMask::sample_rejected() More...
class	dds::core::status::LivelinessLostStatus
	Information about the status dds::core::status::StatusMask::liveliness_lost() More...
class	dds::core::status::LivelinessChangedStatus
	Information about the status dds::core::status::StatusMask::liveliness_changed() More...
class	dds::core::status::OfferedDeadlineMissedStatus
	Information about the status dds::core::status::StatusMask::offered_deadline_missed() More...
class	dds::core::status::RequestedDeadlineMissedStatus
	Information about the status dds::core::status::StatusMask::requested_deadline_missed() More...
class	dds::core::status::OfferedIncompatibleQosStatus
	Information about the status dds::core::status::StatusMask::offered_incompatible_qos() More...
class	dds::core::status::RequestedIncompatibleQosStatus
	Information about the status dds::core::status::StatusMask::requested_incompatible_qos() More...
class	dds::core::status::PublicationMatchedStatus
	Information about the status dds::core::status::StatusMask::publication_matched() More...
class	dds::core::status::SubscriptionMatchedStatus
	Information about the status dds::core::status::StatusMask::subscription_matched() More...
class	rti::core::status::EventCount< IntegerType >
	<<extension>> <<value-type>> Encapsulates an event count containing a total count and an incremental count since the last time a status was read. More...
class	rti::core::status::DataReaderCacheStatus
	<<extension>> Information about the status dds::core::status::StatusMask::datareader_cache() More...
class	rti::core::status::DataReaderProtocolStatus
	<<extension>> Information about the status dds::core::status::StatusMask::datareader_protocol() More...
class	rti::core::status::DataWriterCacheStatus
	<<extension>> Information about the status dds::core::status::StatusMask::datawriter_cache() More...
class	rti::core::status::ReliableWriterCacheChangedStatus
	<<extension>> Information about the status dds::core::status::StatusMask::reliable_writer_cache_changed() More...
class	rti::core::status::ReliableReaderActivityChangedStatus
	<<extension>> Information about the status dds::core::status::StatusMask::reliable_reader_activity_changed() More...
class	rti::core::status::DataWriterProtocolStatus
	<<extension>> Information about the status dds::core::status::StatusMask::datawriter_protocol() More...
class	rti::core::status::DomainParticipantProtocolStatus
class	rti::core::status::ServiceRequestAcceptedStatus
	<<extension>> Information about the status dds::core::status::StatusMask::service_request_accepted() More...

Detailed Description

Kinds of communication status.

Entity:

dds::core::Entity

QoS:

QoS Policies

Listener:

Listener

Each concrete dds::core::Entity is associated with a set of Status objects whose value represents the communication status of that entity. Each status value can be accessed with a corresponding method on the dds::core::Entity.

When these status values change, the corresponding dds::core::cond::StatusCondition objects are activated and the proper Listener objects are invoked to asynchronously inform the application.

An application is notified of communication status by means of the Listener or the dds::core::cond::WaitSet / dds::core::cond::Condition mechanism. The two mechanisms may be combined in the application (e.g., using dds::core::cond::WaitSet (s) / dds::core::cond::Condition (s) to access the data and Listener (s) to be warned asynchronously of erroneous communication statuses).

It is likely that the application will choose one or the other mechanism for each particular communication status (not both). However, if both mechanisms are enabled, then the Listener mechanism is used first and then the dds::core::cond::WaitSet objects are signalled.

The statuses may be classified into:

• read communication statuses: i.e., those that are related to arrival of data, namely dds::core::status::StatusMask::data_on_readers() and dds::core::status::StatusMask::data_available().

• plain communication statuses: i.e., all the others.

Read communication statuses are treated slightly differently than the others because they don't change independently. In other words, at least two changes will appear at the same time (dds::core::status::StatusMask::data_on_readers() and dds::core::status::StatusMask::data_available()) and even several of the last kind may be part of the set. This 'grouping' has to be communicated to the application.

For each plain communication status, there is a corresponding structure to hold the status value. These values contain the information related to the change of status, as well as information related to the statuses themselves (e.g., contains cumulative counts).

Status Values

Changes in Status

Associated with each one of an dds::core::Entity's communication status is a logical StatusChangedFlag. This flag indicates whether that particular communication status has changed since the last time the status was read by the application. The way the status changes is slightly different for the Plain Communication Status and the Read Communication status.

StatusChangedFlag indicates if status has changed

Changes in plain communication status

For the plain communication status, the StatusChangedFlag flag is initially set to FALSE. It becomes TRUE whenever the plain communication status changes and it is reset to false each time the application accesses the plain communication status via the proper getter operation on the dds::core::Entity.

The communication status is also reset to FALSE whenever the associated listener operation is called as the listener implicitly accesses the status which is passed as a parameter to the operation. The fact that the status is reset prior to calling the listener means that if the application calls the getter from inside the listener it will see the status already reset.

An exception to this rule is when the associated listener is the 'nil' listener. The 'nil' listener is treated as a NOOP and the act of calling the 'nil' listener does not reset the communication status.

For example, the value of the StatusChangedFlag associated with the dds::core::status::StatusMask::requested_deadline_missed() will become TRUE each time new deadline occurs (which increases dds::core::status::RequestedDeadlineMissedStatus::total_count). The value changes to FALSE when the application accesses the status via the corresponding dds::sub::DataReader::requested_deadline_missed_status method on the proper Entity

Changes in StatusChangedFlag for plain communication status

Changes in read communication status

For the read communication status, the StatusChangedFlag flag is initially set to FALSE. The StatusChangedFlag becomes TRUE when either a data-sample arrives or else the dds::sub::status::ViewState, dds::sub::status::SampleState, or dds::sub::status::InstanceState of any existing sample changes for any reason other than a call to dds::sub::DataReader::read, dds::sub::DataReader::take or their variants. Specifically any of the following events will cause the StatusChangedFlag to become TRUE:

• The arrival of new data.

• A change in the dds::sub::status::InstanceState of a contained instance. This can be caused by either:

  • The arrival of the notification that an instance has been disposed by:
    • the dds::pub::DataWriter that owns it if OWNERSHIP QoS kind= dds::core::policy::OwnershipKind_def::EXCLUSIVE
    • or by any dds::pub::DataWriter if OWNERSHIP QoS kind= dds::core::policy::OwnershipKind_def::SHARED
  • The loss of liveliness of the dds::pub::DataWriter of an instance for which there is no other dds::pub::DataWriter.
  • The arrival of the notification that an instance has been unregistered by the only dds::pub::DataWriter that is known to be writing the instance.

Depending on the kind of StatusChangedFlag, the flag transitions to FALSE again as follows:

• The dds::core::status::StatusMask::data_available() StatusChangedFlag becomes FALSE when either the corresponding listener operation (on_data_available) is called or the read or take operation (or their variants) is called on the associated dds::sub::DataReader.
• The dds::core::status::StatusMask::data_on_readers() StatusChangedFlag becomes FALSE when any of the following events occurs:
  • The corresponding listener operation (on_data_on_readers) is called.
  • The on_data_available listener operation is called on any dds::sub::DataReader belonging to the dds::sub::Subscriber.
  • The read or take operation (or their variants) is called on any dds::sub::DataReader belonging to the dds::sub::Subscriber.

Changes in StatusChangedFlag for read communication status

See Also

Listener

dds::core::cond::WaitSet, dds::core::cond::Condition