Skip to content

Conversation

Shourya742
Copy link

This PR migrates the new TProxy to the updated handlers. We're no longer using the SendTo and awkward Arc ergonomics, and things feel much cleaner now. Have a look!

@Shourya742 Shourya742 force-pushed the handlers-new-tproxy branch from 7bc040b to 401e5b3 Compare July 20, 2025 13:16
msg.error_code, msg.flags
);

Ok(())
Copy link
Owner

Choose a reason for hiding this comment

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

Shouldn't we return an error here?

Copy link
Author

Choose a reason for hiding this comment

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

I was thinking more on lines liek the user can now report this directly to status handler, respawn the service.

Copy link
Owner

Choose a reason for hiding this comment

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

Yeah that's also kind of what I was thinking about.. would this be done directly here in the handler, right?

Or are we missing anything needed by the status handler?

Copy link
Author

Choose a reason for hiding this comment

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

It can be done.

Shourya742 and others added 24 commits July 22, 2025 10:27
Previously, `HandlerError` only supported a fixed set of internal error types.
This made it difficult for downstream users implementing library traits to
propagate their own custom error types.

This commit introduces a new `External(Box<dyn Error + Send + Sync>)` variant
to allow wrapping arbitrary error values. This enables implementors to return
non-library errors without requiring changes to the core `HandlerError` enum.
- Added downstream_id to Downstream struct for better identification.
- Updated message handling in Downstream to include response handling.
- Enhanced ChannelManager with methods for processing upstream messages and creating channels.
- Refactored SV1Server to manage downstream connections and messages more effectively.
- Improved logging for better traceability of downstream operations.
- Renamed and reorganized modules for clarity, including the introduction of `sv1` and `sv2` directories.
- Added new `Downstream` and `ChannelManager` implementations to enhance message handling and processing.
- Introduced new message handler logic for upstream and downstream communication.
- Implemented share validation and extended mining channel management.
- Improved logging throughout the modules for better traceability and debugging.
- Updated Downstream struct to use a tuple for channel_id and message in the sender/receiver.
- Improved spawn methods to utilize Arc<Mutex<Self>> for better concurrency handling.
- Refactored SV1Server to accommodate changes in Downstream, ensuring proper message broadcasting and handling.
- Enhanced logging for downstream operations to improve traceability.
- Added configuration parameter to SV1Server and TranslatorSv2 for improved flexibility.
- Updated hashrate calculation to utilize configuration settings for downstream difficulty.
- Introduced initial target calculation based on configured hashrate and shares per minute.
- Improved message handling in SV1Server to accommodate new configuration features.
…ove target handling

- Added min_extranonce_size configuration to SV1Server for enhanced flexibility.
- Updated OpenExtendedMiningChannel message to utilize the configured min_extranonce_size.
- Improved target handling by ensuring initial_target is cloned when setting difficulty.
@GitGab19 GitGab19 force-pushed the new-tproxy branch 19 times, most recently from e6e5898 to 328bc6a Compare September 19, 2025 15:27
@GitGab19 GitGab19 force-pushed the new-tproxy branch 11 times, most recently from e77d1ef to f0a69aa Compare September 24, 2025 12:31
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