Description

Gcoap seems not to handle separate responses at all.

Steps to reproduce the issue

• Run a CoAP server that sends separate responses (ie. sends an empty ACK in response to a CON, takes its time, and then sends the response in a CON of its own), for example the aiocoap demo server at its /other/separate resource (which takes several seconds to respond)
• Run the gcoap example
• coap get -c your-own-host 5683 /other/separate

Expected results

The client should cease retransmission once it receives the ACK (which comes along at the original request's MID), and then wait (until its timeout) to receive a any new message on the requested token.

If that request is a CON, the client ACKs it. (If it has timed out, it may also RST it.)

Actual results

The client ignores the empty ACK, keeps retransmitting, ignores the incoming CON when it's finally there and eventually times out.

Versions

Current RIOT master (8a2b089), tested on ntive.

Next steps

I'll look into how this is best resolved.

One likely first step is to remove the check for "does the message ID match" in the response processing -- on request/response level, only the token matters.

Then, on receipt of a CON in a response, an ACK or RST needs to be sent. (The distinction could be whether a memo was found, but just sending an ACK should be just as fine, gotta check with the spec).

Finally, arriving empty ACKs will be checked for whether they match a memo, and silence its retransmissions. This may involve some nontrivial changes because it seems to me that the retransmission counter doubles as an application timeout -- that means that once the ACK is received, the eventual timeout needs to be calculated for an application timeout to be scheduled then.

@kb2ma or @haukepetersen, I'd appreciate a quick "sounds good" or "that's problematic" on the above steps before I start hacking away.