-
Notifications
You must be signed in to change notification settings - Fork 84
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(utxo): prioritize electrum connections #1966
base: dev
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for your effort!
The PR seems to be in its early stages right now. This is not an actual review, I just did a quick review to point out some areas that should not be forgotten.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this is still in progress, I left some comments that can help you improve the code.
I will do a more thorough review when this is ready for review!
Please also merge with latest dev and start adding doc comments.
mm2src/coins/utxo/rpc_clients.rs
Outdated
pub struct ElectrumClientImpl { | ||
weak_self: Mutex<Option<Weak<ElectrumClientImpl>>>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a very bad design choice, the struct should never reference it self to not create any unstable behavior.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why not just introduce a new struct ? e.g
struct ElectrumClientImplWeak(Mutex<Option<Weak<ElectrumClientImpl>>>)
mm2src/coins/utxo/rpc_clients.rs
Outdated
struct ConnMng(Arc<ConnMngImpl>); | ||
|
||
impl ConnMng { | ||
async fn suspend_server(self, address: String) -> Result<(), String> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this is a new implementation, please start using specific error types and MmError
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mm2src/coins/utxo/rpc_clients.rs
Outdated
spawner.spawn(async move { | ||
let state = conn_mng.0.guarded.lock().await; | ||
state.connecting.store(false, AtomicOrdering::Relaxed); | ||
}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you please elaborate on this more? ConnectingStateCtx
will be considered dropped before connecting is set to false if the lock was held by other operation for sometime.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Certainly should have been more detailed! Thanks for pointing this out! This place is the heart of selective connectivity.
mm2src/coins/utxo/rpc_clients.rs
Outdated
let address: String = { | ||
if address.is_some() { | ||
address.map(|internal| internal.to_string()) | ||
} else { | ||
guard.active.as_ref().cloned() | ||
} | ||
}?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let address: String = { | |
if address.is_some() { | |
address.map(|internal| internal.to_string()) | |
} else { | |
guard.active.as_ref().cloned() | |
} | |
}?; | |
let address = address.map_or_else(|| guard.active.as_ref().cloned(), |internal| Some(internal.to_string()))?; |
38adc56
to
cfbeea0
Compare
still needs refactoring for the tons of warnings there also selective connection manager is missing
the total time this method might take is at most the timeout decided in the connection settings, which is the time needed to establish the connection and query for the version
the abortable system that created the children abortable systems for the connections were dropped and that resulted in a non functioning connection abortable systems
electrum servers don't like it when the same connection query for the vesion again, they expect us to store the version and never ask about it again
the middle subsystem wasn't used anywhere, thus was dropped and caused all the connection subsystems to get aborted.
…zation and not in tests
the new design doesn't break the coin initilization if the electrum servers fail for whatever reason. Create the coin and make sure that each server fails version check when queried
This PR introduces a new electrum connection management system that is presented by two defined policies:
multiple
andselective
. In the future the other types of connections are presumably to be managed in the same way.Setting up conn mng policy
To set up connection management policy the
conn_mng_policy
should be provided in the mm2 configuration file (MM2.json
). This setting is also provided by thekomodefi-cli
(adex-cli
)init
commandExample:
Selective move and electrum activation scheme
Selective mode assumes that the electrum activation method is extended by the
priority
andtimeout_sec
settings, which determine in which queue the associated addresses are connected and how long the connection should take, respectively.primary
nodes are connected first thensecondary
ones. These settings are optional and if are not set the default values are applied.secondary
priority is set by default.Example:
For the given activation scheme mm2 has the following addresses queue:
It is important to note that addresses are shuffled before being queued.
If a connection cannot be established with an address or if it is broken for any reason, it is suspended for 30, 60, 120, etc. seconds, after which it is resumed. Resuming assumes that the primary address pushes out the secondary one, if it is currently connected.
Testing
selective
andmultiple
conn mng policyThere are several practices that have been used to test expected behavior. These practices are provided in the examples for your reference:
In the separate frame
elease/adex-cli enable DOC Enabling asset: DOC coin: DOC address: RPFGrvJWjSYN4qYvcXsECW1HoHbvQjowZM balance: 949828.3746221 unspendable_balance: 0 required_confirmations: 1 requires_notarization: No mature_confirmations: 100
Using the table of established connection it's always possible to know what address mm2 is connected to check if it's connected to expected ones. It is also possible to break the certain connection to check if that is suspended/resumed.