feat(network): introduce relay reservation score #2634
Conversation
This should have been collected yesterday, but was forgotten.
…entt feat(metrics): implement custom relay client metrics
…_on_restart fix(network): set the record count metric as soon as we restart
…l addr are private
…or_fix fix(network): consider MultiAddrNotSupported as a serioud issu..
| } | ||
|
|
||
| #[derive(Debug, Default, Clone)] | ||
| struct ReservationStat { |
There was a problem hiding this comment.
shall this to be the score of the recent X number attempts , so that it can reflect the realtime of the health ?
ant-networking/src/relay_manager.rs
Outdated
| self.log_reservation_score(); | ||
| } | ||
|
|
||
| /// Clean up the stats for relay servers that we are no longer connected to. |
There was a problem hiding this comment.
will this make us re-connect to a faulty-server and experience another round of tracking then drop ?
There was a problem hiding this comment.
Yeah, we could add a block list here.
| continue; | ||
| }; | ||
|
|
||
| if elapsed < MAX_DURATION_TO_TRACK_INCOMING_CONNECTIONS_PER_PEER { |
There was a problem hiding this comment.
not quite sure, MAX_DURATION_TO_TRACK_INCOMING_CONNECTIONS_PER_PEER is a fixed duration.
However, according to the log msg, waiting to be established is an event driven status change, not time-driven
Don't get why not timed out means it is still waiting to be established?
There was a problem hiding this comment.
A random peer could make multiple incoming connections through multiple of our relays, so we can't just act on the events, instead we have to give ourselves some time to collect all these incoming connections.
Sometimes we could get 1 incoming connection, sometimes 4, we can't be sure.
ant-networking/src/relay_manager.rs
Outdated
| } | ||
|
|
||
| for from_peer in to_remove { | ||
| debug!("Removing {from_peer:?} from the incoming_connections_from_remote_peer"); |
There was a problem hiding this comment.
incoming_connections_from_remote_peer only got pruned when got updated within above block of code
what if entries remained in the container due to some bug/error, which makes it growing infinitely ?
There was a problem hiding this comment.
The only scenario where this can happen is from the below code
let Some(latest_time) = connections.iter().map(|(_, _, time, _)| time).max() else {
debug!("The incoming connections from {from_peer:?} are empty. Skipping.");
continue;
};
let Ok(elapsed) = SystemTime::now().duration_since(*latest_time) else {
debug!("Could not obtain elapsed time.");
continue;
};
This can only happen if there is a bug in our code. The cleanup does not depend on the events, it depends on just the MAX_DURATION_TO_TRACK_INCOMING_CONNECTIONS_PER_PEER.
Just depending on a timer is fine because a connection cannot take more than 15s before a ConnectionEstablished or a IncomingConnectionError is emitted tbh.
There was a problem hiding this comment.
ok. fine then.
just This can only happen if there is a bug in our code could happen
RolandSherwin
force-pushed
the
relay_healthh
branch
2 times, most recently
from
e09a5aa to
1ce8fc6
Compare
RolandSherwin
force-pushed
the
relay_healthh
branch
from
37331e3 to
63d505b
Compare
No description provided.