mirror of
https://github.com/tendermint/tendermint.git
synced 2026-09-18 22:14:35 +00:00
docs: use hyphens instead of snake case (#5802)
This commit is contained in:
@@ -2,11 +2,11 @@
|
||||
|
||||
## Changelog
|
||||
* 22-10-2019: Initial draft
|
||||
* 05-11-2019: Modify `maximum_dial_period` to `persistent_peers_max_dial_period`
|
||||
* 05-11-2019: Modify `maximum-dial-period` to `persistent-peers-max-dial-period`
|
||||
|
||||
## Context
|
||||
|
||||
When `max_num_inbound_peers` or `max_num_outbound_peers` of a node is reached, the node cannot spare more slots to any peer
|
||||
When `max-num-inbound-peers` or `max-num-outbound-peers` of a node is reached, the node cannot spare more slots to any peer
|
||||
by inbound or outbound. Therefore, after a certain period of disconnection, any important peering can be lost indefinitely
|
||||
because all slots are consumed by other peers, and the node stops trying to dial the peer anymore.
|
||||
|
||||
@@ -15,25 +15,25 @@ This is happening because of two reasons, exponential backoff and absence of unc
|
||||
|
||||
## Decision
|
||||
|
||||
We would like to suggest solving this problem by introducing two parameters in `config.toml`, `unconditional_peer_ids` and
|
||||
`persistent_peers_max_dial_period`.
|
||||
We would like to suggest solving this problem by introducing two parameters in `config.toml`, `unconditional-peer-ids` and
|
||||
`persistent-peers-max-dial-period`.
|
||||
|
||||
1) `unconditional_peer_ids`
|
||||
1) `unconditional-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.
|
||||
`max-num-inbound-peers` or `max-num-outbound-peers` of user's node reached or not.
|
||||
|
||||
2) `persistent_peers_max_dial_period`
|
||||
2) `persistent-peers-max-dial-period`
|
||||
|
||||
Terms between each dial to each persistent peer will not exceed `persistent_peers_max_dial_period` during exponential backoff.
|
||||
Therefore, `dial_period` = min(`persistent_peers_max_dial_period`, `exponential_backoff_dial_period`)
|
||||
Terms between each dial to each persistent peer will not exceed `persistent-peers-max-dial-period` during exponential backoff.
|
||||
Therefore, `dial-period` = min(`persistent-peers-max-dial-period`, `exponential-backoff-dial-period`)
|
||||
|
||||
Alternative approach
|
||||
|
||||
Persistent_peers is only for outbound, therefore it is not enough to cover the full utility of `unconditional_peer_ids`.
|
||||
@creamers158(https://github.com/Creamers158) suggested putting id-only items into persistent_peers to be handled as
|
||||
`unconditional_peer_ids`, but it needs very complicated struct exception for different structure of items in persistent_peers.
|
||||
Therefore we decided to have `unconditional_peer_ids` to independently cover this use-case.
|
||||
Persistent-peers is only for outbound, therefore it is not enough to cover the full utility of `unconditional-peer-ids`.
|
||||
@creamers158(https://github.com/Creamers158) suggested putting id-only items into persistent-peers to be handled as
|
||||
`unconditional-peer-ids`, but it needs very complicated struct exception for different structure of items in persistent-peers.
|
||||
Therefore we decided to have `unconditional-peer-ids` to independently cover this use-case.
|
||||
|
||||
## Status
|
||||
|
||||
@@ -44,8 +44,8 @@ Proposed
|
||||
### Positive
|
||||
|
||||
A node operator can configure two new parameters in `config.toml` so that he/she can assure that tendermint will allow connections
|
||||
from/to peers in `unconditional_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.
|
||||
from/to peers in `unconditional-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
|
||||
|
||||
|
||||
Reference in New Issue
Block a user