cloudhead / cloudhead/nakamoto

Prefer low-latency peers

Open
#12 0 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.