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

Fix ordering arranging handler for >65536 packets #229

Merged
merged 5 commits into from
Sep 1, 2019

Conversation

kstrafe
Copy link
Contributor

@kstrafe kstrafe commented Sep 1, 2019

The arranging handler would not reset the value of the expecting index back to 0 which caused the case of having over 2**16 packets to simply be ignored.

Note: This is #227 but for some reason it didn't track my commits after merging #228, so that one got closed and this one opened. (Apparently had upstreamed to master...)

The expected index is a u16 at the protocol level, but the arranging
implementation for orderingstream does not take this into account. This
caused sending over 2**16 ordered packets to simply default to the
`None` case and get ignored. This patch solves that issue.
@codecov
Copy link

codecov bot commented Sep 1, 2019

Codecov Report

Merging #229 into master will increase coverage by 0.16%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #229      +/-   ##
==========================================
+ Coverage   97.37%   97.54%   +0.16%     
==========================================
  Files          25       25              
  Lines        2440     2486      +46     
==========================================
+ Hits         2376     2425      +49     
+ Misses         64       61       -3
Impacted Files Coverage Δ
src/net/virtual_connection.rs 96.9% <ø> (ø) ⬆️
src/net/socket.rs 96.24% <100%> (+0.17%) ⬆️
src/infrastructure/arranging/ordering.rs 99.23% <100%> (+0.13%) ⬆️
src/packet/enums.rs 97.1% <0%> (+2.89%) ⬆️
src/lib.rs 100% <0%> (+100%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d8f8bd1...ce03a18. Read the comment docs.

Copy link
Owner

@TimonPost TimonPost left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me

Copy link
Contributor

@jstnlef jstnlef left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Besides the 1 comment, looks good.

src/infrastructure/arranging/ordering.rs Outdated Show resolved Hide resolved
Previously we would only store packets with indices higher than the
expected index, this is obviously not going to give us good results when
we receive packets 0..100 while we are currently expecting index 65500.

What this patch does is that it stores all incoming packets with the
condition: expected < index < expected + u16::max/2

With wrapping add this becomes slightly more complex but the gist is the
same.
@jstnlef jstnlef merged commit d93fc01 into TimonPost:master Sep 1, 2019
jstnlef added a commit to jstnlef/laminar that referenced this pull request Oct 12, 2019
Fix ordering arranging handler for >65536 packets
jstnlef added a commit that referenced this pull request Oct 12, 2019
Fix ordering arranging handler for >65536 packets
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants