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
webrtc: close data channels cleanly #2724
base: master
Are you sure you want to change the base?
Conversation
WebRTC data channel close is a synchronous close procedure. We close our outgoing stream, in response the peer is expected to close its outgoing stream. If the peer doesn't close its side of the stream we will end up with a memory leak where the SCTP transport keeps reference to the stream. So we check the number of invalid data channel closures and when this goes over a threshold we close the connection. For our custom purposes we can fork SCTP and implement a unilateral stream Reset which is feasible because we anyway have a state machine on top of the data channels. But for a RFC compliant SCTP implementation, this is how the spec is supposed to work. SCTP stream numbers are limited (uint16) so we do need to reuse the stream ids forcing us to use a synchronous close mechanism.
Was there some scenario that we've run into that hits this case? Is it expected to see a remote peer not ack the close? Or is this preventative? |
It is preventative This would have been fine but pion/sctp has a receive window calculation profile.pb.gz An alternative is to limit our receive window to 100kB. And let reserve 10MB memory for every webrtc connection(thanks @marten-seemann for the idea). This would slow down things but is much simpler. |
I'm missing where the second 100 comes from: |
This 404's for me |
WebRTC data channel close is a synchronous close procedure. We close our outgoing stream, in response the peer is expected to close its outgoing stream. If the peer doesn't close its side of the stream we will end up with a memory leak where the SCTP transport keeps reference to the stream. So we check the number of invalid data channel closures and when this goes over a threshold we close the connection.
For our custom purposes we can fork SCTP and implement a unilateral stream Reset which is feasible because we anyway have a state machine on top of the data channels. But for a RFC compliant SCTP implementation, this is how the spec is supposed to work. SCTP stream numbers are limited (uint16) so we do need to reuse the stream ids forcing us to use a synchronous close mechanism.