-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Update samples to use RTCPeerConnectionState and show graceful teardown #839
Comments
Hey @chrbsg, thanks for filing this issue I love feedback from users. Currently this is working as designed (this isn't to say we can't make it better)
The remote can't send as many tracks as it wants though, it can only send as many tracks as the There might not be further action on this, but in that case we should revise documentation/communicate to the user better about this. thanks! |
Thanks for the quick reply. I didn't know that peerconnection.Close would unblock ReadRTP, but it does and it works. I didn't see peerconnection.Close being used in any of the pion examples so I wasn't calling it at all - is it necessary/expected to call this manually, or is the garbage collector eventually going to do the equivalent? I'm now calling it when ICE state changes to disconnected or failed. |
Correct we don't ever automatically tear down the PeerConnection. We could do that in the future though! That would be a breaking change so something we should do for If you are interested I would love a PR that updates the examples to does a |
TestNonFatalRead now has an timeout. Examples now use Mime types, instead of raw strings. Fixes #839
TestNonFatalRead now has an timeout. Examples now use Mime types, instead of raw strings. Fixes #839
TestNonFatalRead now has an timeout. Examples now use Mime types, instead of raw strings. Fixes #839
TestNonFatalRead now has an timeout. Examples now use Mime types, instead of raw strings. Fixes #839
TestNonFatalRead now has an timeout. Examples now use Mime types, instead of raw strings. Fixes #839
TestNonFatalRead now has an timeout. Examples now use Mime types, instead of raw strings. Fixes #839
TestNonFatalRead now has an timeout. Examples now use Mime types, instead of raw strings. Fixes #839
TestNonFatalRead now has an timeout. Examples now use Mime types, instead of raw strings. Fixes #839
TestNonFatalRead now has an timeout. Examples now use Mime types, instead of raw strings. Fixes pion#839
Your environment.
What did you do?
Have a standard audio channel packet handling loop which is basically:
Started streaming on audio channel with Chrome. Closed chrome tab. Server now appears to be blocked forever in track.ReadRTP, which is a resource leak of the goroutine.
What did you expect?
Some kind of timeout, or other way to not block? A potentially malicious actor could DDOS the server by opening multiple tracks and not sending any RTP packets. Must the remote side be trusted not to do this?
What happened?
Goroutine calling readRTP appears to block forever.
The text was updated successfully, but these errors were encountered: