Child pages
  • Design Decisions - Integrity
Skip to end of metadata
Go to start of metadata

There are following design decisions directly connected to the integrity client.

No persistent data in client

The integrity client are not allowed to contain any persistent data, since this will introduce risk of single point of failure, unnecessary complexities and restricted parallelism. therefore all informaiton must be reproducable from configuration information (in SLA) and maybe optimised by information from logs.

Asynchronous collection of integrity information

We cannot expect all data to be available at the same time (experience from Netarkivet). Therefore collection of integrity informaiton must be asynchronous.

Random check of files

  • Random check can be made by the client using nonce/salts.
  • The samples of files for random check is to be given by the client itself.

Background for decision:

Data transfer after mass loss of data on a pillar

This must partly be based on an organisational solution, which can be supported by functionality in the client (Correct integrity errors process).

Background for decision:

No knowledge of details in Pillars

The Integrity has no registration of where files were last seen, except from the pillar they were seen at.

Background for decision:

Resolved issues

  • Integrity client will discover that a pillar has changed from the IdentifyPillar... repsponses
  • Specification of whether checksumdata, salt data and file list data is to be put into a respons message or transferred via data transmission, is specified by giving a an address id data is to be data transmitted, otherwise it will be given in a message
  • Checksumstype is given in a parameter
  • Information about location of files om pillar can be be needed in special cases, but it is up to the pillars to secure such informaiton.