GPU72's fetching/reporting API
 

I'm editing my gratuitous laughing at the prior two posts to put some actual stuff in here.

I've been thinking about this proxy and really, that's about the most brilliant thing I've seen so far on this forum. That proxy can be more than an attachment or feature of gpu72 and really be [I]the[/I] core mechanism of the entire site. To be able to send our requests for work - regardless of whether the source would be gpu72 or primenet, and have gpu return suitable work (if available) or pass the request on to primenet (as a proxy should) when gpu72 doesn't have the requested work is an exceptional solution. I'm guessing a lot of the way gpu72 works bould be built around that proxy if it's not already, including account registration, averages, end dates, etc. It's just really excellent, even if the format of the api is not everyone's favorite format.

I'm just really enthused by the concept, and so I'm going to spend some time considering how it could be best put to use. With luck, it will take me so long to do that that the proxy api will be complete before I get there.

[QUOTE=Aramis Wyler;334661]It's just really excellent, even if the format of the api is not everyone's favorite format.[/QUOTE]

I'm humbled you are so impressed with it. :smile:

For a bit of history, I had built the proxy years ago when I was the outside consultant for a large call centre here in Bim. With the permission of management, I had ~150 cores doing LHM TFing to monitor machine health, diagnose networking issues, etc.

When I saw Mr. P-1 manually coordinating GPU TFing with a half dozen or so others, I (foolishly) offered to create the system which eventually became GPU72. I [I]thought[/I] it would only take a week or so, but then serious feature creep set in...

Now, specifically about the proxy... One issue we have to deal with is the fact that the Primenet API uses a "Secret Hash" to "sign" all messages, the algorithm for which is (by definition) secret. This is (at least one reason) why mfakt(x) hasn't been able to talk directly to Primenet.

My (already implemented and working) solution is to have a "pre-shared secret" instead. This will be a simple MD5 generated for each GPU on the GPU72 site, and placed in the configuration file of my new (almost finished) Fetching Spider, and Scott's MISFIT. All messages must be signed with this (basically just md5sum(strcat([Message],[Shared_Secret])) to be accepted as valid.

This, however, won't be able to also work with Primenet unless and until it's API is expanded to use this alternate authentication methodology.

Further discussion on this is welcome. We can break this out into another thread if there's enough content generated.

(Ironically, the core code has been working for months. The hold up is I have to add some new functionality to the web UI in order to allow people to create new GPU "Machines" on the site, and get the "secret". "Life" (and a death in the family) got in the way, but things are beginning to calm down again....)

[QUOTE=chalsall;334668]...Further discussion on this is welcome. We can break this out into another thread if there's enough content generated.[/QUOTE]

Please do. I need to be in on this.

[QUOTE=swl551;334679]Please do. I need to be in on this.[/QUOTE]

Yeah, fire one up, Chris, assuming you're willing to take input on how people think about it's function. There will probably be some free flowing thought on that topic for a bit and that doesn't need to be in the status thread.

[QUOTE=Aramis Wyler;334680]Yeah, fire one up, Chris, assuming you're willing to take input on how people think about it's function. There will probably be some free flowing thought on that topic for a bit and that doesn't need to be in the status thread.[/QUOTE]

I'm always willing to accept ideas and feedback from smart people! :smile:

[QUOTE=chalsall;334683]I'm always willing to accept ideas and feedback from smart people! :smile:[/QUOTE]
I'll stay quiet!

[QUOTE=swl551;334684]I'll stay quiet![/QUOTE]

LOL... :smile:

You weren't who I was thinking of.... :wink:

Ok, I don't want to get too grand right off the bat here, but looking at the proxy work has crystalized some concepts in my mind here that were really on a more sub-concious level before.

Specifically, project gpu to 72 is a proxy for primenet.

'the proxy' is possibly but not necisarily functioning as a proxy to primenet's api. As near as I can tell, Challsall wrote it more to accept requests from prime95 as an alternative to (not a proxy for) primenet.

