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

feat: Support WebRTC Browser-to-Browser #448

Open
DougAnderson444 opened this issue Jul 5, 2023 · 7 comments
Open

feat: Support WebRTC Browser-to-Browser #448

DougAnderson444 opened this issue Jul 5, 2023 · 7 comments

Comments

@DougAnderson444
Copy link

I have tried to add Gossipsub to the echo example here: https://github.com/libp2p/js-libp2p/tree/master/packages/transport-webrtc/examples/browser-to-browser

I've posted a repro here: https://github.com/DougAnderson444/libp2p-gossipsub-browser-to-browser

Steps are:

  1. run a relay server
  2. connect first browser to the relay
  3. connect the 2nd browser to the 1t browser's circuit multiaddr
  4. connect the 1st browser to the 2nd browser's circuit relay addr
  5. Drop the relay server <== this is where gossipsub no longer works
  6. Try to exchange messages between browsers

If you follow the instructions in the example, echo works even when the relay server is dropped. But unfortunately, when the relay is gone so is the gossipsub functionality.

I don't know enough about the inner workings of gossipsub to troubelshoot this, so I could really use some assistance solving this.

@justin0mcateer
Copy link

I am investigating this issue. GossipSub ignores any new connections to a peer if it already has a connection to that peer:
https://github.com/ChainSafe/js-libp2p-gossipsub/blob/master/src/index.ts#L745

I am going to take a stab at making the stream management more robust by using the AddressSorter mechanism to determine which connection is more 'preferred'.

One would think that once the Relay connection dies, that GossipSub would attempt to re-connect to the peer via the remaining (WebRTC) connection. Not sure why that doesn't happen I will investigate that further today.

@Marcel-G
Copy link

Marcel-G commented Aug 19, 2023

I think this issue got a little worse since libp2p/js-libp2p#1890
Gossipsub will now not send over relayed (transient) connections and it does not use the upgraded webrtc connection as mentioned in this issue. Effectively it doesn't send at all

@justin0mcateer
Copy link

I have managed to get it working, but it wasn't easy. The biggest problem is that GossipSub tries to connect in peer discovery, but it gets aborted because it is a transient connection. The default connection logic is that GossipSub basically never tries again.

One work around to this is to enable 'directPeers' in the GossipSub config, this will cause GossipSub to attempt to connect to the listed peers every heartbeat (1 second by default).

@Marcel-G
Copy link

@justin0mcateer does that workaround involve knowing the directPeers peer ids and multiaddrs up-front or do you have a way of doing this dynamically?

@Marcel-G
Copy link

Marcel-G commented Aug 22, 2023

@achingbrain I see that runOnTransientConnection was added to handlers, but is it somehow relevant for topologies also?
It feels a little strange we would get onConnect with a connection that cannot be used with the protocol

const topology = {
onConnect: this.onPeerConnected.bind(this),
onDisconnect: this.onPeerDisconnected.bind(this)
}

@justin0mcateer
Copy link

justin0mcateer commented Aug 22, 2023 via email

@achingbrain
Copy link
Collaborator

achingbrain commented Nov 3, 2023

Please can you try with libp2p@0.46.17 (just released) - it has the fixes for protocol handlers & transient streams incorporated - by default gossipsub will no longer run over a transient stream, only direct connections.

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