Skip to content
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

Use only one network service for all chains #111

Closed
tomaka opened this issue Feb 9, 2023 · 3 comments · Fixed by #1200 or #1398
Closed

Use only one network service for all chains #111

tomaka opened this issue Feb 9, 2023 · 3 comments · Fixed by #1200 or #1398

Comments

@tomaka
Copy link
Contributor

tomaka commented Feb 9, 2023

paritytech/smoldot#997

@tomaka
Copy link
Contributor Author

tomaka commented Mar 29, 2023

While this would be a nice to have feature, it is unfortunately insanely complicated.

@tomaka
Copy link
Contributor Author

tomaka commented Mar 30, 2023

The plan, to implement that, is to no longer pass the list of protocols to peers.rs or collection.rs (or anything below) ahead of time.

Instead, the parameters of the protocol (including its name) are now passed every single time a substream is opened. When the remote opens a substream, it generates an event which the service.rs must answer, to determine the type and parameters of the protocol requested by the remote.
For this reason, it is easier if #59 done beforehand.

This would make it possible for service.rs to support additional protocols and remove support for existing protocols. Then, the API of service.rs could be changed to allow adding or removing entire chains.

Note that when it comes to peers.rs, since the state machine must track duplicate substreams, it is unclear how exactly this would look like at the moment.

@tomaka
Copy link
Contributor Author

tomaka commented Sep 27, 2023

Note that it is possible for multiple chains with the same genesis hash and fork ID to be added to the light client.
When that happens, all the chains with the same genesis hash and fork ID should use the same ChainId of that networking service.

This has the consequence that the network service must change to be able to report the existing state of the networking, which is something we already want to do anyway for #519.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant