cloudhead / cloudhead/nakamoto
Prefer low-latency peers
- Dominant language
- Rust
- Stars
- 391
- Forks
- 64
- PR merge metrics
- No merged PRs in 30d
Description
Currently, peer latency is measured in the `PingManager`, but not used.
* We should keep track of latencies, persist them (either in the `client::peer::Cache` or some where else.
* Use it to decide which peers to connect to
* Use it to decide which peers to download headers/blocks from
Some notes:
* We should generally not compromise geo-diveristy when looking for low-latency peers, but having a few low-latency peers is desired
* Low-latency peer selection can either be via `AddressManager::sample` being biased towards low-latency peers, or by simply calling `sample` 2-3 times and picking the peer with the lowest latency.
Contributor guide
Assessment
This issue has not been assessed yet.