2019-10-24 13:28:42 -07:00
|
|
|
use std::{
|
|
|
|
net::{SocketAddr, ToSocketAddrs},
|
2019-10-25 20:54:44 -07:00
|
|
|
string::String,
|
fix panic in seed subcommand (#401)
Co-authored-by: Jane Lusby <jane@zfnd.org>
Prior to this change, the seed subcommand would consistently encounter a panic in one of the background tasks, but would continue running after the panic. This is indicative of two bugs.
First, zebrad was not configured to treat panics as non recoverable and instead defaulted to the tokio defaults, which are to catch panics in tasks and return them via the join handle if available, or to print them if the join handle has been discarded. This is likely a poor fit for zebrad as an application, we do not need to maximize uptime or minimize the extent of an outage should one of our tasks / services start encountering panics. Ignoring a panic increases our risk of observing invalid state, causing all sorts of wild and bad bugs. To deal with this we've switched the default panic behavior from `unwind` to `abort`. This makes panics fail immediately and take down the entire application, regardless of where they occur, which is consistent with our treatment of misbehaving connections.
The second bug is the panic itself. This was triggered by a duplicate entry in the initial_peers set. To fix this we've switched the storage for the peers from a `Vec` to a `HashSet`, which has similar properties but guarantees uniqueness of its keys.
2020-05-27 17:40:12 -07:00
|
|
|
time::Duration, collections::HashSet,
|
2019-10-24 13:28:42 -07:00
|
|
|
};
|
2019-10-16 15:16:29 -07:00
|
|
|
|
2020-03-12 16:34:34 -07:00
|
|
|
use zebra_chain::Network;
|
2019-10-16 15:16:29 -07:00
|
|
|
|
2019-10-08 13:57:24 -07:00
|
|
|
/// Configuration for networking code.
|
|
|
|
#[derive(Clone, Debug, Deserialize, Serialize)]
|
|
|
|
#[serde(deny_unknown_fields)]
|
|
|
|
pub struct Config {
|
2019-10-16 18:29:45 -07:00
|
|
|
/// The address on which this node should listen for connections.
|
|
|
|
pub listen_addr: SocketAddr,
|
2019-10-24 13:28:42 -07:00
|
|
|
|
2019-10-16 15:16:29 -07:00
|
|
|
/// The network to connect to.
|
|
|
|
pub network: Network,
|
2019-10-24 13:28:42 -07:00
|
|
|
|
2019-10-08 13:57:24 -07:00
|
|
|
/// The user-agent to advertise.
|
|
|
|
pub user_agent: String,
|
2019-10-24 13:28:42 -07:00
|
|
|
|
|
|
|
/// A list of initial peers for the peerset when operating on
|
|
|
|
/// mainnet.
|
fix panic in seed subcommand (#401)
Co-authored-by: Jane Lusby <jane@zfnd.org>
Prior to this change, the seed subcommand would consistently encounter a panic in one of the background tasks, but would continue running after the panic. This is indicative of two bugs.
First, zebrad was not configured to treat panics as non recoverable and instead defaulted to the tokio defaults, which are to catch panics in tasks and return them via the join handle if available, or to print them if the join handle has been discarded. This is likely a poor fit for zebrad as an application, we do not need to maximize uptime or minimize the extent of an outage should one of our tasks / services start encountering panics. Ignoring a panic increases our risk of observing invalid state, causing all sorts of wild and bad bugs. To deal with this we've switched the default panic behavior from `unwind` to `abort`. This makes panics fail immediately and take down the entire application, regardless of where they occur, which is consistent with our treatment of misbehaving connections.
The second bug is the panic itself. This was triggered by a duplicate entry in the initial_peers set. To fix this we've switched the storage for the peers from a `Vec` to a `HashSet`, which has similar properties but guarantees uniqueness of its keys.
2020-05-27 17:40:12 -07:00
|
|
|
pub initial_mainnet_peers: HashSet<String>,
|
2019-10-24 13:28:42 -07:00
|
|
|
|
|
|
|
/// A list of initial peers for the peerset when operating on
|
|
|
|
/// testnet.
|
fix panic in seed subcommand (#401)
Co-authored-by: Jane Lusby <jane@zfnd.org>
Prior to this change, the seed subcommand would consistently encounter a panic in one of the background tasks, but would continue running after the panic. This is indicative of two bugs.
First, zebrad was not configured to treat panics as non recoverable and instead defaulted to the tokio defaults, which are to catch panics in tasks and return them via the join handle if available, or to print them if the join handle has been discarded. This is likely a poor fit for zebrad as an application, we do not need to maximize uptime or minimize the extent of an outage should one of our tasks / services start encountering panics. Ignoring a panic increases our risk of observing invalid state, causing all sorts of wild and bad bugs. To deal with this we've switched the default panic behavior from `unwind` to `abort`. This makes panics fail immediately and take down the entire application, regardless of where they occur, which is consistent with our treatment of misbehaving connections.
The second bug is the panic itself. This was triggered by a duplicate entry in the initial_peers set. To fix this we've switched the storage for the peers from a `Vec` to a `HashSet`, which has similar properties but guarantees uniqueness of its keys.
2020-05-27 17:40:12 -07:00
|
|
|
pub initial_testnet_peers: HashSet<String>,
|
2019-10-24 13:28:42 -07:00
|
|
|
|
2019-10-22 09:40:00 -07:00
|
|
|
/// The outgoing request buffer size for the peer set.
|
|
|
|
pub peerset_request_buffer_size: usize,
|
|
|
|
|
|
|
|
// Note: due to the way this is rendered by the toml
|
|
|
|
// serializer, the Duration fields should come last.
|
2019-10-16 15:16:29 -07:00
|
|
|
/// The default RTT estimate for peer responses, used in load-balancing.
|
|
|
|
pub ewma_default_rtt: Duration,
|
2019-10-24 13:28:42 -07:00
|
|
|
|
2019-10-16 15:16:29 -07:00
|
|
|
/// The decay time for the exponentially-weighted moving average response time.
|
|
|
|
pub ewma_decay_time: Duration,
|
2019-10-24 13:28:42 -07:00
|
|
|
|
2019-10-21 22:17:57 -07:00
|
|
|
/// The timeout for peer handshakes.
|
|
|
|
pub handshake_timeout: Duration,
|
2019-10-24 13:28:42 -07:00
|
|
|
|
2019-10-21 22:39:05 -07:00
|
|
|
/// How frequently we attempt to connect to a new peer.
|
|
|
|
pub new_peer_interval: Duration,
|
2020-02-09 20:34:53 -08:00
|
|
|
|
|
|
|
/// The initial target size for the peer set.
|
|
|
|
pub peerset_initial_target_size: usize,
|
2019-10-08 13:57:24 -07:00
|
|
|
}
|
|
|
|
|
2019-10-24 13:28:42 -07:00
|
|
|
impl Config {
|
fix panic in seed subcommand (#401)
Co-authored-by: Jane Lusby <jane@zfnd.org>
Prior to this change, the seed subcommand would consistently encounter a panic in one of the background tasks, but would continue running after the panic. This is indicative of two bugs.
First, zebrad was not configured to treat panics as non recoverable and instead defaulted to the tokio defaults, which are to catch panics in tasks and return them via the join handle if available, or to print them if the join handle has been discarded. This is likely a poor fit for zebrad as an application, we do not need to maximize uptime or minimize the extent of an outage should one of our tasks / services start encountering panics. Ignoring a panic increases our risk of observing invalid state, causing all sorts of wild and bad bugs. To deal with this we've switched the default panic behavior from `unwind` to `abort`. This makes panics fail immediately and take down the entire application, regardless of where they occur, which is consistent with our treatment of misbehaving connections.
The second bug is the panic itself. This was triggered by a duplicate entry in the initial_peers set. To fix this we've switched the storage for the peers from a `Vec` to a `HashSet`, which has similar properties but guarantees uniqueness of its keys.
2020-05-27 17:40:12 -07:00
|
|
|
fn parse_peers<S: ToSocketAddrs>(peers: HashSet<S>) -> HashSet<SocketAddr> {
|
2019-10-24 13:28:42 -07:00
|
|
|
peers
|
|
|
|
.iter()
|
|
|
|
.flat_map(|s| s.to_socket_addrs())
|
|
|
|
.flatten()
|
fix panic in seed subcommand (#401)
Co-authored-by: Jane Lusby <jane@zfnd.org>
Prior to this change, the seed subcommand would consistently encounter a panic in one of the background tasks, but would continue running after the panic. This is indicative of two bugs.
First, zebrad was not configured to treat panics as non recoverable and instead defaulted to the tokio defaults, which are to catch panics in tasks and return them via the join handle if available, or to print them if the join handle has been discarded. This is likely a poor fit for zebrad as an application, we do not need to maximize uptime or minimize the extent of an outage should one of our tasks / services start encountering panics. Ignoring a panic increases our risk of observing invalid state, causing all sorts of wild and bad bugs. To deal with this we've switched the default panic behavior from `unwind` to `abort`. This makes panics fail immediately and take down the entire application, regardless of where they occur, which is consistent with our treatment of misbehaving connections.
The second bug is the panic itself. This was triggered by a duplicate entry in the initial_peers set. To fix this we've switched the storage for the peers from a `Vec` to a `HashSet`, which has similar properties but guarantees uniqueness of its keys.
2020-05-27 17:40:12 -07:00
|
|
|
.collect()
|
2019-10-24 13:28:42 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
/// Get the initial seed peers based on the configured network.
|
fix panic in seed subcommand (#401)
Co-authored-by: Jane Lusby <jane@zfnd.org>
Prior to this change, the seed subcommand would consistently encounter a panic in one of the background tasks, but would continue running after the panic. This is indicative of two bugs.
First, zebrad was not configured to treat panics as non recoverable and instead defaulted to the tokio defaults, which are to catch panics in tasks and return them via the join handle if available, or to print them if the join handle has been discarded. This is likely a poor fit for zebrad as an application, we do not need to maximize uptime or minimize the extent of an outage should one of our tasks / services start encountering panics. Ignoring a panic increases our risk of observing invalid state, causing all sorts of wild and bad bugs. To deal with this we've switched the default panic behavior from `unwind` to `abort`. This makes panics fail immediately and take down the entire application, regardless of where they occur, which is consistent with our treatment of misbehaving connections.
The second bug is the panic itself. This was triggered by a duplicate entry in the initial_peers set. To fix this we've switched the storage for the peers from a `Vec` to a `HashSet`, which has similar properties but guarantees uniqueness of its keys.
2020-05-27 17:40:12 -07:00
|
|
|
pub fn initial_peers(&self) -> HashSet<SocketAddr> {
|
2019-10-24 13:28:42 -07:00
|
|
|
match self.network {
|
2019-10-25 20:54:44 -07:00
|
|
|
Network::Mainnet => Config::parse_peers(self.initial_mainnet_peers.clone()),
|
|
|
|
Network::Testnet => Config::parse_peers(self.initial_testnet_peers.clone()),
|
2019-10-24 13:28:42 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-10-08 13:57:24 -07:00
|
|
|
impl Default for Config {
|
|
|
|
fn default() -> Config {
|
2019-10-25 20:54:44 -07:00
|
|
|
let mainnet_peers = [
|
|
|
|
"dnsseed.z.cash:8233",
|
|
|
|
"dnsseed.str4d.xyz:8233",
|
|
|
|
"dnsseed.znodes.org:8233",
|
|
|
|
]
|
|
|
|
.iter()
|
|
|
|
.map(|&s| String::from(s))
|
|
|
|
.collect();
|
|
|
|
|
|
|
|
let testnet_peers = ["dnsseed.testnet.z.cash:18233"]
|
|
|
|
.iter()
|
|
|
|
.map(|&s| String::from(s))
|
|
|
|
.collect();
|
|
|
|
|
2019-10-08 13:57:24 -07:00
|
|
|
Config {
|
2019-11-13 15:37:48 -08:00
|
|
|
listen_addr: "127.0.0.1:8233"
|
2019-10-16 18:29:45 -07:00
|
|
|
.parse()
|
|
|
|
.expect("Hardcoded address should be parseable"),
|
2019-10-08 13:57:24 -07:00
|
|
|
user_agent: crate::constants::USER_AGENT.to_owned(),
|
2019-10-16 15:16:29 -07:00
|
|
|
network: Network::Mainnet,
|
2019-10-25 20:54:44 -07:00
|
|
|
initial_mainnet_peers: mainnet_peers,
|
|
|
|
initial_testnet_peers: testnet_peers,
|
2019-10-16 15:16:29 -07:00
|
|
|
ewma_default_rtt: Duration::from_secs(1),
|
|
|
|
ewma_decay_time: Duration::from_secs(60),
|
2020-02-19 10:03:06 -08:00
|
|
|
peerset_request_buffer_size: 10,
|
2019-10-21 22:17:57 -07:00
|
|
|
handshake_timeout: Duration::from_secs(4),
|
2020-02-18 13:41:00 -08:00
|
|
|
new_peer_interval: Duration::from_secs(60),
|
2020-02-09 20:34:53 -08:00
|
|
|
peerset_initial_target_size: 50,
|
2019-10-08 13:57:24 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|