[Server][Confirmable] Confirm messages before reply is ready

[mladedav]

I cannot seem to find a method to confirm confirmable messages where the reply may take longer to be generated. Sorry if I have missed the correct functions somewhere.

In other words I have only found SetResponse method, which I assume sends piggy-backed response. The exposed Client also seems to be able to send only requests.

I tried simulating long running operations in the sample server and the sample client fails after about 12 seconds (ignoring WithTimeout) because the request seems to not be acknowledged by default and retransmissions were exhausted.

I would propose to either confirm messages automatically (there are a few problems here - namely there would have to be some mechanism to give the code chance to create the response to be piggy-backed and only then it would send the empty confirmation) or the users have to control this explicitly.

[jkralik]

@mladedav to confirm message go-coap automatic sends a separate message which contains "Acknowledged". So for your use case you can use a similar approach as https://github.com/plgd-dev/go-coap/blob/231b8cdcfcc3c892098539a987c14d7c415c0838/examples/observe/server/main.go#L78

eg something like:

go func() {
   time.Sleep(time.Second*10)
   sendResponse(w.Client(), r.Token, data)
}()

[mladedav]

@jkralik acknowledgement is not the same thing as a response in CoAP. I get that I can send piggy-backed response this way (sending a response along with the acknowledgement), but coap allows ack messages to be sent without payload and the actual response is sent after that in its own confirmable message.

See https://datatracker.ietf.org/doc/html/rfc7252#section-5.2.2 and Figure 5 at https://datatracker.ietf.org/doc/html/rfc7252#section-2.2 for more information.

Also note that the example you provided illustrates the issue because the processing takes long enough for the client to send several retransmissions (which is undesirable) and if you made the sleep a bit longer, clients will time out because no ACK message will be received even though the server started processing the request.

[jkralik]

It is implemented as in mentioned in #474 . Pls we will continue discussion in #474 . Thx