46dbf027af
The changes are somewhat simple but should solve two issues: - When quickly changing between chains once and a second time back again, batchIds would collide and cause havoc. - If we got an out of range response from a peer, sync would remain in syncing but without advancing Changes: - remove the batch id. Identify each batch (inside a chain) by its starting epoch. Target epochs for downloading and processing now advance by EPOCHS_PER_BATCH - for the same reason, move the "to_be_downloaded_id" to be an epoch - remove a sneaky line that dropped an out of range batch without downloading it - bonus: put the chain_id in the log given to the chain. This is why explicitly logging the chain_id is removed
15 lines
360 B
Rust
15 lines
360 B
Rust
//! Syncing for lighthouse.
|
|
//!
|
|
//! Stores the various syncing methods for the beacon chain.
|
|
pub mod manager;
|
|
mod network_context;
|
|
mod peer_sync_info;
|
|
mod range_sync;
|
|
|
|
pub use manager::{BatchProcessResult, SyncMessage};
|
|
pub use peer_sync_info::PeerSyncInfo;
|
|
pub use range_sync::ChainId;
|
|
|
|
/// Type of id of rpc requests sent by sync
|
|
pub type RequestId = usize;
|