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(network): divide compression algorithm support in three categories #150

Merged
merged 5 commits into from
Jan 27, 2025

Conversation

nerodono
Copy link
Contributor

@nerodono nerodono commented Jan 16, 2025

This PR introduces more flexibility in compression algorithm selection by dividing "support" in three categories:

  • supported - the algorithm can be used to communicate with the node
  • preferred - the algorithm should be selected to communicate with the node
  • disabled - the algorithm is not supported

Two nodes decide on the algorithm as follows:

  • If they both have preferred algorithms in common - select in [hard-coded] preference order
  • If first node prefers something that is supported by the second node - the algorithm is selected in the [hard-coded] preference order
  • Otherwise, no compression would be used

First of all, this algorithm implies there's node which "leads" in choice of algorithm ("first node"), in the current implementation, lead node is node that accepts the connection.

BREAKING CHANGES: compression algorithms in config expressed now as follows:

algorithms.lz4 = { preference = "Preferred" }
algorithms.zstd = { preference = "Disabled" }

@nerodono nerodono force-pushed the feat/compression-preferences-in-network branch 2 times, most recently from 6b4872d to b05947d Compare January 16, 2025 13:29
@nerodono nerodono force-pushed the feat/compression-preferences-in-network branch 2 times, most recently from ec329d1 to f91660f Compare January 16, 2025 13:51
@loyd loyd requested review from laplab and loyd January 16, 2025 13:51
@nerodono nerodono force-pushed the feat/compression-preferences-in-network branch from f91660f to 575b557 Compare January 16, 2025 15:10
…ies: supported, preferred and disabled

BREAKING CHANGES: Compression in algorithm configuration format is changed as follows:
```toml
algorithms = { lz4 = "preferred" }
```
@nerodono nerodono force-pushed the feat/compression-preferences-in-network branch from 575b557 to bd294b5 Compare January 16, 2025 20:43
#[serde(default)]
pub algorithm: CompressionAlgorithm,
pub algorithms: CompressionPreference,
Copy link
Collaborator

Choose a reason for hiding this comment

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

This is a breaking change (which is ok because we have alpha versions), but, in this case, I think we can revise it even more and use system.network.compression.lz4 = "Preferred". If other settings (e.g. compression level) will be available to configure in the future, it will support the second per-codec form system.network.compression.zstd = { preference = "Preferred", level = 6 } in a backward-compatible way. I don't see what common options can be added next to algorithms to have this additional nesting level.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Still "algorithms"

Copy link
Collaborator

Choose a reason for hiding this comment

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

gonna fix on my own

…modules, get rid of `CompressionAlgorithm` type
…ence`, add `Disabled` option in it and make algorithms config more backward compatible
@nerodono nerodono force-pushed the feat/compression-preferences-in-network branch 4 times, most recently from de322c8 to 198be9d Compare January 21, 2025 13:38
@nerodono nerodono force-pushed the feat/compression-preferences-in-network branch from 198be9d to af6e7bb Compare January 21, 2025 13:43
Self(joined)
}

pub(crate) fn toggle(&mut self, algos: Algorithms, pref: Preference) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Actually, It's not a "toggle", because this code does not work as expected for toggle(Preferred); toggle(Disabled) sequence.

@loyd
Copy link
Collaborator

loyd commented Jan 27, 2025

First of all, this algorithm implies there's node which "leads" in choice of algorithm ("first node"), in the current implementation, lead node is node that accepts the connection.

What does it mean? Both peers perform the same intersection process.

@loyd loyd merged commit bf162d9 into elfo-rs:master Jan 27, 2025
7 checks passed
loyd added a commit that referenced this pull request Jan 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.

2 participants