Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
discovery: introduce gossiper syncManager subsystem #2740
Gossip Sync Manager
In this PR, we introduce a new subsystem for the gossiper: the SyncManager. This subsystem is a major overhaul on the way the daemon performs the graph query sync state machine with peers.
Along with this subsystem, we also introduce the concept of an active syncer. An active syncer is simply a GossipSyncer currently operating under an ActiveSync sync type. Before this commit, all GossipSyncer's would act as active syncers, which means that we were receiving new graph updates from all of them. This isn't necessary, as it greatly increases bandwidth usage as the network grows. The SyncManager changes this by requiring a specific number of active syncers. Once we reach this specified number, any future peers will have a GossipSyncer with a PassiveSync sync type.
It is responsible for three main things:
Gossip Syncer Sync Transitions
In order for it to achieve its first two responsibilities, GossipSyncer sync transitions were necessary.
We introduce two different sync types:
It's possible to transition from any of these types to any other. Certain transitions require some additional wire messages to be sent, like in the case of an ActiveSync GossipSyncer transitioning to a PassiveSync type.
Gossip Syncer Synced Signal
In order for the SyncManager to achieve its third responsibility, we introduce another feature to the GossipSyncer in which it can deliver a signal to an external caller once it reaches its terminal chansSynced state. This is necessary for our new round-robin sync mechanism, as we need to wait for one active syncer to finish syncing before moving on to the next.
Since the SyncManager now relies on being told how many active syncers it should strive to maintain, a new CLI flag has been added to allow users to manually tune this to their preference:
Roasbeef left a comment
Excellent work! I've completed a first pass, but still need to complete my mental model w.r.t the various state transitions, and if some of the current imposed roles match up to reality and my initial mental mode of this change. Starting to run this on on of my testnet nodes now with logging cranked up so I can get a feel for how it fares in the wild.
If we expose some more status information from the sync manager, then we can have the server be able to query for the gossip syncer status of each peer. With this information, we can add some annotations to
cfromknecht left a comment
Latest batch of changes looking really nice. Have been running this on my node a bit, here's some bandwidth stats after letting this run for a few hours:
LND-LND connections have a very obvious bandwidth footprint, the
Some additional small comments are left inline
I ran some manual light client tests and noticed historical syncs can take some time to completely finish (10-15 mins), so I settled with 20 mins.