For a basic setup I would say, no, this isn't possible. Topics are sent peer-to-peer over regular TCP and UDP connections. Ports used are chosen "randomly" by your OS, from the ephemeral range (on Linux at least). Nodes (in ROS 1) don't have any control over this.
This makes it very difficult to create a configuration like you show, as there is essentially no easy way to either:
- force topics to be only published over certain IPs and/or ports
- determine which IPs/ports are used for certain topics
As a 'trick' (and untested):
- use a 'channel' configuration wrt topics, instead of the normal 'bus' (ie: use dedicated topics to 'connect' single publisher-subscriber pairs, and give each pair its own topic)
- make sure you have a 1-to-1 ratio of topic-to-NIC
- force a node (ie: subscriber) to
bind(..)
to a certain NIC (or really: IP, and have different IPs per NIC) - setup routing on publisher(s) to route traffic for certain IPs/networks over certain NICs
Now if #3 is made true (and there are ways to do this), subscribers will only use a specific IP as their originating IP. Publishers will initiate data connections to those IPs. The ports don't matter any more, as we use IPs to separate traffic in this setup (which is nice, as we can control IPs, we can't control ports).
As publishers will see requests for certain topics come from specific IPs, and their routing tables have been setup such that they route traffic for those IPs over specific NICs, you should end up in a situation where certain topics are only published over certain NICs.
But do note the difference with what you are asking: this is not something we can configure ROS to "do for us". We need to configure the OS and our application (ie: ROS nodes) in such a way that the resultant behaviour is what you're after.
A more advanced alternative (so more work, but less IPs needed and more automated): snoop the traffic between the ROS master and nodes (it's basic XML-RPC). Learn which topics are published over which TCP/UDP ports to which subscribers. Now use iptables
to tag traffic over those ports and then route it over specific interfaces based on those tags (with ip
's fwmark
support). Something like this SO question. But this is a bit more complex than the setup I described earlier and interposing routing based on traffic tags may negatively influence performance.
Related/duplicate: #q311530.
And I believe it would be good to mention your previous question (as it's highly related): #q343874.
Finally: could you give an example of the kinds of traffic that you are dealing with? Assuming regular gbit/s network infrastructure, you must have either a lot of subscribers or some very high bw traffic. Perhaps even a very fast, lossless compression algorithm (example: swri-robotics/imagezero_transport, but there are others) might already remove the bottleneck.