Extra websocket calls during .cat(cid)

[jsonsivar]

Hello, so basically I'm seeing websocket logs that are a little curious in my setup when doing a .cat call. So started looking into it because I'm hoping reducing those would improve performance of those calls if we can indeed reduce anything extraneous.

I currently have a js-ipfs node in the browser (version 0.41.2). It's connecting to a private network of go-ipfs nodes we have over websockets (using a custom protector and the swarm key for libp2p). I get the content back fine but between logging the request and logging my response I see the following:

Further down after getting the content, I also see these:

It appears though it's trying to dial on the localhost and private IPs of those nodes, even though I added them to swarm peers using the public IP. And those are extra calls because I get my content fine despite those errors.

[achingbrain]

This is probably because the remote nodes report loopback addresses in their list of multiaddrs and libp2p dials them all trying to make a connection.

@jacobheun could libp2p filter the addresses it's about to dial, removing say, anything with a loopback address that has the same port that the dialing node is listening on?

[jacobheun]

@jacobheun could libp2p filter the addresses it's about to dial, removing say, anything with a loopback address that has the same port that the dialing node is listening on?

Yes, but this won't solve this problem. In the browser you won't likely be listening on that loopback address, so you'll still get these errors.

There are some things I think we can do here though, while it's not strictly a problem, this could help us avoid the extraneous dials.

• Aside from local loopback addresses, websockets shouldn't really be able to dial to IP addresses. Browsers are going to restrict this to secure connections which require an SSL certificate which prohibits the use of IP addresses. So, restricting dials to dns and other named addresses could help with this to a degree.
• The other issue here is the loopback dial. As 127.0.0.1 is considered secure by most browsers, it's an allowable dial, and it could very well lead to a connected node if you're running one locally, however you're likely going to hit a lot of errors as many nodes will advertise the address, and only 1 will actually work. As part of the PeerStore work @vasco-santos is starting on we'll be looking at adding support for multiaddr denylists. If we dial the loopback address and nothing is there we can simply backoff on that address. If we end up succeeding but the crypto upgrade fails because it's a different peer, we might want to note that, and avoid dialing other peers on that loopback address.

[vasco-santos]

Closing this as this will be fixed on #3427 by updating libp2p-websockets