Filtering self sent data

[Boereck]

Hi,

When subscribing on a topic that the same participant is publishing to, how can one filter out the messages sent by this same participant. When searching on the internet regarding this topic, the only solutions that come up are to use the DDS_Entity API, which does not seem to be supported by Cyclone DDS.
See also: https://community.rti.com/kb/how-do-i-get-datareader-ignore-datawriter-belongs-same-domainparticipant

From dds_sample_info_t it is possible to access the field publication_handle of type dds_instance_handle_t but it seems this handle does not match the instance handle from the sending publisher or participant (gained by calling dds_get_instance_handle).

It seems the publication_handle is always 1 when the sender is receiving its own data, can this be relied upon as a workaround filtering criterion? Or is there a different API that can be used?

I would appreciate your help! Thanks,
Max

[eboasson]

Hi Max,

The use of ignore_participant for this is (in my opinion) an implementation-specific extension done by RTI, although I do agree that it is a practical approach to providing this functionality. You are correct that Cyclone doesn't support this, but it certainly would be possible to implement it should it prove to be the best approach.

Personally I prefer do so such things via a content filtering — DDS is, after all, a shared data space, and it makes more sense to map a subspace based on content than to "arbitrarily" ignore certain sources. There are two problems in that line of thinking: firstly, content filters aren't yet supported by Cyclone and so the filtering would take place in the application at considerably higher overhead; and secondly the purist take on it requires explicitly modelling the source of the data, and so filtering on publication_handle is also a little ... pragmatic. And if one chooses to be so pragmatic, why then not choose the easier and faster approach recommended by RTI?

For now, I can look at getting the publication_handle correct with priority. The current behaviour is simply a left-over from proof-of-concept days and needs to be fixed anyway. What other options to implement and when to do that requires some thought.

[Boereck]

Hi Erik,

Thanks for your quick reply!

I am currently not sure what you mean by "why then not choose the easier and faster approach recommended by RTI?" if the API used in the example is an implementation-specific extension done by RTI? Can you tell me which APIs I could currently use with the current version of Cyclone?

Let me try to summarize the current state and possible future solutions from what I understood. Please correct me if I am wrong.

Current State

• The way to find out if the data was sent by the participant itself this currently only reliably possible by sending an identifier for the sender with the payload data (defined in the IDL type). The filtering has to take place in the application layer. This, of course, is redundant, since the sender information should already be present in the metadata.
• The publication_handle can currently not be reliably used for filtering on application layer side, because it is an implementation detail that is ought to change anyway.
• Content filtering as a framework feature is currently not supported by Cyclone

Possible Future Solutions

• It could be possible to provide an API to retrieve the publication_handle of a participant to allow filtering on application level.
• The more elegant and less overhead way would be to allow content filtering in the framework. This requires more design work.

[eboasson]

Hi Max,

By "why then not choose the easier and faster approach recommended by RTI?" I was trying to give a very abbreviated form of the trade-off to be considered here. In any case, the "ignore_participant" API is a standard feature of DCPS, it is just that (in my opinion) the meaning of ignoring oneself is undefined. The choice made by RTI is entirely reasonable and perhaps the simplest way to get an efficient solution to your problem.

Your summary of the current state is essentially correct, except that: "The publication_handle can currently not be reliably used for filtering on application layer side, because it is an implementation detail that is ought to change anyway." in my opinion conveys the wrong impression. That you always get 1 is indeed an implementation detail, but it is also a bug, instead it should provide you with a valid publication_handle that is identical to that returned by the "get_instance_handle" when applied to the writer entity that originally wrote the sample. This bug I will fix asap. Then, you can filter using the publication_handle.

On a side note: temporarily (until that bug gets fixed), you could get away with dropping everything with publication_handle 1. The likelihood of a remote writer being assigned that particular value is approximately 2^-64.

At least one of the content filtering and/or the ignore_participant options will be provided in the future. The ignore_participant route is probably the easier, and I can have a look what it would involve, but I am rather reluctant to promise anything in that regard.

[Boereck]

Ah, OK! I actually did not understand that this was a bug and the publication_handle should be the same as the one returned by get_instance_handle when called on the writer.

For me this issue is considered "fixed" as soon as this bug is fixed. Maybe you can reference this issue in your commit (#8), so it can be traced.

General content filtering by the framework would probably be desirable, but I guess a different issue can be opened for planning and tracking of this more advanced feature.

[eboasson]

I believe the publication_handle to be set correctly now, so I'm closing the ticket.

[Boereck]

Just wanted to give feedback that the issue is fixed for me on current master. Thanks for the fast fix!