net/gcoap: Provide piggybacked ACK response to confirmable request#7223
net/gcoap: Provide piggybacked ACK response to confirmable request#7223aabadie merged 3 commits intoRIOT-OS:masterfrom
Conversation
| size_t pdu_len = _handle_req(&pdu, buf, sizeof(buf), &remote); | ||
| if (pdu_len > 0) { | ||
| sock_udp_send(sock, buf, pdu_len, &remote); | ||
| if (coap_get_type(&pdu) == COAP_TYPE_NON |
There was a problem hiding this comment.
you could use a switch-case over the possible coap types here, something like
switch(coap_get_type(&pdu)) {
case COAP_TYPE_NON:
case COAP_TYPE_CON:
size_t pdu_len = _handle_req(&pdu, buf, sizeof(buf), &remote);
if (pdu_len > 0) {
sock_udp_send(sock, buf, pdu_len, &remote);
}
break;
case COAP_TYPE_RST:
case COAP_TYPE_ACK:
DEBUG("gcoap: RST and ACK handler not implemented yet!\n");
break;
default:
DEBUG("gcoap: illegal request type: %u\n", coap_get_type(&pdu));
return;
}
[edit] fixed indention above
|
@smlng, thanks for the quick review! I appreciate your debug output to indicate a message can't be handled yet. It made me realize that it wasn't right to say an empty message (code 0.00) is 'illegal'. So, I called that scenario out first, which means that a request code class message must be either NON or CON type. For reference see Table 1 at the end of sec. 4.3 in the spec. |
|
@smlng's code is within the handling for a request-class code (GET, POST, etc). Since RST and ACK types are not valid for a request-class code, there are only two cases -- NON/CON and illegal. A case statement seemed like overkill for only two cases. Am I missing something? |
|
True. @smlng, do you agree? |
|
yes, agreed - RFCs allows NON and CON as requests only. And at least with the current handling of CoAP message types, an |
|
Let's go here. |
Implements the first task of #7192 for confirmable messaging. Also updated documentation and added a couple of unit tests.