PRPNet released!

[PCZ]

I loaded up 2.5 and it is behaving fine now.
Had double checking off but i guess something was wrong with the binary.
It was version 2.15 so quite a few versions old now.

Something might have gone amiss when building it as i had to make a few changes to get the email notification working with my SMTP server.

[rogue]

Originally Posted by PCZ

I loaded up 2.5 and it is behaving fine now.
Had double checking off but i guess something was wrong with the binary.
It was version 2.15 so quite a few versions old now.

Something might have gone amiss when building it as i had to make a few changes to get the email notification working with my SMTP server.

Can you send me your changes? I'm curious as to what is wrong with the code.

[rogue]

There are a number of small changes to the client and the server.

• server: Display count of primes by user on user_stats.html on pages where it was missing.
• server: Fixed an issue with Twin Prime servertype where it did not support certain ABC file formats.
• client: If PFGW fails with -a2, terminate the client.
• client: Pass idle flag to PFGW. If idle=0, then the client will pass -N to PFGW, making run in normal priority.
• client: Delete the temp output file from PFGW so that when re-run with -a1 or -a2 that it doesn't find it and get caught in a loop.
• client: Fixed an issue with Twim Prime searches as client would always do -1 test even when +1 test was composite.
• client: Removed frequency= option. The client will now complete all workunits before reporting to the server.

You can d/l it from here.

Enjoy,
Mark

[rogue]

This release has been pending for a month as I have been waiting for some independent testing from Max (many thanks to him).

There are significant changes to this release to address a number of problems and to provide a number of new features, such as genefer. Note that the 2.4.0 client can only be used with 2.4.0 servers. It will not work with older versions of the server, so you will need to verify that any servers you connect to are using 2.4.0 before upgrading the client. 2.3.0 clients can communicate with 2.4.0 servers as some backwards compatibility is necessary. That support will be removed in a future release.

For server administrators, please update the Greeting.txt file to tell users of the upgrade.

• server: When a client has established a new connection, send a message so that the client does not send any additional data until it receives that confirmation
• server: Return immediately if the test is not found. This addresses an issue where the server would log tests without residues. Send all responses for returned workunits in a single buffer to the client. This eliminates synchronization issues between the client and server.
• server: Send "Acknowledge" message for each returned workunit. If the server loses its connection to the client in the middle of processing, it will terminate the connection immediately. This should eliminate the appearance of the server "hanging" when that happens.
• server: Add additional debug information when expiring tests.
• server: Added support to search for Generalized Fermat Numbers (GFNs).
• client: The client will wait for the server to tell that it has a connection before returning work.
• client: Send all returned workunits in a single buffer to the server and then wait for the server to return its messages. This eliminates synchronization issues between the client and server. Look for "Acknowledge" message from server for each workunit before deleting the workunit.
• client: Tell server that the client has disconnected rather then using the generic "QUIT" message.
• client: This version no longer passes the -e argument to phrot. It presumes that users have upgraded to phrot 0.71.
• client: Added support for GFN servers (and genefer software).

You can d/l it from here.

This release might not be bug free, but it is very stable. There are a couple of other changes I wanted to get done, but they will have to wait for 2.4.1. This release is too significant to wait for those changes.

Enjoy,
Mark[/QUOTE]

[Mini-Geek]

Is there any particular reason it's missing the .exe's? I've built them from the included source without a problem, but they ought to be included.
How exactly would one give the client the three genefer exe file names? How does it know which is which?

[mdettweiler]

Originally Posted by Mini-Geek

Is there any particular reason it's missing the .exe's? I've built them from the included source without a problem, but they ought to be included.
How exactly would one give the client the three genefer exe file names? How does it know which is which?

The .exe's are actually in the "source" directory; Mark, did you forget to move those out of there before you zipped it up?

[mdettweiler]

Mark, I'm having some trouble compiling PRPnet 2.4.0 for Linux (using Cygwin's cross-compiler on Windows XP, which has worked for all previous versions). When I run "make" it errors out on something to do with the new genefer stuff:

g++-linux -c -g -Wall GeneferProgram.cpp
In file included from TestingProgram.h:12,
                 from GeneferProgram.h:5,
                 from GeneferProgram.cpp:1:
gfn.h:11:24: warning: no newline at end of file
GeneferProgram.cpp: In member function `uint32_t GeneferProgram::ValidateExe()
   ':
GeneferProgram.cpp:187: warning: comparison between signed and unsigned integer
   expressions
GeneferProgram.cpp:189: error: `tolower' undeclared (first use this function)
GeneferProgram.cpp:189: error: (Each undeclared identifier is reported only
   once for each function it appears in.)
make: *** [GeneferProgram.o] Error 1

