Differences
This shows you the differences between two versions of the page.
|
iothings:laboratoare:2025:lab4 [2025/10/12 20:20] dan.tudose [Final Thoughts] |
iothings:laboratoare:2025:lab4 [2025/10/12 20:58] (current) dan.tudose |
||
|---|---|---|---|
| Line 3: | Line 3: | ||
| CoAP — the **Constrained Application Protocol** — is a compact, web-inspired protocol designed for tiny devices and lossy networks. Think of it as “HTTP’s cousin” for the Internet of Things: it preserves RESTful ideas (resources, methods, content types) but trims the bandwidth and processing overhead so microcontrollers running on batteries can still speak the language of the web. | CoAP — the **Constrained Application Protocol** — is a compact, web-inspired protocol designed for tiny devices and lossy networks. Think of it as “HTTP’s cousin” for the Internet of Things: it preserves RESTful ideas (resources, methods, content types) but trims the bandwidth and processing overhead so microcontrollers running on batteries can still speak the language of the web. | ||
| + | {{ :iothings:laboratoare:2025:coap_diagrama_example.png?600 |}} | ||
| ===== Why CoAP Exists ===== | ===== Why CoAP Exists ===== | ||
| Line 13: | Line 14: | ||
| **Methods** mirror HTTP semantics with a leaner encoding: **GET**, **POST**, **PUT**, **DELETE**. Servers can expose well-known endpoints (for example, ///.well-known/core///) to advertise available resources and interfaces using the CoRE Link Format. Content types are represented by compact numeric **Content‑Format** identifiers rather than long MIME strings, cutting repeated overhead dramatically. | **Methods** mirror HTTP semantics with a leaner encoding: **GET**, **POST**, **PUT**, **DELETE**. Servers can expose well-known endpoints (for example, ///.well-known/core///) to advertise available resources and interfaces using the CoRE Link Format. Content types are represented by compact numeric **Content‑Format** identifiers rather than long MIME strings, cutting repeated overhead dramatically. | ||
| + | {{ :iothings:laboratoare:2025:sensors-20-06391-g001.png?600 |}} | ||
| ===== 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 24: | 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:coap-requests.png?600 |}} | ||
| ===== URIs, Discovery, and Content ===== | ===== URIs, Discovery, and Content ===== | ||
| Line 30: | Line 37: | ||
| CoAP supports content negotiation via **Accept** and **Content‑Format** options. Common formats include **application/json**, **application/cbor**, and sensor‑oriented binary representations. CBOR pairs well with CoAP because it offers dense, schema‑agnostic encoding with minimal overhead on tiny MCUs. | CoAP supports content negotiation via **Accept** and **Content‑Format** options. Common formats include **application/json**, **application/cbor**, and sensor‑oriented binary representations. CBOR pairs well with CoAP because it offers dense, schema‑agnostic encoding with minimal overhead on tiny MCUs. | ||
| + | {{ :iothings:laboratoare:2025:concept-of-uri-a-for-coap-b-for-coaps-based-on-rfc-7252.jpeg?600 |}} | ||
| ===== Caching and ETags ===== | ===== Caching and ETags ===== | ||
| CoAP borrows HTTP’s cache validators (**ETag**, **Max‑Age**) so intermediaries and clients can avoid redundant transfers. An **ETag** is a small opaque token that changes when the resource representation changes. With **Max‑Age**, clients can confidently reuse cached data until it expires, then revalidate or fetch an update. | CoAP borrows HTTP’s cache validators (**ETag**, **Max‑Age**) so intermediaries and clients can avoid redundant transfers. An **ETag** is a small opaque token that changes when the resource representation changes. With **Max‑Age**, clients can confidently reuse cached data until it expires, then revalidate or fetch an update. | ||
| + | |||
| + | {{ :iothings:laboratoare:2025:hq720.jpg?600 |}} | ||
| ===== Observe: Push‑Style Updates over Pull Semantics ===== | ===== Observe: Push‑Style Updates over Pull Semantics ===== | ||
| Line 38: | Line 48: | ||
| Polling wastes energy. CoAP’s **Observe** extension lets a client register interest in a resource, turning the server into a notifier. After the initial GET with an Observe option, the server streams changes as normal CoAP responses, each correlated by the original token. Ordering and freshness are guided by a **sequence number** (often a monotonic value) so clients can discard stale deliveries. Observe works through intermediaries, letting gateways or proxies fan out updates to many clients efficiently. | Polling wastes energy. CoAP’s **Observe** extension lets a client register interest in a resource, turning the server into a notifier. After the initial GET with an Observe option, the server streams changes as normal CoAP responses, each correlated by the original token. Ordering and freshness are guided by a **sequence number** (often a monotonic value) so clients can discard stale deliveries. Observe works through intermediaries, letting gateways or proxies fan out updates to many clients efficiently. | ||
| + | {{ :iothings:laboratoare:2025:coap-observation.png?600 |}} | ||
| ===== Block‑Wise Transfer: When Payloads Don’t Fit ===== | ===== Block‑Wise Transfer: When Payloads Don’t Fit ===== | ||
| 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 ===== | ||
| - | Security comes in layers. The simplest path is **DTLS** (for UDP) or **TLS** (when using CoAP over TCP), providing channel protection similar to HTTPS. In constrained meshes, channel security alone can be fragile; topologies change, and intermediaries may need to route or cache. **OSCORE** (Object Security for Constrained RESTful Environments) protects the **message payload and options end‑to‑end** using COSE, independent of the transport. This enables proxies to function while keeping application data confidential and authenticated between true endpoints. Keys can be derived from pre‑shared material, EDHOC handshakes, or other provisioning schemes. | + | Security comes in layers. The simplest path is **DTLS** (for UDP) or **TLS** (when using CoAP over TCP), providing channel protection similar to HTTPS. In constrained meshes, channel security alone can be fragile; topologies change, and intermediaries may need to route or cache. |
| + | |||
| + | **OSCORE** (Object Security for Constrained RESTful Environments) protects the **message payload and options end‑to‑end** using COSE, independent of the transport. This enables proxies to function while keeping application data confidential and authenticated between true endpoints. Keys can be derived from pre‑shared material, EDHOC handshakes, or other provisioning schemes. | ||
| ===== Transports and Variants ===== | ===== Transports and Variants ===== | ||
| Line 57: | 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 ===== | ||
| - | |||
| - | term:: **RFC 7252** — base CoAP specification (methods, message formats, reliability). | ||
| - | term:: **RFC 7641** — Observe (server‑initiated notifications). | ||
| - | term:: **RFC 7959** — Block‑Wise transfers (chunking). | ||
| - | term:: **RFC 8323** — CoAP over TCP, TLS, and WebSockets. | ||
| - | term:: **RFC 8613** — OSCORE (object security, end‑to‑end protection). | ||
| - | term:: **CoRE Link Format / /.well-known/core/** — discovery and typed links. | ||
