-
Couldn't load subscription status.
- Fork 505
fix: close webrtc streams without data loss #2073
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
Conversation
5e47bff to
005ddbf
Compare
|
@achingbrain is this ready for review? |
|
@wemeetagain yes! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good so far, left some comments.
Chrome does not always send all messages after closing a datachannel even if `bufferedAmount` is `0` before closing. This PR adds a `FIN_ACK` message that is sent in reply to a `FIN` message - because all messages are send in-order, when this is received we know the remote has received all of our data messages and it's safe to close the channel.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great job on this, one minor comment. lgtm
Co-authored-by: Chad Nehemiah <[email protected]>
- Gracefully close streams on muxer shutdown - Refactor initiator/recipient flows for clarity - Wait for `bufferedAmount` to be `0` before closing a datachannel - Close datachannels on both initiator and recipient - Implements FIN_ACK for closing datachannels without data loss Supersedes #2048 --------- Co-authored-by: Chad Nehemiah <[email protected]>
bufferedAmountto be0before closing a datachannelSupersedes #2048
Depends on: