Fix next source piece index calculation #3300
Conversation
| @@ -143,7 +143,7 @@ impl PieceIndex { | |||
| /// Returns the next source piece index | |||
| #[inline] | |||
| pub const fn next_source_index(&self) -> PieceIndex { | |||
| PieceIndex(self.0.next_multiple_of(Self::source_ratio())) | |||
| PieceIndex(self.0 + Self::source_ratio() - (self.0 % Self::source_ratio())) | |||
There was a problem hiding this comment.
I do not understand why subtraction is needed here, it'll always be 0.
Also the whole source_ratio doesn't really make sense because it only works for cases when numerator is 1. If we had 2/3 it would return 1, which would be wrong, so if this code was to be fixed, it'd be fixed to account for that.
There was a problem hiding this comment.
The subtraction is needed to calculate the next source piece after a parity piece.
Removing source_ratio() is a larger change which isn't needed to fix this bug, I'll push it in another PR.
Edit: see PR #3301.
There was a problem hiding this comment.
source_ratio() is 2, source indices are always even numbers, hence you're always subtracting 0. How would you describe what this code is doing with regular English?
There was a problem hiding this comment.
If you start with a source piece index, add 2 to go to the next source piece index.
If you start with a parity piece index, add 2 to go to the next source/parity piece pair, then subtract 1 to go to the source piece index in that pair.
teor2345
force-pushed
the
fix-multi-piece
branch
from
165c21a to
436f462
Compare
Simplify source piece & data handling during object retrieval
|
#3301 fixed my concerns |
This PR fixes a bug in the next source piece calculation, where it returned the current piece index if it was a source piece. This led to incorrect object data being retrieved during fast object retrieval across pieces.
It also cleans up some of the related data handling code.Code contributor checklist: