Suppose we have 10 subscriber registered for Topic (lets say "Movie") and one publisher registered for (same Topic "Movie") , at one point of time we want that the message should reach all the subscriber who are registered for "Movie". At other point of time we want that message should reach only 6 subscribers.
Concerning the open DDS implementation I cannot help you. Conceptually I think the approach to handle this 'problem' should be different though.
Your approach requires knowledge at the publisher about its subscribers. Adding or removing a subscriber later on or under a certain condition requires adaptations in your publisher as well. These dependencies make your system more complex.
You could also look at it from the other side and let the Subscriber decide what it wants. In this case the publisher would simply publish all its 'Movie' samples in the 'global data space'. Each subscriber can decide for itself which information it needs. You can define and subscribe to a ContentFilteredTopic for instance. This allows you to filter out the samples you don't want or need. Another option for this purpose is the usage of a QueryCondition. This approach of decoupling Publishers and Subscribers reduces your complexity and improves flexibility.
In the specific situation you describe, you could for instance let 4 subscribers subscribe to the 'Movie' Topic and the other 6 to a ContentFilteredTopic that filters out the samples you don't need there.
I have few question. 1) Can a single subscriber be registered for more than one topic. 2)what is the limitation of number of participant for single InfoRepo.(i.e publisher and subscriber) 3)Can we have group communication through DDS.
I mean is it possible to group 4 subcriber in one group 6 in other group.and we can send message in the group.
1) A DataReader is 'registered' for one specific Topic. One Subscriber can have any number of attached DataReaders. 2) I don't know what you mean with an InfoRepo. In principle there is no limitation of the number of DomainParticipants, Publishers and Subscribers in DDS. 3) DDS provides the concept of 'partitions' for this. The PartitionQoSPolicy is part of the set of QoS policies for both a Publisher and a Subscriber. This policy allows the introduction of a logical partition concept inside the ‘physical’ partition induced by a domain. For a DataReader to communicate with a DataWriter, not only the Topic must match, but also they must share a common partition.
In your example you could create two different publishers. One for partition 'x' and one for partition 'y'. You can create different subscribers that subscribe to 'x' or 'y' or to both 'x,y' by specifying this in their PartitionQoSPolicy.