Child pages
  • Unresolved Issues - Architecture
Skip to end of metadata
Go to start of metadata
  • Vi skal have afklaret, hvem der kan kommunikere med hvem:
    • Klient <-> Ben
      • er håndteret
    • Ben <-> Ben
      • Dette er ikke håndteret endnu, eneste case er masseoverførelse af data (se integritetsklienten)
      • Endvidere kan der være en case omkring audit-trails
    • Klient <-> Klient
      • Denne vil sikkert komme til at forekomme, så vi kan designe klienter så fleksibelt som muligt.
      • Endvidere er den et must, hvis vi håndterer fejl via alarm beskeder
  • Behandling af audit-trails (og rapporter). Kommentar bam: Altså efterbehandling udover Get Audit Trails under Protocol eller?
  • Undersøge om request af mange objekter (inklusiv audit og checksummer) på en gang kan løses via offload til dataprotokol.
  • Vi skal evt. overveje om parallelle klienter kan overtage hinandens opgaver - en sender request, men en anden overtager modtagelse af data.
  • Vi skal have afgjort om ben må have sin egen kommandobuffer eller altid skal lade bussen håndtere buffere. Der er forskellige behov alt efter om ben er online / offline storage.
  • Hvordan fungerer det hvis man benytter <synkron> parameteren? Og skal der være konfirmation af sådanne beskeder?
  • Minimal specialisering for Pillars der er et bitmagasin i sig selv. Se http://sbforge.org/display/BITMAG/Design+discussions#Designdiscussions-Bensomkanv%C3%A6reetbitmagasinisigselv.
  • Ben som kan være et bitmagasin i sig selv: Den gode løsning indtil nu er Hvis at bit magasinet det selv skal holde styr på det og evt. bede om hjælp.Dette indebærer at et ben skal kunne bede om alle checksummer til et object - denne del er ikke med i protokollen i øjeblikket, og den dette er et eksempel på at forespørgsler skal kunne gå fra ben til klient.
    Forespørgslen kunne rejses som alarm, hvilket kunne generaliseres med andre alarmer som et ben måtte ønske at rejse, f.eks. hvis det ved at det har mistet diske.
    En alternativt løsning kunne det være at benet gav alle checksuminformationer videre, og lader klienten lave valget. Dette passer dog ikke ind i en general struktur og overlader også ekstra kompleksitet til klienten.

See also