domain participant ignore

[carlocorradini]

I’ve noticed that the domain participant provides some very convenient functions:

• ignore_participant
• ignore_topic
• ignore_publication
• ignore_subscription

I'm primarily interested in ignore_participant, as I want all data published by this participant to be ignored by all of its readers;

domain_participant.ignore_participant(domain_participant.get_instance_handle()).unwrap();

However, it appears that it does not work since all published data is still being read by the readers.
While examining the code, I found some tests related to these functions, but they are ignored because the implementation is considered incomplete.

May I help to fully implement these highly useful functions? 🙌🥳

Checklist:

• feat: ignore participant #499
• ignore_publication
• ignore_subscription
• ignore_topic

[jrebelo]

Any help with this issue would be highly appreciated! I will try to explain how I would approach solving this to help you getting started.

[jrebelo]

The first case is when a participant gets ignored before discovery:

• Once you call ignore_participant, the handle for the participant to be ignored is internally stored:

  dust-dds/dds/src/dcps/domain_participant.rs

  Line 1485 in fecb9b3

  self.domain_participant.ignored_participants.push(handle);

• In the add_discovered_participant method

  dust-dds/dds/src/dcps/domain_participant.rs

  Line 5916 in fecb9b3

  async fn add_discovered_participant(

  you would need to add a let is_participant_ignored to check if this participant is ignored. If it is ignored then it shouldn't be added to any list.

This is pretty much it for this case and should be relatively straightforward to implement.

[jrebelo]

The second case is much more interesting, which is when you ignore the participant after the discovery has already happened. In that case, the method ignore_participant

dust-dds/dds/src/dcps/domain_participant.rs

Line 1485 in fecb9b3

self.domain_participant.ignored_participants.push(handle);

will need to be extended. I expect the following actions would need to be done:

• Go through all the readers in the user_defined_subscriber_list and remove every writer_proxy coming from that participant (this should probably trigger the PublicationMatched to notify listeners something has happened). I think all the samples coming from those writers would also have to be removed from the sample list to make sure they are not given out to the user. (This would probably qualify for an individual test already from an end-user perspective)
• Go through all the writers in the user_defined_publisher_list and remove every reader_proxy coming from that participant. Likely also trigger the SubscriptionMatched for this case. Here I don't think there is anything to do with samples.
• Remove all the matched detectors and announcers (the inverse operation of this https://github.com/s2e-systems/dust-dds/blob/fecb9b323b342989a67291c11e5cf1fbd77ad947/dds/src/dcps/domain_participant.rs#L5947C12-L5958C24) to prevent the SEDP discovery from continuing towards the ignored participant. The name of the methods to add and remove these endpoints comes from the RTPS standard so please have a look there for inspiration on how to name these things: https://www.omg.org/spec/DDSI-RTPS/2.3/PDF

I hope this helps a bit in getting going. Let me know if you have any questions and I will try my best to help you further.

It would be a great contribution and I look forward to review the PR :)

[carlocorradini]

@jrebelo In async fn add_discovered_participant.

Is the following correct for checking whether a discovered participant should be ignored, or am I missing something?

let is_participant_ignored =
            self.domain_participant
                .ignored_participants
                .iter()
                .any(|handle| {
                    handle.guid() == discovered_participant_data.participant_proxy.guid_prefix
                });

or

let is_participant_ignored = self
            .domain_participant
            .ignored_participants
            .iter()
            .any(|handle| handle == &discovered_participant_data.dds_participant_data.key.value);

[carlocorradini]

@jrebelo

Go through all the readers in the user_defined_subscriber_list and remove every writer_proxy coming from that participant (this should probably trigger the PublicationMatched to notify listeners something has happened). I think all the samples coming from those writers would also have to be removed from the sample list to make sure they are not given out to the user. (This would probably qualify for an individual test already from an end-user perspective)

Where is the writer_proxy?

Remove samples with writers associated with the domain participant’s handle (checking guid prefix or?):

for user_defined_subscriber in &mut self.domain_participant.user_defined_subscriber_list {
    for data_reader in &mut user_defined_subscriber.data_reader_list {
        data_reader
            .sample_list
            .retain(|sample| &sample.writer_guid[..12] != handle.guid_prefix());
    }
}

[carlocorradini]

@jrebelo In async fn add_discovered_participant.

Is the following correct for checking whether a discovered participant should be ignored, or am I missing something?

let is_participant_ignored =
self.domain_participant
.ignored_participants
.iter()
.any(|handle| {
handle.guid() == discovered_participant_data.participant_proxy.guid_prefix
});

or

let is_participant_ignored = self
.domain_participant
.ignored_participants
.iter()
.any(|handle| handle == &discovered_participant_data.dds_participant_data.key.value);

@jrebelo Which one is correct, the first or the second? 😥

[jrebelo]

@jrebelo In async fn add_discovered_participant.
Is the following correct for checking whether a discovered participant should be ignored, or am I missing something?
let is_participant_ignored =
self.domain_participant
.ignored_participants
.iter()
.any(|handle| {
handle.guid() == discovered_participant_data.participant_proxy.guid_prefix
});
or
let is_participant_ignored = self
.domain_participant
.ignored_participants
.iter()
.any(|handle| handle == &discovered_participant_data.dds_participant_data.key.value);

@jrebelo Which one is correct, the first or the second? 😥

They are most likely equivalent but I would say the second is nicer to read.

[jrebelo]

@jrebelo

Go through all the readers in the user_defined_subscriber_list and remove every writer_proxy coming from that participant (this should probably trigger the PublicationMatched to notify listeners something has happened). I think all the samples coming from those writers would also have to be removed from the sample list to make sure they are not given out to the user. (This would probably qualify for an individual test already from an end-user perspective)

Where is the writer_proxy?

Remove samples with writers associated with the domain participant’s handle (checking guid prefix or?):

for user_defined_subscriber in &mut self.domain_participant.user_defined_subscriber_list {
for data_reader in &mut user_defined_subscriber.data_reader_list {
data_reader
.sample_list
.retain(|sample| &sample.writer_guid[..12] != handle.guid_prefix());
}
}

The writer proxy is inside the RtpsStatefulReader struct which is inside an enum in the DataReaderEntity.

I think using the guid_prefix is a good solution to remove the samples.

[carlocorradini]

@jrebelo Is something like the following good? What am I missing, and how can I remove all matched detectors and announcers? Is there a method for that?

#[tracing::instrument(skip(self))]
pub fn ignore_participant(&mut self, handle: InstanceHandle) -> DdsResult<()> {
    if !self.domain_participant.enabled {
        return Err(DdsError::NotEnabled);
    }

    self.domain_participant.ignored_participants.insert(handle);

    // The following should be put in a dedicated method
    for user_defined_subscriber in &mut self.domain_participant.user_defined_subscriber_list {
        for data_reader in &mut user_defined_subscriber.data_reader_list {
            // Delete writer proxy
            if let TransportReaderKind::Stateful(stateful_reader) = &mut data_reader.transport_reader {
                stateful_reader.delete_matched_writer(handle);
            }
            
            // Delete samples
            data_reader
                .sample_list
                .retain(|sample| &sample.writer_guid[..12] != handle.guid_prefix());
        }
    }

    Ok(())
}

[carlocorradini]

@jrebelo What is the difference between InstanceHandle and Guid?

[jrebelo]

@jrebelo What is the difference between InstanceHandle and Guid?

The GUID is defines on the RTPS and wire level. It must be unique for all the objects connected on the communication layer. The InstanceHandle is an identifier for DDS object and should only be locally unique (you could think of it as a pointer address) but we directly convert the GUID into the InstanceHandle.