Topic: COMPLETED: Request for an RPC capable fork of cgminer (155 BTC pledged and paid) - page 6. (Read 19357 times)

Kano, thank you for all of your hard work on this feature.

Added another commit of the api-example.c that works in both windows and linux
https://github.com/kanoi/cgminer/commit/c33553d5a65556a4802bea6ec251e7aa80b809d5
and the downloads includes the windows binary api-example.exe

Made a few other changes not yet up in the git:
I've fixed the windows socket error messages and ended up making the api options a bit different again ...
This seems to be the easiest:
 --api-listen (boolean - default is off which means the api thread doesn't wait for connections, specifying it means to turn on the api socket)
 --api-network (boolean - default is off which means only 127.0.0.1 can connect it if is listening, specifying it means anything with netowrk access can connect to cgminer)

Added debug to be able to see what's happening with sends/recvs

Next change - I'll enhance the apiversion command (and just rename it to 'version')
It will return the api version and the cgminer version

Lastly I think I'll change all the field names to actual names - e.g. like for a GPU, instead of "R=0" it will say something like "Rejected=0"
That way everyone isn't trying to translate the codes, cgminer will do it correctly already (also the data quantity is quite small ...)

Lastly, I'll add an identifier to the [STATUS] section (as stated above) --api-description (defaults to "cgminer" or some such)
So if you specify --api-description "7990" it will return that at the bottom of every status section reply

Well nobody has reported it yet but me so it may be an issue w/ my system.  I am running Windows 7 Professional x64.  Unless someone else reports an issue I would chalk it up to a system specific bug.  I am leaving for my cruise tomorrow (woot) so I won't be able to do any more testing for a week.  I like what I see so far, seems very solid.  Once I manually enabled api-listen and set a port I haven't encountered any errors, bugs, or unexpected results.  No crashes or instability on the miner side either.


That works for me.  At this point it doesn't matter so much but IMHO it makes for a better design (and easier integration to the mainline) if a potential attack vector must be explicitly enabled.

Anyways can't wait to see what it looks like in a week.

OK, I'll put in permanent debug so it can be checked with the --debug option if ever needed (and needed now)

hmm maybe MS have done something strange about port numbers?
What Windows OS are you running on?
It really should just be 0-1024 is restricted but all the rest should work the same.
Since I use 4028 by default - could you try that with the config file and see if it is simply just the port number?
I don't know what DTServer is - but: http://tcp-udp-ports.com/port-4028.htm
(though a bit of googling found one app that uses the webcam on that port)

I've written the .c api interface example, works fine on linux but having trouble with it on windows ...
I'll sort that out tonight and also correct all the socket error message code on windows then too.

RPC off by default ... I guess I could do that by giving "--api-listen" 3 options: 'off' (default), 'network' or 'local'
(so without it, it defaults to 'off')
That sound OK - or got another preference?

So I never got it working under Windows even when on machine locally so it wasn't any weirdness w/ RDP.

Now I added the following to me config file.


And it works. Even when connecting to 127.0.0.1.

If I take this out (which if I am understanding this right should still work connecting from local machine) then I get nothing (same error messages).

One change I would recommend (to assist w/ integration into mainline) is to have RPC turned off by default.  Not sure how you want to handle that (RPC off, local connection only, remote connection) but I think it would be best to have RPC disabled until explicitly enabled.  Not a huge issue but something to think about.

Still I have no idea why I can't connect from the same machine without adding the above to my config.  Didn't have much time to experiment but it looks good.


Some RPC calls
[/code][/code]

Thanks very much for the sentiment. A few more people have donated, and some previous people have donated more since I made that comment. Indeed it was hundreds of hours as I spent the greater proportion of my time working on cgminer when I had 3 months off work.

Dear DeathAndTaxes,

Thanks for your clarification. I will start up a new thread for my project. And, like I said, anyone who believe the bounty is fulfilled just go ahead.

Dear kano,

Yeah, you deserve the bounty according to the clarification. I really hope that JSON RPC could be added to cgminer, so that any GUI could call cgminer in a uniform way. For now we have to parse different output from different miners, it's painful.

Yes 2.08w is what is running.

Not sure if the socket still exists but subsequent commands give the same error.

The error occurs on all commands.  Well I only tested a half dozen but the simplest apiversion also gets the error.

Before you rip your hair out I am accessing the windows box (both cgminer & api.class are on the same box) via remote desktop from my work workstation.  Let me check when I get home it may be some "weirdness" w/ RDP.

Yeah no rush.  Get some sleep.

Sigh - that's depressing
Maybe java on windows works differently on different versions of windows?

By default it listens on 127.0.0.1 (--api-listen means listen on 0.0.0.0)

But I'll state the obvious just in case ... cgminer should be saying 2.0.8w at the top of course.

What I've tried (and works fine for me):
php linux to linux miner
php linux to windows miner
java linux to linux miner
java linux to windows miner
java windows to windows miner
java windows to linux miner

So I have tried all combinations except php in windows.
My kids windows box is only WindowsXP Home (and it doesn't have php)

Maybe try to recompile the java? (javac API.java)
I 'compiled' the java on Linux FC12.

Googling I found comments of 'no idea' and 'possible networking problems'

Does the socket still exist? or has the socket thread crashed in cgminer?
(of course you can tell by simply trying again and see if it connects or not)

Which command did you send? Or is it all commands?

I'll write a little 'C' program tomorrow and compile it on windows also
so you can try that and see if it's windows or java
Also note if you run it with "--api-listen" you need to allow it in the firewall
(WindowsXP shows a popup to enable it in the firewall the first time you run it with --api-listen)
It's after 4am here so yeah I'm not gonna try writing any code this late

Ok I lied about not testing.
I dropped a copy into a windows development box at work.

Tried using API.class to connect to cgminer.


The RPC version is listening on 127.0.0.1 by default right? I shouldn't need to add anything to the config.

Firstly ... and just in case it isn't obvious ...
I'm not asking anyone to pay me the bounty now.
I just want feedback to ensure it is what's required or what needs changing.
Of course once it is what's required ... then yes I'll be chasing bounties

abracadabra, I'll respond to each of your points since I guess others may not
fully understand what it does and how it works.

However, some of your questions are due to not reading all my posts.
I have posted quite a bit so yes unfortunately you should read them all

Anyway ...

The point of an RPC interface is something you can access to get information from cgminer
Currently, you look at the screen and respond with keystrokes to what you see

I've added a socket interface that anyone can access with software and also given 2 sample
programs that do that - api-example.php and API.class (API.java)

How the interface works is you simply either just run cgminer as you always do,
or use one or two of the new options.
the new cgminer always has the RPC interface available but by default only listens
to commands sent from the same computer it is running on.
the --api-listen option changes that to allow any computer that has network access
to the miner computer to send it commands.

The point of the RPC interface is so that you can control cgminer via software instead
of only via the keyboard - thus as an example you could write a web page using php
that shows you the status of the miner and also has options to send it commands

e.g. the simple api-example.php shows the basic rules of how to do that and then you just
add your own web page design on top of that.

Yes as quoted by conman, there is a windows version to test it out

The return data is from the rig you are talking to.
If you would like, I could add another option to cgminer --api-description that would be returned in the status section of the return data.
But of course, that would require you to specify that when you run cgminer.
Another option is I could return the hostname  or some windows equivalent, however that is not always useful unless you gave the computer a useful name when you set it up.
The --api-description idea is a very simple change so if that solves your problem, just say you want that.

I updated that info later. Read past that post for the details of the 2 new cgminer options, however to explain the numbers:
It either listens on 127.0.0.1 or on 0.0.0.0
What 127.0.0.1 means is that it will only respond to a message sent from the mining computer to the address 127.0.0.1 - i.e. it is pretty secure.
What 0.0.0.0 means it will listen (and reply) to a message from any computer that has network access to it - i.e. this could be a security issue for some.
So the default is 127.0.0.1 (but --api-listen makes it the other)

ckolivas responded to that part of the post later.
I was simply verifying that what I thought was true was correct

I simply just run api-example.php at a termina/command prompt (or API.class)
So the last post where I posted all the output is what I see in my terminal excluding the reformatted data
(since it's the same data but just formatted neatly)
https://bitcointalksearch.org/topic/m.634588

Also, only 4 of the commands show anything on the cgminer screen:
cguenable|N, gpudisable|N, gpurestart|N, quit
The first 3 show as I said above in that link, and of course quit makes cgminer exit.

Wow reading comprehension fail on my part.  Thanks.

For those talking about the windows version, perhaps you missed this:

+1

Plus maybe some testing by users.  Testing doesn't need only be done by those who have pledged.  If you are interested in remote control cgminer, download it, use kano scripts to control it remotely and report back.

A long post but I wanted to wrap up a couple of different issues all at once.

Very rapid development:
I also wasn't expecting such a rapid development, it kinda caught me off guard.  Not that this is a bad thing just unexpected.

Clarification of the bounty:
As I indicated in the thread my bounty is for a fork of cgminer or integration into cgminer mainline.  While maybe I was unclear (if so I apologize) I have no need/desire for a wrapper in an alternate language.  My experience in project development tells me that will make forward compatibility tough and likely require never ending "mainteance bounties" to keep current.  Sorry lueo you front end looks nice and people will need front ends so hopefully the front end work isn't wasted and can be adapted.  This bounty is for the cgminer modification but I am sure other projects/bounties will be required for the remote control application.

Speaking for others:
I can't speak for all of those pledging funds on if a wrapper is compatible w/ the goals of the project.  I am assuming (possibly incorrectly) they feel the same as me. To anyone pledging a clarification on if a wrapper is acceptable to the terms of the project would be appreciated.

I will be out of the loop:
I am going on a cruise this Friday, need to pack, and am swamped at work wrapping up things before I am gone for a week.  I won't have time to test anything before I get back.  Sorry Kano just bad timing.  Everything you have shown looks good and on paper is exactly what I was looking for when I started the thread.  If what you have developed is as presented I don't see an issue w/ awarding the bounty but for me it won't be until Dec 11th at the earliest.

Windows support:
Since cgminer supports both Linux & Windows I think it is assumed that any code which qualifies for the bounty must work on both operating systems.  Personally I don't really care as my rigs are linux but others likely do and it would be "clunky" to have a portion which only compiles in Linux.  I feel the pain of anyone trying to get the code working in Windows but that is likely non-negotiable.
Note to self reading the entire thread helps.  kano already published a windows version.

In my absence:
To any of the others w/ pledges if anyone feels the work completed meets the requirements for the bounty then no need to wait for me to get back to award some/all funds.  I will award once I get back but my absence shouldn't be taken as putting things on hold.

Sockets vs. JSON:
 In the OP I indicated JSON was acceptable but not required.  As far as I know nobody indicated dissatisfaction w/ that requirement.   My personal position is still the same.  I have done extensive windows development work w/ sockets so that is a non-issue for me.  If anyone who has pledged funds feels otherwise please speak up now.  It is unfair for developers to labor under false constraints and waste time.  

Fork vs Mainline:
Since there is a "Bonus" of 25 BTC for integration into the mainline, if kano code is acceptable and ckolivas integrates it I think a fair split would be the main bounty to Kano and the "bonus" to ckolivas.  I will add another 5 BTC to the "bonus" portion.  Obviously it is up to each individual awarding but I think that is the best way to encourage mainline integration.  Hopefully this clears up some of the vagueness about "who" gets the bonus if integrated into the mainline.

To YOU reading right now who haven't pledged (my soap box):
It makes me embarrassed by how little ckolivas has been compensated for all his hard work.  
If this project is interesting to you then here is a chance to make it right.  Pledge 1, 2 or 5 BTC towards the mainline integration "bonus" portion.  I have written shareware poker apps which generated 5 figures in revenue.  It is beyond sad that such an amazing project (which likely has required hundreds of hours) is so under-compensated.  If you don't support developers then don't complain when projects stall and die.  Saying "great work" is one thing putting your money where your mouth is means a lot more.  


Conclusion:
Wow that was lot.  If you are paying for internet by the bit/byte well I am sorry.  
If anyone who has pledged has a disagreement with what I wrote please state so in the thread.  This isn't a dictatorship it is more like herding cats.  I can only speak for "my funds" and anything I say should be taken like that.

The future ....(will he ever shut up)
web developers & android developers ... obviously RPC miner will need some remote front ends to be useful.  I am already thinking of web front end & android app front ends which connect to cgminerRPC.  Obviously that would be a separate projects/bounties but I am willing to put some funds towards that too.  Nothing formal yet and it likely won't happen (unless started by someone else) until I get back but if you want a head start take a look at this thread and get thinking on how you would write your front end.

I thought that's what the majority of the bounty was for! 


I agree, but seeing the screenshots from lueu's project, makes me interested in what is going on there too 

By "multiple pools" I assume you mean when you have cgminer setup to have a backup pool? Not sure, since that's not a feature of cgminer I use.

+1

Kano, sorry haven't checked this thread recently, with Thanksgiving last week. Didn't realize someone was going to take this on so quickly (and cheaply  j/k)

Anyways.. see my comments inline below.. please forgive the newbishness of some of my questions..


The .php would be run locally?


Not sure if this should have been mentioned earlier, but I need a windows version and unfortuantely I can't build from scratch. 


Do the status strings differentiate the data returned as to which "rig" and which GPU on said "rig"? ie.  Is the name of the "rig" returned with the status string? Or we have to remember which one were were just talking to when we got the status return?


I'm assuming --api-port & --api-address is the port and address of the actual "rig" we are talking to? --api-access is the ip of the computer allowed to communicate with the rig?


I guess I don't get this.  I understand listening port, but what other ip would the "rig" running cgminer listen to other than it's own?


No idea what this means.


Do you have any screenshots of what frontend you have running for you right now?

Thanks!