domain filtering

If they are on different domains, they will not be seen by each other, as they are selecting different UDP/IP port ranges.

But:  They will still be sending discovery messages to the discovery multicast address, in order to discover that there is nobody there.  The assumption being made by the domain participants is that there will eventually be another participant at the ports being checked, and so they will periodically 'ping' those ports until something appears.

So, what you are (probably) seeing is discovery traffic.  Use the search bar above to look for pages on "how to tune discovery traffic"; it is also covered in the documentation.  Every domain participant you add to the graph will entail additional discovery traffic overhead, but you can reduce both the number of peers each one is looking for, and you can also stretch out the delay between discovery announcements.  There are knobs which may be twiddled in order to maximise the performance/overhead ratio for your system.

Using subscriber-defined filtering (content filter topics), and allowing the publishing side to filter samples and instances, will not prevent the discovery traffic from happening.

Hi,

Discovery works the following way:

• When a Participant is created it send a few (2-3) messages to the standard RTPS multicast address to a port number that depends on the domainId.  E.g. by default for DomainId=0 that port is 7400. For domainId=1 it is 7650, and for domain 2 its is 7900. See https://community.rti.com/content/forum-topic/statically-configure-firewall-let-omg-dds-traffic-through.
• Absent other DomainParticipants on the same DomainId only thing that gets sent to this port is a periodic "Participant Announcement" which is a pretty small message. The default period for this is about 100 seconds if I recall correctly.
• If other DomainParticipants appaer on the same domain, then once the participants discover each other they will send additional discovery data on the DataWriters and DataReaders, and eventually, assuming there is a match, actual application user data.

So "domain filtering" to use your words is actually happening by the operating-system and network switches in that the messags are being directed to different ports.  However there are some caveats depending on how your network is configured...

If you are using a switch that does not support "ICMP" snooping, then multicast traffic will be forwarded by the switch to all its output ports, just in case there is someone there. This is a problem because then the operating system UDP stack will get the packet, see it is for a port that it does not have open (because it is a different domainId) and drop the packet, and to make things worse reply with an ICMP 'port unreachable; message. If you have many computers on that network, even if they are not running DDS, they will all reply with ICMP port unreachable... 

This will also happen for application data if you are sending it via multicast. This can explain why you see the extra 50Mbit/sec when you are publishing on the other domain.

So my suspicion is that this is caused by a swich that either does not suport IGMP snooping, or has it disabled. The easiest way to confirm this would be to use Wireshark to capture some UDP traffic. It already has an RTPS2 dissector and you will be able to see the nature of the extra traffic you are receiving.

Gerardo

Are you using the same multicast IP address for the DataReaders on both domains with same or different port? If so then that would cause the problem you describe because the multicast routing/forwarding is based only on the "IP address" part and ignores the port number. 

Gerardo

The port number will be chosen as a function of the domainId so different ports will be chosen for different domains. That is true.

However the IGMP protocol and the multicast routing/forwarding performed by the switches and routers do not look at the port number at all. The decision is made based on the IP address alone. So the fact that two different ports are used does not help that much. It helps a little in that when the packet arrives the operating system/network stack will notice it is for a port that is not open and will drop it, rather than delivering it to DDS and having the middleware drop it. But still the packet will show up at the network interface and the computer will have to waste CPU discarding it. So you should definitely use different IP multicast addresss for different domains.

Gerardo