Supervising Endpoint Discovery

It is possible to control for which DomainParticipants endpoint discovery may occur. You can configure this behavior with the enable_endpoint_discovery field in the DISCOVERY QosPolicy (DDS Extension):

• When set to TRUE (the default value), endpoint discovery will automatically occur for every discovered DomainParticipant. This is the normal operation of the discovery process.
• When set to FALSE, endpoint discovery will be disabled for every discovered DomainParticipant. Then applications will have to manually enable endpoint discovery (described below) for the DomainParticipants they are interested in communicating with. By disabling endpoint discovery, the DomainParticipant will not store any state about remote endpoints and will not send local endpoint information to remote DomainParticipants.

When enable_endpoint_discovery is set to FALSE, you have two options after a remote DomainParticipant is discovered:

• Call the DomainParticipant’s resume_endpoint_discovery() operation to enable endpoint discovery. After invoking this operation, the DomainParticipant will start to exchange endpoint information so that matching and communication can occur with the remote DomainParticipant.

DDS_ReturnCode_t resume_endpoint_discovery( 
	const DDS_InstanceHandle_t & remote_participant_handle)

Or

• Call the DomainParticipant’s ignore_participant() operation to permanently ignore endpoint discovery with the remote DomainParticipant.

Setting enable_endpoint_discovery to FALSE enables application-level authentication use cases, in which a DomainParticipant will resume endpoint discovery with a remote DomainParticipant after successful authentication at the application level. The following example shows how to provide access control using this feature:

class MyParticipantBuiltinTopicDataListener :
		public DDSDataReaderListener {
	public:
	virtual void on_data_available(DDSDataReader *reader);
	// ...
};
void MyParticipantBuiltinTopicdataListener::on_data_available(
	DDSDataReader *reader) {
DDSParticipantBuiltinTopicDataDataReader 
*builtinTopicDataReader =
	DDSParticipantBuiltinTopicDataDataReader *) reader;
DDS_ParticipantBuiltinTopicDataSeq data_seq;
DDS_SampleInfoSeq info_seq;
int = 0;
if (builtinTopicDataReader->take(
	data_seq, info_seq,
	DDS_LENGTH_UNLIMITED, 
	DDS_ANY_SAMPLE_STATE,
	DDS_ANY_VIEW_STATE, 
	DDS_ANY_INSTANCE_STATE)!= DDS_RETCODE_OK){
	// ... error
}
for (i  = 0; i < data_seq.length(); ++i) {
    if (info_seq[i].valid_data) {
	DDSDomainParticipant * localParticipant = 
	  builtinTopicDataReader->
	get_subscriber()->get_participant();
	DDS_ReturnCode_t retCode;
	// check user_data for access control
	if (data_seq[i].user_data[0] != 0x9) {
		retCode = localParticipant->
		    ignore_participant(
			info_seq[i].instance_handle);
	}else {
		retCode = localParticipant->
		    resume_endpoint_discovery(
			info_seq[i].instance_handle)
	}
    }
}
if (builtinTopicDataReader->return_loan(
	data_seq, info_seq) 
	!= DDS_RETCODE_OK) {
	// ... error }
}

© 2016 RTI