-
Notifications
You must be signed in to change notification settings - Fork 25
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
Comments
Also related to #215 |
This comment was marked as outdated.
This comment was marked as outdated.
Related, but in the other direction: Event rate limiting for Webhooks. |
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. |
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.
The text was updated successfully, but these errors were encountered: