maxconnections for internet vs. maxconnections for local network

[btc123thatthere]

Hi there

I had maxconnections set to 4 (maxconnections=4) on my bitcoin server node, and noticed that my other machine on the local network running bitcoin core wasn't able to connect to to it.
So, I changed maxconnections to 40 (maxconnections=40), restarted the server node, and the other machine connected to it without a problem.

My question is: is their a way to limit maxconnections for internet connections vs limiting maxconnections for local network connections?

Thanks

[1715111312]

1715111312

[1715111312]

1715111312

[1715111312]

1715111312

[NotATether]

No there isn't, the maxconnections parameter limits inbound connections from clients on all networks. It doesn't treat any network interfaces specially.

The reason why your node failed to connect to your other node when you had maxconnections=4 is because Bitcoin Core has a predefined list of peers that it connects to first when you start Core. It scrapes their lists of peers, and lists of peers of those peers, and so on, and tries to connect to each node until it saturates the number of connections. So it finished 4 connections quickly before you were able to connect with your other node.

Core usually gets around 15 inbound connections very quickly after it's started, from my experience. So setting maxconnections=40 gave you more time for your other node to make a connection, but if you waited for too long, then there would also be no more slots for peers.

[odolvlobo]

Perhaps adding "connect=..." to the configuration files would ensure that at least one connects to the other.

[nc50lc]

Another option aside from the above which will isolate your connection to the specified peers, you can also use "addnode=".
Then limit the maxconnections to your liking.

https://github.com/bitcoin/bitcoin/blob/master/share/examples/bitcoin.conf#L26-L34

Quick Primer on addnode vs connect
Let's say for instance you use addnode=4.2.2.4 addnode will connect you to and tell you about the nodes connected to 4.2.2.4.  In addition it will tell the other nodes connected to it that you exist so they can connect to you. connect will not do the above when you 'connect' to it. It will *only* connect you to 4.2.2.4 and no one else.

[btc123thatthere]

I've already got connect= on the client's .conf file (otherwise it probably wouldn't connect to it anyway.)

If I put connect= on the server's .conf file, will it serve the IP address specified in connect=, or is connect= only used for specifying blockchain sources?

[nc50lc]

If I put connect= on the server's .conf file, will it serve the IP address specified in connect=, or is connect= only used for specifying blockchain sources?

It will only connect to the peers you've specified in "connect" (one line per peer), it won't connect to others.
If you need to connect to rest of the network, I'd suggest you to use addnode= on the server machine instead.

For more info: You can ready lines 49 and 53 in my previous post's link above, that's from bitcoin's repository.

[pooya87]

https://github.com/bitcoin/bitcoin/blob/master/share/examples/bitcoin.conf#L26-L34
and tell you about the nodes connected to 4.2.2.4.

How can this be possible?
Does this mean just the list of nodes that 4.2.2.4 sends back in response to getaddr? But these aren't nodes that are connected to 4.2.2.4, these are nodes that 4.2.2.4 knows about and were either connected to at some point or received their information in an addr message.
What else am I missing?

[nc50lc]

https://github.com/bitcoin/bitcoin/blob/master/share/examples/bitcoin.conf#L26-L34

and tell you about the nodes connected to 4.2.2.4.

How can this be possible?
Does this mean just the list of nodes that 4.2.2.4 sends back in response to getaddr? But these aren't nodes that are connected to 4.2.2.4, these are nodes that 4.2.2.4 knows about and were either connected to at some point or received their information in an addr message.

AFAIK, a node's response to getaddr will only contain active peers and won't include the inactive ones. [CMIIAW]

[NotATether]

https://github.com/bitcoin/bitcoin/blob/master/share/examples/bitcoin.conf#L26-L34

and tell you about the nodes connected to 4.2.2.4.

How can this be possible?
Does this mean just the list of nodes that 4.2.2.4 sends back in response to getaddr? But these aren't nodes that are connected to 4.2.2.4, these are nodes that 4.2.2.4 knows about and were either connected to at some point or received their information in an addr message.

AFAIK, a peer's response to getaddr will only contain active peers and won't include the inactive nodes if it's currently not connected to them. [CMIIAW]

No actually Core stores a list of known peers and it sends peers from that list as a response to getaddr.

This is where in the RPC call the address are gathered: https://github.com/bitcoin/bitcoin/blob/e20b488395c1c6c54b934714b436f72a3d4ecb1c/src/rpc/net.cpp#L831

NodeContext has a CConnman member that has a getAddresses() method which is what's called here. That calls the getAddr method in CAddrMan, the class responsible for tracking all the known nodes. https://github.com/bitcoin/bitcoin/blob/884bde510e2db59ee44604e2cccabb0bf1ef6ada/src/addrman.h

This agrees with what's written in the developer docs:

Once a program has connected to the network, its peers can begin to send it addr (address) messages with the IP addresses and port numbers of other peers on the network, providing a fully decentralized method of peer discovery. Bitcoin Core keeps a record of known peers in a persistent on-disk database which usually allows it to connect directly to those peers on subsequent startups without having to use DNS seeds.

[nc50lc]

-snip-

Thanks for the correction.
I'm aware of the persistent peer database, what had been unclear to me was what's being sent in response to getaddr.

[pooya87]

Unless there is something I am missing about the communication protocol, that must just be ambiguity in the explanation of what is being received.