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.
There was previously an issue with the nack buffer that would occur when an uploader was experiencing packet loss (or otherwise had reordering occur).
lastAdded
was getting set for every packet added to the buffer, but packets could get added out of order, causinglastAdded
to go backwards. The impact was that packets at the end of the buffer were sometimes considered stale and cleared out. Consider the following sequence of packets being added to the buffer:1, 2, 4, 3, 5, ...
When 4 is added,
lastAdded
would correctly be 4, but then when 3 arrived,lastAdded
would go backwards to 3. This would cause two related problems: trying to get 4 from the buffer would fail (uint16(3 - 4) > Uint16SizeHalf
), and then when we add 5, we would treat 4 as a gap betweenlastAdded
(3) andseq
(5) and thus release 4 from the buffer, such that even after 5 was added, we would still not be able to retrieve 4 from the buffer.This PR modifies the logic to only move
lastAdded
forward ifdiff
is "positive" (less thanUint16SizeHalf
), meaning the new packet is newer than any packet received previously.