Revision as of 14:19, 26 October 2022 edit DrTobbe (talk \| contribs) 12 edits →CoAP Fixed Header: Clarify that the first 4 bytes constitute the header which is why they are always required ← Previous edit		Revision as of 14:56, 26 October 2022 edit undo DrTobbe (talk \| contribs) 12 edits →Message formats: Clarify message ID usage for acknowledgement/reset matching and token usage for request-response-matching Next edit →
Line 145: ==== Message ID (16 bits) ==== :Used to detect message duplication and to match messages of type acknowledgement/reset to messages of type confirmable/non-confirmable~~. Response messages will have the same message ID as the request has~~. === Token === ~~This~~Every isrequest ancarries ~~optional~~a ~~field~~token ~~whose~~(but ~~size~~it ismay ~~indicated~~be ~~by the token~~zero length ~~field,~~) whose ~~values~~value iswas 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 ~~provide~~match ~~extra~~requests ~~context~~and ~~for~~responses, ~~certain~~especially for concurrent ~~transactions~~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 ===

Constrained Application Protocol: Difference between revisions