ECMNet Feature Requests

[em99010pepe]

Originally Posted by rogue

I would like to start some testing of ECMNet 3.0. One of the tests I need to run is the upgrade from an ECMNet 2.x ecmserver.ini file. If you are running a server, would you mind e-mailing it to me?

Sorry but I am still not running the ecmnet server.

[rogue]

Originally Posted by rogue

I would like to start some testing of ECMNet 3.0. One of the tests I need to run is the upgrade from an ECMNet 2.x ecmserver.ini file. If you are running a server, would you mind e-mailing it to me?

Thanks guys. I have received 5 different files. I'll do some testing tomorrow.

[rogue]

I'm pleased to relate that all ini files (even Paul's which has over 12000 composites) loaded flawlessly, at least as far as I can tell. I did run into a couple of bugs as part of the import, but those are fixed. I did discover a couple of problems in one ini file, which could be a problem in the 2.x code that I am unaware of.

The next testing I need to do is on client/server communication. Maybe I can start on that this weekend.

[xilman]

Originally Posted by rogue

I'm pleased to relate that all ini files (even Paul's which has over 12000 composites) loaded flawlessly, at least as far as I can tell.

Good!

Originally Posted by rogue

The next testing I need to do is on client/server communication. Maybe I can start on that this weekend.

If you would like me to run test clients and/or servers, please ask.

Paul

[rogue]

Originally Posted by xilman

Good!
If you would like me to run test clients and/or servers, please ask.

Paul

Thanks.

Eventually I will initiate some alpha testing and I could use some help then, but before then I need to make sure that the most egregious errors in the code are fixed. Since the protocol has been completely rewritten, there is a bit of testing to be done. These are some of the areas that need testing and the order in which I intend to attack them:

1) ECMNet 3.0 server working with ECMNet 3.0 client.
2) ECMNet 3.0 server working with ECMNet 2.x client.
3) ECMNet 2.x server working with ECMNet 3.0 client.
4) Factor submission and e-mail notification.
5) Master/slave (3.0 server to 3.0 server only).

As stated previously, I have no intention to make the master/slave logic be backward compatible with 2.x servers.

[rogue]

I have been fortunate to have a lot of time to test v3.0 in the past couple of days. The testing is going slowly, but I do have the client and server talking to one another along with the appropriate database updates. I haven't tested the code for newly found factors yet, but hopefully I will get to it this week. The interoperability of 2.x and 3.0 is really an issue of 3.0 using the correct protocol. That should go fairly quickly.

I have removed the logic to send multiple types of factoring work at one time. It was proving to be too complex and I didn't want the 3.0 release to be dependent upon it working. Fortunately the 3.0 client should support it, if I do ever put the time into getting it to work in the server.

I revamped the server_stats.html page to not show all of the details for each composite. It will show the current B1 and number of factors found for the composite, but it won't show factoring work done or the factors themselves. So that the functionality isn't lost, I have added a composites.html page which closely corresponds to the old server_stats.html page. The nice thing about this change is that server_stats.html will take a lot less time to generate than composites.html since they both need to hit the database to generate the data.

I have added a user_stats.html page which shows how much work and time was spent by each user (and how many factors they found). I'm suspecting that some stats lovers will gravitate towards ECMNet if they have a means of seeing how much work they have done over time.

All in all, once I feel that the 3.0 server and 3.0 client are working well together, I might release an alpha before testing either with its 2.x counterpart. It would be for those who have a private ECMNet server who are willing to subject themselves to an alpha test.

[xilman]

Originally Posted by rogue

All in all, once I feel that the 3.0 server and 3.0 client are working well together, I might release an alpha before testing either with its 2.x counterpart. It would be for those who have a private ECMNet server who are willing to subject themselves to an alpha test.

Count me in.

Paul

[rogue]

I have added a "pending_work.html" webpage to the server. This will show the outstanding, i.e. not returned, factoring work sent to clients.

Note that this is not a reservation system. It is only intended to give people an idea of how many clients are actively doing factoring work for that server. There is no requirement that returned work marries up to one of the "pending work" records.

Via configuration, the admin can control how long they want records to show up on this page, thus presuming that a client has abandoned work and won't be returning it.

