| Key | Issue | Reported | Fixed | Disposition | Status | |
|---|---|---|---|---|---|---|
| DDSIRTP23-136 | Erratum | DDSI-RTPS 2.2 | open | |||
| DDSIRTP23-135 | Use of Stateful versus Stateless Endpoints | DDSI-RTPS 2.2 | open |
An erratum has been attached with some grammatical mistakes we found.
The specification defines two reference implementations for RTPS Readers and Writers:
Section 8.4.3 (Implementing the RTPS Protocol) indicates that it is an implementation decision whether to have the implementation match either the "Stateful" or "Stateless" reference behaviors. There are tradeoff with regards to the scalability and resources that may dictate which is preferable. But it does not impact interoperability.
While that is true, there are still some observable behavioral differences that users have encountered and been surprised by.
For example a BestEffort StatelessReader can add to the ReaderCache samples that arrive out of order. If the Reader has PRESENTATION access_scope=INSTANCE and the out of order samples are for different instances then they can be received by DDS.
A BestEffort StatefulReader will drop the out of order sample when this happens.
The problem is that in some cases the users are sensitive to this difference in behavior. This is specially a problem for best-efforts when you mix samples that require fragmentation with some not requiring fragmentation. In this case a later "non-fragmented" sample can arrive ahead of a fragment in the "fragmented sample", or be prioritized by the receiver stack ahead of the re-assembly...
Because of this there is a desire to be able to somehow indicate or configure the use of a Stateless Reader versus a StatefulReader. This does not mean the user's require that there is a portable configuration mechanism (e.g via DDS Qos) rather that they know that all implementations will provide some means to configure it.
A possible way to address this would be to add a sub-section to 8.4.15 (Implementation Guidelines) that discusses the selection of Stateful versus Stateless readers, especially for the best-effort case, and recommends that the choice is configurable using the DDS layer.