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

feat(libp2p): implement message sizes per topic. #5868

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

Conversation

elijahhampton
Copy link

@elijahhampton elijahhampton commented Feb 18, 2025

Description

Fixes: #5745

Notes & open questions

N/A

Change checklist

  • I have performed a self-review of my own code
  • I have made corresponding changes to the documentation
  • I have added tests that prove my fix is effective or that my feature works
  • A changelog entry has been made in the appropriate crates

… warnings from clippy, check and fmt. Modifies test cases to use TopicMeshConfig::default() in place of explicit default values
@elijahhampton
Copy link
Author

@AgeManning I opened this PR in regards to #5745. It still needs some work to ensure consistency and correctness, although, I want to get it in front of the appropriate parties to ensure the PR is in the right direction in regards to the objective.

@dariusc93 dariusc93 requested review from jxs and AgeManning February 18, 2025 05:01
Copy link
Member

@dariusc93 dariusc93 left a comment

Choose a reason for hiding this comment

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

Thanks for the PR. I did leave a comment but i wonder if we should in a way assign the size to the topic after the behavior is constructed (eg assigning it to TopicHash or via Behaviour::subscribe or through some means) vs providing it in the config, which i believe the former is meant to be intended, though I could be wrong.


/// The topic configuration sets mesh parameters for a given topic. See [`TopicMeshConfig`]
/// for defaults.
pub fn set_topic_config(&mut self, topic: TopicHash, config: TopicMeshConfig) -> &mut Self {
Copy link
Member

Choose a reason for hiding this comment

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

Is there a reason why we should set the topic in the config itself?

Copy link
Author

Choose a reason for hiding this comment

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

Set topic will be removed from Config as it was only meant to be on ConfigBuilder. It's just a duplicate I placed there while refactoring

Copy link
Contributor

@AgeManning AgeManning left a comment

Choose a reason for hiding this comment

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

This looks good imo.

Do we need to clone the config everytime we read it?

Also, I think it would be nice to maintain backwards compatibility. i.e, if users are already using mesh_n() then it works as before, I think it would be nice to add additional config, like mesh_n_topic() which changes just that topic, all others revert to the default or if mesh_n() etc was set.

Nice work.

@elijahhampton
Copy link
Author

This looks good imo.

Do we need to clone the config everytime we read it?

Also, I think it would be nice to maintain backwards compatibility. i.e, if users are already using mesh_n() then it works as before, I think it would be nice to add additional config, like mesh_n_topic() which changes just that topic, all others revert to the default or if mesh_n() etc was set.

Nice work.

This looks good imo.

Do we need to clone the config everytime we read it?

Also, I think it would be nice to maintain backwards compatibility. i.e, if users are already using mesh_n() then it works as before, I think it would be nice to add additional config, like mesh_n_topic() which changes just that topic, all others revert to the default or if mesh_n() etc was set.

Nice work.

You're right. I will look into removing the unnecessary cloning and the backwards compatibility makes sense. I will try to get this wrapped up this weekend between tomorrow and Sat.

@elijahhampton elijahhampton changed the title Draft: Feat(5745) implement message sizes per topic Feat(5745) implement message sizes per topic Feb 23, 2025
@elijahhampton elijahhampton changed the title Feat(5745) implement message sizes per topic feat(libp2p): implement message sizes per topic. Feb 27, 2025
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.

Gossipsub - Implement message sizes per topic
3 participants