Hello,
I am trying to create an application in which I want to restrict multiple DDS_DataWriters communicating with 1 DDS_DataReader, or vice-versa (multiple DDS_DataReaders communicating with 1 DDS_DataWriter). Because the user might choose to connect multiple data readers to the same data writer, I have to restrict the operation when creating the DDS Data Readers and DDS Data Writers. Is it possible to configure data writers and data readers by not accepting more than 1 connection when creating them (via QoS configuration or other configuration)?
Thank you!
- Andrei
Hi,
I do not think there is a way to enforce this. In general this pattern goes against the general publish-subscribe philosophy where aplications are decoupled from each other and not aware of who else is observing the system. If matching was limited to 1, then , then some other things (lime monitoring tools, recording tools, etc) would not be able to work because they create additional datareaders on the Topic that the initial application may not have expected.
That said, nothing stops you from crafting Topic names that encode the DataWriter-DataReader pair. Or configuring your DataReader to use a content filter on some field that the DataWriter uses to direct messages to specific DataReaders. But this would be a use-patetrn and not enforced by the middleware.
If what you wanted was to have each message delivered to a single DataReader, even in the case whre multiple are matched. For example, to load-balance tasks among different worker processes, then you could use the RTI Queing Service. This service implements that "exacrlty once delivery" pattern on top of DDS.
Gerardo
I found some QoS policies that limits the maximum number of remote readers for a DDS_DataWriter by setting the writer_resource_limits.max_remote_readers to "1" and the maximum number of remote writers for a DDS_DataReader by setting the reader_resource_limits.max_remote_writers to "1". This works on the DDS_DataReaderSide, but I get a QoS error when I try to create the DDS_DataWriter entity. Do I need to configure something else to make this work?
Note: I don't really care if other monitoring applications connect to my readers & writers. This would be a user's fault from my point of view.
-Andrei
Dear all,
I have similar problem to the one stated above, namely to realize a one DataWriter and multiple DataReaders, as well as, multiple DataWriters and one single DataReader communication policy. For the former, the Ownership QoS is quite useful and serves my purpose. For the latter, however, I did not find a matching counterpart to the Ownership QoS that whould set the Ownership to a single DataReader (not writer). Is there any other "official" way how I can restrict the reader side to one single reader at the same time?
I know that I can monitor the PublicationMatchedStatus on the DataWriter side to detect if there are more than one DataReaders, but that only tells me the "error" case and does not allow preventing mutliple readers to initiate communication in the first place. I was even considering opening a dummy DataWriter on the reader's side for the sole purpose of checking if there already is a reader registered for a topic, but that is quite a sledge hammer method and surely there must be something more elegant than that?
Hi,
I think this can be achieved through 'Named subscription'. Please look into the following link: https://community.rti.com/static/documentation/connext-dds/5.3.0/doc/manuals/connext_dds/html_files/RTI_ConnextDDS_CoreLibraries_UsersManual/Content/UsersManual/Required_Subscriptions.htm
I know that it can be used to make sure that connection is made with a particular subscriber. Probably the same can be used for publisher as well. Check for 'Entity Name' QoS policy at "https://community.rti.com/static/documentation/connext-dds/5.3.0/doc/manuals/connext_dds/html_files/RTI_ConnextDDS_CoreLibraries_UsersManual/Content/UsersManual/Setting_Publisher_QosPolicies.htm"
Hi,
thanks! This sounds interesting. I was not aware that I could use the entity name in this way (to be honest, I I didn't know what the entity name is good for at all), now it makes a bit more sense.