[riot-notifications] [RIOT-OS/RIOT] sys/net/gcoap: allow seperate response (#16578)

Jana Eisoldt notifications at github.com
Thu Jun 24 10:22:25 CEST 2021


> Short test on native showed that it works as decribed:
> ![separate_response_test](https://user-images.githubusercontent.com/5045674/123120697-d321bb80-d444-11eb-9d1c-f446ea7751e8.png)
> 
> The RFC section for separate responses is not totally clear to me: https://datatracker.ietf.org/doc/html/rfc7252#section-5.2.2
> 
> ```
> When the server chooses to use a separate response, it sends the
> Acknowledgement to the Confirmable request as an Empty message.  Once
> the server sends back an Empty Acknowledgement, it MUST NOT send back
> the response in another Acknowledgement, even if the client
> retransmits another identical request. 
> ```
> 
> If I understand it correctly, the separate response is not allowed to be sent back as an ACK in this case, since we sent an empty ACK before? So it must be a non-confirmable or confirmable message?

I understand this section the way that there must not be another ACK for the request as it is sent in piggybacked responses.

If the separate response is sent as a non-confirmable of confirmable message depends on the server (see again https://datatracker.ietf.org/doc/html/rfc7252#section-5.2.2):
```
 When the server finally has obtained the resource representation, it
   sends the response.  When it is desired that this message is not
   lost, it is sent as a Confirmable message from the server to the
   client and answered by the client with an Acknowledgement, echoing
   the new Message ID chosen by the server.  (It may also be sent as a
   Non-confirmable message; see Section 5.2.3.)
```

I assume a CON message for the response, but since my implementation includes a flag anyways it could of course also allow to go for a NON message.



> What this PR also completely lacks is handling empty ACKs on client side, right? So a node still sends retransmissions, even when a server sent an empty ACK msg to indicate a separate response. This must be addressed in any case.

This is already implemented, see [gcoap.c](https://github.com/RIOT-OS/RIOT/pull/16578/files#diff-ded782b26b569cf2266e68098c3500e2cbd358ad2a3d161617ea6dd6acee76c7L188-L190) in `static void _process_coap_pdu(sock_udp_t *sock, sock_udp_ep_t *remote,
                              uint8_t *buf, size_t len)` in line 188:
```                
if ((memo != NULL) && (memo->send_limit != GCOAP_SEND_LIMIT_NON)) {
      DEBUG("gcoap: empty ACK processed, stopping retransmissions\n");
      _cease_retransmission(memo); 
```
                    
That was apparently added in #14178. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/RIOT-OS/RIOT/pull/16578#issuecomment-867441917
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20210624/4da390bb/attachment.htm>


More information about the notifications mailing list