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

So many seemingly dangling peer connections, even if no peer is open #920

Open
neilyoung opened this issue May 14, 2023 · 7 comments
Open

Comments

@neilyoung
Copy link

Right after launching my app, which is at this moment just inserted the simple-peer script by HTML script tag (no peer open), I'm observing three of such entries in webrtc-internals, from which one disappears after a minute:

image

After having held a couple of session, which are all terminated with peer.destroy() the number of those entries has increased dramatically. Only the complete termination of the browser page removes these entries.

Is this just a laziness of the WebRTC internal process, which keeps this statistics open, or am I doing something wrong?

@DanyPell
Copy link

Interesting. Following...

@szcuipeng
Copy link

start debugging use chrome F12, add breakpoint in simplepeer.min.js 's lines:

this._pc = new (this._wrtc.RTCPeerConnection)(this.config)
this._pc.createDataChannel
this._pc.close
this._channel.close

confirm your souce code.

it's all ok in my program.

webrtc-internals will dynamic add/remove log instances of connections and channels.

@neilyoung
Copy link
Author

start debugging use chrome F12, add breakpoint in simplepeer.min.js 's lines:

this._pc = new (this._wrtc.RTCPeerConnection)(this.config) this._pc.createDataChannel this._pc.close this._channel.close

confirm your souce code.

it's all ok in my program.

webrtc-internals will dynamic add/remove log instances of connections and channels.

Not sure what you are talking about.

@neilyoung
Copy link
Author

In order to demonstrate the issue I have created a little video showing a screen recording of the little problem.

Maybe then we are all on the same page.

https://youtu.be/Ffi2Te4x750

@szcuipeng
Copy link

start debugging use chrome F12, add breakpoint in simplepeer.min.js 's lines:
this._pc = new (this._wrtc.RTCPeerConnection)(this.config) this._pc.createDataChannel this._pc.close this._channel.close
confirm your souce code.
it's all ok in my program.
webrtc-internals will dynamic add/remove log instances of connections and channels.

Not sure what you are talking about.

you should know how to debug javascript using chrome,
and know some knowledge about RTCPeerConnection/RTCDataDatachannel create and close.

@neilyoung
Copy link
Author

But you are able to watch the video and see, that the required close is called? Not? Then stop spamming here, clown

@TheSalarKhan
Copy link

TheSalarKhan commented May 31, 2024

@neilyoung I ran into the same exact problem. We had a website on which we had a paginated view of incoming video feeds, each time we switched a page all the streams on that page would get connected, and when we switched to the next page their peer object would get destroy() ed

But my chrome showed that the connections are still in 'connected' state, and they would never get removed until I hit refresh. This is also what you should look for, the connection state must say 'closed' and the browser will automatically remove the tab after a few minutes, as long as connections stay in 'connected' state the browser does not clean them up.

This was causing connectivity issues after the application ran for a couple of minutes. What ended up fixing this was a bug in our own logic.

But additionally while trying to fix this issue, I also changed the simple-peer library to close receivers. here's the code for that.

      try {
        // stop the tranceivers befre closing the connection
        this._pc.getTransceivers().forEach((transceiver) => {
          transceiver.stop();
        });
      } catch (err) {}

This block was added to the _destroy() method in index.js of simple-peer, just before:

      try {
        this._pc.close()
      } catch (err) {}

I was never able to instrument if having this and not having this made any difference. But you can give this a try if nothing works.

Also here is a really good article on how to properly close WebRTC connections: https://medium.com/@BeingOttoman/best-practices-for-closing-webrtc-peerconnections-b60616b1352

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

No branches or pull requests

4 participants