les: duplicate downloader and fetcher to allow progressive refactoring #23561
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
karalabe
requested review from
gballet,
holiman,
rjl493456442 and
zsfelfoldi
as code owners
karalabe
force-pushed
the
temp-split-leseh
branch
from
35d716c
to
9e17648
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR duplicates (copy pasta) the
eth/downloaderandeth/fetcherpackages underlesand rewires the light client to use these instead. The reason is that we're working on overhauling eth to useeth/66style request IDs. This permits us to switch from the current async packet handling (where replies descend from higher layers to lower layers) to a blocking API (where the response teleports to the request callsite directly), which makes everything a lot more correct and a lot cleaner.The hard part of the refactor is that currently the reply packets propagate through a lot of layers, each potentially interacting with them. Changing the req/rep APIs to blocking ones inherently changes the internal behavior of these components and also their external APIs. It's hard enough to keep
ethin one piece while this is done, but having to constantly keeplesin the picture too and ensure it does not break is just pointless juggling.After the update to the
ethpackages is done, we'll be able to see what the final shape of things are and we can decide to deduplicate these common components or potentially roll simplified ones for LES (which might make a lot of sense given that LES does not use 90% of the code it imports).