Closed DougAnderson444 closed 1 month ago
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.
I think this issue got a little worse since https://github.com/libp2p/js-libp2p/pull/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
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 directPeers
peer ids and multiaddrs up-front or do you have a way of doing this dynamically?
@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
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
— Reply to this email directly, view it on GitHubhttps://github.com/ChainSafe/js-libp2p-gossipsub/issues/448#issuecomment-1688373394, or unsubscribehttps://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.