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.
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).
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.
- 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.