Closed draeder closed 2 years ago
@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 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.
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. 😁
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.