A change I made to the client will allow the user to control what they want to do when shutting down. Currently the client automatically returns completed work to the server. The change is to allow the client to shutdown without returning that work so that they can restart and continue with the previous factoring assignment. Grabbed from PRPNet, this is called "stopoption" in the ini file.

There is also a change in the client to allow the client to shutdown upon completion of a curve. Also grabbed from PRPNet, this is called "stopasaption" in the ini file. The ini file is read after each curve is completed. By looking at stopasapoption, the client can be told to report the completed work and shutdown as soon as it has completed working on the current curve.

[jyb]

Originally Posted by rogue

I have added a "pending_work.html" webpage to the server. This will show the outstanding, i.e. not returned, factoring work sent to clients.

Note that this is not a reservation system. It is only intended to give people an idea of how many clients are actively doing factoring work for that server. There is no requirement that returned work marries up to one of the "pending work" records.

Via configuration, the admin can control how long they want records to show up on this page, thus presuming that a client has abandoned work and won't be returning it.

I assume that goes both ways? I.e. there may never be returned work for some given outstanding work, but is it also the case that work can be returned which the server doesn't have in its pending work records?

Originally Posted by rogue

A change I made to the client will allow the user to control what they want to do when shutting down. Currently the client automatically returns completed work to the server. The change is to allow the client to shutdown without returning that work so that they can restart and continue with the previous factoring assignment. Grabbed from PRPNet, this is called "stopoption" in the ini file.

There is also a change in the client to allow the client to shutdown upon completion of a curve. Also grabbed from PRPNet, this is called "stopasaption" in the ini file. The ini file is read after each curve is completed. By looking at stopasapoption, the client can be told to report the completed work and shutdown as soon as it has completed working on the current curve.

That last one is identical to the current behavior on receipt of a SIGTERM, right?

[rogue]

Originally Posted by jyb

I assume that goes both ways? I.e. there may never be returned work for some given outstanding work, but is it also the case that work can be returned which the server doesn't have in its pending work records?

That last one is identical to the current behavior on receipt of a SIGTERM, right?

Yes to your first question.

No. In the ECMNet client SIGTERM immediately stops working on the curve. I don't know what GMP-ECM does (as the SIGTERM will be passed to it as well), by the client acts as if GMP-ECM was terminated without completng a curve.

The difference is that today the client will always report completed work upon ^C, i.e. the user has no choice in the matter. stopoption gives the user the choice of what to do with completed work with ^C is hit, i.e. return or hold on to it to do more work on it later.

stopasapoption does not deal with signal handling at all. If GMP-ECM is running and the user decides that they want to complete the current curve run by GMP-ECM (without interrupting GMP-ECM), then shut down, they would update this option in the ini file. The client will read the ini file after each curve is done and decide if it needs to shut down and upon shut down if the completed work is to be returned or held (like stopoption).

I hope that clears up any confusion.

[jyb]

Originally Posted by rogue

Yes to your first question.

No. In the ECMNet client SIGTERM immediately stops working on the curve. I don't know what GMP-ECM does (as the SIGTERM will be passed to it as well), by the client acts as if GMP-ECM was terminated without completng a curve.

The difference is that today the client will always report completed work upon ^C, i.e. the user has no choice in the matter. stopoption gives the user the choice of what to do with completed work with ^C is hit, i.e. return or hold on to it to do more work on it later.

stopasapoption does not deal with signal handling at all. If GMP-ECM is running and the user decides that they want to complete the current curve run by GMP-ECM (without interrupting GMP-ECM), then shut down, they would update this option in the ini file. The client will read the ini file after each curve is done and decide if it needs to shut down and upon shut down if the completed work is to be returned or held (like stopoption).

I hope that clears up any confusion.

I didn't ask about hitting ^C, I asked about sending a SIGTERM to the ecmclient process. Hitting ^C causes a SIGINT to be sent to all processes in the foreground process group, which would ordinarily include the GMP-ECM process as you say, but that's not what I'm talking about.

This has already been covered earlier in this thread. See post #24. As far as I can tell, sending a SIGTERM (or SIGINT) to *just the ecmclient process* has exactly the behavior you're going for with stopasapoption.