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

Max Polling Time in CoAP #349

Closed
egekorkan opened this issue Feb 9, 2024 · 4 comments · Fixed by #352
Closed

Max Polling Time in CoAP #349

egekorkan opened this issue Feb 9, 2024 · 4 comments · Fixed by #352
Labels
coap related to coap protocol binding

Comments

@egekorkan
Copy link
Contributor

Similar to Modbus, some CoAP devices also have a maximum polling time they support due to their resources. This means that the consumers are advised/recommended not to poll more frequently.

The devices in question are using TD 1.1 so it can only be in the CoAP binding. Once the use cases start, I will propose this as a new term for TD.

@egekorkan egekorkan added the coap related to coap protocol binding label Feb 9, 2024
@egekorkan
Copy link
Contributor Author

Also related to #215

@JKRhb

This comment was marked as outdated.

@benfrancis
Copy link
Member

Related, but in the other direction: Event rate limiting for Webhooks.

@ektrah
Copy link
Member

ektrah commented Feb 13, 2024

Polling is a valid use case in CoAP, although in many cases Observe offers better performance. (In fact, a typical client implementation is to poll for as long as the client is interested in having a current resource state representation, setting the Observe option each time. As long as the client is receiving notifications, it doesn't need to poll; as soon as the notifications are missing, the client polls again with the Observe option set.)

The freshness of the resource state representations is independent of how often a client polls. For example, if a CoAP resource reflects the current position of a moving aircraft, after less than a second it can no longer be assumed that the aircraft is still in the same position. This means the server would set Max-Age to 0 in the response. Nevertheless, the server may not want the client to request the current position more often than every three seconds.

If a client polls too frequently, a server may send a 4.29 (Too Many Requests) response. This error response is cacheable, with the Max-Age indicating after which time the client is allowed to try again.

I think it makes sense to be able to specify in TDs how frequently a client is allowed to poll a CoAP resource without running into a 4.29 response (for resources for which such a statement can be made).

In other words, the CoAP feature of interest is the 4.29 (Too Many Requests) error response, and the corresponding element in the TD would be the information that saves the client the round trip. I would be in favor of adding that.

@egekorkan egekorkan added Has Use Case Potential The use case can be extracted and explained Selected for Use Case and removed Has Use Case Potential The use case can be extracted and explained Selected for Use Case labels Feb 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
coap related to coap protocol binding
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants