-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Create adr-050-improved-trusted-peering.md #4072
Conversation
Modify `maximum_dial_period` to `persistent_peers_maximum_dial_period`
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.
LGTM
1) `wildcard_peer_ids` | ||
|
||
A node operator inputs list of ids of peers which are allowed to be connected by both inbound or outbound regardless of | ||
`max_num_inbound_peers` or `max_num_outbound_peers` of user's node reached or not. |
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.
Are there limits on the number of trusted/wildcard peers a node can specify? And does adding a trusted/wildcard peer effectively increase the maximum number of peers by 1 (e.g. is the maximum number of inbound peers specified by max_num_inbound_peers
+ n, where n is the number of wildcard peers)?
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.
-
There is no limits for wildcard peers. I think it is OK without the limit. Do we need it?
-
The peers in wildcard_peer_ids is not objective to
max_num_inbound_peers
. So we don't addn
. The state machine just does not checkmax_num_inbound_peers
criteria for any wildcard_peer_ids. Also the state machine just does not count any peer in wildcard_peer_ids to comparemax_num_inbound_peers
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.
NOTE: we will have a problem with "wildcard_peer_ids is not objective to max_num_inbound_peers" because there's usually a limited number of connections per OS process (ulimit
)
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 sounds like we should have some kind of limit here.
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.
I think the OS limit is much far larger than what we need to connect practically. 200 peers are what we practically think maximum, and it is nowhere close to default limit on OS.
Also users can aware that maxpeernum + numofunconditionalpeers = actual possible number of peers. So it is not a unpredictable risk to manage.
For such reason, I think it can be stated in ADR, but we dont think it is needed to be implemented in this spec.
from/to peers in `wildcard_peer_ids`. Also he/she can assure that every persistent peer will be dialed at least once in every | ||
`persistent_peers_max_dial_period` term. It achieves more stable and persistent peering for trusted peers. | ||
|
||
### Negative |
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.
Are there any possible performance downsides?
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.
Additional calculation what we need for the new features
- checking whether given peer is listed in
wildcard_peer_ids
- for
persistent_peers
, the state machine will dial indefinitely with given period
We think both calculation is not a significant factor for performance downsides.
Co-Authored-By: Tess Rinearson <tess.rinearson@gmail.com>
Co-Authored-By: Tess Rinearson <tess.rinearson@gmail.com>
Co-Authored-By: Tess Rinearson <tess.rinearson@gmail.com>
Co-Authored-By: Tess Rinearson <tess.rinearson@gmail.com>
wildcard -> unconditional
I see that you checked the "referenced an issue" box, but I don't see the issue linked. Can you include it in the PR description and the ADR, please? |
I didn't realize I missed that. Thank you. //edit Do you want me to also locate the link in another location? |
I think it would be helpful to put it in the PR description so that the Github UI links them together. Thanks! |
Done. |
Codecov Report
@@ Coverage Diff @@
## master #4072 +/- ##
==========================================
+ Coverage 66.57% 66.68% +0.11%
==========================================
Files 246 246
Lines 21156 21148 -8
==========================================
+ Hits 14085 14103 +18
+ Misses 6008 5985 -23
+ Partials 1063 1060 -3
|
Refs #4053