The following issues await resolution:
With suitable client programs, DCP could proceed with no more than sporadic human intervention, with the DCP server accumulating results and automatically issuing appropriate notifications.
It is anticipated that DCP could be used for attacks on other computation-intensive problems in which the specification of arguments and values is compact, including but not limited to (a) factoring of large numbers, (b) public experimental attacks on cryptosystems.
Thereafter the client may report properties of a key, query the properties of keys, reserve a key to work on, or release previously reserved keys. On the assumption that multiple verifications are desirable, the DCP server permits multiple reservations up to a configured maximum and records the number of times a key has been tested.
The protocol knows nothing about properties associated with a key. They may be interpreted as values of a function, or as intermediate computation state associated with a function, or as anything else. Property semantics are project-specific. Reservations include the address of the reserving party and a timestamp. They expire after a configurable period.
The DCP reference software will provide client and server-side state machines for the protocol which take as arguments a method table, with each method including a name and appropriate hook functions.
A DCP client will typically support only one project (though this is not a protocol requirement). DCP servers may support one or more projects; indeed, one goal of DCP is to prevent multiple TCP/IP service numbers from being claimed separately by multiple projects.
The DCP maintainers will keep a registry of public project names.
;; Server IDs itself and returns an encoded timestamp S: * OK DCP 1.0 locke.ccil.org <[email protected]> ;; Client IDs itself for request-logging purposes C: A0000 HELO [email protected] S: A0000 OK Hello, [email protected]. Pleased to meet you. ;; DCP may support more than one search database. C: A0001 PROJECT FORBIN S: A0001 ERR No such database ;; This is the right one. Observe that tags may be re-used, though it ;; is better practice not to do so. C: A0001 PROJECT GIMPS S: A0001 OK Great Internet Mersenne Prime Search ;; Client authenticates self with an MD5 hash of the timestamp. ;; (This requires a per-project shared secret known to the server side.) S: A0002 AUTH MD5-CRAM esr 1e55fabe5c2c943f1d6578eb184734d4 C: A0002 OK esr authenticated ;; Assert that the exponent key "2" in the GIMPS database has the property ;; "prime" (that is, 2^2 - 1 is prime). C: A0003 RECORD 2 prime S: A0003 OK GIMPS "2" <= "prime" C: A0004 RECORD 3 prime S: A0004 OK GIMPS "3" <= "prime" C: A0005 RECORD 5 prime S: A0005 OK GIMPS "5" <= "prime" C: A0006 RECORD 7 prime S: A0006 OK GIMPS "7" <= "prime" ;; Assert that the exponent key "11" in the GIMPS database has the property ;; "composite" (that is, 2^2 - 1 is prime). C: A0007 RECORD 11 prime S: A0007 OK GIMPS "11" <= "composite" ;; Query the status of a numeric range of keys. For each key, return the key, ;; the property, the number of times the key has been tested, the number of ;; reservations on it, and the estimated Kflops needed to test it. C: A0008 QUERY 12-20 S: * 3 keys S: "13" "prime" 2317 0 1 S: "17" "prime" 2317 0 1 S: "19" "prime" 2317 0 1 S: A0008 OK 3 key(s) from GIMPS database ;; Request a key without specifying properties. This leaves it to the ;; server to prioritize pending keys and assign the next logical one. C: A0009 REQUEST S: * 1 key(s) S: * "20003" "unknown" 0 0 459 ;; This tells us that the server picked 20003, that its status is unknown, ;; that it has never been tested, there are no reservations on it, and that ;; the server estimates that the remaining computations to extract all ;; properties will require 459 Kflops. S: A0009 OK 1 key(s) reserved ;; This is what a response to an invalid key request looks like C: A0010 REQUEST 20005 S: * 0 keys S: A0010 ERR No valid keys are in range ;; Client is done C: A0011 QUIT S: A0011 OK Bye
DCP is a line-oriented protocol. Requests and responses are terminated by \n, with optional preceding \r ignored.
DCP is client-driven. After the initial greeting line, every transaction is initiated by a client command beginning with a tag token. Server responses consist of any number of untagged response lines, followed by a tagged status line with tag matching the initiating client command.
Every status line follows its tag token with one of the tokens OK, or ERR. The response OK indicates a successful transaction. The response ERR indicates a failed transaction. Failed transactions do not change the server's database.
Commands and responses are token-oriented, with tokens being separated by whitespace. Tokens containing whitespace may be protected with double quotes.
(The design of DCP is explicitly modeled after IMAP4 as described in RFC1730.)
+-------------------------------------------------+
| (A) initial connection and server greeting |
+-------------------------------------------------+
|| (1) || (7)
VV ||
+---------------------+ ||
| (B) non-selected |<==++ ||
+---------------------+ || (5) ||
|| (7) || (3) || ||
|| VV || ||
|| +---------------------+ ||
|| | (C) selected |<=++ ||
|| +---------------------+ || (6) ||
|| || (7) || (4) || ||
|| || VV || ||
|| || +------------------+ ||
|| || |(D) authenticated | ||
|| || +------------------+ ||
|| || || (7) ||
VV VV VV VV
+-------------------------------------------------+
| logout and close connection |
+-------------------------------------------------+
(1) connection (OK greeting)
(2) rejected connection (ERR greeting)
(3) successful PROJECT command
(4) successful AUTH
(5) failed PROJECT command
(6) Failed AUTH command
(7) QUIT command, server shutdown, or connection closed
No argument selects the entire database. A single argument selects the corresponding key. A range argument selects a range of keys in a project-dependent order (numeric range extrema are guaranteed to generate the range of integers bounded by them inclusive).
Each subsequent line except the last is a key report. Each includes a key, its properties, the number of times the key has been tested, the number of reservations on it, and the estimated Kflops needed to complete property computations. One such line is generated for every key matching the specification.
The response is terminated by a tagged status line:
A single argument selects the corresponding key. A range argument selects a range of keys in a project-dependent order (numeric range extrema are guaranteed to generate the range of integers bounded by them inclusive).
Each subsequent line except the last is a key report. Each includes a key, its properties, the number of times the key has been tested, the number of reservations on it, and the estimated Kflops needed to complete property computations. One such line is generated for every key matching the specification and successfully reserved.
The response is terminated by a tagged status line:
GIMPS keys are syntactically numeric. Valid GIMPS keys are prime numbers.
The property data of a GIMPS database entry always contains one of the properties "prime", "composite", or "unknown". It may contain other properties representing intermediate computation state. Properties are semicolon-separated.
The test count of a GIMPS entry is incremented on each report of "prime" or "composite".