Closed MichalPoterek closed 2 years ago
You can find a more detailed explanation of the procedure in section 4.2 of RFC 7252. The request is (by default) re-sent up to 4 times. Once the ack timeout has passed, a new timeout is set with a doubled duration (the resend timer grows exponentially). In order to not overwhelm a server if multiple clients should be sending at the same time, there is also a randomization factor, so the exact timeout period always varies a bit.
Thank you very much for kind explanation ;)
You're welcome :) Feel free to ask if you have any more questions :)
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within the next 7 days. Please check if the issue is still relevant in the most current version of the adapter and tell us. Also check that all relevant details, logs and reproduction steps are included and update them if needed. Thank you for your contributions.
This issue has been automatically closed because of inactivity. Please open a new issue if still relevant and make sure to include all relevant details, logs and reproduction steps. Thank you for your contributions.
Hi, I would like to confirm that the retransmission time for Confirmable COAP Messages is ackTimeout. Does my understanding is correct that after some COAP message is sent then COAP message msgid is kept in a table and COAP daemon is waiting for confirmation message which should be received for this msgid within the time range specified in ackTimeout? If confirmation will not arrive within ackTimeout range then retransmission will happen?