The main addition of the PR is the connection scheduler module. I've chosen to begin with a very simple implementation. The flow is as follows:
Combine the list of peers to be dialed from replication.toml and --connect (CLI) into a single vector
Spawn the connection scheduler actor, passing in the list of peers to be dialed
Place all peers to be dialed into an "eager" queue
Pull one peer from the eager queue every 5 seconds and attempt a connection
If the connection fails, push the peer to the "lazy" queue
If the connection succeeds, push the peer back to the eager queue
Pull one peer from the lazy queue every 60 seconds and attempt a connection
I've introduced the ConnectionDatastruct in the connection manager which allows the passing of the connection ID, remote peer address and remote peer public key for each connection. The connection data is passed along with each ConnectionEvent emitted during the connection and replication lifecycle.
That's really all there is to it. The connection scheduler listens for connection events to determine the post-connection placement of each peer.
I'll aim to further refine the separation of concerns in the next PR (for example, moving modifications of the CONNECTED_PEERS vector out of the secret handshake and replication modules and into the connection manager).
Addresses https://github.com/mycognosist/solar/issues/63
The main addition of the PR is the connection scheduler module. I've chosen to begin with a very simple implementation. The flow is as follows:
replication.toml
and--connect
(CLI) into a single vectorI've introduced the
ConnectionData
struct
in the connection manager which allows the passing of the connection ID, remote peer address and remote peer public key for each connection. The connection data is passed along with eachConnectionEvent
emitted during the connection and replication lifecycle.That's really all there is to it. The connection scheduler listens for connection events to determine the post-connection placement of each peer.
I'll aim to further refine the separation of concerns in the next PR (for example, moving modifications of the
CONNECTED_PEERS
vector out of the secret handshake and replication modules and into the connection manager).This is fun!