Page Comparison

To be translated and elaborated

Følgende beskeder er involveret:

...

Vi kan overveje om der skal være individuelle beskeder adresseret til specifikke ben, eller om ben adresseres via "SLA" identifikator, - dvs. en besked trigger alle relevante ben. Integritetsklienten skal under alle omstændigheder have check på hvilke ben der indgår, for at sikre at den har fået svar fra alle og at afstemning foregår fra svar fra alle og rigtige ben.

Der er en ekstra lille udfordring her i forbindelse med at der udskiftes, tilføjes eller "slettes" ben for en SLA - især når integritetstjekkene laves asynkront.

Svarene til forespørgslerne behandles uafhængigt. Hvis der ikke er kommet svar, så vil dette inten rettes op ved næste forespørgsel, eller via "Check information is up-to-date" når der er gået for lang tid uden opdatering.

Der vil være den sædvanlige fejlhændtering (svarende til get) såfremt der ikke kommer nogen data trods token er givet.
Image Removed

Minimums informationer i request beskeder:

• Header informationer - dato m.m.
• Evt. autorisationsdata
• Klient identificerings informationer (evt. indirekte)
• Pillar identificerings informationer (evt. indirekte)
• Besked type og formål (evt. nedbrydning svarende til protokol og funktionalitet som besked tjerner til)
• Evt. Checksumsalgoritme for checksummer
• Evt. afgrænsning af objekter det vedrører i form af dato, volume koder eller lign. (evt. som fil liste)
• Evt. ekstra tegn til direkte checksumscheck (Rosenthal NONCE)
• Evt. max antal checksummer i svarbesked ??? (fra service modellen)
  

Information omkring afsendt request kan evt. lægges på separat kø for klient til at understøtte at andre instanser kan modtage svar. Den kunne have følgende udseende:

• Header informationer - dato m.m.
• Evt. autorisationsdata
• Klient identificerings informationer (evt. indirekte)
• konversationsinformation
• token hvor data bliver lagt
  

Minimums informationer i answer beskeder (kan være delt såfremt selve informationer sendes via andet net/protokol):

• Header informationer - dato m.m.
• Evt. autorisationsdata
• Identifikation af besked som dette er svar på (id. af klient, pillar, besked type/formål, checksumsalg., objekter, beregning er implicit indeholdt i dette)
• svar eller information til gensidig etablering af svar forbindelse
  

Specifikt for checksummer skal denne information indeholde:

• information per fil (evt. repeterbar)
  • checksum
  • fil id
  • tidspunkt hvor checksum sidst blev beregnet (hvis det ikke er online, kan denne information være vigtig for alarmering)
• antal filer
  

tilsvarende for filer, blot uden checksummer.The integrity client is special compare to other clients considering knowledge of pillars, since it must have knwoledge of which pillars that should be part of a voting. this also adds an extra challenge in cases where the are changes in the pillar combination for a SLA, especially in this case where we wnat asynchronous collection of integrity information.

The responses to requests for different integrity informaiton is treated separately from the actual requests. Note that this will mean less complexity in cases where there are no answer to a request, since this will be handled, either by the next request or by alarms produced by Check inf. is up-to-data process, when the data is alarmingly old compared to deadlines defined in the SLA. This is illustrated by two processe in the below figure.

Image Added

In any cases of errors the processes wil raise alarms.

For details on message and data transmitted, please refer to Collection communication