The software
The software available here contains a client-server wrapper for running the ECM search program (available at the above link). The advantage of using this is that you can remotely control and monitor the progress of multiple machines from a central location.

The software compiles on a variety of platforms. Windows binaries are precompiled in the distribution. It can be compiled on unix with the included Makefile.

The most recent package available is version 2.0k. It was released on June 21, 1999. Source is included in this file.

What it does
The client will contact the server for a work assignment. Each assignment basically tells the client which composite number to attempt factoring, using the ecm method. When complete, the client informs the server of either success or failure. The server will count the number of curves run fro mall clients, and adjust the parameters of the search as time goes on.

When the server is run, it will read an INI file (sample provided). This file holds a listing of numbers to factor. There are several different types of row possible. The following shows three of them...

2^727-1.c219 N 706003489677054...
2^727-1.c219 A
2^727-1.c219 B 11000 90 90 0
2^727-1.c219 B 50000 300 0 0
2^727-1.c219 B 250000 700 0 0
2^727-1.c219 B 1000000 1800 0 0
2^727-1.c219 B 3000000 5200 0 0
2^727-1.c219 B 11000000 7083 83 40
2^727-1.c219 B 44000000 517 517 517

The first row identifies the Number. The second labels it as 'active' (it will be handed out to clients). The "B" rows identify various B1 levels and the # of curves processed at each of these levels. The forth possibility is a "F" row identifying a factor, and the person who found it. This file is dynamically updated as clients connect to it. If a factor is returned, the row is marked as inactive (unless this behaviour is overridden on the command line), and won't be handed out to other clients.

The server randomly picks an 'active' number from those 'active' ones stored, and then calculates the amount of 'work' done for this number (sum(B1*curves)). Based on this calculation, it determines what B1 level should be used. This algorithm can be modified to suit. One alternative is to assign 'priorities' to each number and always hand out the one with the highest priority.

I've started using a naming convention for the numbers as above. It's relatively important that this be adhered to if your server will be sending its data to an upstream server. Especially true if you want the benefit of your server knowing what work has been done elsewhere to avoid duplicating effort.

As it runs, the server will re-write an INI file as needed, write a log file, and write a "Factors.LOG" file as new factors are returned.

The client will create and update a compatible INI file as it runs which will hold information on what it has processed, as well as what the current state of factoring is for any number it attempts to factor.

The INI files' "B" rows hold three different counts of information about the various different B1 levels. Consider the second last row in the list above. The first number (7083) means that 7083 different curves at a B1=11000000 level have been run for this number. This includes all curves that the server was aware of when last contacted, as well as curves this machine has processed since then. The second number (83) means that this machine has processed a total of 83 of these curves. Alternatively, if this is a server's INI file, it means that 83 curves were uploaded to this server from other machines. The third number (40) means that there are 40 curves which have not been sent to the server yet.

The client will run very smoothly, basically just calling ECM3 over and over, contacting the server before/after each run. It sends details about completed runs back to the server, as well as new factors that are found. As the client runs, it creates an INI file showing exactly what curves it has run. This INI file will also store any factors that the client finds (and is identical in format to the server copy).

I've provided a WIN95/NT binary for each of the client and server, as well as a sample INI file. This sample file includes three composites of varying degress of difficulty (although all relatively easy compared to the difficulty of this project). Use of this ini file will enable you to see how the setup actually works.

Where to connect to
Paul Leyland has volunteered to host a server. Its address is red.cam.uk.eu.microsoft.com (port 8194). The machine may change, but please point your client at this server (check back here for updates if it stops working). It will be very useful to have machines in various environments all accessing this server. Let us know of any problems you encounter.

Server 'chaining'
One very useful part of the server configuration is that they can be 'chained' together. In this manner, a client can connect to server A. Server A can be configured to periodically send all new information to server B, which can then send its information up to server C. As each communication occurs, the 'downstream' server will be updated so that it knows all the details of the # of curves at each B1 level which the upstream server is aware of (only for the curves for which the downstream server is trying to update the upstream one). This upstream/downstream method of communication is what enables a given client/server to share what it knows with all other machines which are working on factoring the same number.

Remote Control
The server also has the ability to be remotely administered if it is configured to have a password. While a telnet session can be used, the ecmclient.exe that is distributed can be run with "-admin" to access these administration functions. These functions let you remotely query information on the various numbers, change the status of a number, or add a new number to the server's list.

