posted on Thursday, September 03, 2009 - 08:52 pm
I have a question about DDS QoS after reading the specification.
Is it valid/consistent to set ResourceLimits.max_samples_per_instance to a number, like 5, and set History.kind=KEEP_ALL. I would think it would be invalid because History.kind=KEEP_ALL would imply a History.depth=UNLIMITED which would violate the consistency requirement that “depth <= max_samples_per_instance”. Or is KEEP_ALL have an undefined depth value and hence that “depth <= max_samples_per_instance” check does not apply.
Your particular example is valid, since KEEP_ALL applies to the situation where no more resources are available. Basically if you specify unlimited resources, there is no difference between the KEEP_ALL policy and a KEEP_LAST policy that has unlimited depth. The purpose of the history policy is to specify what to do when you run out of your available resources.
Setting history to KEEP_ALL with limited resources means that the entity in question will not overwrite old data with new data, instead it will just refuse to insert the new data until old data is 'consumed' by your application.
If the entity to which the Qos is applied is a reader that ran out of resources, it will reject new samples until your application 'takes' away some old samples. That way it makes room for the new ones.
If the entity to which the Qos is applied is a writer that ran out of resources, it will first try to see if it can deliver some of its samples to attached readers, making room for new samples. However, if one or more of the connected readers have a KEEP_ALL policy and also ran out of resources, and you are using RELIABLE communication, the writer has no way to make room for new samples without dropping older samples, which can then no longer be retransmitted to those connected readers once they have storage space available again. Since the policies clearly specify no data is to be dropped, the writer will then block the 'write' call, until it has resources available again. In case of reliable communication, a duration field in the reliability policy specifies how long a DataWriter may block the 'write' call at maximum. If it exceeds this max_blocking_time, the write call will fail and return a RETCODE_TIMEOUT.
The KEEP_LAST policy works a little bit differently: it has pre-allocated resources (according to the 'depth' you specified) and just drops the oldest sample in case of resource congestion. This way there is always room for the latest samples. (KEEP_LAST works like a FIFO queue, where old samples are pushed out on one side, while new samples are pushed in on the other side). Since the KEEP_LAST policy pre-allocates its resources, it can determine a-priori whether it will need more resources than you specified in your ResourceLimits Qospolicy. Here the rule depth >= max_samples_per_instance definitly applied.
Please note that the 'depth' field in the HistoryQosPolicy has no semantical meaning in case of KEEP_ALL. It is only to be interpreted in case of KEEP_LAST.
Of course I meant to say that in case of KEEP_LAST, the constraint that depth may NOT (!!) be >= max_samples_per_instance will be enforced. In other words, for KEEP_LAST the following rule must always be satisfied:
depth <= max_samples_per_instance
When you try to set a Qos that violates this rule, your operation will fail and return a RETCODE_INCONSISTENT_QOS.