Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Messages are always retained #41

Open
bdamm opened this issue Oct 30, 2019 · 1 comment
Open

Messages are always retained #41

bdamm opened this issue Oct 30, 2019 · 1 comment
Assignees

Comments

@bdamm
Copy link

bdamm commented Oct 30, 2019

The pubsub protocol -09 requires the broker to always provide the most recent message to a subscriber. Why? The message might be very out-dated. Also, this requires the broker to retain the most recent message for every topic. If the topic tree is large and the broker is acting as an exchange point for millions of devices then the requirement that all topics have a cached message puts a big burden on the broker.

@jaimejim
Copy link
Member

jaimejim commented Oct 2, 2023

Hi @bdamm please find the current working version here https://core-wg.github.io/coap-pubsub/ps-rev/draft-ietf-core-coap-pubsub.html

NEW COMMENT
Editing my comment here sorry. I realized I missunderstood the request "cached message" to be related to caching and freshness in the CoAP sense. Topics are just links to CoAP resources hosted by a server.
AFAIK when the broker is hosting the topic_data as well, it obviously needs to provide a resource representation when requested.
However if the broker is just an "exchange point for millions of devices", that would mean that the topic_data resource is hosted elsewhere. When a subscriber subscribes to a topic in that context, the broker does not mediate in that.

https://core-wg.github.io/coap-pubsub/ps-rev/draft-ietf-core-coap-pubsub.html#name-topic-data-interactions

OLD COMMENT
The current version does not specify anything new in relation to caching freshness so the same logic as that for CoAP and CoAP Observe will apply.

The default Max-Age Option value is 60 in CoAP but that can be modified to cater to different deployment scenarios. If an origin server (i.e., origin server for the topic_data resource) wishes to prevent caching, it MUST explicitly include a Max-Age Option with a value of zero seconds.

https://www.rfc-editor.org/rfc/rfc7252#section-5.6
https://www.rfc-editor.org/rfc/rfc7641.html#section-3.3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants