pool: Use regular expressions to identify clients. #406
Conversation
davecgh
force-pushed
the
identify_miner_by_regex
branch
from
f2e4ecd to
4b3e62e
Compare
davecgh
force-pushed
the
identify_miner_by_regex
branch
2 times, most recently
from
61ef5ad to
065813f
Compare
|
|
||
| // miningClients maps regular expressions to the supported mining client IDs | ||
| // for all user agents that match the regular expression. | ||
| miningClients = map[*regexp.Regexp][]string{ |
There was a problem hiding this comment.
| miningClients = map[*regexp.Regexp][]string{ | |
| miningClients = map[*regexp.Regexp]string{ |
I think this change would serve to simplify things quite a bit. Maybe there is a reason for it, but I don't see why a single ID would need to be mapping to multiple miner types. We can add support for that later if it ever becomes necessary.
There was a problem hiding this comment.
I left it that way because there is infrastructure for upgrading based on the hash rate. There is nothing forcing two different devices to use a different user agent, and as a result, you can have multiple devices with wildly different hashrates identifying themselves the same.
There are tests which cover the upgrading as well (see testClientUpgrades).
There was a problem hiding this comment.
As an aside, I think that ideally the pool really generally shouldn't even be assigning hash rates and instead should figure it out dynamically. It would be similar to how the client upgrade code is doing for devices with the same UA, but instead it would allow it to become more or less difficult depending on share submission rate.
Then, it could assign some initial hash rates per UA and even better would be for the protocol to allow clients to specify it themselves (which is unfortunately not part of stratum). Naturally, it would need to be sanity checked and only serve as an initial starting point for the aforementioned dynamic behavior.
However, that is a fair amount of work that doesn't seem worth it given the goal at the moment is primarily getting into shape for BLAKE3 and gominer as opposed to adding new features.
This modifies that logic that identifies mining clients by their user agent to use regular expressions instead of requiring hard coded version numbers. It also adds tests to ensure proper matching functionality. The primary motivation is to allow the pool to continue to work with new patch versions of mining clients without requiring updates the pool software. However, it also provides the flexibility to adapt to specific client software that might not conform to semver semantics in the future if is desired.
davecgh
force-pushed
the
identify_miner_by_regex
branch
from
065813f to
13bba52
Compare
This modifies that logic that identifies mining clients by their user agent to use regular expressions instead of requiring hard coded version numbers.
It also adds tests to ensure proper matching functionality.
The primary motivation is to allow the pool to continue to work with new patch versions of mining clients without requiring updates the pool software.
However, it also provides the flexibility to adapt to specific client software that might not conform to semver semantics in the future if is desired.