You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I tried using the simple server with long-running operation and since the server doesn't send back ACKs, 3 retransmissions occured. After the handler finished, the server sent 4 answers, 1 for each received message, all four in less than 1 millisecond.
All messages were identical including message ID and token since they are presumably all responses to the same request.
The text was updated successfully, but these errors were encountered:
If the lock cannot be acquired right away, it means something is already processing the message and therefore the request is a retransmission/duplicate. Thus it can and should be dropped. Since the answer is not ready yet and will be sent as soon as it is available.
For the record if the server handles the request fast enough it currently works correctly (i.e. handler is not called again and the response is retransmitted) and with this change that would still be the case.
Am I missing something?
This is happening because the request was not confirmed by the server, but a scenario where the confirming message is lost is very real and in that case the same issue with retransmissions would occur and the server should be ready for that case.
…y response bodies
Large sync responses take longer than the default `time.Second` to send over blockwise
xfer so increase the timeout.
Added `WaitTimeBeforeACK` to the proxy `Config` which is
the number of seconds to wait before sending an ACK back if the upstream HS hasn't
responded yet. Without this, large sync responses which take a while to calculate on
the HS side would cause the client to retransmit the sync request, which, when coupled
with a go-coap bug plgd-dev/go-coap#218 would cause the
large response to be sent multiple times via blockwise xfer.
Sometimes servers respond with no bodies, which was not correctly handled in the proxy
server or some CLI tools.
I tried using the simple server with long-running operation and since the server doesn't send back ACKs, 3 retransmissions occured. After the handler finished, the server sent 4 answers, 1 for each received message, all four in less than 1 millisecond.
All messages were identical including message ID and token since they are presumably all responses to the same request.
The text was updated successfully, but these errors were encountered: