[ANN] Stratum mining protocol - ASIC ready - page 10.

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

Quote from: slush on February 23, 2013, 01:03:05 PM

Quote from: kano on February 23, 2013, 12:52:23 PM

If you wish to see the old downloads you put in your git then just add "/downloads/" to your git address.
GutHub has disabled being able to add new downloads and will delete all download files soon.

I know that "/download" trick, I just wanted to make the announcement simple :-). But the important part is highlighted.

I solved it by creating a cgminer-binaries git for me

slush

legendary

Activity: 1386

Merit: 1097

Quote from: kano on February 23, 2013, 12:52:23 PM

If you wish to see the old downloads you put in your git then just add "/downloads/" to your git address.
GutHub has disabled being able to add new downloads and will delete all download files soon.

I know that "/download" trick, I just wanted to make the announcement simple :-). But the important part is highlighted.

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

Quote from: slush on February 23, 2013, 12:33:10 PM

Because Github no longer provides "Download section", I moved Windows binaries of Stratum Proxy here: https://mining.bitcoin.cz/media/download/mining_proxy.exe

This URL will always serve the latest Windows binary. I tried to update links on websites to this new URL, but please let me know if you'll find old link to Github download section somewhere.

If you wish to see the old downloads you put in your git then just add "/downloads/" to your git address.
GutHub has disabled being able to add new downloads and will delete all download files soon.

slush

legendary

Activity: 1386

Merit: 1097

Because Github no longer provides "Download section", I moved Windows binaries of Stratum Proxy here: https://mining.bitcoin.cz/media/download/mining_proxy.exe

This URL will always serve the latest Windows binary. I tried to update links on websites to this new URL, but please let me know if you'll find old link to Github download section somewhere.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

I've implemented the modified protocol for reconnection and it's in the current cgminer master git. Not sure if anyone's interested in testing it as you all could be too busy fapping to ASIC hashrates right about now. Either way it should work in a way that doesn't break existing pool stratum support or slush's proxy.

slush

legendary

Activity: 1386

Merit: 1097

They're documented in not-yet-written BIP 40/41 O:-). I recommend to check stratum proxy as a reference implementation: https://github.com/slush0/stratum-mining-proxy/blob/master/mining_libs/client_service.py

DrHaribo

legendary

Activity: 2730

Merit: 1034

Needs more jiggawatts

Quote from: slush on February 22, 2013, 11:34:45 AM

There's mining.reconnect(). It should work in proxy, poclbm and cgminer too.

Is this an extension? Where are those documented?

techwtf

full member

Activity: 140

Merit: 100

Quote from: slush on February 22, 2013, 11:34:45 AM

There's mining.reconnect(). It should work in proxy, poclbm and cgminer too.

thank you and eleuthria

I didnt come up with "reconnect" so it is ignored

slush

legendary

Activity: 1386

Merit: 1097

There's mining.reconnect(). It should work in proxy, poclbm and cgminer too.

eleuthria

legendary

Activity: 1750

Merit: 1007

Quote from: techwtf on February 22, 2013, 11:31:41 AM

Any chance to have the functionality like "X-Switch-To" in getwork protocol extension?
this may allow pool operators do some maintenance work & ask the miners to migrate to a fallback server.

I'm not sure if similar idea is asked before.

This was actually suggested by me on the very first reply to the thread. I'm not sure if we'll see it standardized though.

techwtf

full member

Activity: 140

Merit: 100

Any chance to have the functionality like "X-Switch-To" in getwork protocol extension?
this may allow pool operators do some maintenance work & ask the miners to migrate to a fallback server.

I'm not sure if similar idea is asked before.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: DrHaribo on February 21, 2013, 01:43:02 AM

Quote from: -ck on February 20, 2013, 07:17:19 PM

Is it possible to use the existing unique subscription ID as the session ID with mining.resume instead?

Sounds good to me, mine is just hardcoded to "1" at the moment. I'll make it unique when it is actually used for something. Wink

We had a chat about this on IRC and agreed this would be the most seamless conversion without breaking existing clients. If the client gets a different id or enonce1 they assume it didn't resume.

DrHaribo

legendary

Activity: 2730

Merit: 1034

Needs more jiggawatts

Quote from: -ck on February 20, 2013, 07:17:19 PM

Is it possible to use the existing unique subscription ID as the session ID with mining.resume instead?

Sounds good to me, mine is just hardcoded to "1" at the moment. I'll make it unique when it is actually used for something. Wink

Quote from: slush on February 20, 2013, 08:34:40 PM

