Synchronizing Topics ?

6 posts / 0 new
Last post
Offline
Last seen: 2 years 7 months ago
Joined: 03/31/2022
Posts: 11
Synchronizing Topics ?

Folks,

If I have 2 topics, TopicA and TopicB, and I have a writer app (App A), that writes a sample to TopicA followed by a sample to TopicB, is there any way to ensure that a reader app (App B) will process the sample from TopicA before the sample from TopicB ? And if such a way exists, is it in the DDS standard, or just an RTI extension. I know that right now if I construct such a pair of apps, for at least the first time, the TopicB sample is being processed before the TopicA sample.

The reason for this is we have been given a third-party IDD that appears to assume the above can be done. I am hoping they know something I do not.

Thanks,

Dale Pennington

Howard's picture
Offline
Last seen: 6 days 7 hours ago
Joined: 11/29/2012
Posts: 618

Short answer is you can use the Presentation Qos, see this section of the Users Manual:

https://community.rti.com/static/documentation/connext-dds/6.1.1/doc/manuals/connext_dds_professional/users_manual/index.htm#users_manual/PRESENTATION_QosPolicy.htm#7.4.6_PRESENTATION_QosPolicy%3FTocPath%3DPart%25202%253A%2520Core%2520Concepts%7C7.%2520Sending%2520Data%7C7.4%2520Publisher%252FSubscriber%2520QosPolicies%7C7.4.6%2520PRESENTATION%2520QosPolicy%7C_____0

The longer answer must also include the startup phase where the two apps haven't fully discovered each other but the first app starts sending data.  I'm not certain that using Presentation QoS, it'll work even with incomplete discovery, but in any case, if you require data sent by a publishing application to be received by a subscribing application, independent of the startup discovery race condition, you either have to

1) use APIs to check to see if the publishing app has fully discovered the datareaders of the subscribing app before it sends the data (this assumes a RELIABLE Reliability QoS configuration).

or

2) Use the Durability QoS to have DDS automatically send previously published data to newly discovered DataReaders.

Offline
Last seen: 2 years 7 months ago
Joined: 03/31/2022
Posts: 11

OK,

So I read the sections of the manual on this, and it clear I would want Access Scope of GROUP and Ordered Access of TRUE.

For that to work in the reader app, all reads need to take place with a pair of begin_access()/end_access() calls.  Is a safe solution to this to just do the begin_access() call right after I create the Subscriber and the end_access() at program termination, or is more needed.

Also when I searched the Modern C++ API, I could not find the begin_access()/end_access() calls. Are they known by a different name there ?

Thanks,

Dale Pennington

Howard's picture
Offline
Last seen: 6 days 7 hours ago
Joined: 11/29/2012
Posts: 618

You should probably refer to the Modern C++ documentation for the Presentation Qos:  https://community.rti.com/static/documentation/connext-dds/6.1.1/doc/api/connext_dds/api_cpp2/classdds_1_1core_1_1policy_1_1Presentation.html

The description section has a detailed explanation...

However, to access ordered data from multiple DataWriters, you should read this: https://community.rti.com/static/documentation/connext-dds/6.1.1/doc/manuals/connext_dds_professional/users_manual/index.htm#users_manual/BeginEndGroupOrderedAccess.htm#8.2.5_Beginning_and_Ending_Group-Ordered_Access%3FTocPath%3DPart%25202%253A%2520Core%2520Concepts%7C8.%2520Receiving%2520Data%7C8.2%2520Subscribers%7C_____5

and this: https://community.rti.com/static/documentation/connext-dds/6.1.1/doc/manuals/connext_dds_professional/users_manual/index.htm#users_manual/Getting_DataReaders_with_Specific_DDS_Sa.htm

Note, in Modern C++, ou need to creating the object dds::sub::CoherentAccess::CoherentAccess() when you want to access a set of data and then destroying the object or calling dds::sub::CoherentAccess::end() when you're done accessing the data.  It is not correct to create the object when you start your application and calling end()/destroying the object when you stop the application.

You're also going to have to use this method: https://community.rti.com/static/documentation/connext-dds/6.1.1/doc/api/connext_dds/api_cpp2/namespacedds_1_1sub.html#a5589bfe6a27860c75389fcebcbd45c06 in order to get an ordered list of DataReader that has received data.

Using the search capability on the RTI Community website for "Presentation Ordered Access", you can find articles as well as examples...such as

https://community.rti.com/examples/ordered-presentation-group

There is a Modern C++ example there.  HOWEVER, I think that the example subscriber code does not need to take() 1 data sample at a time from each datareader returned by the find() operation.  I believe it can just take all samples and iterate through all samples received from a DataReader as it iterates through the DataReaders.

        for (int i = 0; i < num_readers; i++) {
            dds::sub::DataReader<ordered_group> reader =
                    readers[i].get<ordered_group>();

            dds::sub::LoanedSamples<ordered_group> samples =
                    reader.select().take();

            std::cout << "." << std::endl;
            for (const auto& sample : samples) {
                if (sample.info().valid()) {
                    std::cout << sample.data() << std::endl;
                }
            }
        }

Offline
Last seen: 2 years 7 months ago
Joined: 03/31/2022
Posts: 11

Thanks for that information. I had read some of those,  but the user's manual uses what appears to be the C interface, and does not mention the Modern C++ equivalent.

I am assuming that for any given group of related topics, they need their own publisher on the write side, and subscriber on the receive side, to seperate them from other topics being written/received by those applications.

Dale

Howard's picture
Offline
Last seen: 6 days 7 hours ago
Joined: 11/29/2012
Posts: 618

Typically, I would explore the HTML API documentation (for Modern C++) if you want details of how to do something in a particular language...whereas the manual is better for the big picture and overall concepts.  Again, I would point to searching on community.rti.com to find posting/solutions/examples for a particular subject.

Yes, all DataWriters of a single Publisher and all DataReaders of a single Subscriber are affected by the Presentation QoS setting for those objects.  DataWriters and DataReaders that should not be "grouped" together for Presentation Access or Order...should be created with a different Publisher/Subscriber objects.