-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Duplicate ACK to same message id will cause receiver reject the message #7909
Comments
#7935 will mostly do that. We could still run into it in the following way, with events listed in the order they happen, with time passing between the steps:
This is a perfectly legitimate sequence of events, albeit one that is not going to happen in our CI as things currently stand, because our CI does not test interesting complicated network scenarios so far... I keep hoping we'll re-enable the cirque tests and use those to test this sort of thing. Anyway, given the scenario above it seems clear to me that a message with a piggyback ack that is not itself a duplicate has to be processed properly even if the ack is for a message id that we don't think we need an ack for. |
Or another scenaraio where we have the same problem:
This scenario we could test in our existing CI, by just having our loopback-drops-messages stuff set up to strategically drop the right things (the message from step 3 in this case). |
We can get a message with a piggybacked ack for a message we have already gotten a standalone ack for. In this case we should process the message, not drop it. Fixes project-chip#7909
We can get a message with a piggybacked ack for a message we have already gotten a standalone ack for. In this case we should process the message, not drop it. Fixes project-chip#7909
We can get a message with a piggybacked ack for a message we have already gotten a standalone ack for. In this case we should process the message, not drop it. Fixes project-chip#7909
We can get a message with a piggybacked ack for a message we have already gotten a standalone ack for. In this case we should process the message, not drop it. Fixes project-chip#7909
We can get a message with a piggybacked ack for a message we have already gotten a standalone ack for. In this case we should process the message, not drop it. Fixes #7909
We can get a message with a piggybacked ack for a message we have already gotten a standalone ack for. In this case we should process the message, not drop it. Fixes project-chip#7909 Signed-off-by: Doru Gucea <doru-cristian.gucea@nxp.com>
…chip#9875) We can get a message with a piggybacked ack for a message we have already gotten a standalone ack for. In this case we should process the message, not drop it. Fixes project-chip#7909 Signed-off-by: Doru Gucea <doru-cristian.gucea@nxp.com>
Problem
Proposed Solution
Analysis the protocol and
The text was updated successfully, but these errors were encountered: