-
Notifications
You must be signed in to change notification settings - Fork 38.8k
Added -whiteconnections=<n> option #5288
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
5b7faeb to
46a7467
Compare
|
Refactored, after conversation with gmaxwell on #bitcoin-dev. Default of whiteconnections is now 4 (if user isn't using whitelist feature at all, default is 0). Now acts to essentially reserve slots for exclusive use by whitelisted peers, against the given maxconnections limit, instead of increasing the maxconnections limit. Warning message given if whiteconnections value is so high that it will reserve all inbound slots, preventing any non-whitelisted peer from ever being able to connect. If user has not given a maxconnections value, then as a special case it adds the value of whiteconnections to the default for maxconnections. This is to avoid establishing a new default which would inadvertently reduce the number of incoming slots available for public (non-whitelisted) use. With the popularity of SPV wallets these days, incoming slots on full nodes are a rather precious resource. This whiteconnections feature is rather nice, especially for long-lived full nodes which reach their capacity of inbound connections. Now, you don't have to restart your node whenever you restart your miner, just to free up a slot so that your miner can get in! |
src/net.h
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add a comment here saying that this number is the reserved number of connections for white connections?
|
Tested that whitelisted connections are restricted to the whitelisted reserved count, and that the implicit + 4 without specified -maxconnections works as intended. |
46a7467 to
cae9ef9
Compare
|
Thanks, sipa, I added a comment showing some of the theory of operation behind nMaxConnections and nWhiteConnections. |
cae9ef9 to
48610c2
Compare
|
Rebased against the latest, no changes were necessary :) |
48610c2 to
910d9a8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you update this to use our doxygen comment format.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not easy to integrate a 'floating' comment like this into doxygen.
One way would be to group nMaxConnections and nWhiteConnections using @{ @} and add it as doxygen comment of the group.
|
Thanks, will update it. |
|
utAck. Is the pending update keeping the merge up? |
|
Yikes! Forgot about this. Will update ASAP. |
910d9a8 to
334299f
Compare
|
There, got it merged with latest master, and made the requested documentation cleanup changes! The Travis build still fails for the "no wallet" case, but the same thing happens right now for the latest upstream master.... |
334299f to
55b94ad
Compare
|
No code change, just rebased with latest master to pick up the Travis build fix. |
|
Thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if the user is using whitebind instead?
|
Good to point out! I will change it so that the "User is using whitelist feature" test matches on either |
e317c43 to
d7fcdd0
Compare
|
There, updated it as described (both |
src/init.cpp
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This inner if() seems a bit overcomplicated. I think this addition should either be always done (when whitelisting is used), or never at all. To me it doesn't hold up to the principle of least surprise to do this only to the default -maxconnections but not when the user provides one. Too much parameter interaction...
|
I thought about that as well, during initial implementation thoughts over IRC. Talked about it with a few others. Tried to avoid surprise and unintended behavior as best as possible, and this was a compromise. If the increase was done always, then it would be surprising to the user, because it would look like we were blatantly disobeying their given If user doesn't provide So, there's thinking that went into both sides of this decision. |
|
Trivial change to keep up with latest upstream. |
|
@Krellan There are several unaddressed comments? |
|
@sipa Which comments? Thought I addressed all concerns. |
|
Sorry, I missed that you answered in the PR rather than on the commits. |
|
The "increase the maxconnections if not specified, don't if it is" is fine, I think, but I wonder if the -whiteconnections default = 4 is needed. An existing user of one of the white* features won't expect a change in behaviour. I wonder if this isn't a concise way to specify it:
Seems easier to explain, and wouldn't violate the least surprise principle either? |
|
Good point. I will make it default to 0 instead of 4, so that the default behavior is to change nothing at all. |
|
There, as requested, changed the default from 4 to 0. Made no other code changes, just these constants. Also rebased to latest upstream. So, the behavior is now unchanged, by default. If the user wants the benefit of reserved slots for their whitelisted incoming connections, they will have to explicitly specify how many slots they want to reserve. |
src/init.cpp
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Slightly preferred for readability:
nMaxConnections = std::min(nFD - MIN_CORE_FILEDESCRIPTORS, nMaxConnections);|
utACK apart from nit (but needs rebase) |
40dc4a7 to
2edda2b
Compare
|
Rebased. |
This sets aside a number of connection slots for whitelisted peers, useful for ensuring your local users and miners can always get in, even if your limit on inbound connections has already been reached.
2edda2b to
e3cae52
Compare
|
Addressed the nit, good catch. Also found another place where the default was still 4, changed to 0. |
|
Untested ACK |
e3cae52 Added -whiteconnections=<n> option (Josh Lehan)
Zcash: Was "Added -whiteconnections=<n> option" from bitcoin/bitcoin#5288. The option was later removed in bitcoin/bitcoin#6374 which we merged in zcash#1258. This commit contains the difference between the two.
Zcash: Was "Added -whiteconnections=<n> option" from bitcoin/bitcoin#5288. The option was later removed in bitcoin/bitcoin#6374 which we merged in zcash#1258. This commit contains the difference between the two.
Zcash: Was "Added -whiteconnections=<n> option" from bitcoin/bitcoin#5288. The option was later removed in bitcoin/bitcoin#6374 which we merged in zcash#1258. This commit contains the difference between the two.
Bitcoin 0.12 misc P2P/Net PRs Cherry-picked from the following upstream PRs: - bitcoin/bitcoin#5288 - Only the reorg, option was removed in bitcoin/bitcoin#6374 which we merged in #1258 - bitcoin/bitcoin#6561 - bitcoin/bitcoin#6728 - bitcoin/bitcoin#6829 - bitcoin/bitcoin#6974 - bitcoin/bitcoin#7075 - bitcoin/bitcoin#7166 Part of #2074.
This allows whitelisted peers a higher connection limit,
so they can exceed the normal -maxconnections limit,
useful for ensuring your local users and miners can always get in.