Quote from: DiabloD3 on July 09, 2011, 01:33:24 PM

-snip old stuff-

"" makes no sense, because then it would use the existing URL with no modifications. How would the pool server be able to tell the difference? My miner immediately starts a new LP attempt once the existing one completes. So, yes, it starts spamming because LP is not supposed to return immediately.

"foo" adds /foo to the end of the existing URL's path. "/foo" replaces the entire path, and then it also accepts a fully qualified URL. Other miners seem to only accept "foo" in violation of any sane interpretation of the URL RFC.

Quote from: [url=https://deepbit.net/longpolling.php

https://deepbit.net/longpolling.php[/url]]Long polling protocol description

1) Miner initiates connection to the mining pool just as usual, requests getwork and starts working on it.

2) If mining pool does supports Long Polling, it should include a special header:
X-Long-Polling: /long-polling-url
where /long-polling-url is a path for long polling connection. It can be a full URL with separate port too.

3) Miner starts a request to long polling URL with GET method and same basic authorization as on main connection.
This request is not answered by server until new block is found by bitcoin network. The answer is the same as getwork on the main connection. Upon receiving this answer, miner should drop current calculation in progress, discard it's result, start working on received data and make a new request to a long polling URL.

4) If all the nonce space is exhausted during calculation or 60 seconds passed since receiving the data, the miner should request new one by means of main connection. 60 seconds limit is set to allow adding new transactions into the block.

So yes "" does make sense because the pool can just check wether it's a GET or POST request...
Anyway that's not important because i changed my code...

Also we're talking past eachother here i think... Because it doesn't matter wether i add /foo, foo or http://localhost:8000/foo to the header, it still connects just fine...

the Longpolling issue is already fixed!

The spamming im talking about now is this:

Code:

[18:28:24] {"method":"getwork","params":[],"id":1}
[18:28:34] {"method":"getwork","params":[],"id":1}
[18:28:35] {"method":"getwork","params":[],"id":1}
Longpoll connection added
[18:28:44] {"method":"getwork","params":["0000000150038abc2f93cb863de66465583803
652bc9b21f3914467a0000043a00000000293f71de5bfea504c4dd9bedd2f29788c74d310d6a00ba
823ae665894adaeb7b4e1881b71a0abbcf4655401100000080000000000000000000000000000000
0000000000000000000000000000000000000000000000000080020000"],"id":1}
Solved work submitted
[18:29:34] {"method":"getwork","params":[],"id":1}
[18:29:35] {"method":"getwork","params":[],"id":1}
[18:29:35] {"method":"getwork","params":[],"id":1}
[18:29:35] {"method":"getwork","params":[],"id":1}
[18:29:36] {"method":"getwork","params":[],"id":1}
[18:29:36] {"method":"getwork","params":[],"id":1}
[18:29:37] {"method":"getwork","params":[],"id":1}
[18:29:37] {"method":"getwork","params":[],"id":1}
[18:29:37] {"method":"getwork","params":[],"id":1}
[18:29:38] {"method":"getwork","params":[],"id":1}
[18:29:38] {"method":"getwork","params":[],"id":1}
[18:29:38] {"method":"getwork","params":[],"id":1}
[18:29:39] {"method":"getwork","params":[],"id":1}
[18:29:39] {"method":"getwork","params":[],"id":1}
[18:29:39] {"method":"getwork","params":[],"id":1}
[18:29:40] {"method":"getwork","params":[],"id":1}

diablominer output says nothing about the issue... And phoenix doesn't do the same, nor does poclbm so i has to assume you're doing something special?