docs: use hyphens instead of snake case (#5802)

This commit is contained in:
Callum Waters
2020-12-17 08:59:58 +01:00
committed by GitHub
parent 6ef81c6074
commit ebff8a96a5
29 changed files with 206 additions and 207 deletions
@@ -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