Are data samples queued and if so, where?

3 posts / 0 new
Last post
Offline
Last seen: 7 months 3 weeks ago
Joined: 02/15/2019
Posts: 44
Are data samples queued and if so, where?

My understanding is that DDS DataWriters communicate CacheChanges to the HistoryCaches of the associated RTPS Writer. This CacheChange is then propagated to the mapped RTPS Readers before notifying their associated DDS DataReaders.

From the above statement, there are queues (the HistoryCache) on the RTPS Writers and Readers.

My question is: from a DDS point of view, are there queues for the samples (both on the publishing and the subscribing sides)? When the DataWriter writes a sample and is blocked, does it place this sample into a queue or does it just wait to become unblocked?

This is, of course, disregarding the use HISTORY_QOS.

Howard's picture
Offline
Last seen: 3 days 14 hours ago
Joined: 11/29/2012
Posts: 608

Yes, both DataWriters and DataReaders have queues, aka caches aka history caches, for the data samples sent (writer) or received (reader).  The physical size of the queue and how many samples are stored in the queue are control by various QoSes, notably RESOURCE_LIMITS and HISTORY.

However, how the queue behaves is control by other QoSes, notably RELIABILITY and HISTORY.kind.

If the end-to-end connection is configured with "strict" reliability (tcp-like reliability), then data is only removed from the writer queue if it's fully ACKed.  The writer queue can be filled with un-ACKed samples if the app sends faster than the reader app is able to ACK or if the writer app is unable to receive ACKs from the reader app (reader app is hung, crashed, network is disconnected).

In that situation, once the Writer queue is full, the next DataWriter::write() call will block.  The max blocking time is configurable in the RELIABILITY qos.  If the amount of time waiting exceeds the max_blocking_time without a slot freed up in the queue (usually due to receiving an ACK while blocked), the write call will return with a failure code indicating timeout.  In which case, the data sample was never entered into the queue (or sent on the wire).

You can also configure the queue never to block by using BEST_EFFORT RELIABILITY or by using KEEP_LAST HISTORY.

This is a good place to read about configuring reliable topic connections in DDS:

https://community.rti.com/content/forum-topic/qos-policies-configuring-reliability

Of course the Connext Users Manual also has this information.

Offline
Last seen: 7 months 3 weeks ago
Joined: 02/15/2019
Posts: 44

Many thanks for this Howard!