Gossipsub and transient connections in Libp2p v0.46.6

[haydenyoung]

After updating to latest Helia v2.0.3. which includes Libp2p v0.46.6, I have started to receive transient connection errors from gossipsub:

CodeError: Cannot open protocol stream on transient connection

My understanding is that support for transient connections needs to be explicitly set (I believe the flag is something like useTransientConnections: true). However, it seems that this configuration is not passed to gossipsub and so transient connections are not supported at all by gossipsub?

Is there any configuration or workaround for gossipsub and transient connections in Libp2p 0.46.6?

I found the following two posts which appear to discuss the issue; ChainSafe/js-libp2p-gossipsub#448, #2049.

[achingbrain]

I think you may be running into #2036 which was fixed by #2049

It'll be in the #2185 release, likely later today.

Before then you can also install libp2p@next which will have the fixes but has no breaking changes - it should solve the problem, please try it out if you have time.

[achingbrain]

[email protected] has been released - it should resolve this issue, please try again.

[haydenyoung]

Thanks for the update. The transient error has been resolved but unfortunately the peers will now no longer communicate with each other.

Please see my simple example at https://github.com/haydenyoung/helia-browser.

To deploy:

• Configure a circuit relay by editing index.js @ L47. I am using the OrbitDB's test relay but any correctly configured relay will do. If using OrbitDB relay, you will not need to edit index.js as the address will be correctly configured:

git clone https://github.com/orbitdb/orbitdb.git
cd orbitdb
npm i
npm run webrtc 

Clone repo:

git clone https://github.com/haydenyoung/helia-browser.git

• Install deps:

npm i

• Build with webpack:

./node_modules/.bin/webpack

Run with a basic web server:

python3 -m http.server 8082

Checking the browser console, you will see the peers successfully connect to the relay and then to one another but there is no communication between the two peers.

The only error I can see that could point to a problem is:

libp2p:circuit-relay:discover-relays:error failed when finding relays on the network +0ms CodeError: No content routers available
    at CompoundContentRouting.findProviders (index.js:38:19)
    at findProviders.next (<anonymous>)
    at RelayDiscovery.discover (discovery.js:87:30) 

