Commit reliability on client after receiving ACK #227
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
From RFC 8832 https://www.rfc-editor.org/rfc/rfc8832.html#name-procedures, messages should be ordered till dialing/opening side receives ACK. ``` After the DATA_CHANNEL_OPEN message has been sent, the sender of that message MAY start sending messages containing user data without waiting for the reception of the corresponding DATA_CHANNEL_ACK message. However, before the DATA_CHANNEL_ACK message or any other message has been received on a data channel, all other messages containing user data and belonging to this data channel MUST be sent ordered, no matter whether the data channel is ordered or not. After the DATA_CHANNEL_ACK or any other message has been received on the data channel, messages containing user data MUST be sent ordered on ordered data channels and MUST be sent unordered on unordered data channels. Therefore, receiving a message containing user data on an unused stream indicates an error. In that case, the corresponding data channel MUST be closed, as described in [RFC8831]. ``` Without waiting, the data channel open failed on Accept side as the first message did not have PPI of DCEP. It got a user message and that caused the Accept to fail.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #227 +/- ##
==========================================
- Coverage 67.79% 67.66% -0.13%
==========================================
Files 4 4
Lines 267 266 -1
==========================================
- Hits 181 180 -1
Misses 61 61
Partials 25 25
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Sean-Der
approved these changes
Aug 16, 2024
|
Thank you @boks1971 ! wanna tag and put in /v3 and /v4 I believe we have an open issue because of this. You can override the CI failure. I’m not sure why it started falling yesterday will fix today |
Can do that @Sean-Der . But, GH is not allowing me to override (greyed out button). Lint is failing on deps. |
cnderrauber
approved these changes
Aug 16, 2024
edaniels
approved these changes
Aug 16, 2024
|
@Sean-Der Renovate PR updated the tag (I created v1.5.9 with this change) in I am trying to update Can you advise what we should do here? |
|
Tests do work though although |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
From RFC 8832
https://www.rfc-editor.org/rfc/rfc8832.html#name-procedures, messages should be ordered till dialing/opening side receives ACK.
Without waiting, the data channel open failed on Accept side as the first message did not have PPI of DCEP. It got a user message and that caused the Accept to fail.
Description
Reference issue
Fixes #...