Skip to content
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

Merged
merged 12 commits into from
Nov 20, 2019
Merged

Conversation

Hyung-bharvest
Copy link
Contributor

@Hyung-bharvest Hyung-bharvest commented Oct 22, 2019

Refs #4053

  • Referenced an issue explaining the need for the change
  • Updated all relevant documentation in docs
  • Updated all code comments where relevant
  • Wrote tests
  • Updated CHANGELOG_PENDING.md

Modify `maximum_dial_period` to `persistent_peers_maximum_dial_period`
@Hyung-bharvest
Copy link
Contributor Author

Hyung-bharvest commented Nov 11, 2019

@melekes @tessr @ebuchman
Is the spec discussed enough for us to PullRequest our implementation?
Waiting for confirmation.

Copy link
Contributor

@melekes melekes left a 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.
Copy link
Contributor

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)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. There is no limits for wildcard peers. I think it is OK without the limit. Do we need it?

  2. The peers in wildcard_peer_ids is not objective to max_num_inbound_peers. So we don't add n. The state machine just does not check max_num_inbound_peers criteria for any wildcard_peer_ids. Also the state machine just does not count any peer in wildcard_peer_ids to compare max_num_inbound_peers

Copy link
Contributor

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)

Copy link
Contributor

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.

Copy link
Contributor Author

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
Copy link
Contributor

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?

Copy link
Contributor Author

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

  1. checking whether given peer is listed in wildcard_peer_ids
  2. for persistent_peers, the state machine will dial indefinitely with given period

We think both calculation is not a significant factor for performance downsides.

Hyung-bharvest and others added 5 commits November 14, 2019 16:45
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
@tessr
Copy link
Contributor

tessr commented Nov 15, 2019

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?

@Hyung-bharvest
Copy link
Contributor Author

Hyung-bharvest commented Nov 15, 2019

I didn't realize I missed that. Thank you.

//edit
Rechecked it and the link is located at the bottom of the ADR.(reference)

Do you want me to also locate the link in another location?

@tessr
Copy link
Contributor

tessr commented Nov 19, 2019

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!

@melekes
Copy link
Contributor

melekes commented Nov 20, 2019

I think it would be helpful to put it in the PR description so that the Github UI links them together. Thanks!

Done.

@codecov-io
Copy link

Codecov Report

Merging #4072 into master will increase coverage by 0.11%.
The diff coverage is n/a.

@@            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
Impacted Files Coverage Δ
libs/events/events.go 93.2% <0%> (-4.86%) ⬇️
consensus/state.go 77.84% <0%> (+0.1%) ⬆️
tools/tm-bench/transacter.go 8.96% <0%> (+0.46%) ⬆️
p2p/pex/addrbook.go 68.34% <0%> (+0.5%) ⬆️
consensus/reactor.go 78.49% <0%> (+1.61%) ⬆️
blockchain/v2/reactor.go 54.38% <0%> (+3.5%) ⬆️
types/tx.go 91.3% <0%> (+4.34%) ⬆️
p2p/pex/errors.go 25% <0%> (+12.5%) ⬆️

@melekes melekes merged commit acac525 into tendermint:master Nov 20, 2019
@dongsam dongsam mentioned this pull request Nov 21, 2019
5 tasks
melekes pushed a commit that referenced this pull request Dec 4, 2019
…od` (#4176)

implementation spec of Improved Trusted Peering ADR-050 by B-Harvest

- add unconditional_peer_ids and persistent_peers_max_dial_period to config
- add unconditionalPeerIDs map to Switch struct

default config value of persistent_peers_max_dial_period is 0s(disabled)

Refs #4072, #4053
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants