Should a bootstrap node always respond to new nodes by simply accepting connections from the new node, exchanging peer IDs, and then disconnecting?
Imagine in a congested network, the bootstrap node itself might have the maximum number of connections. In our network, which consists of more than 150 nodes, this situation can occur frequently. I can easily reproduce it; just try to connect to a bootstrap node that I know is busy. All connections fail with the following error message:
Failed to dial: failed to dial 12D3Koo...: all dials failed\n * [/ip4/xx.xx.xx.xx/tcp/xx] failed to negotiate security protocol: read tcp4 192.168.0.xx:xx->xx.xx.xx.xx:xx: read: connection reset by peer"
The expected behavior is that I should somehow be able to obtain information about other peers from the bootstrap node. Otherwise, if all bootstrap nodes are busy, we end up with a closed network. It doesn’t make sense.
Do I understand correctly that your bootstrap node connection limit is < 150? If so, I would consider that very restrictive.
To give you an intuition, one of the IPFS bootstrap nodes is handling > 10_000 connections without significant resource usage. See A Rusty Bootstrapper | IPFS Blog & News
Most of the bootstrap nodes are maintained by the community, and I am sure they don’t want to maintain too many connections for their nodes. Is there any way to instruct the bootstrap node to accept a new connection, exchange peers, and then disconnect? In this way, they can keep the number of connections within a reasonable range.
Another question arises here:
IPFS bootstrap nodes are handling > 10,000 connections without significant resource usage.
It appears that the bootstrap node is not a full node but rather serves as a seeder in IPFS.
Do we need to have a separate implementation for the bootstrap node?