Constrained Application Protocol: Difference between revisions

Content deleted Content added
Tags: Mobile edit Mobile web edit
Message formats: style adaptation
Line 16:
 
==Message formats==
The smallest CoAP message is 4 bytes in length, if omittingthe Tokentoken, Optionsoptions and Payloadpayload fields are omitted. CoAP makes use of two message types, requests and responses, using a simple, binary, base header format. The base header may be followed by options in an optimized Type-Length-Valuetype–length–value format. CoAP is by default bound to [[User Datagram Protocol|UDP]] and optionally to [[DTLS]], providing a high level of communications security.
 
Any bytes after the headers in the packet are considered the message body. The length of the message body is implied by the datagram length. When bound to UDP, the entire message MUST''must'' fit within a single datagram. When used with [[6LoWPAN]] as defined in RFC 4944, messages SHOULD''should'' fit into a single [[IEEE 802.15.4]] frame to minimize fragmentation.
{| class="wikitable" style="margin: 0 auto; text-align:center"
|+ CoAP Header
! Offsets !! [[Octet (computing)|Octet]] offset !! !! colspan="8" | 0 !! colspan="8" | 1 !! colspan="8" | 2 !! colspan="8" | 3
|-
! Octet !! [[Bit (computing)|Bit]] offset !! 0 !! 1 !! 2 !! 3 !! 4 !! 5 !! 6 !! 7 !! 8 !! 9 !! 10 !! 11 !! 12 !! 13 !! 14 !! 15 !! 16 !! 17 !! 18 !! 19 !! 20 !! 21 !! 22 !! 23 !! 24 !! 25 !! 26 !! 27 !! 28 !! 29 !! 30 !! 31
|-
! 4 !! 32
| colspan="2" | VERver || colspan="2" | Typetype || colspan="4" | Tokentoken Lengthlength || colspan="8" | Requestrequest/Responseresponse Codecode || colspan="16" |Message message ID
|-
! 8 !! 64
| colspan="32" rowspan="2" | Tokentoken (0 - 80–8 bytes)
|-
! 12 !! 96
|-
! 16 !! 128
| colspan="32" | Optionsoptions (Ifif Availableavailable)
|-
! 20 !! 160
| 1 || 1 || 1 || 1 || 1 || 1 || 1 || 1 || colspan="24" | Payloadpayload (Ifif Availableavailable)
|}
 
=== CoAP Fixed Header: Version, Type, Token Length, Request/Response Code and Message ID. ===
The first 4 bytes are mandatory in all CoAP datagrams.
 
These fields can be easily 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 )
#define COAP_HEADER_TKL(data) ( (0x0F & (data)[0]) >> 0 )
#define COAP_HEADER_CLASS(data) ( ((data)[1] >> 5) & 0x07) )
#define COAP_HEADER_CODE(data) ( ((data)[1] >> 0) & 0x1F) )
#define COAP_HEADER_MID(data) ( ((data)[2] << 8) | (data)[3]) )
</syntaxhighlight>
 
==== Version (VERver) (2 bits) ====
 
:Indicates the CoAP version number.
Line 60:
:This describes the datagram's message type for the two message type context of Request and Response.
:* Request
:** 0 : Confirmable : This message expects a corresponding Acknowledgementacknowledgement message.
:** 1 : Non-confirmable : This message does not expect a confirmation message.
:* Response
Line 66:
:** 3 : Reset : This message indicates that it had received a message but could not process it.
 
==== Token Lengthlength (4 bits) ====
 
:Indicates the length of the variable-length Token field, which may be 0-80–8 bytes in length.
 
==== Request/Responseresponse Codecode (8 bits) ====
{| class="wikitable"
!0
Line 125:
| Unsupported Content-Format
}}
* Server Errorerror: 5.XX {{ordered list|start=0
| Internal Serverserver Errorerror
| Not Implementedimplemented
| Bad Gatewaygateway
| Service Unavailableunavailable
| Gateway Timeouttimeout
| Proxying Notnot Supportedsupported
}}
* Signaling Codes: 7.XX {{ordered list|start=0
Line 145:
==== Message ID (16 bits) ====
 
:Used to detect message duplication and to match messages of type Acknowledgementacknowledgement/Resetreset to messages of type Confirmableconfirmable/Nonnon-confirmable. Response messages will have the same Messagemessage ID as the request has.
 
=== Token ===
OptionalThis is an optional field whose size is indicated by the Tokentoken Lengthlength field, whose values is generated by the client. The server must echo every token value without any modification back to the client. It is intended for use as a client-local identifier to provide extra context for certain concurrent transactions.
 
=== Option ===
{| class="wikitable"
|+Option Format
! colspan="8" |Bit Positionsposition
|-
!0
Line 164:
!7
|-
| colspan="4" |Option Deltadelta
| colspan="4" |Option Lengthlength
|-
| colspan="8" |Option Deltadelta Extendedextended (Nonenone, 8 bits, 16 bits)
|-
| colspan="8" |Option Lengthlength Extendedextended (Nonenone, 8 bits, 16 bits)
|-
| colspan="8" |Option Valuevalue
|}
Option Deltadelta:
 
* 0 to 12: For delta between 0 to 12: Represents the exact delta value between the last option ID and the desired option ID, with no Optionoption Deltadelta Extendedextended value
* 13: For delta from 13 to 268: Option Deltadelta Extendedextended is an 8-bit value that represents the Optionoption Deltadelta value minus 13
* 14: For delta from 269 to 65,804: Option Deltadelta Extendedextended is a 16-bit value that represents the Optionoption Deltadelta value minus 269
* 15: Reserved for Payloadpayload Markermarker, where the Optionoption Deltadelta and Optionoption Lengthlength are set together as 0xFF.
 
Option Lengthlength:
 
* 0 to 12: For Optionoption Lengthlength between 0 to 12: Represents the exact length value, with no Optionoption Lengthlength Extendedextended value
* 13: For Optionoption Lengthlength from 13 to 268: Option Lengthlength Extendedextended is an 8-bit value that represents the Optionoption Lengthlength value minus 13
* 14: For Optionoption Lengthlength from 269 to 65,804: Option Lengthlength Extendedextended is a 16-bit value that represents the Optionoption Lengthlength value minus 269
* 15: Reserved for future use. It is an error iffor Optionthe Lengthoption length field isto be set to 0xFF.
 
Option Valuevalue:
 
* Size of Optionoption Valuevalue field is defined by Optionoption Lengthlength value in bytes.
* Semantic and format this field depends on the respective option.