domain filtering

9 posts / 0 new
Last post
fps
fps's picture
Offline
Last seen: 1 year 7 months ago
Joined: 01/17/2013
Posts: 16
domain filtering

Hi,

There is a computer on the network publishing a topic on domain 2. When I start my computer and listen to the same topic on domain 1, I see my network traffic increase dramatically (even though I quite rightly cannot see the messages).

Is it correct to assume that the domain filtering is being done on my computer (the subscriber)?

Is is possible to change it so that the domain filtering is performed by the publisher instead? (so that it doesn't bother sending me its samples)

We are using udp multicast.

Thank you,

Fidel

Keywords:
rip
rip's picture
Offline
Last seen: 1 month 2 weeks ago
Joined: 04/06/2012
Posts: 315

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.

 

fps
fps's picture
Offline
Last seen: 1 year 7 months ago
Joined: 01/17/2013
Posts: 16

Thanks for the reply Richard, much appreciated. I suspect it might be more than discovery traffic because the publisher is sending at 50Mbit and the traffic I'm seeing on my NIC is 50MBit (once my domain 1 application has started).

Perhaps we have misconfigured the participant or its QOS settings?

Gerardo Pardo's picture
Offline
Last seen: 3 weeks 2 days ago
Joined: 06/02/2010
Posts: 588

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

 

 

fps
fps's picture
Offline
Last seen: 1 year 7 months ago
Joined: 01/17/2013
Posts: 16

Many thanks Gerardo. We've had a look and IGMP snooping is enabled. (We could also tell that was the case because when the domain 1 application (subscriber) is closed, the traffic stops arriving on the NIC)

Our QOS settings file defines a specific address for the topic:

/qos_profile/datareader_qos/multicast/value/element/receive_address

Could this be causing all domains to publish to the same multicast address?

Thanks,

Fidel

Gerardo Pardo's picture
Offline
Last seen: 3 weeks 2 days ago
Joined: 06/02/2010
Posts: 588

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

fps
fps's picture
Offline
Last seen: 1 year 7 months ago
Joined: 01/17/2013
Posts: 16

Thanks again Gerardo. Yes, we are using the same multicast IP address for the DataReaders on both domains. So that explains it! Also, we have left the port blank. This page says that if the port is left blank, the chosen port will be a function of the domain id. Are you saying that isn't the case?

Gerardo Pardo's picture
Offline
Last seen: 3 weeks 2 days ago
Joined: 06/02/2010
Posts: 588

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

fps
fps's picture
Offline
Last seen: 1 year 7 months ago
Joined: 01/17/2013
Posts: 16

I see! Thanks so much Gerardo. As always you have been a tremendous help :)

Best regards,
Fidel