coap-engine,coap-transactions: Fix handling of separate response #953
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
akindestam
force-pushed
the
coap-separate-response
branch
2 times, most recently
from
ef14fde
to
236a8e5
Compare
akindestam
force-pushed
the
coap-separate-response
branch
from
236a8e5
to
627235d
Compare
|
Rebased on latest develop. Also added some missing includes |
A response from a server might come as a "separate response" where first an empty message ACK is sent to tell the client there is no need to retransmit, and that it should expect a response message soon. (RFC 7252 §5.2.2) To stop the client from retransmitting when our message has already been ACKed, a field was added to coap_transaction_t that blocks the coap_sendto call in coap_send_transaction, with the retrans_timer continuing to fire like normal so that we can still time out if the response from the server never shows up. The response message is sent with a new Message ID chosen by the server, and if its type is CON it should be ACK:ed by the client to inform the server that the response has been successfully received. To be able to handle all of the above we also need to fix how transactions are managed and matched; the response from the server won't be using the same Message ID as in the request. According to RFC, request/response should be matched using the token and endpoint information only (RFC 7252 §5.3), so transactions were refactored to match on this information instead of matching on Message ID (except in the case of an empty message ACK).
The confirmable type needs to be acknowledged. When DTLS is used the ack can no longer be contained only in the header part of the coap message and the call to coap_sendto() overwrites the payload of a message stored in uip_buf (calls uip_udp_packet_sendto() from dtls_write with a data length > 0), hence the need to store the payload before sending the ack is needed.
akindestam
force-pushed
the
coap-separate-response
branch
from
09200e5
to
e4b6f84
Compare
|
Hi! This was my mistake, very sorry about it, re-opening this PR now. What happened is the following: I was switching the base branch for this repository https://github.com/wittra/contiki-ng from develop to wittra. But accidentally, I made the change on the wrong repo (this repo) and instead of switching the base branch I renamed it. And somehow github deleted develop and closed all PRs... Many apologies for this mishap 🙏; I haven't contributed in a while.. but now at least everybody got some notification from me :p |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A response from a server might come as a "separate response" where first an
empty message ACK is sent to tell the client there is no need to retransmit, and
that it should expect a response message soon. (RFC 7252 §5.2.2)
To stop the client from retransmitting when our message has already been ACKed,
a field was added to coap_transaction_t that blocks the coap_sendto call in
coap_send_transaction, with the retrans_timer continuing to fire like normal so
that we can still time out if the response from the server never shows up.
The response message is sent with a new Message ID chosen by the server, and if
its type is CON it should be ACK:ed by the client to inform the server that the
response has been successfully received.
To be able to handle all of the above we also need to fix how transactions are
managed and matched; the response from the server won't be using the same
Message ID as in the request. According to RFC, request/response should be
matched using the token and endpoint information only (RFC 7252 §5.3), so
transactions were refactored to match on this information instead of matching on
Message ID (except in the case of an empty message ACK).