nanocoap: add support for no-response option

[benpicco]

Contribution description

This adds support for the no-response option (RFC 7968) in the nanoCoAP server.

To allow for testing and easy use, the two client functions nanocoap_sock_put_non() and nanocoap_sock_post_non() are also added which will add the no-response option if no payload response is requested.

Testing procedure

A new put_non command has been added to tests/nanocoap_cli:

> put_non coap://[fe80::58b0:8ff:fe67:ad82]/value 42
> ncget coap://[fe80::58b0:8ff:fe67:ad82]/value -
42

Verify in Wireshark that indeed no response was generated to the PUT request

Issues/PRs references

[chrysn]

I've pushed a suggestion (GitHub doesn't let me add suggestions to files you didn't touch) to reflect the response code in the documentation.

An aspect this misses on the CoAP side is that No-Response acts on the request-response sublayer, but leaves the reliability sublayer intact. IOW: When a CON request is sent with No-Response, there still needs to be an ACK (but if the response is actually suppressed, it would be an empty ACK). In the implementation, that'd mean building a response header with a zero-length token and a zero code, and returning the header length.

[benpicco]

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.

[miri64]

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.

[benpicco]

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.

[miri64]

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.

[benpicco]

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)

[miri64]

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 #18386 for a server application that generates "separate responses").

RIOT/sys/net/application_layer/gcoap/gcoap.c

Lines 446 to 450 in c9bbac8

	switch (coap_get_type(&pdu)) {
	case COAP_TYPE_CON:
	messagelayer_emptyresponse_type = COAP_TYPE_ACK;
	DEBUG("gcoap: Answering CON response with ACK\n");
	/* fall through */

[chrysn]

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.

[benpicco]

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?

[chrysn]

I'm happy with this now, thanks for sticking with it.

Not too much has changed since the version I've tested. Two notes on documentation in the usual mixture of "I think this needs to be documented" and "If this is inaccurate I'd have misunderstood something" -- but unless the latter triggers, it's fine without them as well.

Please squash.