Topic: New method for stratum protocol: ping (Read 1610 times)
I'm not being aggressive, I'm being critical which is what all changes deserve these days as the stability in pooled mining has come hard fought and you'll get much more resistance from the pool ops than me. If there was universal support for anything I'd add support myself, but I don't see it forthcoming with this one.
Came on, I just thought this new method would be interesting for the global Bitcoin/Altcoin mining community (and I still think so).
Of course I needed it, and this is why I've come here to get some feedback and try to push the implementation in the current stratum softwares.
Most of my work (not only related with crypto currencies) is public available in my github repository, I'm open source, open standards follower and contributor since always.
I don't understand why you are so aggressive. But of course you are in your right.
Nothing more to add, if people think this method is not useful, then I will just try to find another way to solve this issue.
By the way, ckolivas, thank you for your work in Cgminer, it is just amazing.
PS: I think it would be very interesting to publish an "official" RFC for the stratum protocol so software developers will have an official standard to follow
Of course I needed it, and this is why I've come here to get some feedback and try to push the implementation in the current stratum softwares.
Most of my work (not only related with crypto currencies) is public available in my github repository, I'm open source, open standards follower and contributor since always.
I don't understand why you are so aggressive. But of course you are in your right.
Nothing more to add, if people think this method is not useful, then I will just try to find another way to solve this issue.
By the way, ckolivas, thank you for your work in Cgminer, it is just amazing.
PS: I think it would be very interesting to publish an "official" RFC for the stratum protocol so software developers will have an official standard to follow
There is no official documentation apart from the current implementation in cgminer and various bitcoin pools however there is generous discussion.
I put together a summary of documentation here:
https://bitcointalksearch.org/topic/stratum-protocol-documentation-557866
The closest we have to an RFC is this thread here where extensions got discussed along with standards.
https://bitcointalksearch.org/topic/ann-stratum-mining-protocol-asic-ready-108533
If you don't like the defacto standards I'm sorry.
If you wish to extend the protocol for your coin's mining software and pool, go nuts. No one's stopping you, but as I said what you are asking serves zero utility in bitcoin mining so no one here will care to adopt it or extend the defacto standard to include it.
I put together a summary of documentation here:
https://bitcointalksearch.org/topic/stratum-protocol-documentation-557866
The closest we have to an RFC is this thread here where extensions got discussed along with standards.
https://bitcointalksearch.org/topic/ann-stratum-mining-protocol-asic-ready-108533
If you don't like the defacto standards I'm sorry.
If you wish to extend the protocol for your coin's mining software and pool, go nuts. No one's stopping you, but as I said what you are asking serves zero utility in bitcoin mining so no one here will care to adopt it or extend the defacto standard to include it.
This is a solution looking for a problem. Stratum servers are obliged to send you work updates no farther than 60 seconds
Then many pools are not following this "obligation". Where is it specified? I'm not able to find it in here http://mining.bitcoin.cz/stratum-mining
Is there some other official standard specification for stratum?
apart and I doubt they'd appreciate a way for you to spam them with requests.
They are already spammed by submitted shares. I don't thing this ping method which contains just few bytes can make a difference here. In addition it must be used only when the pool has not sent a job for N (N=60?) seconds before waiting for a TCP connection timeout. So we are actually talking about very very few network bandwidth.
If this is some workaround for some altcoin design or pool issue you'll get no love here.
Came on, does it matters? At the end we all are trying to improve our services by improving the public/common services. I'm pretty sure the stratum protocol was born to cover the pool's (an also user) needs.
Please, reconsider your position here, if you don't want (or you don't need) to use this method in your software, just don't do it. But let the others have the possibility of doing it.
This is a solution looking for a problem. Stratum servers are obliged to send you work updates no farther than 60 seconds apart and I doubt they'd appreciate a way for you to spam them with requests. If this is some workaround for some altcoin design or pool issue you'll get no love here.
Hi.
When using multiple pools, it would be useful to add a new ping method for the stratum protocol.
So the worker does not need to wait until the timeout or the TCP connection lost event. It can send pings periodically, wait some seconds for the reply and if not change to the second pool.
Client: {"params": [], "id": 4, "method": "ping"}
Server: {"error": null, "id": 4, "result": true}
If the pool is sending new jobs often (every few seconds) this method is not needed, but in case the pool is sending jobs or changing difficulty not so often (depends on the coin, the block generation time, etc.), then this method might increase the performance of many workers by not spending time waiting for a pool timeout.
What do you think? It looks simple and easy to implement.
When using multiple pools, it would be useful to add a new ping method for the stratum protocol.
So the worker does not need to wait until the timeout or the TCP connection lost event. It can send pings periodically, wait some seconds for the reply and if not change to the second pool.
Client: {"params": [], "id": 4, "method": "ping"}
Server: {"error": null, "id": 4, "result": true}
If the pool is sending new jobs often (every few seconds) this method is not needed, but in case the pool is sending jobs or changing difficulty not so often (depends on the coin, the block generation time, etc.), then this method might increase the performance of many workers by not spending time waiting for a pool timeout.
What do you think? It looks simple and easy to implement.
+1 for this idea. It would need to be implemented on stratum and new CGMiners/BFGminer w/e you use.
Hi.
When using multiple pools, it would be useful to add a new ping method for the stratum protocol.
So the worker does not need to wait until the timeout or the TCP connection lost event. It can send pings periodically, wait some seconds for the reply and if not change to the second pool.
Client: {"params": [], "id": 4, "method": "ping"}
Server: {"error": null, "id": 4, "result": true}
If the pool is sending new jobs often (every few seconds) this method is not needed, but in case the pool is sending jobs or changing difficulty not so often (depends on the coin, the block generation time, etc.), then this method might increase the performance of many workers by not spending time waiting for a pool timeout.
What do you think? It looks simple and easy to implement.
When using multiple pools, it would be useful to add a new ping method for the stratum protocol.
So the worker does not need to wait until the timeout or the TCP connection lost event. It can send pings periodically, wait some seconds for the reply and if not change to the second pool.
Client: {"params": [], "id": 4, "method": "ping"}
Server: {"error": null, "id": 4, "result": true}
If the pool is sending new jobs often (every few seconds) this method is not needed, but in case the pool is sending jobs or changing difficulty not so often (depends on the coin, the block generation time, etc.), then this method might increase the performance of many workers by not spending time waiting for a pool timeout.
What do you think? It looks simple and easy to implement.
Jump to: