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

Close event takes 15 seconds to emit #22

Closed
draeder opened this issue Jan 27, 2022 · 3 comments
Closed

Close event takes 15 seconds to emit #22

draeder opened this issue Jan 27, 2022 · 3 comments
Labels
question Further information is requested

Comments

@draeder
Copy link

draeder commented Jan 27, 2022

I have been trying to track down what causes the close event to emit, because I would like to reduce the time it takes to emit.

I have poured over all of the dependencies I can, all the way down to simple-peer, but I can't figure out where the 15 second timeout is configured.

The reason I would like to be able to control this is because the close event appears to trigger a new MMST lookup. Let's say I have Peer A, with connections to Peer B and Peer C. When Peer A disconnects, Peer B and Peer C won't know about each other until after they get the 'close' event for Peer A.

If I can shorten the timeout, the unconnected peers can find each other sooner.

@RangerMauve
Copy link
Owner

@draeder Sadly I'm not sure where 15 seconds could be coming from either. 🤔

Did you confirm that the 15 seconds is the time until onClose gets invoked in the RTCDataChannel?

Usually I run ping/pong messages on connections to detect when they've timed out, and send a clear close packet over before cleaning up the connection on one side in order to have them react sooner.

@RangerMauve RangerMauve added the question Further information is requested label Feb 15, 2022
@draeder
Copy link
Author

draeder commented Feb 15, 2022

@RangerMauve Through the process of elimination, I was able to determine it is simple-peer, since I've experimented with multiple libraries that have it as a dependency. I still don't fully understand what in simple-peer leads to this event -- perhaps it's actually wrtc itself.

I did end up going with a ping/pong ack, but found that simple-peer has some other issues that are leading to webrtc instability. For example, it doesn't attempt RTCPeerConnection.restartIce() upon ICE failures (which don't necessarily indicate the connection is lost). Yet destroys the connections on ICE failure anyway. :(

So, I've been exploring building my own WebRTC peer library that works in both node and the browser. If I'm successful, I'll come back here and let you know about it.

@RangerMauve
Copy link
Owner

Youch. I think I've also had some issues with the default XHR-based signalling server APIs that simple-peer was using since they were adding a bunch of latency in my experience.

Down to talk about alternatives to simple-peer. Currently most of the WebRTC stuff this library is using is inside discovery-swarm-webrtc so it might be good to continue discussions there if you find/make a better alternative. 😁

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants