- We can consider to have estimated time in get...Reply in order to get time out information. Another possibility is to introduce a get...Time and a get...TimeReply for these operations.
- We need to consider whether get... is sent om pillar queue or general topic. There is here a coordination challenge if a pillar is changed!!!!
- We need to consider whether the client should ask for pillars that think they are involved in SLA - could be by use of the GetTime???!!!
- How do we want to address whether checksumdata, salt data and file list data is to be put into a respons message or transferred via data transmission???? In the first case we will need to introduce a special get...ReplyData message.
- Integrity correct process (and communication including messages) is missing analysis, especially regarding effective coorection, where pillars may transmit coorect objects directly, instead of using temporary storage pointed out by the integrity client.
- Handling audit trails needs further analysis. it can also be considered whether parts of chashe database can be reestablised from audit trails.
- Integrity check needs further analysis, especially regarding the cases where a pillar is exchanged by another.
- Handling more checksumsalgorithms needs further analysis
- Exact use of alarm messages needs further analysis
- Still need more analysis on whether information on location of pillar can be be needed in special cases
- Still need more analysis on whether behavior is sufficient in cases where pillars are representing a bit repository, or when integrity client report to other bit repository. For example: this may raise a requirement saying that a pillar must be able to request a copy from another pillar (in connection with correct)
- Missing specification of needed integrity informaiton information in "database".
- We need to investigate the needed procedures to handle restore after a mass loss without using the protocol.
- Vi skal evt. kunne sende patterns af fil ids??????
. ellers skal alle ids nævnes - Kan forespørgsel på checksummer samles for flere pillars?
. de er splittet ud i 1a ovenfor, idet det sikekrt er lettest at splitte dem op. - Effektivitet ved at forspørge på alle checksummer fremfor individuelle
. Der kan være forskellige scenarier hvor der er lige så billigt blot at lave enkelt request fremfor at udvælge specifikke checksums man ønsker. For eksempel hvis alle checksummer ligger i en slags front end for et ben, så kan det være lige så let at få alle og overlade til clienten kun at opdatere informationer om nyudregnede checksummer. Derimod hvis der kun er tale om et meget begrænset antal checkesummer som udregnes direkte, så kan det være bedre at om hver enkel. Dette kunne evt. også være en opsætningsparameter til klienten. - Skal vi angive checksumstype? eller skal dette ligge i operationsnavnet, f.eks. getChecksumsMD5. jeg synes bedst om den første.
See also unresolved issues for Get |