-
-
Notifications
You must be signed in to change notification settings - Fork 116
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Server][Confirmable] Confirm messages before reply is ready #216
Comments
@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 go-coap/examples/observe/server/main.go Line 78 in 231b8cd
eg something like:
|
@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. |
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 exposedClient
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.
The text was updated successfully, but these errors were encountered: