DDS — Writer_notification_of_delivery_failure Issue

Issue# 2070 Writer_notification_of_delivery_failure Issue [Boeing SOSCOE] ? This requirement applies to Point2Point and Group communications, not to Pub/Sub. ? In the case where the QoS is set to RELIABLE or TRANSACTIONAL there is a need for the application to be notified of delivery failures and also find out the delivery-status of individual messages. ? The application needs to get delivery confirmation with the granularity of a single message. ? Notification of delivery can be either synchronous (wait for delivery) or asynchronous (notification via listener). Proposal [Boeing SOSCOE] ? Add DataWriterListener::on_sent_data_lost and DataWriterListener::on_sent_data_received listener methods to notify sender asynchronously of reliable message send status ? Add UserListenerData for use in transactional and reliable processing. This data is specified on each write() and given back to the user through the DataWriterListener::on_sent_data_lost and DataWriterListener::on_sent_data_received methods to help the user determine what should be done with the data. ? Provide a way to get the ID of each message written (WriteMessageID). This can be used by the user to learn more about the message that was lost or received and is used by the system to track transactional and reliable messages that might have to be present. This id is passed to the on_sent_data_lost and on_sent_data_received listener methods and could become invalid at the end of those methods (the system must have some consistent way of determining when to clean up). Comment [RTI] ? In order for the application to find out the status of an individual message it needs to have some way to identify each message. Currently the DDS specification does not provide said mechanism. ? There are several ways to extend DDS to provide message identification functionality. • One way would be to change the return value of DataWriter::write() to return some kind of messageID or handle that can be used to refer to that message. Or alternatively return the messageId as an out parameter. However, this approach may complicate the application which now would need to perhaps track these IDs. • Another would be to add an operation to DataWriter to get the messageId of the last message written. This would have the advantage that it does not require a change of the API, just an extension. However, this would be potentially less efficient and also not safe if multiple application threads are using the same DataWriter to send information. • Another approach is that the MessageId would only be available by means of the callback. • With regards to the UserListenerData, it appears it needs to be either a parameter to the write call, or else something that could be set using a separate call. The first would clearly be more efficient but increases the complexity of the write API.

duplicate, close