Which document is correct regarding response to "subscribe" method

[konradp]

Hi.

About stratum protocol, which document is correct?

https://www.btcguild.com/new_protocol.php

or

http://mining.bitcoin.cz/stratum-mining

The first says, to the "subscription" method, a pool should respond with:
Server:  {"id": 1, "result": [["mining.notify", "ae6812eb4cd7735a302a8a9dd95cf71f"], "08000002", 4], "error": null}\n

The latter says:
{"id": 1, "result": [[["mining.set_difficulty", "b4b6693b72a50c7116db18d6497cac52"], ["mining.notify", "ae6812eb4cd7735a302a8a9dd95cf71f"]], "08000002", 4], "error": null}\n

Please help... I'm a bit stuck at this now.

[konradp]

I think I figured it out.

I've just discovered the -D flag in cpuminer, which turns on debbugging info. And with the first example above I can see a "Failed to get Stratum session id" message. With the second example everything's look fine.

So, for example slush pool or 50btc.com handle this correctly, while for example bitminter and btcguild handle this incorrectly.

I'm only wondering why nobody answered the question, isn't the stratum protocol well known among cryptocurrencies decs?

[CaptEmulation]

stratum is more of an idea-- JSON over TCP/IP socket.  I too have found the protocol specification lacking and resorted to using a stratum proxy to reverse-engineer the protocol (similar to you).

[-ck]

I think I figured it out.

I've just discovered the -D flag in cpuminer, which turns on debbugging info. And with the first example above I can see a "Failed to get Stratum session id" message. With the second example everything's look fine.

So, for example slush pool or 50btc.com handle this correctly, while for example bitminter and btcguild handle this incorrectly.

I'm only wondering why nobody answered the question, isn't the stratum protocol well known among cryptocurrencies devs?

The stratum protocol is really only known to mining software and pool devs as it has nothing to do with the regular bitcoin client. There was an extension to the protocol which allows the session id to be reused or not depending on whether there was a plan to support reconnect or not. Very few pools support reconnect.
There is no official documentation apart from the discussion thread in the pool section. Here is the definitive word on reconnect support that I wrote when we agreed on how it should be managed:
https://bitcointalk.org/index.php?topic=108533.msg1557099#msg1557099

[konradp]

I think I figured it out.

I've just discovered the -D flag in cpuminer, which turns on debbugging info. And with the first example above I can see a "Failed to get Stratum session id" message. With the second example everything's look fine.

So, for example slush pool or 50btc.com handle this correctly, while for example bitminter and btcguild handle this incorrectly.

I'm only wondering why nobody answered the question, isn't the stratum protocol well known among cryptocurrencies devs?

The stratum protocol is really only known to mining software and pool devs as it has nothing to do with the regular bitcoin client. There was an extension to the protocol which allows the session id to be reused or not depending on whether there was a plan to support reconnect or not. Very few pools support reconnect.
There is no official documentation apart from the discussion thread in the pool section. Here is the definitive word on reconnect support that I wrote when we agreed on how it should be managed:
https://bitcointalk.org/index.php?topic=108533.msg1557099#msg1557099

Thanks guys!

@ckolivas - yes, I did read this thread, I know about the reconnect functionality - I'm not going to implement it. But I was asking about a pool's response to the "subscribe" method. Different pools answer differently. I understand that some pools don't send session id (plus the answer's format is completely different).  But are all the miners (or at least most of them) able the handle this situation?

[-ck]

Perhaps you want this:
https://bitcointalk.org/index.php?topic=557866.0

And this:
https://bitcointalk.org/index.php?topic=557991.0

And this:

2013 Feb, after discussion, mining.subscribe was extended to take 2 arguments, so now it's mining.subscribe(String useragent, sessionid) where sessionid is optional, but if provided must match a previous session's mining.notify subscription id. If the server allows resuming a session, it will give you back the same subscription id and extranonce information.

cgminer handles it. No idea bout the rest.

[konradp]

Thank you!