Pool should not close the connection on unknown message.

Can this go in the docs?

As well as mining.resume and mining.identify or whatever the "which client version are you" message is called.

slush

legendary

Activity: 1386

Merit: 1097

It will be better to ask Eleuthria to add standard error messages for unknown methods. It's actually pretty easy and it will make the life easier.

Auth messages are a bit sensitive, because pool may need database lookup. Especially during the server restart authorization messages may take longer time than usual, because of connection storms.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: slush on February 20, 2013, 08:41:09 PM

Quote from: -ck on February 20, 2013, 08:38:37 PM

Thanks. However what if it's the first command after the socket is opened?

Why there should be any exception for first message?

If the miner knows any recent session id, it should send mining.resume(id) firstly. If miner don't have any session id, it should send mining.subscribe(). When the pool doesn't understand mining.resume message, it should respond with standard error, not by closing the connection.

Is there really any pool which closes the connection on unknown message?

I was mistaken. I checked with Eleuthria and he said his pool simply doesn't respond to messages it doesn't recognise. This is a problem for me since I would have to wait for a response to time out and that would not be graceful or efficient. Perhaps for important auth messages I should let cgminer time out relatively quickly like 5 seconds since it really shouldn't take the pool longer than that to respond.

slush

legendary

Activity: 1386

Merit: 1097

Quote from: -ck on February 20, 2013, 08:38:37 PM

Thanks. However what if it's the first command after the socket is opened?

Why there should be any exception for first message?

If the miner knows any recent session id, it should send mining.resume(id) firstly. If miner don't have any session id, it should send mining.subscribe(). When the pool doesn't understand mining.resume message, it should respond with standard error, not by closing the connection.

Is there really any pool which closes the connection on unknown message?

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: slush on February 20, 2013, 08:34:40 PM

Quote from: -ck on February 20, 2013, 08:29:19 PM

Well of course I like that (since I suggested it) but the only disadvantage I see is the pool really does not have a flag now in its parameters to tell the mining software whether it supports resume or not, so the only way to find out is if cgminer tries the command first. That's ok too, but the issue there is what the pool does in response to a command it does not recognise: some will drop the connection, and I'm not sure what others do. I need some comments from the pool ops please?

Pool should not close the connection on unknown message. Like this:

Code:

{"id": 1, "method": "mining.resume", "params": []}
{"error": [-3, "Method 'resume' not found for service 'mining'", null], "id": 1, "result": null}

Server should close connection only when the payload is corrupted (thus there's no way to identify messages and respond with standard error).

Thanks. However what if it's the first command after the socket is opened?

slush

legendary

Activity: 1386

Merit: 1097

Quote from: -ck on February 20, 2013, 08:29:19 PM

Well of course I like that (since I suggested it) but the only disadvantage I see is the pool really does not have a flag now in its parameters to tell the mining software whether it supports resume or not, so the only way to find out is if cgminer tries the command first. That's ok too, but the issue there is what the pool does in response to a command it does not recognise: some will drop the connection, and I'm not sure what others do. I need some comments from the pool ops please?

Pool should not close the connection on unknown message. Like this:

Code:

{"id": 1, "method": "mining.resume", "params": []}
{"error": [-3, "Method 'resume' not found for service 'mining'", null], "id": 1, "result": null}

Server should close connection only when the payload is corrupted (thus there's no way to identify messages and respond with standard error).

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: slush on February 20, 2013, 07:54:38 PM

The first parameter is the rest of original Stratum idea; to be universal overlay protocol with some extended publish/subscribe features. To be honest, there's still no real use for initial meaning of the first parameter and the whole idea seems to be a bit overcomplicated.

So I'm offering to change meaning of the first parameter, let's call it session_id :-). I checked all known implementations (stratum proxy, poclbm, cgminer/bfgminer) and all three seems to completely ignore the first parameter. Using first argument as session_id seems to be fully backward compatible.

Any ideas?

Well of course I like that (since I suggested it) but the only disadvantage I see is the pool really does not have a flag now in its parameters to tell the mining software whether it supports resume or not, so the only way to find out is if cgminer tries the command first. That's ok too, but the issue there is what the pool does in response to a command it does not recognise: some will drop the connection, and I'm not sure what others do. I need some comments from the pool ops please?

slush

legendary

Activity: 1386

Merit: 1097

...and I'll also fix proxy to ignore any unknown parameters in subscribe notification. It wasn't intentional, I'm sorry for such kind of issue :-/.

Topic: [ANN] Stratum mining protocol - ASIC ready - page 10. (Read 146229 times)