libp2p
bug: webrtc connections fail after relayed connection is closed/expired
Users report that webrtc (brower-to-browser) connections fail after connectivity to the relay node is closed/reservation expires
Related: https://github.com/libp2p/js-libp2p-webrtc/issues/173
I am still seeing this.
In order to aid troubleshooting, how can I determine in JavaScript whether the browser is connected directly to the other browser? Is the other browser listed in the PeerStore or something along those lines?
In order to aid troubleshooting, how can I determine in JavaScript whether the browser is connected directly to the other browser? Is the other browser listed in the PeerStore or something along those lines?
So in the UI we display info about the transports for connections so that should indicate if a node is connected via webRTC.
This issue may be fixed in v2.0.10 @DougAnderson444 would you be interested in upgrading the webrtc dep and seeing this issue still exists?
Ok I will take a look at the multiaddrs there, but last I checked was still seeing the issue even with 2.0.10
I have been troubleshooting this a little bit, and have narrowed it down to a gossipsub issue. It has nothing to do with UV, IPv6 or WebRTC itself.
Once the relay is dropped, the gossipsub also seems to fail for some reason
I've raised an issue here https://github.com/ChainSafe/js-libp2p-gossipsub/issues/448
and a repro here https://github.com/DougAnderson444/libp2p-gossipsub-browser-to-browser
@DougAnderson444 Thanks for looking into this. Just to confirm, when you isolated to gossipsub, there was a webrtc browser to browser connection established right?
Yes correct. What happens is we still see the /echo/ messages passed back and forth without the relay, but no longer gossipsub passed back and forth. That's how we know it's a gossip issue and not WebRTC.
I wonder if gossipsub in javascript is looking for either Kad peers or perhaps Server style gossipsub? Which we wouldn't get with the browsers. I don't have a deep enough understanding of how the js-gossipbsub inner workings happen to figure that out
I think I may have mentioned this in a different thread, so apologies if I am posting twice. However, I've run into this same issue and I found that GossipSub is ignoring all 'subsequent' connections to a Peer. So, if you allow it to connect on CircuitRelay, it will never connect on WebRTC. See this logic: https://github.com/ChainSafe/js-libp2p-gossipsub/blob/master/src/index.ts#L745
There is a change that was just applied to libp2p master yesterday that prevents GossipSub (and most other protocols) from connecting over CircuitRelay, so this effectively works around the issue of GossipSub limiting/locking itself to the first connection per peer. https://github.com/libp2p/js-libp2p/commit/a1ec46b5f5606b7bdf3e5b085013fb88e26439f9
I believe I am also seeing some issues with GossipSub re-connecting after a disconnection, but I am still investigating that. It could be an issue with the CircuitRelayTransport and I haven't ruled that out.
