This commit makes sure we continue to wait for extra confirmations even
after the request is done so we can handle duplicate confirmations if any.
Detailed description:
rfc7252#section-4.5 specifies that:
"The recipient SHOULD acknowledge each duplicate copy of a
Confirmable message".
So if, for example, the client sends to a multicast destination address,
the server will get multiple requests and will confirm all of them.
Without this commit, the client will set the request to done after
receiving the first answer.
From here the request object will be marked as free and the duplicate
acknowledgements will stay buffered in the network stack.
Once the client tries to send a new request, it will unbuffer those
duplicate acknowledgements but now the request object is unallocated
so the client won't be able to handle those acknowledgements as duplicates.
It will instead treat it as an unexpected ACK.
To work around this issue, rfc7252#section-4.8.2 states that:
"EXCHANGE_LIFETIME is the time from starting to send a Confirmable
message to the time when an acknowledgement is no longer expected,
i.e., message-layer information about the message exchange can be
purged."
Keeping the request object allocated for EXCHANGE_LIFETIME ensures that
duplicate acknowledgements can be handled accordingly.
This commit adds a basic implementation of what is stated in the RFC.
EXCHANGE_LIFETIME has been arbitrarily set to 3 * ACK_TIMEOUT which
seems more reasonable than the 247 seconds stated in the RFC.
Signed-off-by: Francois Gervais <francoisgervais@gmail.com>
bfed8d0966