Pages:
Author

Topic: Flexible mining proxy - page 13. (Read 88812 times)

full member
Activity: 207
Merit: 100
May 16, 2011, 11:27:25 PM
#77
Took me a while, but I got it set up! Thanks!

1 BTC heading your way
full member
Activity: 753
Merit: 100
May 16, 2011, 09:58:57 AM
#76
can you give me a name of web hoster where your proxy can work ?

All i test, had 'php_auth_user' disable ......

Sorry for my poor english
full member
Activity: 125
Merit: 100
May 11, 2011, 05:12:39 AM
#75
Hmm... I'm not going to discount this explanation, but I don't see any evidence that sending an HTTP 1.0 request is causing problems.  My workers are issuing long-polling requests to deepbit through the proxy and they appear to be working just fine.

I just cranked up a new kind of sniffer, one that logs each unique tuple into a separate file.  What I found is that upon receiving my input text (fed to your proxy via telnet) as follows:

Quote
GET /index.php?lpurl=http%3A%2F%2Fdeepbit.net%3A8332%2FlistenChannel&pool=1 HTTP/1.1
Connection: close
Host: bitproxy.xxxxx.com
Authorization: Basic xxx
User-Agent: phoenix/v1.2
(and one more trailing CR)

Your proxy actually connected to deepbit twice.  The first time was apparently to setup the actual long-polling session for my telnet to the proxy.  The second communication was completely blank - neither side said anything.  After a couple of minutes, my telnet session spat back the following:

Quote
HTTP/1.1 200 OK
Date: Wed, 11 May 2011 09:59:01 GMT
Server: Apache/2.2.3 (CentOS)
X-Powered-By: PHP/5.1.6
X-Source-Code: https://github.com/cdhowie/Bitcoin-mining-proxy
Set-Cookie: PHPSESSID=bd8s2r4gnb80pgl6n3hd3ne606; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Length: 78
Connection: close
Content-Type: application/json-rpc

{"error":"Invalid response from long-poll request.","result":null,"id":"json"}

This was not in response to anything being sent from deepbit to the proxy - deepbit never at any time uttered another word.  I ran the same testing iteration again and got a successful long poll when the pool jumped to the next block, but on the next iteration it was exactly the same behavior as above.  (note that all of this is still based on a 2-day old pull, I did not pull the code again per your mention above).

Does that help?
full member
Activity: 182
Merit: 107
May 11, 2011, 01:54:27 AM
#74
Ahhh I see the problem.  From your proxy to deepbit:

GET /listenChannel HTTP/1.0
Authorization: Basic youcanthavemypassword;]
Host: deepbit.net:8332

I watched it send this to deepbit once and it worked, but the next time it didn't.  The request was the same, but it appears to be failing because you're sending the request as HTTP 1.0.  Based on the reply from the pool, you can see that the pool wants to serve HTTP/1.1.  So my guess is we're hitting nginx, which is setup as a loadbalancer, and one of the backend machines is configured to work with HTTP 1.0 and the other is not.  You can also see from my previous post that the client normally asks in HTTP/1.1 (though in the long polling specification at deepbit's website, they don't mention that it needs HTTP/1.1).  If that all looks sensible, can you commit a fix to make the long polling requests in HTTP/1.1?

Thanks!
Hmm... I'm not going to discount this explanation, but I don't see any evidence that sending an HTTP 1.0 request is causing problems.  My workers are issuing long-polling requests to deepbit through the proxy and they appear to be working just fine.
full member
Activity: 182
Merit: 107
May 11, 2011, 01:49:17 AM
#73
I've just done a push.  I recommend that everyone update from master.

This update fixes some PHP warnings that would get triggered on a failover, effectively breaking failover entirely on configurations where PHP warnings are emitted.  The pool timeout has also been lowered from 5 seconds to 2 since the default configuration of some miners is to request work every 5 seconds.  These miners will break if the proxy takes too long to respond, terminating the active getwork request and issuing another.  (This timeout will be made configurable in a later push so that you can customize it to your configuration.)

An error_reporting() call has also been added to the config.inc.php.sample file.  It's strongly recommended that you copy this into your config.inc.php to mitigate any possible future issues caused by PHP warnings getting mixed into the JSON response for workers.
full member
Activity: 125
Merit: 100
May 10, 2011, 11:15:14 PM
#72
Quote from: cdhowie
Hmm.  This capture is helpful, but without seeing the long-polling request and response that the proxy itself sends out, I can't really say why it's doing this.  It is possible that deepbit itself is returning an error from the long-polling request and I'm just forwarding it on to the worker.

Ahhh I see the problem.  From your proxy to deepbit:

GET /listenChannel HTTP/1.0
Authorization: Basic youcanthavemypassword;]
Host: deepbit.net:8332

I watched it send this to deepbit once and it worked, but the next time it didn't.  The request was the same, but it appears to be failing because you're sending the request as HTTP 1.0.  Based on the reply from the pool, you can see that the pool wants to serve HTTP/1.1.  So my guess is we're hitting nginx, which is setup as a loadbalancer, and one of the backend machines is configured to work with HTTP 1.0 and the other is not.  You can also see from my previous post that the client normally asks in HTTP/1.1 (though in the long polling specification at deepbit's website, they don't mention that it needs HTTP/1.1).  If that all looks sensible, can you commit a fix to make the long polling requests in HTTP/1.1?

Thanks!
full member
Activity: 182
Merit: 107
May 10, 2011, 06:45:40 PM
#71
Maybe you want to set the error_reporting level somewhere centrally to avoid this problem happening to others and also to avoid having to explain all the notices.
Hmm, I thought I did.  Maybe I just did that in my own php.ini or something.  Anyway, thanks for the comment.  I'll add this in a future push.
donator
Activity: 2772
Merit: 1019
May 10, 2011, 05:34:13 PM
#70
hey cdhowie,

great proxy, just checking it out.

Had problems with the php notices spamming the pages to the point where chrome refused to render them (they get inserted before DOCTYPE decl):

Example:
Code:


Notice:  Undefined variable: viewdata in /var/www/localhost/htdocs/bmproxy/admin/pool.php on line 55



   
...

I simply put
Code:
error_reporting(E_ERROR);
in my config.inc.php, that fixed the issue nicely.

Maybe you want to set the error_reporting level somewhere centrally to avoid this problem happening to others and also to avoid having to explain all the notices.
full member
Activity: 182
Merit: 107
May 10, 2011, 11:30:38 AM
#69
Great, it works for me too, just had to change the URL in my scripts. I think using such an API to run cronjobs against is more useful than having it crammed into the web interface.
Yup, that's why it's there.  Smiley  Not all of the pages have proper JSON support implemented, simply because for most of them it wouldn't be terribly useful.  But at some point, the proxy should allow full manipulation of the database objects via JSON, allowing you to code an alternative interface (like a desktop app) against the JSON API.  That probably wouldn't be a good thing to do, but it would at least be possible.

I guess I can drop the stats branch then, since it already works out of the box from your dashboard. On the worker-hashing branch I made the average interval configurable because it strongly depends on the hashing speed (high hashing speeds can get a more accurate reading with shorter intervals, while slow miners will have the average jump wildly around for small values). I think it is ready to be pulled. Once again sorry for all the noise I created in here ^^
Alright, I'll have a look at it at some point later.  Thanks for the patch!
hero member
Activity: 489
Merit: 505
May 10, 2011, 11:21:56 AM
#68
Being a stats junky I'm working on a simple page that dumps the data in the dashboard to JSON so that I can then write a munin plugin to monitor the status of my miners, I guess we could use that one with a cronjob to kick off custom scripts. It would make it much easier and more flexible since the web server user is usually quite constrained in what he can do ^^
There is support in the MVC framework for JSON output.  The dashboard view page already implements IJsonView so try visiting /admin/?format=json.  This works for me.
Great, it works for me too, just had to change the URL in my scripts. I think using such an API to run cronjobs against is more useful than having it crammed into the web interface.

BTW: htdocs/index.php@71 is throwing a lot of errors since in getwork requests the lpurl parameter is not set, and since we already check 2 lines below and then set $lpurl again it is redundant and should be removed ^^
You're right, I'm not sure why that's there.  That being said, PHP is a whiny little bitch and it likes to complain about things that aren't problems.  Wink
Agreed Cheesy

Edit: My first attempt on a JSON stats dump is here: https://github.com/cdecker/Bitcoin-mining-proxy/commit/82f8ad9e352352cdbe81d84a8939b817204cb59d

Edit2: hope you didn't yet look at the stats and the worker-hashing branch because I was missing two GROUP BYs in the shares subquery which resulted in the hashing rate of all miners to be reported on a single miner instead of distinguishing. I fixed it in the branches ^^
I haven't looked at it in-depth yet.  Let me know when you are done with it and have tested it and I'll review the pull request.
I guess I can drop the stats branch then, since it already works out of the box from your dashboard. On the worker-hashing branch I made the average interval configurable because it strongly depends on the hashing speed (high hashing speeds can get a more accurate reading with shorter intervals, while slow miners will have the average jump wildly around for small values). I think it is ready to be pulled. Once again sorry for all the noise I created in here ^^
full member
Activity: 182
Merit: 107
May 10, 2011, 09:29:05 AM
#67
Being a stats junky I'm working on a simple page that dumps the data in the dashboard to JSON so that I can then write a munin plugin to monitor the status of my miners, I guess we could use that one with a cronjob to kick off custom scripts. It would make it much easier and more flexible since the web server user is usually quite constrained in what he can do ^^
There is support in the MVC framework for JSON output.  The dashboard view page already implements IJsonView so try visiting /admin/?format=json.  This works for me.

BTW: htdocs/index.php@71 is throwing a lot of errors since in getwork requests the lpurl parameter is not set, and since we already check 2 lines below and then set $lpurl again it is redundant and should be removed ^^
You're right, I'm not sure why that's there.  That being said, PHP is a whiny little bitch and it likes to complain about things that aren't problems.  Wink

Edit: My first attempt on a JSON stats dump is here: https://github.com/cdecker/Bitcoin-mining-proxy/commit/82f8ad9e352352cdbe81d84a8939b817204cb59d

Edit2: hope you didn't yet look at the stats and the worker-hashing branch because I was missing two GROUP BYs in the shares subquery which resulted in the hashing rate of all miners to be reported on a single miner instead of distinguishing. I fixed it in the branches ^^
I haven't looked at it in-depth yet.  Let me know when you are done with it and have tested it and I'll review the pull request.
full member
Activity: 182
Merit: 107
May 10, 2011, 09:25:02 AM
#66
Correct.  One could specify a shell script in the database, and perhaps two other user-defined arguments which would be called like:

`$script $minerip $timedelta $userdefinedarg1 $userdefinedarg2`

And would hopefully cause the script to send me an email letting me know that miner 1.2.3.4 has been down for 300 seconds.
I'm not sure I could include the IP since that's not logged anywhere.  But I could include the worker's database ID as well as the worker name.

Or the script could be a field in the database for workers, i.e. if the miner is a Windows box you might want a simple email, but if it's Linux, you might want to execute a different script that runs 'expect' and attempts to restart the miner by logging in via ssh and giving it a kick.  For that matter, the other two could be database arguments, but if it's too difficult to be practical from a programmatical standpoint, no worries.
To keep database schema changes to a minimum, I'm not sure if I would want to do this.  But if I pass the worker's ID to the script, you could have your script look at the ID and figure out what to do.

Useful indeed, if only I could make it function as flawlessly in my environment as it does in yours.  So as I mentioned, Phoenix 1.2 prints periodic "disconnected" messages.  Phoenix 1.45 seems to sporadically connect to the long-polling URL.  Phoenix 1.2 will connect, but it disconnects after a period of time.  I think I see why.  I hit my local mining proxy and fetched the long polling URL.  The first time it worked, and actually sent me info on a new block.  But the next time I tried it, I encountered a problem that almost surely explains what I'm seeing in Phoenix:

...

Based on the 3 or 4 times I've done this, it seems to happen when there is in fact a new block.  This should be easily duplicable for you.  If not, I can PM you the info on my proxy and let you see for yourself.  Hope that helps.
Hmm.  This capture is helpful, but without seeing the long-polling request and response that the proxy itself sends out, I can't really say why it's doing this.  It is possible that deepbit itself is returning an error from the long-polling request and I'm just forwarding it on to the worker.
hero member
Activity: 489
Merit: 505
May 10, 2011, 07:02:58 AM
#65
Just wanted to update this to let you know that Phoenix 1.2 (version I've run for the last couple weeks) seemed to exhibit the problem, while version 1.45 has not yet exhibited the problem during several hours of testing.  I'm going to let this thing run for several more hours, then switch over a few more miners to the proxy and see how it goes.
Cool, keep me posted on that.

1) Can you add in code (maybe configured by config.inc.php) to adjust the timestamp according to a user-defined timezone?  I've become accustomed to looking at UTC and knowing the offset, but still would be a nice thing to have.
Sure!  I planned to do this at one point but forgot about it later.  Thanks for reminding me.

2) The purpose of my push for your software, and what makes it valuable to me, is being able to know if a miner stops pulling and submitting shares (in addition to all of the wonderful features you've coded in so far).  Is this a feature you plan to add in the future, i.e. with simply listing all of the miners in red/green status like deepbit does, and having the option to act on it somehow, like with a shell script?
Yeah, this is probably something that could be done.  The red display is pretty easy to do; the shell script will require DB schema changes and a bit more work, but will still be possible.  I assume this would be used to, for example, email you if one of the miners stops requesting work?

I could define three new configuration options: one for the amount of time a miner must have not requested work for it to display differently, one for the amount of time a miner must have not requested work for the script to be run, and one for the script to run.
Being a stats junky I'm working on a simple page that dumps the data in the dashboard to JSON so that I can then write a munin plugin to monitor the status of my miners, I guess we could use that one with a cronjob to kick off custom scripts. It would make it much easier and more flexible since the web server user is usually quite constrained in what he can do ^^

BTW: htdocs/index.php@71 is throwing a lot of errors since in getwork requests the lpurl parameter is not set, and since we already check 2 lines below and then set $lpurl again it is redundant and should be removed ^^

Edit: My first attempt on a JSON stats dump is here: https://github.com/cdecker/Bitcoin-mining-proxy/commit/82f8ad9e352352cdbe81d84a8939b817204cb59d

Edit2: hope you didn't yet look at the stats and the worker-hashing branch because I was missing two GROUP BYs in the shares subquery which resulted in the hashing rate of all miners to be reported on a single miner instead of distinguishing. I fixed it in the branches ^^
full member
Activity: 125
Merit: 100
May 10, 2011, 01:19:10 AM
#64
Yeah, this is probably something that could be done.  The red display is pretty easy to do; the shell script will require DB schema changes and a bit more work, but will still be possible.  I assume this would be used to, for example, email you if one of the miners stops requesting work?

Correct.  One could specify a shell script in the database, and perhaps two other user-defined arguments which would be called like:

`$script $minerip $timedelta $userdefinedarg1 $userdefinedarg2`

And would hopefully cause the script to send me an email letting me know that miner 1.2.3.4 has been down for 300 seconds.

Thanks again for all of your hard work!
No problem!  I'm glad you find the software useful.  Smiley
[/quote]

Useful indeed, if only I could make it function as flawlessly in my environment as it does in yours.  So as I mentioned, Phoenix 1.2 prints periodic "disconnected" messages.  Phoenix 1.45 seems to sporadically connect to the long-polling URL.  Phoenix 1.2 will connect, but it disconnects after a period of time.  I think I see why.  I hit my local mining proxy and fetched the long polling URL.  The first time it worked, and actually sent me info on a new block.  But the next time I tried it, I encountered a problem that almost surely explains what I'm seeing in Phoenix:

GET /index.php?lpurl=http%3A%2F%2Fdeepbit.net%3A8332%2FlistenChannel&pool=1 HTTP/1.1
Connection: close
Host: bitproxy.xxxxx.com
Authorization: Basic xxx
User-Agent: phoenix/v1.2


(((2 minutes elapse, and then...)))


HTTP/1.1 200 OK
Date: Tue, 10 May 2011 06:00:12 GMT
Server: Apache/2.2.3 (CentOS)
X-Powered-By: PHP/5.1.6
X-Source-Code: https://github.com/cdhowie/Bitcoin-mining-proxy
Set-Cookie: PHPSESSID=4j2r53dsse5afoa5u9k3oratn0; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Length: 78
Connection: close
Content-Type: application/json-rpc

{"error":"Invalid response from long-poll request.","result":null,"id":"json"}Connection closed by foreign host.


Based on the 3 or 4 times I've done this, it seems to happen when there is in fact a new block.  This should be easily duplicable for you.  If not, I can PM you the info on my proxy and let you see for yourself.  Hope that helps.
full member
Activity: 182
Merit: 107
May 09, 2011, 10:19:09 PM
#63
Just wanted to update this to let you know that Phoenix 1.2 (version I've run for the last couple weeks) seemed to exhibit the problem, while version 1.45 has not yet exhibited the problem during several hours of testing.  I'm going to let this thing run for several more hours, then switch over a few more miners to the proxy and see how it goes.
Cool, keep me posted on that.

1) Can you add in code (maybe configured by config.inc.php) to adjust the timestamp according to a user-defined timezone?  I've become accustomed to looking at UTC and knowing the offset, but still would be a nice thing to have.
Sure!  I planned to do this at one point but forgot about it later.  Thanks for reminding me.

2) The purpose of my push for your software, and what makes it valuable to me, is being able to know if a miner stops pulling and submitting shares (in addition to all of the wonderful features you've coded in so far).  Is this a feature you plan to add in the future, i.e. with simply listing all of the miners in red/green status like deepbit does, and having the option to act on it somehow, like with a shell script?
Yeah, this is probably something that could be done.  The red display is pretty easy to do; the shell script will require DB schema changes and a bit more work, but will still be possible.  I assume this would be used to, for example, email you if one of the miners stops requesting work?

I could define three new configuration options: one for the amount of time a miner must have not requested work for it to display differently, one for the amount of time a miner must have not requested work for the script to be run, and one for the script to run.

Thanks again for all of your hard work!
No problem!  I'm glad you find the software useful.  Smiley
full member
Activity: 125
Merit: 100
May 09, 2011, 06:34:38 PM
#62
Just wanted to update this to let you know that Phoenix 1.2 (version I've run for the last couple weeks) seemed to exhibit the problem, while version 1.45 has not yet exhibited the problem during several hours of testing.  I'm going to let this thing run for several more hours, then switch over a few more miners to the proxy and see how it goes.

Two additional feature requests:

1) Can you add in code (maybe configured by config.inc.php) to adjust the timestamp according to a user-defined timezone?  I've become accustomed to looking at UTC and knowing the offset, but still would be a nice thing to have.

2) The purpose of my push for your software, and what makes it valuable to me, is being able to know if a miner stops pulling and submitting shares (in addition to all of the wonderful features you've coded in so far).  Is this a feature you plan to add in the future, i.e. with simply listing all of the miners in red/green status like deepbit does, and having the option to act on it somehow, like with a shell script?

Thanks again for all of your hard work!
full member
Activity: 182
Merit: 107
May 09, 2011, 12:56:57 PM
#61
Ok further to my issue, I captured one of those sessions per below:
If I'm reading this right, the miner is actually closing the long-polling connection of its own accord, mid-stream.  What miner are you using?  Perhaps I can reproduce the issue locally.
full member
Activity: 125
Merit: 100
May 09, 2011, 12:50:16 PM
#60
Ok further to my issue, I captured one of those sessions per below:

Code:
13:43:46.455793 IP xxx.113.52046 > xxx.170.http: S 744407596:744407596(0) win 8192
E..4.^@.~.ewD..qD....N.P,^.,...... .    ...............
13:43:46.455904 IP xxx.170.http > xxx.113.52046: S 3067826941:3067826941(0) ack 744407597 win 5840
E..4..@[email protected].,^.-....    B..............
13:43:46.456045 IP xxx.113.52046 > xxx.170.http: . ack 1 win 16425
E..(._@.~.e.D..qD....N.P,^.-..R.P.@) ...
13:43:46.456723 IP xxx.113.52046 > xxx.170.http: P 1:489(488) ack 1 win 16425
E....`@.~.c.D..qD....N.P,^.-..R.P.@)....POST / HTTP/1.1
Connection: close
Content-Length: 302
Host: bitproxy.xxxxx.com
Content-Type: application/json
Authorization: Basic xxx
User-Agent: phoenix/v1.2

{"method": "getwork", "params": ["00000001bc66976a156c69045f8108574a73efd268ee2faed010d66f00000672000000003d9dd833b0ac46504204b3be7b9dfa2ce1295409970ac51eab2b8e0ed66d12b34dc827ba1b0098fa02ec2550000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"], "id": 1}
13:43:46.456743 IP xxx.170.http > xxx.113.52046: . ack 489 win 432
E..(W.@[email protected].,^..P...]I..
13:43:46.956705 IP xxx.170.http > xxx.113.52046: P 1:484(483) ack 489 win 432
E...W.@[email protected].,^..P.......HTTP/1.1 200 OK
Date: Mon, 09 May 2011 17:43:46 GMT
Server: Apache/2.2.3 (CentOS)
X-Powered-By: PHP/5.1.6
X-Source-Code: https://github.com/cdhowie/Bitcoin-mining-proxy
Set-Cookie: PHPSESSID=badcm71qo331pfnu8b9420med3; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Length: 37
Connection: close
Content-Type: application/json-rpc

{"result":true,"error":null,"id":"1"}
13:43:46.956767 IP xxx.170.http > xxx.113.52046: F 484:484(0) ack 489 win 432
E..(W.@[email protected].,^..P...[e..
13:43:46.956948 IP xxx.113.52046 > xxx.170.http: . ack 485 win 16304
E..(.c@.~.e~D..qD....N.P,^....T.P.?..e..
13:43:47.330166 IP xxx.113.52046 > xxx.170.http: F 489:489(0) ack 485 win 16304
E..(.e@.~.e|D..qD....N.P,^....T.P.?..d..
13:43:47.330189 IP xxx.170.http > xxx.113.52046: . ack 490 win 432
E..(W.@[email protected].,^..P...[d..
13:43:55.614063 IP xxx.113.52047 > xxx.170.http: S 3321044043:3321044043(0) win 8192
E..4..@.~.eSD..qD....O.P...K...... ..I..............
13:43:55.614082 IP xxx.170.http > xxx.113.52047: S 3074415693:3074415693(0) ack 3321044044 win 5840
E..4..@[email protected].?.M...L....................
13:43:55.614375 IP xxx.113.52047 > xxx.170.http: . ack 1 win 16425
E..(..@.~.e^D..qD....O.P...L.?.NP.@).N..
13:43:55.615008 IP xxx.113.52047 > xxx.170.http: P 1:230(229) ack 1 win 16425
..@.~.dxD..qD....O.P...L.?.NP.@).I..POST / HTTP/1.1
Connection: close
Content-Length: 44
Host: bitproxy.xxxxx.com
Content-Type: application/json
Authorization: Basic xxx
User-Agent: phoenix/v1.2

{"method": "getwork", "params": [], "id": 1}
13:43:55.615027 IP xxx.170.http > xxx.113.52047: . ack 230 win 432
E..(.f@[email protected].?.N...1P.......
13:43:56.104782 IP xxx.170.http > xxx.113.52047: P 1:1133(1132) ack 230 win 432
D...D..q.P.O.?.N...1P....u..HTTP/1.1 200 OK
Date: Mon, 09 May 2011 17:43:55 GMT
Server: Apache/2.2.3 (CentOS)
X-Powered-By: PHP/5.1.6
X-Source-Code: https://github.com/cdhowie/Bitcoin-mining-proxy
Set-Cookie: PHPSESSID=qt55pon5dn780ipddvv5b5b6i3; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
X-Long-Polling: /index.php?lpurl=http%3A%2F%2Fdeepbit.net%3A8332%2FlistenChannel&pool=1
Content-Length: 596
Connection: close
Content-Type: application/json-rpc

{"error":null,"result":{"midstate":"dfbbd14c8d2c37fbcc47bc795c40fe6c8785fe34516942c390fd3fc51ad5eda5","data":"00000001bc66976a156c69045f8108574a73efd268ee2faed010d66f0000067200000000684f3b8dea52cfbfb263679b2f60b4852a54003f9a515ba1fd86c967ea4c79c54dc827d61b0098fa00000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000","hash1":"00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000","target":"ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000"},"id":"json"}
13:43:56.104936 IP xxx.170.http > xxx.113.52047: F 1133:1133(0) ack 230 win 432
E..(.h@[email protected].?.....1P....u..
13:43:56.105108 IP xxx.113.52047 > xxx.170.http: . ack 1134 win 16142
E..(..@.~.e\D..qD....O.P...1.?..P.?.....
13:43:56.487939 IP xxx.113.52047 > xxx.170.http: F 230:230(0) ack 1134 win 16142
E..(..@.~.eZD..qD....O.P...1.?..P.?.....
13:43:56.487966 IP xxx.170.http > xxx.113.52047: . ack 231 win 432
E..(.i@[email protected].?.....2P....t..
13:43:59.944022 IP xxx.170.http > xxx.113.52026: P 2946665288:2946665812(524) ack 1221764226 win 432
E..4*\@[email protected].:...HH...P.......HTTP/1.1 200 OK
Date: Mon, 09 May 2011 17:42:03 GMT
Server: Apache/2.2.3 (CentOS)
X-Powered-By: PHP/5.1.6
X-Source-Code: https://github.com/cdhowie/Bitcoin-mining-proxy
Set-Cookie: PHPSESSID=dtmsljts7gfebhij4jhkt76e75; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Length: 78
Connection: close
Content-Type: application/json-rpc

{"error":"Invalid response from long-poll request.","result":null,"id":"json"}
13:43:59.944091 IP xxx.170.http > xxx.113.52026: F 524:524(0) ack 1 win 432
E..(*]@[email protected].:...TH...P...-^..
13:43:59.944370 IP xxx.113.52026 > xxx.170.http: . ack 525 win 16294
E..(..@.~.eND..qD....:.PH......UP.?..g..
13:43:59.981456 IP xxx.113.52026 > xxx.170.http: F 1:1(0) ack 525 win 16294
E..(..@.~.eMD..qD....:.PH......UP.?..f..
13:43:59.981474 IP xxx.170.http > xxx.113.52026: . ack 2 win 432
E..(*^@[email protected].:...UH...P...-]..
13:44:00.417881 IP xxx.113.52048 > xxx.170.http: S 387224838:387224838(0) win 8192
E..4..@.~.e4D..qD....P.P.......... .Ll..............
13:44:00.417910 IP xxx.170.http > xxx.113.52048: S 3089436255:3089436255(0) ack 387224839 win 5840
E..4..@[email protected].%._........................
13:44:00.418212 IP xxx.113.52048 > xxx.170.http: . ack 1 win 16425
E..(..@.~.e?D..qD....P.P.....%.`P.@).z..
13:44:00.418829 IP xxx.113.52048 > xxx.170.http: P 1:230(229) ack 1 win 16425
..@.~.dYD..qD....P.P.....%.`P.@).u..POST / HTTP/1.1
Connection: close
Content-Length: 44
Host: bitproxy.xxxxx.com
Content-Type: application/json
Authorization: Basic xxx
User-Agent: phoenix/v1.2

{"method": "getwork", "params": [], "id": 1}
13:44:00.418849 IP xxx.170.http > xxx.113.52048: . ack 230 win 432
E..(..@.@..)D...D..q.P.P.%.`....P.......
13:44:00.948140 IP xxx.170.http > xxx.113.52048: P 1:1133(1132) ack 230 win 432
E.....@[email protected].%.`....P....u..HTTP/1.1 200 OK
Date: Mon, 09 May 2011 17:44:00 GMT
Server: Apache/2.2.3 (CentOS)
X-Powered-By: PHP/5.1.6
X-Source-Code: https://github.com/cdhowie/Bitcoin-mining-proxy
Set-Cookie: PHPSESSID=63481nkntcud9f6m4pagb9b1t7; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
X-Long-Polling: /index.php?lpurl=http%3A%2F%2Fdeepbit.net%3A8332%2FlistenChannel&pool=1
Content-Length: 596
Connection: close
Content-Type: application/json-rpc

{"error":null,"result":{"midstate":"b182bf7d65f2d20ac82d0d4b565784c2068e9d74540395d99371d401a3771bd3","data":"000000010bf5756fc40209bedd2d96da3a11c0c58e17ead100c5b17f000092cc000000008580d382a53b5854437590690a3931aef8099d83a94942bf6394ac2fc7a09a9b4dc827de1b0098fa00000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000","hash1":"00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000","target":"ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000"},"id":"json"}
13:44:00.948266 IP xxx.170.http > xxx.113.52048: F 1133:1133(0) ack 230 win 432
E..(..@.@..'D...D..q.P.P.%......P.......
13:44:00.948593 IP xxx.113.52048 > xxx.170.http: . ack 1134 win 16142
E..(..@.~.e=D..qD....P.P.....%..P.?..C..
13:44:01.297377 IP xxx.113.52048 > xxx.170.http: F 230:230(0) ack 1134 win 16142
E..(..@.~.e;D..qD....P.P.....%..P.?..B..
13:44:01.297402 IP xxx.170.http > xxx.113.52048: . ack 231 win 432
E..(..@.@..&D...D..q.P.P.%......P.......
13:44:01.734129 IP xxx.113.52049 > xxx.170.http: S 3138450324:3138450324(0) win 8192
E..4..@.~.e D..qD....Q.P.......... .I...............
13:44:01.734154 IP xxx.170.http > xxx.113.52049: S 3082134796:3082134796(0) ack 3138450325 win 5840
E..4..@[email protected].............:..............
13:44:01.734452 IP xxx.113.52049 > xxx.170.http: . ack 1 win 16425
...)..@.~.e+D..qD....Q.P.......
13:44:01.734985 IP xxx.113.52049 > xxx.170.http: P 1:203(202) ack 1 win 16425
P.@)....GET /index.php?lpurl=http%3A%2F%2Fdeepbit.net%3A8332%2FlistenChannel&pool=1 HTTP/1.1
Connection: close
Host: bitproxy.xxxxx.com
Authorization: Basic xxx
User-Agent: phoenix/v1.2


13:44:01.734999 IP xxx.170.http > xxx.113.52049: . ack 203 win 432
..._P...K`..D...D..q.P.Q...
13:44:02.170888 IP xxx.113.52050 > xxx.170.http: S 2138553343:2138553343(0) win 8192
...............qD....R.P.w........ ..
13:44:02.170915 IP xxx.170.http > xxx.113.52050: S 3093645464:3093645464(0) ack 2138553344 win 5840
E..4..@[email protected].......,..............
13:44:02.171211 IP xxx.113.52050 > xxx.170.http: . ack 1 win 16425
E..(..@.~.e'D..qD....R.P.w...eH.P.@)....
13:44:02.171933 IP xxx.113.52050 > xxx.170.http: P 1:230(229) ack 1 win 16425
..@.~.dAD..qD....R.P.w...eH.P.@)....POST / HTTP/1.1
Connection: close
Content-Length: 44
Host: bitproxy.xxxxx.com
Content-Type: application/json
Authorization: Basic xxx
User-Agent: phoenix/v1.2

{"method": "getwork", "params": [], "id": 1}
13:44:02.171954 IP xxx.170.http > xxx.113.52050: . ack 230 win 432
E..(\.@[email protected]..
13:44:02.670896 IP xxx.170.http > xxx.113.52050: P 1:1133(1132) ack 230 win 432
E...\.@[email protected]^D...D..q.P.R.eH..w..P....u..HTTP/1.1 200 OK
Date: Mon, 09 May 2011 17:44:02 GMT
Server: Apache/2.2.3 (CentOS)
X-Powered-By: PHP/5.1.6
X-Source-Code: https://github.com/cdhowie/Bitcoin-mining-proxy
Set-Cookie: PHPSESSID=m3et5o4vie44qhibp48aol5ge0; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
X-Long-Polling: /index.php?lpurl=http%3A%2F%2Fdeepbit.net%3A8332%2FlistenChannel&pool=1
Content-Length: 596
Connection: close
Content-Type: application/json-rpc

{"error":null,"result":{"midstate":"50c28d3c275afafd87eed724bd0d5b1847e9dbdda7e79e12ed0e6418ff49766f","data":"000000010bf5756fc40209bedd2d96da3a11c0c58e17ead100c5b17f000092cc00000000cb9cc4fb77da766429a30281b126ccec2aa1e6675f45a1067d56ff2c3bf1be654dc827de1b0098fa00000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000","hash1":"00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000","target":"ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000"},"id":"json"}
13:44:02.671014 IP xxx.170.http > xxx.113.52050: F 1133:1133(0) ack 230 win 432
E..(\.@[email protected].......
13:44:02.671333 IP xxx.113.52050 > xxx.170.http: . ack 1134 win 16142
E..(..@.~.e.D..qD....R.P.w...eM.P.?..k..
13:44:03.047103 IP xxx.113.52050 > xxx.170.http: F 230:230(0) ack 1134 win 16142
E..(..@.~.e.D..qD....R.P.w...eM.P.?..j..
13:44:03.047124 IP xxx.170.http > xxx.113.52050: . ack 231 win 432
E..(\.@[email protected].......
13:44:03.483509 IP xxx.113.52049 > xxx.170.http: F 203:203(0) ack 1 win 16425
P.@)....~.e     D..qD....Q.P..._...
13:44:03.520512 IP xxx.170.http > xxx.113.52049: . ack 204 win 432
...`P...K_..D...D..q.P.Q...

This is mid-stream, i.e. I let the miner run for maybe 2 minutes, then turned on the sniffer when I thought it would throw the error, so it sent in maybe 2 or 3 successful shares, then the miner threw a disconnection error per below:

[09/05/2011 13:43:22] Result: f780500d accepted
[09/05/2011 13:43:53] Result: 98a41184 accepted
[09/05/2011 13:44:06] Disconnected from server
[09/05/2011 13:44:07] Connected to server

The capture looks completely normal to me, based on my (very lay) knowledge of the protocol. 
full member
Activity: 182
Merit: 107
May 09, 2011, 10:59:08 AM
#59
In your Install file you say:
2.  Create a MySQL user for the proxy, giving it the privileges SELECT, INSERT, UPDATE, DELETE, and LOCK TABLES on the proxy's database only.  (Optional, but recommended.)

Is it the same user than:

3.  Set the admin user and password.  This will be used when logging in to the web management console.
No.  The first is a user in the MySQL database; all of the workers as well as the admin account will cause the proxy to authenticate to the database server with these credentials.  The admin user is a separate set of credentials that you use to log in to the proxy management console.  You can pick whatever you want for the admin credentials, but the MySQL credentials must match a MySQL user.

and an other question is, when i connect on the "/" of my proxy, it ask me a login and password.
Is it the same than in the admin section ?
No.  When you use the "/admin" URI, it will ask for admin credentials.  When you use the "/" URI it will ask for worker credentials.
full member
Activity: 753
Merit: 100
May 09, 2011, 10:39:24 AM
#58
How to set up a "no admin ask password" to test it
I'm not sure what you mean.  Can you elaborate?


yes sorry....

In your Install file you say:
2.  Create a MySQL user for the proxy, giving it the privileges SELECT, INSERT, UPDATE, DELETE, and LOCK TABLES on the proxy's database only.  (Optional, but recommended.)

Is it the same user than:

3.  Set the admin user and password.  This will be used when logging in to the web management console.


and an other question is, when i connect on the "/" of my proxy, it ask me a login and password.
Is it the same than in the admin section ?

sorry for my bad english
Pages:
Jump to: