search

libp2p / universal-connectivity

Realtime decentralised chat with libp2p showing ubiquitous peer-to-peer connectivity between multiple programming languages (Go, Rust, TypeScript) and runtimes (Web, native binary) using QUIC, WebRTC and WebTransport
https://universal-connectivity.vercel.app
Other
83 stars 32 forks source link

bug: webrtc connections fail after relayed connection is closed/expired #74

Open p-shahi opened 1 year ago

p-shahi commented 1 year ago

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

DougAnderson444 commented 1 year ago

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?

maschad commented 1 year ago

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?

DougAnderson444 commented 1 year ago

Ok I will take a look at the multiaddrs there, but last I checked was still seeing the issue even with 2.0.10

DougAnderson444 commented 1 year ago

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

p-shahi commented 1 year ago

@DougAnderson444 Thanks for looking into this. Just to confirm, when you isolated to gossipsub, there was a webrtc browser to browser connection established right?

DougAnderson444 commented 1 year ago

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

justin0mcateer commented 1 year ago

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.