But at it's heart, the entire gpu to 72 project is abstractly and rather indirectly performing as a proxy to primenet. I think by recognizing this, we can simplyfy the functioning of gpu72.com and reduce maintenance by actually making it, on a technical and specific level, a proxy rather than an alternative or side project.

I've studied the primenet api. The gimps website already deals with every function gpu72 supports, including account creation and work tracking. By intercepting (and possibly altering) requests designed for primenet (not specifically designed for gpu72) a lot of things become possible or easier.

Before going into more detail and to keep this post from becoming even longer, I'm going to pause before I start posting details about account binding, trust levels, etc. But I see a gpu to 72 v3 coming.

So, let's begin:
One of the thing that troubles me about the primenet api is the lack of an authenticated user. (as far as I can tell)

Here are my thoughts on how the repository, application and user can interact over the API.

[B]APP IDENTIFICATION:[/B]
App builders, like myself, petition a repository master(chris) for an APP_ID_GUID which I statically build into each of my apps. Each app gets its own GUID. Unregistered apps would use {0000......} or a faux GUID (not assigned by the GUID authority). API endpoint would decide the policy for handling api calls with invalid/unknown APP_ID_GUIDS


[B]MACHINE IDENTIFICATION:[/B]
When someone installs my app on a PC[B] it[/B] generates a static GUID used to identify "this machine". By doing so this PC can be tracked independently of the user.

[B]USER AUTHENTICATION:[/B]
Users create accounts/passwords via public websites (gimps/gpu72) and configures applications to use those credentials. This user credential is passed to the repository for verification/authentication

______________________________________

Possible api payload values from above

APP_GUID:30ad5904-b818-4f26-aaa2-947b0863fa4f
MACHINE_GUID:6b2d76dd-0cd9-4249-9e05-14b87ec95bd7
USER_ID:SWL551
PASSWORD:abc123EFG
....... additional request specific values......

----------------------------------------------
If secrecy of the above items is of importance ensure the API endpoint is listening only on an SSL connection.


-----------------------------------------

I believe the benefit of this design is as follows.

The repository master ensures the calling application and the user requesting services is "valid". Putting the MACHINE_GUID in the hands of the application prevents the repository from having to pre-determine this value and simplifies the consumer interaction with the entire system.


Scott

Edit: This approach was not written with a "proxy" in mind. It may be meaningless in that context.

The Mission, should you choose to accept it...
 

I'd appreciate a restating of gpu72's mission statement, so that we're clear on that. Right now what I have is 'compress the curve(s)' and 'increase the factored bitdepth of candidates primenet releases'. I am proceeding as such, but it is always nice to have a formal and agreed apon mission statement.

Why we do what we do: we disagree with primenet's release algorithm in some regards. That is importamt to the (proxy style) train of thought I am working on, because the work requests/results/statements that we do agree with can simply be passed on for primenet to deal with.

So what don't we like, and/or what could we add? An example of something we don't like is the bitdepth release policy. An example of something we can add are the fabulous charts and graphs the gpu72 site provides. [B]We can affect some of these things w/o setting up an alternative project, but rather by intercepting some requests and returning results from our own cache.[/B] Gpu72 basically does this now, but the mindset of an alternative vs a cache is, I think, relevant.

An example of things we agree with primenet on may be it's tracking of ll and dc assignments. In this case, I say hell on that work in the gpu72 arena. Log the request, pass it to primenet, log the response (for reporting graphs) and pass it to the client. We don't need to handle that work to log it if we function as a pure proxy in that regard.

[QUOTE=swl551;334691][B]APP IDENTIFICATION:[/B]
App builders, like myself, petition a repository master(chris) for an APP_ID_GUID which I statically build into each of my apps. Each app gets its own GUID. Unregistered apps would use {0000......} or a faux GUID (not assigned by the GUID authority). API endpoint would decide the policy for handling api calls with invalid/unknown APP_ID_GUIDS[/QUOTE]

As described, it would be trivial for someone to spoof an app GUID (even if encrypted en route, it can be decrypted at the client end). If this is intended as a security mechanism, this is not a suitable one. If merely as a polite way to say what app is what, then it's fine.