How to tell if a discovered topic is for a reader or writer

[samcarey]

I'm trying to figure out how to tell if a discovered topic is a reader or a writer.

Looking at the implementation of the discovered_topics in all_user_topics , it seems that there is a DiscoveredVia enum that could potentially be used to filter the topics based on DiscoveredVia::Publication or DiscoveredVia::Subscription like so:

pub fn discovered_writers(&self) -> impl Iterator<Item = &DiscoveredTopicData> {
    self
      .topics
      .iter()
      .filter(|(s, _)| !s.starts_with("DCPS"))
      .flat_map(move |(_, gm)| {
        gm.iter()
          .filter(|(_, (discovered_via, _))| discovered_via == &DiscoveredVia::Publication)
          .map(|(_, dtd)| &dtd.1)
      })
  }

The problem with this approach is that in , the DiscoveredVia value is overwritten with DiscoveredVia::Topic after a few seconds when more info on the topic is found here.

So, unless there's already a way to permanently distinguish readers from writers, I would propose that instead of overwriting the previous value with "DiscoveredVia::Topic", the original value be preserved somehow and used to filter with something like the function above. I might just patch in some extra variants (e.g. TopicPreviouslyPublication) temporarily for my immediate purposes. I'm still not sure if this would work if somehow the original DiscoveredVia::Publication was never set in the first place, if that's even possible. If you think that would be the best approach, I can open a PR.

Thanks!

[Juhana Helovuo]

There seems to be some confusion in your question:

... tell if a discovered topic is a reader or a writer.

Topics are not Readers or Writers. Topics are like chat rooms that may have any number of Readers or Writers connected.

The code you are referring to in Discovery is just making note of how we found out that a Topic exists. It can be either by receiving an announcement of a Reader, Writer, or just about the Topic itself.

Or maybe this is an XY problem? What are you ultimately trying to accomplish?

[samcarey]

Ok, maybe the DiscoveredVia info isn't the best way to handle this. I think what I'm looking for is a way to get a list of actual readers and writers that are currently detected on a domain for each topic.

What I'm trying to accomplish right now is to implement a DDS-serial bridge, where two machines on different networks (let's call them X and Y) connected via serial could forward DDS traffic over the serial cable to the other network.

One issue is that the serial bandwidth is limited, so I don't want to just forward everything. I want to only forward a topic if there's actually a reader for it on the other network. So I need one machine to be able to detect if there are any readers, not just other writers or topics. Now that I think of it some more... I guess I could just create a writer, on Y, for every topic detected on the other network, X, and see if anything connects to it, since there's already a PublicationMatched event I could listen for. Then, if a subscription is matched on Y, I could tell the other machine on X to forward that topic across the serial link. So maybe that's not a good reason 😅 for this feature.

If I went that route, I would want to know which topics on X have writers, so I could tell Y which topics to create writers for. I wouldn't want to detect a topic with only a reader on X, and then have Y create a writer for that. I suppose that wouldn't be catastrophic, just confusing for readers on Y, to see another topic that never produces anything.

If nothing else, it seems like this feature would be helpful for debugging purposes.

[Thomas Cravic]

The purpose of DDS is to be a data-centric publish-subscribe model. This means that there are publishers one one side, subscribers on the other one, and a decentralized middleware between them.

On one hand, the publishers will provide the data they can, without the need to know where it goes. It's the role of the middleware to propagate the data to the subscribers. On the other hand, the subscribers will subscribe to some data (i.e. topics), and not to some publishers. There can be as many publishers and subscribers you want for a single topic.

In your use case, you could make the publisher always forward the desired data, and if nothing is subscribed to the topic it publishes on, the middleware will just store the data it needs to assure the Quality Of Service (for example, to re-publish the samples to late joiners, if you set the Durability and History QoS properly).