FYI: the master is not involved in datastreams for topics after two nodes have negotiated their connections (see wiki/Master fi). This doesn't necessarily change your problem, but your 'diagram' is only valid for the initial negotiation phase. wiki/ROS/Technical Overview is also a good link with info on how the master and nodes interact.
Also: this sounds a bit like an xy-problem. What is the real issue that you are trying to solve? Is it lowering traffic on your radio-link, or do you want all traffic, but want to be able to prioritise?
Edit:
My TCPROS jargon wasn't accurate enough. I edited the question accordingly.
I have the same example, camera and viewer, and roscore is running in the same host as the viewer is. Once connections are negotiated, topic datastreams are flowing through the RF link, and I'd like to apply topic filtering
When the RF link is saturated (bottleneck) we need to lower the traffic, dropping packets from low priority topics. Ideally TCP would try to resend this packets and our RF link should be able to send them eventually.
Anyway, simply put: Yes, we want to lower the traffic on our radio-link.
I would look into the things the teams in the DRC did: they had to work with low-bw, high-latency and lossy links all the time. I remember some of them implementing custom gateways (nodes) that used UDP to 'bridge' over the wireless links.
(related thought: ROS2 / DDS should actually make this much simpler: proper QoS settings should make this easier)
I would also look into separation of ROS graph sections, the way multi-master setups allow you to. That should make it possible to completely control which topics do get tranmitted over your wireless link. Do all 71 topics actually need to be transmitted?
What you are asking is probably possible (you could probably use the master to track IP:PORT combos for pub/subs, etc), but it might be easier to achieve your goal in a different way, hence my suggestions. I also purposefully used comments, to not answer your question with non-answers.
Edit2:
ROS2/DDS: I forgot to mention we don't have access to the endpoints, as they belong to another company and ROS version is fixed. We are only in charge of the radio platforms and RF link. To inform us which topics are high priority they appended a prefix to each topic, like: /high/flir/imageraw
pfew. Raw images over a radio link. There are lossless compression options (compressed_image_transport with PNG fi) that save quite some bandwidth. Irrespective of what you end up doing I would look into that.
About the UDP Bridge: that's mainly what our radio platforms do. I'll try to check DRC projects.
About tracking IP:PORT: I guess that's our only choice to implement within the radio platform. But it doesn't seem too straight forward.
yes, that is probably not straightforward, and it'll probably be brittle as ... (more)
Thank you @gvdhoonr, you've already given us plenty of useful information to start working with. I consider all your comments made more than a full answer so I'll add an answer redirecting to these comments. Regards.
I've merged my comments into an answer. If you want (and consider your question answered) you could accept that answer.
Btw: your question was more a discussion, which would probably have worked better over at
discourse.ros.org. The one-question-one-answer structure of ROS Answers isn't really suited for that.I've also given you enough karma to attach an image to your question (if you'd like to replace your ascii diagram).
Done. Thank you again, gvdhoorn.
No problem.
Keep us up-to-date on what you eventually decide to do. I'm interested to see whether something like this is doable (with reasonable effort).