Discovered too many peers?

[alanshaw]

I mean, this is 😎, but I don't think there's that many peers on the network. At this same time my go-ipfs node was settling on ~800 nodes.

[lidel]

Companion just counts the number of entries returned by ipfs.swarm.peers() :)
I think 3k peers will really happen if you disable connection manager in go-ipfs.

So my guess is that either:

• (A) ipfs.swarm.peers() returns invalid/duplicate entries or gets mangled somehow,
• (B) peer count is valid and enabling DHT in js-ipfs surfaced the need for enforcing connection manager limits by default just like go-ipfs does 🙃

Excerpt from release notes of go-ipfs v0.4.12:

The most critical change is the 'Connection Manager': it allows an ipfs node to maintain a limited set of connections to other peers in the network. By default (and with no config changes required by the user), ipfs nodes will now try to maintain between 600 and 900 open connections. These limits are still likely higher than needed, and future releases may lower the default recommendation, but for now we want to make changes gradually. The rationale for this selection of numbers is as follows:

• The DHT routing table for a large network may rise to around 400 peers
• Bitswap connections tend to be separate from the DHT
• PubSub connections also generally are another distinct set of peers (including js-ipfs nodes)

Because of this, we selected 600 as a LowWater number, and 900 as a HighWater number to avoid having to clear out connections too frequently. You can configure different numbers as you see fit via the Swarm.ConnMgr field in your ipfs config file. See here for more details.

[alanshaw]

Incredible knowledge @lidel as usual ❤️

[x5engine]

I only have 35 peers come on! I need more like you!!!

[vasco-santos]

How are you testing this @x5engine ?