Content deleted Content added
Citation bot (talk | contribs) Alter: title, template type. Add: chapter. | Use this bot. Report bugs. | #UCB_CommandLine 18/8263 |
ce |
||
| (19 intermediate revisions by 12 users not shown) | |||
Line 2:
{{IP stack}}
'''Constrained Application Protocol''' ('''CoAP''') is a specialized [[User Datagram Protocol|UDP-based]] Internet application protocol for constrained devices, as defined in [https://datatracker.ietf.org/doc/html/rfc7252 RFC 7252] (published in 2014). It enables those constrained devices called "nodes" to communicate with the wider Internet using similar protocols.
CoAP is designed for use between devices on the same constrained network (e.g., low-power, lossy networks), between devices and general nodes on the Internet, and between devices on different constrained networks both joined by an internet. CoAP is also being used via other mechanisms, such as SMS on mobile communication networks.
CoAP is an application-layer protocol that is intended for use in resource-constrained Internet devices, such as [[wireless sensor network]] nodes. CoAP is designed to easily translate to [[HTTP]] for simplified integration with the web, while also meeting specialized requirements such as [[multicast]] support, very low overhead, and simplicity.<ref>[https://tools.ietf.org/html/rfc7252 RFC 7252, Constrained Application Protocol (CoAP)]</ref><ref>"[http://hinrg.cs.jhu.edu/joomla/images/stories/IPSN_2011_koliti.pdf Integrating Wireless Sensor Networks with the Web] {{Webarchive|url=https://web.archive.org/web/20170830060917/http://hinrg.cs.jhu.edu/joomla/images/stories/IPSN_2011_koliti.pdf |date=2017-08-30 }}" , Walter, Colitti 2011</ref> Multicast, low overhead, and simplicity are important for [[Internet of things]] (IoT) and [[machine-to-machine]] (M2M) communication, which tend to be [[Embedded system|embedded]] and have much less memory and power supply than traditional Internet devices have. Therefore, efficiency is very important. CoAP can run on most devices that support
The Internet Engineering Task Force ([[IETF]]) Constrained [[RESTful]] Environments Working Group ([https://datatracker.ietf.org/doc/charter-ietf-core/ CoRE]) has done the major standardization work for this protocol. In order to make the protocol suitable to IoT and M2M applications, various new functions have been added.
Line 41:
|}
=== CoAP
The first 4 bytes are mandatory in all CoAP datagrams, they constitute the fixed-size header.
These fields can be extracted from these 4 bytes in C via these macros:
<syntaxhighlight lang="c"> #define COAP_HEADER_VERSION(data) ( (0xC0 & (data)[0]) >> 6 )
#define COAP_HEADER_TYPE(data) ( (0x30 & (data)[0]) >> 4 )
Line 151 ⟶ 152:
Every request carries a token (but it may be zero length) whose value was generated by the client. The server must echo every token value without any modification back to the client in the corresponding response. It is intended for use as a client-local identifier to match requests and responses, especially for concurrent requests.
Matching requests and responses is not done with the message ID because a response may be sent in a different message than the acknowledgement (which uses the message ID for matching). For example, this could be done to prevent retransmissions if obtaining the result takes some time. Such a detached response is called "separate response". In contrast, transmitting the response directly in the acknowledgement is called "piggybacked response" which is expected to be preferred for efficiency reasons.
=== Option ===
Line 178 ⟶ 179:
Option delta:
* 0 to 12: For delta between 0
* 13: For delta from 13 to 268: Option delta extended is an 8-bit value that represents the option delta value minus 13
* 14: For delta from 269 to 65,804: Option delta extended is a 16-bit value that represents the option delta value minus 269
Line 185 ⟶ 186:
Option length:
* 0 to 12: For option length between 0
* 13: For option length from 13 to 268: Option length extended is an 8-bit value that represents the option length value minus 13
* 14: For option length from 269 to 65,804: Option length extended is a 16-bit value that represents the option length value minus 269
* 15: Reserved for future use. It is an error for the option length field to be set to 0xFF.
Option value:
Line 195 ⟶ 196:
* Semantic and format this field depends on the respective option.
{| class="wikitable sortable"
|-
Line 202 ⟶ 203:
| coap || Dart || RFC 7252|| Client || Blockwise Transfers, Observe, Multicast, Proxying (partial) || MIT || https://github.com/shamblett/coap
|-
| aiocoap || Python 3 || RFC 7252, RFC 7641, RFC 7959, RFC 8323, RFC 7967, RFC 8132, RFC 9176, RFC 8613, RFC 9528|| Client + Server || Blockwise Transfers, Observe (partial) || MIT || {{URL|https://pypi.python.org/pypi/aiocoap}}
|-
| Californium || Java || RFC 7252, RFC 7641, RFC 7959|| Client + Server || Observe, Blockwise Transfers, Multicast (since 2.x), DTLS (+ DTLS 1.2 Connection ID) || EPL+EDL || {{URL|https://www.eclipse.org/californium}} {{URL|https://github.com/eclipse/californium}}
|-
|
|-
|
|-
| Go-CoAP || [[Go (programming language)|Go]] || RFC 7252, RFC 8232, RFC 7641, RFC 7959|| Client + Server || Core, Observe, Blockwise, Multicast, TCP/TLS || Apache License 2.0 || {{URL|https://github.com/plgd-dev/go-coap}}
|-
|
|-
|
|-
|libcoapy
| CoAPSharp || C#, .NET || RFC 7252|| Client + Server || Core, Observe, Block, RD || LGPL || http://www.coapsharp.com▼
|Python
| colspan="3" |same support as libcoap
|MIT
|{{URL|https://github.com/anyc/libcoapy}}
|-
|
|-▼
|
|-
▲|
|-
RFC 7641, RFC 7959▼
| Client + Server || Core, Observe, Block || MIT || {{URL|https://github.com/mcollina/node-coap}}▼
|-
|
|-
| coap-rs || Rust || RFC 7252|| Client + Server || Core, Multicast, Observe option, ''Too Many Requests'' Response Code || MIT || {{URL|https://github.com/Covertness/coap-rs}}▼
{{URL|https://docs.rs/coap/}}▼
|-
|}
==Proxy implementations==
There exist [[Proxy server|proxy]] implementations which provide [[Forward proxy|forward]] or [[Reverse proxy|reverse]] proxy functionality for the CoAP protocol and also implementations which translate between protocols like HTTP and CoAP.
The following projects provide proxy functionality:
* [http://telecom.dei.unipd.it/pages/read/90/ Squid 3.1.9 with transparent HTTP-CoAP mapping module]▼
* [https://code.google.com/p/jcoap/ jcoap Proxy]▼
* [https://github.com/eclipse/californium/tree/master/californium-proxy2 Californium cf-proxy2]▼
* [https://github.com/Tanganelli/CoAPthon CoAPthon]▼
* [https://github.com/keith-cullen/FreeCoAP FreeCoAP]▼
* [https://github.com/obgm/libcoap libcoap]
==Projects using CoAP==
{| class="wikitable sortable"
|-
! Name !! Programming Language !! Implemented CoAP version !! Client/Server !! Implemented CoAP features !! License !! Link
|-
| CoAP Shell || Java || RFC 7252|| Client || Observe, Blockwise Transfers, DTLS || Apache License 2.0 || https://github.com/tzolov/coap-shell
|-
| Copper || JavaScript (
|-
|}
▲| eCoAP || C || RFC 7252|| Client + Server || Core || MIT || https://gitlab.com/jobol/ecoap
==Inactive protocol implementations==
{| class="wikitable sortable"
|-
! Name !! Programming Language !! Implemented CoAP version !! Client/Server !! Implemented CoAP features !! License !! Link
▲| Erbium for Contiki || C || RFC 7252|| Client + Server || Observe, Blockwise Transfers || 3-clause BSD || http://www.contiki-os.org/ (er-rest-example)
|-
|
|-
|
|-
|
|-
|
|-
|
|-
|
|-
|
|-
|
|-
|
|-
|
|-
|
|-
|
|-
| nCoap || Java || RFC 7252|| Client + Server || Observe, Blockwise Transfers, CoRE Link Format, [https://tools.ietf.org/html/draft-kleine-core-coap-endpoint-id-01 Endpoint-ID-Draft] || BSD || https://github.com/okleine/nCoAP
▲| node-coap || Javascript || RFC 7252,
▲RFC 7641, RFC 7959
▲| Client + Server || Core, Observe, Block || MIT || https://github.com/mcollina/node-coap
|-
| Ruby coap || Ruby || RFC 7252|| Client + Server (david) || Core, Observe, Block, RD || MIT, GPL || https://github.com/nning/coap<br/>https://github.com/nning/david
Line 269 ⟶ 306:
|-
| txThings || Python (Twisted) || RFC 7252|| Client + Server || Blockwise Transfers, Observe (partial) || MIT || https://github.com/mwasilak/txThings/
▲|-
▲| coap-rs || Rust || RFC 7252|| Client + Server || Core, Multicast, Observe option, ''Too Many Requests'' Response Code || MIT || https://github.com/Covertness/coap-rs
▲https://docs.rs/coap/
|-
| YaCoAP || C || || || || MIT || https://github.com/RIOT-Makers/YaCoAP
|-
|}
▲==Proxy implementations==
▲* [http://telecom.dei.unipd.it/pages/read/90/ Squid 3.1.9 with transparent HTTP-CoAP mapping module]
▲* [https://code.google.com/p/jcoap/ jcoap Proxy]
▲* [https://github.com/eclipse/californium/tree/master/californium-proxy2 Californium cf-proxy2]
▲* [https://github.com/Tanganelli/CoAPthon CoAPthon]
▲* [https://github.com/keith-cullen/FreeCoAP FreeCoAP]
==CoAP group communication==
Line 295 ⟶ 322:
== Security ==
CoAP defines four security modes:<ref>
* NoSec, where [[DTLS]] is disabled
* PreSharedKey, where DTLS is enabled, there is a list of pre-shared keys, and each key includes a list of which nodes it can be used to communicate with. Devices must support the AES cipher suite.
Line 301 ⟶ 328:
* Certificate, where DTLS is enabled and the device uses [[X.509]] certificates for validation.
Research has been conducted on optimizing DTLS by implementing security associates as CoAP resources rather than using DTLS as a security wrapper for CoAP traffic. This research has indicated that improvements of up to 6.5 times none optimized implementations.
In addition to DTLS, RFC8613<ref>{{Cite journal|last1=Palombini|first1=Francesca|last2=Seitz|first2=Ludwig|last3=Selander|first3=Goeran|last4=Mattsson|first4=John|title=Object Security for Constrained RESTful Environments (OSCORE)|url=https://tools.ietf.org/html/rfc8613.html|access-date=2021-05-07|website=tools.ietf.org|year=2019 |doi=10.17487/RFC8613 |s2cid=58380874 |language=en}}</ref> defines the Object Security for Constrained RESTful Environments ([[OSCORE]]) protocol which provides security for CoAP at the application layer.
| |||