Differences
This shows you the differences between two versions of the page.
|
iothings:laboratoare:2025:lab4 [2025/10/12 20:40] dan.tudose [Observe: Push‑Style Updates over Pull Semantics] |
iothings:laboratoare:2025:lab4 [2025/10/12 20:58] (current) dan.tudose |
||
|---|---|---|---|
| Line 17: | Line 17: | ||
| ===== Messages, Types, and Reliability ===== | ===== Messages, Types, and Reliability ===== | ||
| - | Every CoAP message carries a tiny fixed header followed by **Options** and an optional **Payload**. Options are encoded in a delta/length scheme that compresses repeated numbers and elides absent fields. Four message types shape reliability and control flow: | + | Every CoAP message carries a tiny fixed header followed by **Options** and an optional **Payload**. Options are encoded in a delta/length scheme that compresses repeated numbers and elides absent fields. |
| + | |||
| + | {{ :iothings:laboratoare:2025:sensors-20-06391-g002-550.jpg?500 |}} | ||
| + | |||
| + | Four message types shape reliability and control flow: | ||
| * **CON** (Confirmable) requires an **ACK** and is retransmitted with exponential backoff until acknowledged or timed out. | * **CON** (Confirmable) requires an **ACK** and is retransmitted with exponential backoff until acknowledged or timed out. | ||
| Line 26: | Line 30: | ||
| The combination allows request/response exchanges over UDP without a connection handshake. **Message IDs** and **Tokens** help match responses to requests, even across retransmissions or when responses are sent later (separate response). | The combination allows request/response exchanges over UDP without a connection handshake. **Message IDs** and **Tokens** help match responses to requests, even across retransmissions or when responses are sent later (separate response). | ||
| - | {{ :iothings:laboratoare:2025:sensors-20-06391-g002-550.jpg?500 |}} | + | {{ :iothings:laboratoare:2025:coap-requests.png?600 |}} |
| ===== URIs, Discovery, and Content ===== | ===== URIs, Discovery, and Content ===== | ||
| Line 49: | Line 53: | ||
| Small MTUs and duty‑cycle limits make large payloads tricky. **Block1** and **Block2** options slice requests and responses into manageable chunks. The client or server moves block‑by‑block, using the options to indicate size and index. This allows firmware downloads, log retrieval, or model updates without exceeding link constraints, while keeping memory footprints small on each side. | Small MTUs and duty‑cycle limits make large payloads tricky. **Block1** and **Block2** options slice requests and responses into manageable chunks. The client or server moves block‑by‑block, using the options to indicate size and index. This allows firmware downloads, log retrieval, or model updates without exceeding link constraints, while keeping memory footprints small on each side. | ||
| + | {{ :iothings:laboratoare:2025:coap-block-wise-transfer_1_.png?600 |}} | ||
| ===== Security: DTLS/TLS and OSCORE ===== | ===== Security: DTLS/TLS and OSCORE ===== | ||
| Line 66: | Line 71: | ||
| Because it rides over UDP by default, CoAP specifies conservative retransmission backoff, leaky‑bucket style pacing, and limits on simultaneous confirmable messages. Implementations typically expose tunables for **ACK_TIMEOUT**, **ACK_RANDOM_FACTOR**, and **MAX_RETRANSMIT**. The aim is politeness on shared, lossy links: back off early, avoid bursts, and prefer NON traffic when eventual consistency suffices. | Because it rides over UDP by default, CoAP specifies conservative retransmission backoff, leaky‑bucket style pacing, and limits on simultaneous confirmable messages. Implementations typically expose tunables for **ACK_TIMEOUT**, **ACK_RANDOM_FACTOR**, and **MAX_RETRANSMIT**. The aim is politeness on shared, lossy links: back off early, avoid bursts, and prefer NON traffic when eventual consistency suffices. | ||
| - | |||
| - | ===== Design Tips for Real Deployments ===== | ||
| - | |||
| - | Plan the resource tree as if you were designing a public API. Use nouns for resources, reserve verbs for state changes, and stick to predictable shapes so intermediaries can cache intelligently. Choose compact encodings (CBOR) for high‑volume telemetry but keep human‑readable JSON for diagnostics. Embrace **ETags** and **Max‑Age** to cut chatter; adopt **Observe** for state that changes often; and reach for **Block‑Wise** when transferring anything larger than your typical MTU. For security, default to **OSCORE** when proxies are involved, and to **DTLS/TLS** when you control both endpoints and want a protected channel. Document your **Content‑Format** numbers and keep a registry in your codebase to avoid mismatches during updates. | ||
| - | |||
| - | ===== Example Exchange ===== | ||
| - | |||
| - | Below is a minimal round‑trip. The client fetches a temperature resource and receives a piggybacked response. Encoding is shown schematically rather than byte‑exact: | ||
| - | |||
| - | <code> | ||
| - | Client → Server | ||
| - | CON, MID=0x4A3B, Token=0xC1 | ||
| - | Code=GET | ||
| - | Uri-Path: "sensors" | ||
| - | Uri-Path: "temp" | ||
| - | Accept: application/cbor | ||
| - | |||
| - | Server → Client | ||
| - | ACK (to 0x4A3B), Token=0xC1 | ||
| - | Code=2.05 Content | ||
| - | Content-Format: application/cbor | ||
| - | Payload: { "t": 21.6, "u": "C" } | ||
| - | </code> | ||
| - | |||
| - | Subsequent updates could use Observe so the server pushes new readings as they happen, each carrying the same token and an incremented Observe sequence value. | ||
| - | |||
| - | ===== Troubleshooting Checklist (Short) ===== | ||
| - | |||
| - | - Ordered List Item If a client waits forever, verify message types: a CON should elicit an ACK or a separate response; mismatched tokens often indicate a stale or retransmitted request. | ||
| - | - Ordered List Item When payloads seem truncated, confirm **Block2** negotiation and size exponents on both ends. | ||
| - | - Ordered List Item Cache weirdness is frequently an **ETag** or **Max‑Age** problem; change the representation without changing the tag and your intermediaries will happily serve old data. | ||
| - | - Ordered List Item Interop failures through proxies usually trace to **Content‑Format** vs **Content‑Type** differences; ensure your mappings are explicit and consistent. | ||
| - | |||
| - | ===== When to Choose CoAP (and When Not To) ===== | ||
| - | |||
| - | Pick CoAP when you need web‑style resource semantics on severely constrained devices, when UDP is available and cheap, and when gateways, caches, and multicast discovery will simplify your topology. It shines for sensor/actuator fleets, smart buildings, and industrial telemetry with intermittent connectivity. Prefer HTTP/HTTP/2 or gRPC when you require continuous high‑throughput streams, large messages without chunking, or when infrastructure mandates strictly connection‑oriented flows and rich middleware that already speaks HTTP at every hop. | ||
| - | |||
| - | ===== Key Standards to Know ===== | ||
| - | |||
| - | * **RFC 7252** — base CoAP specification (methods, message formats, reliability). | ||
| - | * **RFC 7641** — Observe (server‑initiated notifications). | ||
| - | * **RFC 7959** — Block‑Wise transfers (chunking). | ||
| - | * **RFC 8323** — CoAP over TCP, TLS, and WebSockets. | ||
| - | * **RFC 8613** — OSCORE (object security, end‑to‑end protection). | ||
| - | * **CoRE Link Format / /.well-known/core/** — discovery and typed links. | ||
