-
Notifications
You must be signed in to change notification settings - Fork 43
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
Comments
I am investigating this issue. GossipSub ignores any new connections to a peer if it already has a connection to that peer: 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. |
I think this issue got a little worse since libp2p/js-libp2p#1890 |
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). |
@justin0mcateer does that workaround involve knowing the |
@achingbrain I see that js-libp2p-gossipsub/src/index.ts Lines 589 to 592 in a2981f9
|
I agree. I was thinking about whether it would make sense to have the Identify service filter out 'non-transient' protocols on transient connections. To minimize superflous new stream requests.
Or maybe have GossipSub use 'dialProtocol' and filter connections based on whether the protocol is transient.
…________________________________
From: Marcel Gleeson ***@***.***>
Sent: Tuesday, August 22, 2023 10:05:25 AM
To: ChainSafe/js-libp2p-gossipsub ***@***.***>
Cc: justin0mcateer ***@***.***>; Mention ***@***.***>
Subject: Re: [ChainSafe/js-libp2p-gossipsub] feat: Support WebRTC Browser-to-Browser (Issue #448)
I see that runOnTransientConnection was added to handlers, but is it somehow relevant to topologies also?
It feels a little strange we would get onConnect with a connection that cannot be used with the protocol
https://github.com/ChainSafe/js-libp2p-gossipsub/blob/a2981f956d1f427fae9deb9c769f0baab0db5d26/src/index.ts#L589-L592
—
Reply to this email directly, view it on GitHub<#448 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAT4Q7OMG5VGD2SU7HCWQSTXWTDDLANCNFSM6AAAAAAZ6ZCFOY>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
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. |
closing as stale |
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-browserI've posted a repro here: https://github.com/DougAnderson444/libp2p-gossipsub-browser-to-browser
Steps are:
<== this is where gossipsub no longer works
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.
The text was updated successfully, but these errors were encountered: