PRPNet released!

[Mini-Geek]

Ok. I've run it from a command line instead. I'll let you know what happens.
I'll also include the PFGW version I'm using. (PFGW is the helper app being used for my current work)

[Mini-Geek]

Three of four instances (I started more clients than I have cores so that I'd minimize idle time) crashed at some point overnight. All three said "Could not file [work_local.save] for writing. Exiting program". One crashed between finishing the last candidate in the batch and reporting the work as complete, the other two crashed between finishing the getwork comm. and printing the server's greeting (i.e. they got work, the greeting, and finished the comm., then crashed before doing anything).
In case I wasn't clear enough, here are the last few lines for all three:

16616*24^34743-1 is composite: RES64: [C67472DE9730F9AE] (221.7809s+0.0006s)
[2009-11-23 06:12:11 GMT] local: 16616*24^34743-1 is not prime.  Residue C67472DE9730F9AE
Could not file [work_local.save] for writing.  Exiting program

[2009-11-23 09:28:10 GMT] sending on socket 340 [GETGREETING]
[2009-11-23 09:28:10 GMT] 12 bytes received
[2009-11-23 09:28:10 GMT] received on socket 340 [Hi, me!]
[2009-11-23 09:28:10 GMT] received on socket 340 [OK.]
[2009-11-23 09:28:10 GMT] sending on socket 340 [Client Disconnecting]
[2009-11-23 09:28:10 GMT] closing socket 340
Could not file [work_local.save] for writing.  Exiting program

[2009-11-23 07:23:03 GMT] sending on socket 504 [GETGREETING]
[2009-11-23 07:23:03 GMT] 8 bytes received
[2009-11-23 07:23:03 GMT] received on socket 504 [Hi, me!]
[2009-11-23 07:23:03 GMT] 4 bytes received
[2009-11-23 07:23:03 GMT] received on socket 504 [OK.]
[2009-11-23 07:23:03 GMT] sending on socket 504 [Client Disconnecting]
[2009-11-23 07:23:03 GMT] closing socket 504
Could not file [work_local.save] for writing.  Exiting program

PFGW Version 20090928.Win_Dev (Beta 'caveat utilitor') [GWNUM 25.13]

I'm not sure if it's possible to do so, (e.g. if the error message is coming from an outside source) but it'd be nice if it had logged that message at the end there instead of only posting it to the console output.

[rogue]

Originally Posted by Mini-Geek

Three of four instances (I started more clients than I have cores so that I'd minimize idle time) crashed at some point overnight. All three said "Could not file [work_local.save] for writing. Exiting program". One crashed between finishing the last candidate in the batch and reporting the work as complete, the other two crashed between finishing the getwork comm. and printing the server's greeting (i.e. they got work, the greeting, and finished the comm., then crashed before doing anything).

I'm not sure if it's possible to do so, (e.g. if the error message is coming from an outside source) but it'd be nice if it had logged that message at the end there instead of only posting it to the console output.

I want to make this clear, this is not a crash. The client is exiting because it cannot open the save file. This is code I wrote. Theoretically, I could just exit the routine if it cannot write the file, but that puts the client at risk of losing work if it is terminated due to any means. I could log the message, but I don't know if it would help much. If you can determine why it is unable to write the file, that would be helpful. I don't know if I can do much in code to give a specific reason for it's inability to open the file for writing.

[Mini-Geek]

Originally Posted by rogue

I want to make this clear, this is not a crash. The client is exiting because it cannot open the save file. This is code I wrote.

Right, right, sorry.
I can't think of what would make it so it couldn't write to the file...
Do you think it'd be useful to make it try writing to the file a few times after a short delay (e.g. after 5, 10, and 15 seconds)? Would that be very hard to implement?

[Mini-Geek]

What do you think about adding an option for whether to hand out, and sort in prpserver.candidates (could be 1 option for both hand-out and prpserver.candidates order, or two separate options) by your choice of BKCN or length (or the third sorting...I don't remember what it was ATM, but I recall seeing it when looking in the source) instead of being fixed to BKCN in prpserver.candidates and by length in being handed out? I think that'd be a handy option, making PRPnet more convenient for more types of work (e.g. the recent discussions in NPLB regarding getting the candidates file to sort by n and, separately, for it to hand out candidates by k).

[rogue]

Originally Posted by Mini-Geek

What do you think about adding an option for whether to hand out, and sort in prpserver.candidates (could be 1 option for both hand-out and prpserver.candidates order, or two separate options) by your choice of BKCN or length (or the third sorting...I don't remember what it was ATM, but I recall seeing it when looking in the source) instead of being fixed to BKCN in prpserver.candidates and by length in being handed out? I think that'd be a handy option, making PRPnet more convenient for more types of work (e.g. the recent discussions in NPLB regarding getting the candidates file to sort by n and, separately, for it to hand out candidates by k).

That shouldn't be too hard to do.

[mdettweiler]

Originally Posted by Mini-Geek

What do you think about adding an option for whether to hand out, and sort in prpserver.candidates (could be 1 option for both hand-out and prpserver.candidates order, or two separate options) by your choice of BKCN or length (or the third sorting...I don't remember what it was ATM, but I recall seeing it when looking in the source) instead of being fixed to BKCN in prpserver.candidates and by length in being handed out? I think that'd be a handy option, making PRPnet more convenient for more types of work (e.g. the recent discussions in NPLB regarding getting the candidates file to sort by n and, separately, for it to hand out candidates by k).

Seconded. For now we can just recompile the appropriate changes into the server, but yes, it would be handy to have a switch in prpserver.ini for it.

[Xentar]

Just tested version 2.4.6 and found a small bug:
I got an access violation in the client, when there is no value for pfgwexe= in the ini file, but PFGW should be used for the tests.

Edit:
Feature request: Is there a possibility, to add srsieve support? :) So the client can choose, whether to sieve or to LLR?
It's just an idea.

[rogue]

Originally Posted by Xentar

Just tested version 2.4.6 and found a small bug:
I got an access violation in the client, when there is no value for pfgwexe= in the ini file, but PFGW should be used for the tests.

Edit:
Feature request: Is there a possibility, to add srsieve support? :) So the client can choose, whether to sieve or to LLR?
It's just an idea.

Sorry, but that isn't on my radar. The main problem is that the server has no ability to validate factors without writing lots of new code in it. Removing candidates due to found factors is limited only to the admin tool.