CoAP · Study deck
CoAP API Design: Delivery and Security Decisions
A sleepy node may lose a confirmable message, one that asks for an acknowledgement, or repeat a command.
Broker Bex is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: The selection depends on criticality and update timing rather than using the same exchange policy for both valve commands and routine temperature reports.
- Explain: An HTTP-to-CoAP proxy can return stale readings when one cache policy is applied to clients with different freshness needs.
- Explain: The Mistake: HTTP-to-CoAP proxy aggressively caches based on Max-Age without considering that freshness requirements vary by use case.
- Explain: Repeated wakeups consume battery energy, while excessive traffic can make a client unresponsive and produce repeated reset responses.
Major section
Message Type Selection
Confirmable messages support failure detection for actuator commands, configuration changes, and important alerts.
- The selection depends on criticality and update timing rather than using the same exchange policy for both valve commands and routine temperature reports.
- Configuration changes.
- Any operation where failure must be detected.
- If no, ask whether the data will be sent again soon.
Major section
Security Best Practices
A protected CoAP service combines transport protection with controls on resource access and request behavior.
- DTLS protects the transport path, while access control decides which clients may use particular resources.
- Input validation and rate limits address malformed or excessive requests that encryption alone does not resolve.
- Protect the production exchange with DTLS (coaps://) or an appropriate OSCORE deployment.
Major section
Security Best Practices (continued)
Credential rotation and session limits remain separate operating responsibilities after the protected connection has been established.
- Implement access control (not all clients can access all resources).
- Validate input (prevent injection attacks).
- Use short session timeouts (minimize exposure).
- Token bucket algorithm (allow bursts, limit sustained rate).
Major section
Common Pitfall: CoAP Observe Notification Flood
An Observe server can overwhelm clients when notifications follow minor sensor changes without a separate delivery policy.
- Repeated wakeups consume battery energy, while excessive traffic can make a client unresponsive and produce repeated reset responses.
- A minimum notification interval and a meaningful change threshold separate sensor sampling from useful notification delivery.
- Client sends RST messages repeatedly.
Major section
Common Pitfall: CoAP Observe Notification Flood (continued)
Max-Age communicates value validity, and client reset responses provide evidence that the notification policy needs review.
- The mistake: Configuring a server to send Observe notifications on every minor resource change, overwhelming clients.
- Client device becomes unresponsive or crashes.
- Monitor client RST responses (may indicate an unrecognized notification or lost observation state).
Major section
Pitfall: HTTP-CoAP Proxy Caching Stale Data
An HTTP-to-CoAP proxy can return stale readings when one cache policy is applied to clients with different freshness needs.
- Max-Age describes a validity interval, but that interval must still fit the receiving use case.
- The Mistake: HTTP-to-CoAP proxy aggressively caches based on Max-Age without considering that freshness requirements vary by use case.
- CoAP Max-Age itself is a response freshness option, not a client request option.
Deck summary
Key takeaways
Confirmable messages support failure detection for actuator commands, configuration changes, and important alerts.
- A protected CoAP service combines transport protection with controls on resource access and request behavior.
- Credential rotation and session limits remain separate operating responsibilities after the protected connection has been established.
- An Observe server can overwhelm clients when notifications follow minor sensor changes without a separate delivery policy.
- Max-Age communicates value validity, and client reset responses provide evidence that the notification policy needs review.
Retrieval practice
Recall check 1 of 2
Broker Bex says: answer from memory, then check your reasoning.
Q1A CoAP client sends a valve command and must detect delivery failure. Which message type fits?
Show answer
Answer: A The section selects CON for actuator commands and detected failure.
Q2A CoAP service uses protected transport but lets any client modify resources. Which control is missing?
Show answer
Answer: D The checklist separately requires permission checks for resource access.
Retrieval practice
Recall check 2 of 2
Broker Bex says: answer from memory, then check your reasoning.
Q3What expresses a CoAP operation whose safety and idempotence affect retry behaviour?
Show answer
Answer: D GET, PUT, POST, or DELETE expresses the requested operation whose safety and idempotence shape retry behaviour.
Q4Complete the CoAP resource endpoint with content format:
Show answer
Answer: A CoAP server resources extend aiocoap.resource.Resource and implement render_get/render_put/render_post methods. Responses use CoAP response codes like CONTENT (2.05). Payloads must be bytes, so strings need .encode().
Print reference
Four API decisions
Answer key.
- A · The section selects CON for actuator commands and detected failure.
- D · The checklist separately requires permission checks for resource access.
- D · GET, PUT, POST, or DELETE expresses the requested operation whose safety and idempotence shape retry behaviour.
- A · CoAP server resources extend aiocoap.resource.Resource and implement render_get/render_put/render_post methods. Responses use CoAP response codes like CONTENT (2.05). Payloads must be bytes, so strings need .encode().