Currently, there is nothing stopping a subscriber from receiving messages from both the intra process mechanism and the inter-process mechanism. Therefore publishers and subscriptions connected by intra process should avoid (through filtering or some other mechanism) exchanging messages using the inter process communications.

So far I have looked into:

• Publisher side filtering: before calling rmw_publish, make sure someone is going to get it, i.e. len(connected_subscritpions - intra_process_subscriptions) > 0.
  • The problem with this is latching. If we never call rmw_publish then when a new subscription comes up the message will not be delivered via the latched mechanism.
• Using the DDS functions like ignore_subscription (https://community.rti.com/static/documentation/connext-dds/5.2.0/doc/api/connext_dds/api_cpp/classDDSDomainParticipant.html#ad9b1a187eabf36e2c370bbe1b87f76b0)
  • I haven't gotten this to work as expected, I think because of when the function must be called (cannot be called after creating the publisher), but it needs more investigation.
  • It is not implemented by some vendors like OpenSplice.
• Subscription side filtering: simply not delivering messages received from inter process from publishers which are connected via intra process.
  • This is inefficient since the publisher has to serialize and send and the subscription must then receive and deserialize the message before dropping it.
  • Without help from the middleware this may have to happen anyways (like if multicast is being used).

As a stop gap measure we should implement the subscription side filtering so that users don't get duplicate callbacks when intra process is being used.

If other methods become available then we can change how we do it then.