I get a similar error when I try to compile a normal Cygwin binary (as opposed to a crosscompiled Linux binary). Additionally, running "make prpserver" works fine and produces a server binary, so it seems this is just a problem local to the client.

[mdettweiler]

BTW, one other thing that I noticed: the web interface now doesn't seem to work right. When I try to load it from a web browser, it just hangs, and the server doesn't say anything after "message coming in on socket 5"; then when I cut the connection by closing the browser tab or hitting "Stop", the server's debug log shows "error sending [s] to insert line from HTML file here" for every single line in the HTML file it was supposed to send.

Edit: Come to think of it, I didn't think to test the web interface during my alpha testing of 2.4.0. It's possible this isn't new to this latest build.

[Mini-Geek]

Originally Posted by mdettweiler

BTW, one other thing that I noticed: the web interface now doesn't seem to work right. When I try to load it from a web browser, it just hangs, and the server doesn't say anything after "message coming in on socket 5"; then when I cut the connection by closing the browser tab or hitting "Stop", the server's debug log shows "error sending [s] to insert line from HTML file here" for every single line in the HTML file it was supposed to send.

Edit: Come to think of it, I didn't think to test the web interface during my alpha testing of 2.4.0. It's possible this isn't new to this latest build.

It's not quite working for me either, but with very different results:
PRPnet reports no errors.
In Firefox, Chrome, and Opera it does not display at all (loads almost instantly with a blank page/source).
In IE it all works as expected.
p.s. I just had an idea for finally getting the favicon to work: base64 encoding. I'll try it out and edit with the results...

[mdettweiler]

Originally Posted by Mini-Geek

It's not quite working for me either, but with very different results:
PRPnet reports no errors.
In Firefox, Chrome, and Opera it does not display at all (loads almost instantly with a blank page/source).
In IE it all works as expected.
p.s. I just had an idea for finally getting the favicon to work: base64 encoding. I'll try it out and edit with the results...

Actually, I was using IE for it--IE 8, to be exact. Which version were you using?

Oh, and PRPnet won't report anything unless you have debug logging turned on. Normally it doesn't say anything about web traffic (even errors).

[Mini-Geek]

Originally Posted by Mini-Geek

p.s. I just had an idea for finally getting the favicon to work: base64 encoding. I'll try it out and edit with the results...

Success! To get the favicon to work (at least in everything except IE...I read that it should work in IE8, but in my tests it doesn't work), add this to the code (in HTMLOutput.cpp) for user_stats.html and server_stats.html, such that it will appear somewhere in the <head> section of the HTML:

theSocket->Send("<link rel=\"icon\" type=\"image\/ico\" href=\"data:image\/ico;base64,AAABAAEAEBAQAAAABAAoAQAAFgAAACgAAAAQAAAAIAAAAAEABAAAAAAAgAAAAAAAAAAAAAAAEAAAABAAAAAAAAAAAACAAACAAAAAgIAAgAAAAIAAgACAgAAAgICAAMDAwAAAAP8AAP8AAAD\/\/wD\/AAAA\/wD\/AP\/\/AAD\/\/\/8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD\/\/wAA\/\/8AAP\/\/AAD\/\/wAAva8AAL1vAAC87wAAhCEAALWtAAC1rQAAhCEAAP\/\/AAD\/\/wAA\/\/8AAP\/\/AAD\/\/wAA\">");

(and optionally remove the code trying to send something useful when "favicon.ico" is requested - and no, it can't simply be encoded like the other way it is sent)
(you could set that line to a string and call it wherever needed to save on file size, but I'll let you do that...not exactly sure how to in C++)
What this is doing is giving the browser the data directly, in the form of the .ico file encoded in base 64.
So you don't even have to worry about taking prpnet.ico and reading its binary data, or supplying anything if favicon.ico is requested.
Only real downsides are:
it won't work in older IE versions, and
a user would have to go through a few steps (encode their image, replace / with \/ to escape the slashes, edit the source code, and recompile the server) to have their own icon instead of the default.

If you're at all worried about that little amount of bandwidth, we should be able to replace that with an encoded version of the .ico in .gif or some other more compressed format without any problems or major changes.

Attached is the modified HTMLOutput.cpp file (in a .zip).

Now we just need this problem of not being able to view it correctly to be worked out! What timing...

Originally Posted by mdettweiler

Actually, I was using IE for it--IE 8, to be exact. Which version were you using?

Oh, and PRPnet won't report anything unless you have debug logging turned on. Normally it doesn't say anything about web traffic (even errors).

IE8. I enabled debug logging. I set it to 2. It shows normal web traffic, and did not report errors. (I suppose that it should have reported any errors, with how I had it set)