Communication protocol
The client/server (or server/server) communication protocol is available in protocol.doc.

Factors found so far
I found a factor with this setup even before I released it. The following file is an up-to-date list of everything found that was turned in so far. factors.html.

Please let me know of any feedback you have (good or bad!)

• 1.0 (98.9.15) Initial release
• 1.2 (98.9.25) Lots of additions and bug fixes
• 1.4 (98.9.30)
  • Single client/server connection used for both retrieve/return of data.
  • Added 'smallini' option to client
  • Added GETACTIVES and GETBASE10 support to server
  • Added 'Slave' option to server
• 1.4b (98.10.2)
  • "-idle" support on unix machines
  • Better detection of brak key
• 1.5 (98.10.5) NT Service versions of both ecmclient/ecmserver relased
• 1.6 (98.10.7) Added rudimentary stats on work performed by curve/user to server code
• 1.6b (98.10.7) Stats of #curves/sum(b1)/sum(b1)*len(n)^2 by day
• 1.7c (98.10.9)
  • Added ability for server to hand out keys based on 'strategies' (random, minimum sum(b1), etc)
  • Fixed problem that an interrupted run would count as a completed curve
• 1.8 (98.10.15) 1.7c got deleted, and this was my then-most-recent source
• 1.8d (98.10.18)
  • Cofactor and primality of factor & cofactor are now sent to server.
  • Server permits startegy of 'shortest' composite
  • Selected numbers can be labelled as 'Local Control' which means that their active/inactive status won't mirror the upstream server when in slave mode.
• 1.9 (98.10.26)
  • Small memory leaks fixed
  • Fixed crash when composites have ',' in their name
  • Admin options that don't change server config. no longer require password
  • Fixed bug in recurse that was was causing crash
  • Unix now supports SIGUSR1 to force an upstream connection, and SIGTERM to kill it
• 1.9b (98.10.28)
  • Added support for identifying factors found in step1 vs step2
  • Fixed bug when server sends 'down' a new factor -- sigma info was occasionally lost.
  • default error timeout changed to 5 minutes
  • Added support for server specifed 'max # curves' to process
  • get_sumb1 now returns the better of upstream server totals, or downstream totals
  • Sped up 'getwork' when using very large INI files.
  • Cleaned up info that's logged to server screen/file to be more readable (well, slightly more ;)
  • Corrected minor bug in get_bestb1
• 1.9c (98.11.2)
  • Faster upstream communications (especially server to server)
  • Changes to allow compiling with MSVC++
• 2.0 (98.11.8)
  • Added a 'greeting' that is sent from the server to client at each connect.
  • Server can send a mail message when a new factor is returned
  • Server will trigger it's upstream connection when a new factor is found
  • Fixed strategy 3 hang under linux
  • Support for multiple simultaneous strategies in the server
  • Fixed a bug in open_server that caused a hang when the upstream socket was opened, but no data was available
• 2.0a (98.11.8) Timeouts all fixed to defaults of 20 minutes
• 2.0d (98.11.12)
  • Fixed bug in recursion which was causing curve count information to _not_ be copied from the old number to the new one
  • Added ability to sort INI file by name, b1, sum(b1), work, len(composite)
  • Fixed bug in strategy handling
  • Made output of admin_status() more readable
• 2.0e (98.11.20) Improved communications error detection on unix systems (no effect on win32)
• 2.0f (98.11.30) Fixed bug in is_LocalControl -- it was getting the local control status of the _next_ composite
• 2.0g (99.4.15) Allowed specification of server names using name (instead of only IP address)
• 2.0h (99.4.22) Server names > 20 characters were not working properly.
• 2.0j (99.6.21)
  • Server drops connections from client if no composites are available (factored or unfactored composites) (Courtesy of RZG (gevaryah@netaxs.com)
  • Server can be started in slave mode with no INI file available
  • Fixed server crash when GETBASE10 asked about non-existent number. (courtesy of Paul Abelian)
  • Fixed possible crash when processing returning a factor. (courtesy of Paul Abelian)
  • Fixed command line parsing when last parameter is incomplete (courtesy of Paul Abelian)
  • Fixed misc. problems with getstring() NULL/"" return values and strlen()/free() etc.
• 2.0k (99.6.21) Upstream server communications were broken in 2.0j.