I've written an entirely functional first app which creates four different topics, various readers/writers all wrapped as objects, all operating independently.
Superficially it's working well - but now I'm trying to work out how I should have written it!
Currently, each reader or writer has it's own domain participant, a topic gets created for each contributor/subscriber to the topic - separately for each reader/writer...it works, but my research says likely to come crashing down in a big heap the bigger the system gets.
So...I'll rework for a single domain participant for my app (it's all it needs) - but then I start to misunderstand the relationship between domains/topics/readers/writers etc. Does the domain "own" the topic which may be used by both a reader and writer? Similarly when registering types do I do this once per topic or once per reader or writer?
Excellent questions.
Start with: An app needs a single Domain Participant per domain that it is on. Occasionally you'll have a use case that needs two participants on one domain, but that use case involves different participants with different transport requirements. You might have ShParticipant on 112, but on SHMEM only, and V4Participant on 112, but only on IPv4. The app is then a "bridge" app probably, and is filtering traffic between IPv4 and SHMEM for example... really this kind of implementation is an edge/outlier use case.
But generally, the rule should be one Participant per Domain.
The Participant does not own the domain. The concept behind DDS is Data Centricity. The Domain owns itself, but it exists only when there is at least one participant that is active on it. Topics are also not owned by the Participant, but exist only when there is a Reader or Writer on it. What the Participant owns are the resources (memory, etc) that are needed by the Participant and all of its child entities (Subscribers, Publishers, DataWriters, DataReaders, Topics. Although if you wanted to be pedantic, the Publisher and Subscriber own the ports that stuff is written/read on.
Once you register a Type or create a Topic with a Participant, then it is registered with that Participant, and you don't need to do it again. In any case, the register Type/create Topic actions are idempotent so if you do repeat it...eh, happens -- this also means you don't need to worry about thread startup order inside the application. The reader on a topic and the writer on the same topic, on the same domain, either may register the Type first, either may create the Topic first).
(If you have a Participant with readers and writers on the same Topic, then the writers -will- send data to the readers, even though they are siblings of the same Participant. You can turn this behavior off using the Qos, cf https://community.rti.com/kb/how-do-i-get-datareader-ignore-datawriter-belongs-same-domainparticipant
You can have multiple writers on a single Topic in a single Participant. I tend to not, the applications I write (in Java) lend themselves to only a single Writer per Topic, and I share the Writer between threads that need to write on that Topic. You could very well have multiple Readers per Topic, there are a multitude of use cases that rely on content-filtered-topics, Readers that only look for data when it meets certain criteria.
Subscribers and Publishers can be as little or as many as you want. There are reasons to have more than one, but again edge/outlier cases. I tend to use one of each, but I'd split Readers between multiple Subscribers only if I was seeing weird thread latency issues, and then only to test if that was the cause. Some of the outlier Write/Read use cases (coherent sets, for example) require that the writers be from the same Publisher, and the readers need to be on the same Subscriber.
Let me know if I've confused or clarified the issues, and I'll try to clarify or confuse further, as the case may be.
rip
Hello David,
You may want to also check out this Best Practices Whitepaper, as well as the DDS best practices list found in the RTI Community Knowledge Base. Specifically this one: https://community.rti.com/best-practices/create-few-domainparticipants-possible
Gerardo