-
Key: DDSIRTP2-11
-
Legacy Issue Number: 11039
-
Status: closed
-
Source: Real-Time Innovations ( Mr. Kenneth Brophy)
-
Summary:
Source:
Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
Summary:
The specification should describe how finite resources impact reliable communications.Writer queue resources should be reclaimed when no remote reader needs the corresponding sample. This means at least samples that have been fully acknowledged may be reclaimed. However they may exist unresponsive readers that are alive but for some reason never acknowledge the writer. To enable a writer to reclaim resources in this case, we define the notion of inactive Readers. If a reader is detected to be unresponsive through some mechanism (for example, when not responding to successive Heartbeats), the reader is deemed inactive. Then, samples that have been fully acknowledged by all active readers may be reclaimed. The writer should continue sending new samples and Heartbeats to inactive readers, but the writer need not hold onto old samples that were not acknowledged by inactive readers. The specification must note that strict reliability is no longer guaranteed when a reader becomes inactive.
Resolution:
Explain reliability in the presence of finite resources. Introduce and describe "isActive" reader attribute.Revised Text:
Add new section
8.4.14.6 Reclaiming Finite Resources from Unresponsive ReadersAn implementation likely has finite resources to work with. For a writer, reclaiming queue resources should happen when all readers have acknowledged a sample in the queue and resource limits dictate that the old sample entry is to be used for a new sample.
There may be scenarios where an alive reader becomes unresponsive and will never acknowledge the writer. Instead of blocking on the unresponsive reader, the writer should be allowed to deem the reader as 'Inactive' and proceed in updating its queue. The state of a reader is either Active or Inactive. Active readers have sent ACKNACKs that have been recently received. The writer should determine the inactivity of a reader by using a mechanism based on the rate and number of ACKNACKs received. Then samples that have been acknowledged by all active readers can be freed, and the writer can reclaim those resources if necessary. Note that strict reliability is not guaranteed when a reader becomes inactive.
Add to table 8.59 - RTPS ReaderProxy Attributes
Attribute Type Meaning Relation to DDS
isActive bool Specifies whether the remote reader is responsive to the writer. N/A -
Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
-
Disposition: Resolved — DDSI-RTPS 2.0
-
Disposition Summary:
see above
-
Updated: Fri, 6 Mar 2015 20:58 GMT
DDSIRTP2 — Reclaiming finite resources from inactive readers
- Key: DDSIRTP2-11
- OMG Task Force: DDS Interoperability FTF