Skip to content

Conversation

@ardocrat
Copy link
Contributor

@ardocrat ardocrat commented Dec 19, 2025

  • For each segment request, the peer that last received it is saved
  • If a timeout expires, the next attempt is actively performed on a different peer
  • Segment batch optimization and logging

Thanks to @wiesche89.

/// How long the state sync should wait after requesting a segment from a peer before
/// deciding the segment isn't going to arrive. The syncer will then re-request the segment
pub const SEGMENT_REQUEST_TIMEOUT_SECS: i64 = 60;
pub const SEGMENT_REQUEST_TIMEOUT_SECS: i64 = 20;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This may be okay, but we do have a lot of slow peers on the network and the rangeproof segments can be kind of large IIUC. It'd be a good idea to look for someone with a slow connection to test this change and make sure we aren't causing needless churn with the timeout reduction.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, will try to simulate slow connection to see the difference.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants