Client: Separate responses not processed

[chrysn]

A CoAP server has the choice to either send the response message to a confirmable request as a piggy-backed response (along with the ACK), or as a separate message. When coap-rs is used in a client and the server sends a separate message, the empty ACK is given to the application, where I'd expect the library to give the application the actual response (which is sent later).

If this is not handled in the CoAP library, client applications can easily start breaking once a server is updated to a newer version (that might make better informed decisions on when to send which kind of response), when proxies are in use, or simply when the server is under higher load than usual. I do not think that it is reasonable to expect application code to handle this manually, given the overall high level of abstraction coap-rs provides. Depending on how #79 is implemented, applications might not even have the means to implement the necessary behavior on their own.

RFC 7252 has the precise details, but the rough logic I'm using in other implementations is:

• Send the request, configuring its retransmissions.
• When an empty ACK is received, cease retransmissions. The application configured total timeout is still left active.
• When receiving a response, present it to the application and terminate all timeouts.
  • If the response is sent in a CON, send an ACK.
• When receiving a response that does not match any (or, in a fully serialized library, the) outstanding request, and the response is sent in a CON, send a RST. If ihas any other type, silently ignore it.

(CC @malishav with whom I encountered this).

[Covertness]

The client need to be enhanced.

[Covertness]

resolved in #91