You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
uProtocol notifications are very similar to email in that they are sent from one source to a specific destination. Like with emails, it would be great to know if the notification was delivered or not but currently only the RCP pattern supports acknowledgement of receipt of a request with a response message.
We have relied on notifications as part of the core uProtocol business logic for subscription and discovery database changes however we have observed that often these messages are getting lost and there is no feedback to the producer who sent the notification message.
If we want notifications to truly be like emails and provide some reliability in the delivery, we need to send feedback to the sender if a notification failed to be delivered, that is where a protocol (or concept) like Delivery Status Notifications (DSN) comes into play described in RFC3464.
This issue will be used to discuss and propose a solution for delivery status notifications.
The text was updated successfully, but these errors were encountered:
@stevenhartley was curious as to why messages are getting lost. Is there no QoS defined on a UPlatform for message delivery?
In addition, it sounds a little like an exactly once delivery semantics which, in distributed systems, is quite complex to implement with high reliability.
Can you specify the use cases where this is a concern. It would make it easier to identify the correct solution.
stevenhartley
changed the title
Delivery Status Notifications (DSN)
Should notifications have a feedback loop (a.k.a. Delivery Status Notifications like with email)?
Apr 3, 2024
uProtocol notifications are very similar to email in that they are sent from one source to a specific destination. Like with emails, it would be great to know if the notification was delivered or not but currently only the RCP pattern supports acknowledgement of receipt of a request with a response message.
We have relied on notifications as part of the core uProtocol business logic for subscription and discovery database changes however we have observed that often these messages are getting lost and there is no feedback to the producer who sent the notification message.
If we want notifications to truly be like emails and provide some reliability in the delivery, we need to send feedback to the sender if a notification failed to be delivered, that is where a protocol (or concept) like Delivery Status Notifications (DSN) comes into play described in RFC3464.
This issue will be used to discuss and propose a solution for delivery status notifications.
The text was updated successfully, but these errors were encountered: