Skip to content

eth: stabilize tx relay peer selection #31714

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

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

cskiraly
Copy link
Contributor

When maxPeers was just above some perfect square, and a few peers
dropped for some reason, we changed the peer selection function.
When new peers were acquired, we changed again.

This PR will stabilize the selection function under normal operating
conditions by adding some hysteresis.

The first patch was a first implementation that worked only close to maxPeers.
The second version (second patch) works all over the spectrum.

When maxPeers was just above some perfect square, and a few peers
dropped for some reason, we changed the peer selection function.
When new peers were acquired, we changed again.
This patch stabilizes the selection function under normal operating
conditions close to saturation.

Signed-off-by: Csaba Kiraly <[email protected]>
…cast

When maxPeers was just above some perfect square, and a few peers
dropped for some reason, we changed the peer selection function.
When new peers were acquired, we changed again.

This patch stabilizes the selection function under normal operating
conditions by adding some hysteresis.

Signed-off-by: Csaba Kiraly <[email protected]>
@cskiraly cskiraly requested a review from rjl493456442 as a code owner April 25, 2025 10:41
@cskiraly cskiraly requested a review from fjl April 25, 2025 10:44
@fjl fjl changed the title Stabilize tx peer selection eth: stabilize tx relay peer selection Apr 29, 2025
@fjl fjl self-assigned this Apr 29, 2025
@cskiraly
Copy link
Contributor Author

cskiraly commented May 6, 2025

@fjl I don't think we use the atomicity of lastDirect, simply because the way we use BroadcastTransactions, it has its own loop in a dedicated goroutine.
Still it seemed better to me to make it atomic, but we can also remove it.

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.

2 participants