RTI Connext DDS Micro  Version 2.4.10
 All Data Structures Files Functions Variables Typedefs Enumerations Enumerator Macros Groups Pages
DDS_Listener Struct Reference

<<interface>> Abstract base class for all Listener interfaces. More...

#include <dds_c_infrastructure.h>

Data Fields

void * listener_data
 A place for listener implementors to keep a pointer to data that may be needed by their listener.

Detailed Description

<<interface>> Abstract base class for all Listener interfaces.

QoS Policies
Status Kinds All the supported kinds of concrete DDS_Listener interfaces (one per concrete DDS_Entity type) derive from this root and add functions whose prototype depends on the concrete Listener. Listeners provide a way for RTI Connext Micro to asynchronously alert the application when there are relevant status changes. Almost every application will have to implement listener interfaces. Each dedicated listener presents a list of operations that correspond to the relevant communication status changes to which an application may respond. The same DDS_Listener instance may be shared among multiple entities if you so desire. Consequently, the provided parameter contains a reference to the concerned DDS_Entity.

Access to Plain Communication Status

The general mapping between the plain communication statuses (see Status Kinds) and the listeners' operations is as follows:

  • For each communication status, there is a corresponding operation whose name is on_<communication_status>(), which takes a parameter of type <communication_status> as listed in Status Kinds.
  • on_<communication_status> is available on the relevant DDS_Entity as well as those that embed it, as expressed in the following figure:
    "Hierarchical listener processing. The most specific relevant enabled listener is called."
  • When the application attaches a listener on an entity, it must set a mask. The mask indicates to RTI Connext Micro which operations are enabled within the listener (cf. operation DDS_Entity set_listener() ).
  • When a plain communication status changes, RTI Connext Micro triggers the most specific relevant listener operation that is enabled. In case the most specific relevant listener operation corresponds to an application-installed 'nil' listener the operation will be considered handled by a NO-OP operation that does not reset the communication status. This behavior allows the application to set a default behavior (e.g., in the listener associated with the DDS_DomainParticipant) and to set dedicated behaviors only where needed.

Access to Read Communication Status

The two statuses related to data arrival are treated slightly differently. Since they constitute the core purpose of the Data Distribution Service, there is no need to provide a default mechanism (as is done for the plain communication statuses above). The rule is as follows. Each time the read communication status changes:

Field Documentation

void* DDS_Listener::listener_data

A place for listener implementors to keep a pointer to data that may be needed by their listener.

RTI Connext DDS Micro Version 2.4.10 Copyright © Fri Jun 30 2017 Real-Time Innovations, Inc