Flood ACKs on DM back to original sender #2069
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This changes the hopLimit for real ACKs (only sent when receiving a DM) from 0 to the configured one, like normal packets. This way the ACK will be flooded back to the original sender, such that can be guaranteed that the packet arrived at the intended receiver.
When a client now gets an ACK, if the ‘from’ field is your nodeNum, then it is an implicit ACK (meaning a rebroadcast on the mesh), if it is the nodeNum of the intended receiver, successful reception is confirmed.
Based on what I saw using the simulator, I now removed resending ACKs for repeated incoming messages (introduced in #924), as this may happen due to flooding and then you will send another ACK each time. Since the ACKs are now flooded back, there is already some redundancy for lost ACKs.