• project: A long-term endevour in order to accomplish a specific, clearly defined goal. RC5, DES, OGR, CSC are all distributed.net projects. All distributed.net clients supports at least one project, and all recent clients are capable of processing data from multiple projects simultaneously.

• core: The code in a client that is responsible for processing the data associated with a project. Each project that a client supports may have multiple cores associated with it (each core is then optimized for a specific processor or processor family/group).

• iteration: An iteration is a generic term used to denote the smallest unit of work processed by a core. For crypto projects (RC5, DES, CSC) this is a key, for OGR it is a node.

• key: This is the smallest unit of measurement that can be checked by the client for cryptographic projects (RC5,DES,CSC). Each key represents one possibility of the solution. (for DES contests, each key actually represents two possibilities since each key and its opposite [complement] are automatically checked at the same time). Individual keys can be checked relatively quickly by your computer, usually several hundred thousand per second.

• node: This is the smallest unit that is individually checked by the client for OGR. A typical desktop computer may be able to check a million nodes per second. Each node represents a single golomb ruler possibility.

• stub: Stubs represent groups of OGR nodes that need to be checked. The number of nodes within a stub cannot be precisely determined in advance, ergo the amount of time needed to complete a given stub cannot be determined either. In general, stubs whose marks sum to a smaller total will take longer to check.

• stats-unit: a quantum of fixed size, used for stats and nowhere else.
  
  • For crypto-projects (RC5-56, RC5-64, DES, CSC) a stats-unit is 2²⁸ or 268,435,456 keys. The exception is RC5-72, where each stats-unit is 2³² or 4,294,967,296 keys.
  • For OGR a stats-unit is 1 billion nodes (one Gnode).

• packet: a discrete unit of work which will be processed. Clients send, recieve and crunch in terms of packets. A packet may be composed of any number of stats-units, including fractional portions thereof.
  • RC5-56, RC5-64, DES, and CSC packets have anything from 1*2²⁸ to 32*2²⁸ keys.
    (ie, 1 to 32 stats-units)
  • RC5-72 packets can contain from 1 to multiple stats-units, or X*2³² keys.
  • An OGR packet has exactly one stub, and that stub may have any number of nodes.
    (ie, 0.01 to N.nn stats-units)

Obsolete, historical terms:

The first and second generation of clients ran only crypto-projects: RC5 and DES. These two projects were sponsored by RSA and had a winner (and the prospect of monetary award), and as such were called contests.

Since a computer is capable of processing many hundreds of thousands of RC5 and DES keys per second, counting in single keys quickly becomes onerous, and the very first generation of clients introduced the unit of 2²⁸ keys, as a handier unit of measure. These first generation clients worked solely with this number, both as the number of keys it sent/received/processed as well as the number of keys used to represent "effort", or the "unit of of work" done, and what was displayed on the stats server. Consequently, this number of keys came to be known as a work-unit.

The second generation of clients introduced the ability to send/receive/process many more than 2²⁸ keys at once. For the purpose of (backwards-compatibility and) statistics, the 2²⁸ key "unit of of work" retained its meaning, but the term used to represent the number of keys being sent/received/processed at once had to be changed. Since the number of keys being sent/received/processed continued to be a multiple of 2²⁸, the unit being sent/received/processed was called a "block of work-units", or in short, a block.

With the introduction of non-crypto projects such as OGR, the terms contest, work-unit and block had to be reconsidered. OGR neither had a winner, nor did it use keys, nor did it have a fixed number of iterations ('keys' in crypto-parlance) per "unit-of-work", nor could multiple "units-of-work" be combined into "blocks of work-units" for sending/receiving/processing. Indeed, for OGR, there was a tendency to revert to the older meanings, since a stub is a work-unit in the oldest sense of the term, both as a literal "unit of work" and as the unit that is sent/received/processed.

To overcome this confusion, more generic terms project, stats-unit and packet came to replace the older contest, work-unit and block respectively.

	First Generation Term	Second Generation Term	Current Term
endevour/undertaking	contest	contest	project
unit used by stats	work-unit	work-unit	stats-unit
unit sent/received/processed	work-unit	block	packet

However, old habits die hard, and the old and new terms are often used interchangeably. While not technically correct in the generic sense, the old terms are still perfectly valid for the crypto-contests, errr... crypto-projects. :)