Skip to content
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 sends replies to all received retransmissions at the same time #218

Open
mladedav opened this issue Mar 23, 2021 · 2 comments
Open
Labels
bug Something isn't working

Comments

@mladedav
Copy link
Contributor

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.

@mladedav
Copy link
Contributor Author

I believe that the issue lies here:

l := cc.msgIdMutex.Lock(reqMid)

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.

@jkralik jkralik added the bug Something isn't working label May 20, 2021
@jkralik
Copy link
Member

jkralik commented May 20, 2021

@mladedav Thx for find the core of problem.

kegsay added a commit to matrix-org/lb that referenced this issue Jun 1, 2021
…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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants