RIOT
RIOT copied to clipboard
RIOT-OS
nanocoap: add support for no-response option for non-confirmable messages
Contribution description
This adds support for the no-response option (RFC 7968)
Testing procedure
Issues/PRs references
I suppose it makes sense to limit no-response to NON requests then, when we are sending a response anyway we might was well include the payload.
I suppose it makes sense to limit no-response to NON requests then, when we are sending a response anyway we might was well include the payload.
As far as I understood @chrysn, CON requests are also possible to have no-response. They would just an empty ACK. Shouldn't be too difficult to implement.
But does it make sense? The RFC says
Using this option with CON requests may not serve the desired purpose if piggybacked responses are triggered. But, if the server responds with a separate response (which, perhaps, the client does not care about), then this option can be useful.
Since we are not doing separate response, I don't think this is useful for CON messages.
Since we are not doing separate response, I don't think this is useful for CON messages.
What even are "separate responses" in this context? Late CON responses after the server already ACK'd the request with an empty ACK? In this case, I think it does all the more sense to save traffic from the server.
Yes - but we don't have this implemented AFAIK (and it would also not be relevant here since the payload length of the ACK would then be 0 anyway)
Yes - but we don't have this implemented AFAIK (and it would also not be relevant here since the payload length of the ACK would then be 0 anyway)
We do have empty ACKs implemented. In gcoap at least (also see https://github.com/RIOT-OS/RIOT/pull/18386 for a server application that generates "separate responses").
https://github.com/RIOT-OS/RIOT/blob/c9bbac816c54c7fe994867a7245e2e68d37b0059/sys/net/application_layer/gcoap/gcoap.c#L446-L450
Just because we don't have them implemented (well) doesn't mean that the client can't send a CON request with a No-Response option. Sending the full answer (as we do now) is not wrong, as the option is not critical.
Adding no-response support for NON messages is easy (less than 10 lines in nanocoap.c), adding no-response support for CON messages is a whole different effort that I'm still not sure if it's justified. Could we relegate that to a separate PR?
Adding no-response support for NON messages is easy (less than 10 lines in
nanocoap.c), adding no-response support for CON messages is a whole different effort that I'm still not sure if it's justified. Could we relegate that to a separate PR?
If this is true, something is seriously wrong with the message layering in nanocoap.c... From the request-response layer perspective the addition of an option in said layer should not make any difference, if the underlaying message type is NON or CON to wait or not to wait for a response. As said before: handling of empty ACKs is already implemented, so the retransmission algorithm should work regardless of if there is a response or not.
From the request-response layer perspective the addition of an option in said layer should not make any difference, if the underlaying message type is NON or CON to wait or not to wait for a response.
This is about the server, it will not wait for a response, it generates the response. The client will already handle this just fine. (Although nanoCoAP sock client currently has no support for separate response)
Currently we can just return 0 in coap_build_reply() if we don't want to send anything (NON and no-response).
If we have CON and no-response, we still have to send the ACK, but not the payload. Modifying only coap_build_reply() will not work here, we also have to touch all callers of the function.
Since no-response CON doesn't seem very useful, I really don't think it's worth the effort.
Ah sorry, I thought the warning about using the no-response option and NON was still in place. There is no request handling per se in nanocoap.c, that why I was thinking you were still talking about the message construction.
Since no-response CON doesn't seem very useful, I really don't think it's worth the effort.
Why doesn't it seem useful to you to have a confirmed request transmission where you can tell the server "no thank you no full response needed"? If you send a unidirectional message e.g. via TCP, the exact same thing happens and there it also seems useful.
Murdock results
:heavy_check_mark: PASSED
29cb2d05a3b76173a52eda9edb0d89e94d0ea00e tests/nanocoap_cli: add test for no-response
| Success | Failures | Total | Runtime |
|---|---|---|---|
| 1983 | 0 | 1983 | 06m:54s |
Artifacts
This only reflects a subset of all builds from https://ci-prod.riot-os.org. Please refer to https://ci.riot-os.org for a complete build for now.