Other than that it appears both peers successfully connect (as seen by the 'connect' event listener added to both peers.

To recap:

• When helia-browser is built with helia@1.* [email protected] the connection is successful and both communication works as expected (blockstore.get, pubsub),

• With [email protected] [email protected], gossipsub fails with transient connection,

• With [email protected] [email protected], peers connect but seem unable to communicate with one another (blockstore.get never fetches remote block, pubsub does not show other peer's messages).

[achingbrain]

That said it doesn't appear to transfer the block from helia1 to helia2 in Chrome. PubSub works bit bitswap doesn't.

Both work in Firefox and node if you run the index.js file with the fix from the PR in my previous comment.

Let me look into it a bit more.

[haydenyoung]

Thanks for looking into it and the patch you provided helped.

As an aside, the reservationClearInterval we had set in the relay config (=500) was causing a NO_RESERVATIONS error in FF. Removing this and both FF and Node.js are working for me also. However, this would suggest peer1's reservation is stale almost immediately after connecting to the relay? Is this because once the relay discovers peer1's addresses, it is finished with peer1?

Please feel free to reach out if you need any more information from me.

[achingbrain]

I've found a few issues with the WebRTC transport and how it interacts with the rest of libp2p. These have been fixed & shipped as of a couple of hours ago so the demo works a lot better now.

There's one final issue in Chrome I'm seeing where helia2 dials helia1's webrtc address over p2p-circuit. It makes the relay connection, does the WebRTC handshake, closes the relay connection, opens the WebRTC connection, opens a stream to run identify and... nothing. helia1 never gets the notification of a new datachannel having been opened.

Consequently bitswap is never notified of the direct connection to helia1 and helia2.get never resolves.

I'm currently looking into this to see if it's a browser bug or a problem in the webrtc transport, or if we need to be smarter about stream opening.

This only affects Chrome, Firefox seems a lot more reliable.

[achingbrain]

Ok, I think I found the source of the bug - not browser related after all..

Please reinstall your deps an/or otherwise ensure you have @libp2p/[email protected] and it should be a lot more reliable.

[haydenyoung]

Thanks for the update.

I have upgraded dependencies in, and tested, the helia-browser script from earlier in this post in the following browsers:

Firefox 118 - works
Brave 1.160 - works
Chromium 119 - does not work, but worked with earlier versions of libp2p.

Node.js also works.

Chromium errors with:

dial-queue.js:221 Uncaught (in promise) CodeError: The task was aborted.
    at eval (dial-queue.js:221:31)
    at async DialQueue.dial (dial-queue.js:228:28)
    at async DefaultConnectionManager.openConnection (index.js:332:28)
    at async eval (index.js:82:1)

Turning on libp2p DEBUG I see some dialling errors:

libp2p:connection:error error encountered during graceful close of connection to /ip4/127.0.0.1/tcp/12312/ws/p2p/12D3KooWMSwwjDuY9bsuLUfy5L3mM6M38hLRSMVwJvLLAY5na8w4/p2p-circuit/p2p/12D3KooWDaBnz46Pv4hGVbxZRyRnGZd8MWrMPXXPA7hedqHy6AKK +0ms Error: The operation was aborted
    at raceSignal (index.js:26:31)
    at eval (stream.js:218:76)
common.js:113 libp2p:connection:error aborting connection to /ip4/127.0.0.1/tcp/12312/ws/p2p/12D3KooWMSwwjDuY9bsuLUfy5L3mM6M38hLRSMVwJvLLAY5na8w4/p2p-circuit/p2p/12D3KooWDaBnz46Pv4hGVbxZRyRnGZd8MWrMPXXPA7hedqHy6AKK due to error +1ms Error: The operation was aborted
    at raceSignal (index.js:26:31)
    at eval (stream.js:218:76)
common.js:113 libp2p:connection:error all streams aborted +1ms 0
common.js:113 libp2p:connection-manager:dial-queue:error error during dial of /ip4/127.0.0.1/tcp/12312/ws/p2p/12D3KooWMSwwjDuY9bsuLUfy5L3mM6M38hLRSMVwJvLLAY5na8w4/p2p-circuit/webrtc/p2p/12D3KooWDaBnz46Pv4hGVbxZRyRnGZd8MWrMPXXPA7hedqHy6AKK +5ms Error: Aborted while reading ICE candidates
    at readCandidatesUntilConnected (util.js:83:15)
    at async initiateConnection (initiate-connection.js:114:13)
    at async WebRTCTransport.dial (transport.js:101:35)
    at async DefaultTransportManager.dial (transport-manager.js:91:20)
    at async queue.add (dial-queue.js:407:42)

but not sure if they are related.

However, perhaps it is the version of Chromium I'm running and in other versions of Chrome it runs fine?

[achingbrain]

Is this running the relay script in your example or something else?

It all works for me on Chrome 119, Firefox 119 and node 20.8.0.

% npm ls libp2p
[email protected] /Users/alex/Documents/Workspaces/haydenyoung/helia-browser
├─┬ [email protected]
│ └── [email protected] deduped
└── [email protected]

% npm ls @libp2p/webrtc
[email protected] /Users/alex/Documents/Workspaces/haydenyoung/helia-browser
└─┬ [email protected]
  └── @libp2p/[email protected]

[haydenyoung]

I ran webrtc diagnostics (chrome://webrtc-internals/) and was seeing iceCandidateFailed errors. Changing the setting "WebRTC IP policy" in chrome://flags seems to have fixed the problem. I'm guessing something about localhost not being an allowed IP address?

As a side note, it seems FF does not resolve the localhost domain which causes ice candidate errors also. This is resolved using the local ip address explicitly, I.e. 127.0.0.1. I'm wondering if either localhost is not allowed because of FF's webrtc configuration or whether it is resolving to a different ip? I'd have to explore further.

Anyway, current versions of libp2p and helia seem to be working as expected.

Thanks again for looking into this. I'm thinking to mark #2179 (reply in thread) as the answer?

[christroutner]

I've been following this discussion as I'm experiencing similar issues in a node.js-only environment. I captured the errors I've been seeing here.

I tried to update libp2p v0.46.19 and the app crashed with the error I captured in this Issue.