-
Notifications
You must be signed in to change notification settings - Fork 97
Add constants for session protocol and transport config #6609
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
Conversation
Introduced `MAX_MESSAGE_SIZE` constant in session protocol and added validation for message length. The upper six bits are reserved for future use. Also, replaced magic numbers with constants for timeout and retries in transport configuration.
📝 Walkthrough📝 Walkthrough## Walkthrough
The changes introduced in this pull request enhance the `SessionMessage` protocol and session configuration management. A new constant `MAX_MESSAGE_SIZE` is added to the `SessionMessage` struct, along with improved error handling in the `try_next` method. In the session configuration file, several constants related to session management are defined and integrated into the `SessionGlobalConfig` struct, replacing hardcoded values. Additionally, the `Segment` struct's maximum size constraint is removed, allowing for more flexible segment sizes. These modifications aim to improve the integrity and maintainability of the protocol without altering its core functionality.
## Changes
| File Path | Change Summary |
|----------------------------------------------|-------------------------------------------------------------------------------------------------|
| common/network-types/src/session/protocol.rs | - Added constant `pub const MAX_MESSAGE_SIZE: usize` in `SessionMessage`. <br> - Updated `try_next` method in `SessionMessageIter` to include checks for message length and reserved bits. <br> - Enhanced error handling for message parsing. |
| transport/api/src/config.rs | - Added constants: `const DEFAULT_SESSION_IDLE_TIMEOUT: Duration`, `const SESSION_IDLE_MIN_TIMEOUT: Duration`, `const DEFAULT_SESSION_ESTABLISH_RETRY_DELAY: Duration`, `const DEFAULT_SESSION_ESTABLISH_MAX_RETRIES: u32`. <br> - Updated `SessionGlobalConfig` to use new constants. <br> - Modified `validate_session_idle_timeout` function to use `SESSION_IDLE_MIN_TIMEOUT`. <br> - Removed utility functions returning hardcoded durations. <br> - Reordered import statements. |
| common/network-types/src/session/frame.rs | - Removed constant `pub const MAXIMUM_SIZE: usize` from `Segment`. <br> - Updated `try_from` implementation to remove maximum size checks. |
## Possibly related PRs
- **#6312**: This PR introduces a new session protocol that includes segmentation and retransmission features, which are closely related to the changes in the `SessionMessage` protocol implementation in the main PR.
- **#6500**: Although primarily focused on HTTPS communication tests, this PR's enhancements to session management could relate to the robustness improvements in the `SessionMessage` protocol.
- **#6506**: This PR adds a test for a WireGuard tunnel, which may involve session management and message handling similar to the changes in the main PR.
- **#6580**: The updates to the OpenAPI specification regarding message tagging could relate to the validation improvements in the `SessionMessage` protocol.
- **#6583**: This PR addresses network heartbeat behavior, which may indirectly relate to session management and message handling in the context of the main PR's changes.
## Suggested labels
`feature`, `improvement`, `crate:core-protocol`, `crate:hoprd`
## Suggested reviewers
- Teebor-Choka
- QYuQianchen Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
Changed `MAX_MESSAGE_SIZE` to match Ethernet MTU minus segment overhead, and removed redundant `MAXIMUM_SIZE` constant from `segment`. This ensures consistency with typical Ethernet MTU constraints and removes superfluous checks on segment size.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (6)
transport/api/src/config.rs (3)
168-174
: Add documentation for the session-related constants.The constants effectively replace magic numbers and have reasonable values. Consider adding documentation to explain the rationale behind these values and any constraints they must satisfy.
Add rustdoc comments for each constant:
+/// Default session idle timeout (3 minutes). const DEFAULT_SESSION_IDLE_TIMEOUT: Duration = Duration::from_secs(180); +/// Minimum allowed session idle timeout (1 minute). const SESSION_IDLE_MIN_TIMEOUT: Duration = Duration::from_secs(60); +/// Default delay between session establishment retry attempts. const DEFAULT_SESSION_ESTABLISH_RETRY_DELAY: Duration = Duration::from_secs(2); +/// Default maximum number of session establishment retry attempts. const DEFAULT_SESSION_ESTABLISH_MAX_RETRIES: u32 = 3;
Line range hint
189-193
: Enhance the validation error message.The error message could be more descriptive by including the minimum allowed value.
- Err(ValidationError::new("session idle timeout is too low")) + Err(ValidationError::new(&format!( + "session idle timeout must be at least {} seconds", + SESSION_IDLE_MIN_TIMEOUT.as_secs() + )))
Line range hint
205-224
: Extract validation range limits as constants.For consistency with other constants and to make the limits more maintainable, consider extracting the validation range for
establish_max_retries
.+/// Minimum allowed value for session establishment retries. +const MIN_SESSION_ESTABLISH_RETRIES: u32 = 0; + +/// Maximum allowed value for session establishment retries. +const MAX_SESSION_ESTABLISH_RETRIES: u32 = 20; + #[validate(range(min = 0, max = 20))] #[default(DEFAULT_SESSION_ESTABLISH_MAX_RETRIES)] #[serde(default = "default_session_establish_max_retries")]Then update the validation:
-#[validate(range(min = 0, max = 20))] +#[validate(range(min = "MIN_SESSION_ESTABLISH_RETRIES", max = "MAX_SESSION_ESTABLISH_RETRIES"))]common/network-types/src/session/protocol.rs (3)
311-315
: Consider enhancing documentation forMAX_MESSAGE_SIZE
The new constant
MAX_MESSAGE_SIZE
has been introduced. Providing additional details in the documentation comments about its purpose and how it relates toSegment::MAXIMUM_SIZE
would improve code readability and help other developers understand its significance.
428-429
: Define the reserved bits mask as a constant for clarityThe mask
0b111111_0000000000
used to extract reserved bits could be defined as a named constant (e.g.,RESERVED_BITS_MASK
). This would improve code readability and make future maintenance easier.
501-501
: Explain the magic number in the test assertionIn the test assertion
assert!(SessionMessage::<0>::MAX_MESSAGE_SIZE < 2048);
, the magic number2048
is used without context. Consider defining it as a constant or adding a comment to explain its significance, enhancing the clarity of the test.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (2)
common/network-types/src/session/protocol.rs
(3 hunks)transport/api/src/config.rs
(4 hunks)
🔇 Additional comments (2)
transport/api/src/config.rs (2)
5-9
: LGTM: Import statements are well-organized.
The new imports are properly scoped and necessary for the added functionality.
176-185
: LGTM: Default value functions are well-implemented.
The functions provide a clean way to use the constants as default values in the serde deserialization.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
common/network-types/src/session/protocol.rs (1)
500-501
: Consider adding specific test cases for size validation.While the basic size constraint is tested, consider adding test cases that specifically verify:
- Messages exactly at
MAX_MESSAGE_SIZE
- Messages exceeding
MAX_MESSAGE_SIZE
- Messages with non-zero reserved bits
#[test] fn session_message_should_validate_size_and_reserved_bits() { // Test maximum allowed size let msg = create_message_with_size(SessionMessage::<0>::MAX_MESSAGE_SIZE); assert!(SessionMessage::try_from(&msg[..]).is_ok()); // Test exceeding maximum size let msg = create_message_with_size(SessionMessage::<0>::MAX_MESSAGE_SIZE + 1); assert!(matches!( SessionMessage::try_from(&msg[..]), Err(SessionError::IncorrectMessageLength) )); // Test non-zero reserved bits let mut msg = create_valid_message(); set_reserved_bits(&mut msg, 0b100000_0000000000); assert!(matches!( SessionMessage::try_from(&msg[..]), Err(SessionError::ParseError) )); }
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (2)
common/network-types/src/session/frame.rs
(0 hunks)common/network-types/src/session/protocol.rs
(3 hunks)
💤 Files with no reviewable changes (1)
- common/network-types/src/session/frame.rs
🔇 Additional comments (2)
common/network-types/src/session/protocol.rs (2)
311-314
: LGTM! Well-documented constant definition.
The MAX_MESSAGE_SIZE
constant is appropriately defined and documented, accounting for protocol overhead based on typical Ethernet MTU size.
422-434
: LGTM! Robust validation implementation.
The validation logic effectively enforces:
- Message size limits using
MAX_MESSAGE_SIZE
- Reserved bits constraint for future protocol extensions
The error handling and comments are clear and appropriate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
common/network-types/src/session/protocol.rs (1)
500-501
: Consider documenting the significance of 2048.While the test verifies that
MAX_MESSAGE_SIZE
is less than 2048, it would be helpful to document why this specific value was chosen as the upper bound.- assert!(SessionMessage::<0>::MAX_MESSAGE_SIZE < 2048); + // Ensure MAX_MESSAGE_SIZE fits within 11 bits (< 2048) since we reserve + // the upper 6 bits of the u16 message length field + assert!(SessionMessage::<0>::MAX_MESSAGE_SIZE < 2048);
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (2)
common/network-types/src/session/frame.rs
(0 hunks)common/network-types/src/session/protocol.rs
(3 hunks)
💤 Files with no reviewable changes (1)
- common/network-types/src/session/frame.rs
🔇 Additional comments (2)
common/network-types/src/session/protocol.rs (2)
311-314
: LGTM! Well-documented constant definition.
The MAX_MESSAGE_SIZE
constant is well-defined and documented, with a clear explanation of how it's calculated based on the Ethernet MTU size minus the segment overhead.
422-434
: LGTM! Robust message validation logic.
The implementation includes two important validations:
- Message length check against
MAX_MESSAGE_SIZE
- Reserved bits validation for future protocol versions
This ensures both safety (preventing buffer overflows) and forward compatibility.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder whether these should be exposed in the configuration like this. These are more of niche config options... that probably should not be presented to the user, but could be configured by env variables, e.g. as libp2p does.
As I mentioned earlier, the Exit node's config exposure was requested for Ronny. |
Yeah, but could it be done in the form of ENV variables? |
Which ones would you rather have as env variables? And why would it be better than exposing them in the config? |
We can change everything in 3.0. |
Right. I believe the configs in And in the top-level binaries, there should be new (simplified) configs which will subset of |
Introduced
MAX_MESSAGE_SIZE
constant in session protocol and added validation for message length. The upper six bits of length are reserved for future use.Also, replaced magic numbers with constants for timeout and retries in transport configuration.