Tor-Eirik Bakke Lunde

Transkript

1 Obligatorisk oppgave 1 INF oktober 2003 Tor-Eirik Bakke Lunde torebl@stud.cs.uit.no

2 Oppgavebeskrivelse: Designe og implementere en distribuert ray-tracing applikasjon, med basis i kontroller- arbeider paradigmet. Kontrolleren mottar en jobb fra en klient, og deler jobben opp i mindre mer håndterlige biter. Disse bitene blir en etter en tildelt tilgjengelige arbeidere som utfører sin del av jobben og så sender sin del av det endelige resultatet til kontrolleren. Når alle bitene er utført blir alle delresultatene kombinert til ett resultat og returnerer dette til klienten. Kontrolleren er nå klar for å motta en ny jobb. Design: Ut ifra oppgavebeskrivelsen er det definert ett behov for tre separate programmer (eventuelt Extensions ) i form av klient, kontroller og arbeider (drone). Illustrasjonen gitt i oppgaven (se bilde under) viser generelt en situasjon som kan tolkes som at vi har en jobb delt i tre deler, der hver av de tre bitene blir tildelt en av de tre tilgjengelige arbeiderne. Velger derimot ikke å dele opp jobben i deler på basis av antallet tilgjengelige arbeidere, men heller å dele opp jobben i en forhåndsdefinert mengde jobber (standard er 20).

3 Dette gir da en arbeidstildeling som mer eller mindre tilsvarer en metode kalt Sentralisert dynamisk arbeidsbalanse (oversatt fra Centralized Dynamic Load Balancing ). Dvs.: Små biter av den totale jobben blir delt ut til de tilgjengelige arbeiderne. Når en arbeider har fullført en bit av jobben og har sendt resultatet til kontrolleren, sender arbeideren en forespørsel om en ny jobb fra kontrolleren (kontrolleren tolker automatisk mottatt resultat som forespørsel om ny jobb). Implementasjon: Som følge av at TOS-middelvaren utfører det meste av detaljarbeidet når det kommer til mottakk og sending av meldinger samt kontroll over tilkobling til de forskjellige endepunktene, kan implementasjonen skrives på en måte som fremstår som helt sekvensiell. Dette innebærer at det mest sentrale punktet i de tre applikasjonene/extensions er det en best kan beskrive som en beskjedpumpe. Se eksempelkode på dette konstruktet nedenfor. while stopp_kondisjon: if io.available(1) == 0: continue processmessage() Med en eller annen form av en slik beskjedpumpe implementert i hver av de tre applikasjonene er alt som gjenstår å definere formatet på beskjedene som utveksles dem imellom. All data som utveksles skal ligge i en liste kalte data, som skal være en del av selve beskjeden. Listen data skal inneholde ett element CMD som angir hvordan beskjeden skal tolkes. Se eksempelvis oppbygning av en beskjed i tekstboksen nedenfor. msg = { to : ( Extension_name, Extension host ), data : { CMD : Defined command }, files : { workload : file_path } } Dette konkluderer den generelle implementasjonsmessige delen av oppgaven, og beskriver i hovedsak hvordan de tre programmene fungerer. Mer detaljmessig angående implementasjon av de forskjellige programmene følger.

4 Klient: Klienten er implementert som frittstående program, som ikke er avhengig av å bli lastet inn som en extension til TOS, men heller benytter seg av TOS som bibliotek dette til forskjell fra implementasjonen av Kontroller og Arbeider. Klienten, se filen client.py for full implementasjon, er programmer med etter mal gitt av eksempelklient bar.py som følger med TOS. Klienten har følgende hendelsesforløp: * Kontakt kontroller à Kontroller svarer med: * Ingen svar innen tidsgrense (kontroller svarer ikke) à Avslutt * Kontroller er opptatt. à Avslutt * Kontroller utfører din jobb à Vent mens jobb utføres à Motta resultat à Avslutt Kontroller: Implementasjonen av denne delen er utført som en utvidelse (extension) til TOS, se fil controller.py. Nøyaktig hva, og hvilket ansvar kontrolleren har er oppsummert i følgende liste: Ta imot ny jobb Del opp jobb i flere deler Holde oversikt over tilgjengelige arbeidere Holde oversikt over del-jobbene Fordel jobber Kombiner resultat Returner kombinert resultat til klient. Kontrolleren kan kun håndtere en jobb av gangen, kode er programmert med tanke på at funksjonalitet for dette kan implementeres på ett senere tidspunkt. Dersom en ny forespørsel fra en annen klient mottas får klienten beskjed om at den er opptatt for øyeblikket. Mottatte jobber deles opp i flere mindre deler, organisert internt som en liste objekter av klassen Job som etter hvert deles ut til tilgjengelige arbeidere. Hvert objekt av denne klassen inneholder informasjon som sekvensnummer, status samt hvilken drone denne jobben er tildelt. De forskjellige arbeiderne, heretter og i selve implementasjonen referert til som droner, må melde fra til kontrolleren at de kan ta imot jobber. Informasjon om de forskjellige dronene organiseres internt som en liste objekter av klassen Drone, og inneholder all kjent informasjon om denne - inkludert adresse og hva den holder på med. Ettersom det er forventet at en drone på ethvert tidspunkt kan krasje, trenger vi en måte å overvåke at det er kontakt med hver og en av dem. For å løse dette problemet definerer vi at en av utvidelsene som følger med TOS, fd, skal startes sammen med kontrolleren. Kontrolleren ber fd om å overvåke at dronene kjører, og dersom vi mister kontakt med en av dem får vi

5 beskjed om dette. På basis av denne beskjeden identifiseres dronen, og fjernes fra listen over tilgjengelige droner samt frigi eventuelle del-jobber den måtte være tildelt. Hendelsesdiagram over programforløpet av kontrolleren hadde vært overdokumentering, og hele dens funksjon defineres flytmessig av hendelser som resulterer i distribuering av deljobber og hva som skjer når alle jobbene er utført. Fører til distribuering av jobber til droner: Mottar ny jobb fra klient (dersom ikke hadde en fra før) Ny drone melder seg inn i kollektivet Mottatt resultat av del-jobb fra drone Når alle del-jobbene er utfør brukes det funksjonalitet fra klassen Join_ppm, se filen join_ ppm.py, til å kombinere alle resultatene til en enkelt fil. Denne filen returneres til klienten. Arbeider: Dette programmet refereres til under navnet drone, og implementasjonen er i filen drone.py. Utfører jobber den blir tildelt av kontrolleren. Programforløp: 0. Kontakt kontroller, og gi beskjed om at drone er klar for arbeid. 1. Motta jobb 2. Utfør jobb 3. Returner resultat til kontrolleren 4. Gjenta steg 1-3. Lite interessant som foregår, all output fra pov-ray redirigeres til en fil kalt exec_log.log. Utvidelsen fd som kjører på samme TOS som kontrolleren krever at utvidelsen echo kjøres på samme TOS som dronen. Installasjonsguide og manual: Se egen fil.

6 Diskusjonsemner: Beskjed- orientert mellomvare, TOS. Hvorfor? Ett spørsmål flere av mine medstudenter har vært inne på under utførelsen av oppgaven er vel nærmere hvorfor mellomvare i det hele tatt?. Nåda oppgaven er utført viser det seg at den lavnivå kontrollen over nettverkskoblinger en mister ved bruk av mellomvare, egentlig verken var nødvendig eller ønskelig ved implementasjon av en slik oppgave. Ved å i tillegg benytte seg av et beskjedorientert mellomvare system kan en la det underliggende systemet ta seg av detaljene ved overføring og mottak av data. Dermed kan en konsentrere seg om det programmet faktisk skal utføre, og ikke ting som burde være en formalitet (overføring av datastrukturer osv ). Det at systemet er beskjedorientert gjør at en kan implementere program i form av beskjedpumper og kan programmere ting som potensielt foregår parallelt like lett som ethvert. Antagelser. Konsekvenser? Har antatt at på ett fremtidig stadium vil kontrolleren oppgraderes til å håndtere jobber fra flere klienter samtidig, og gi hver klient lik tilgang til prosesseringsressursene. Som følge av dette kan en ikke anta at hver del-jobb tilhører den samme jobben, og dermed overføres dataen det skal prosesseres på sammen med hver del-jobb, noe som bruker en del bortkastet overføring av data. En datafil, dvs. en povray fil, er i som regel i størrelsesorden 1-32 kb og gir ett del resultat i størrelsesorden kb. Sammenlignet utgjør dette en svært liten del av totalt overført data, og en kan uten å være for perfeksjonistisk bare neglisjere dette. Antok i starten av oppgaven at dataen som det skulle prosesseres på kun besto av en enkelt fil, dvs. ingen avhengighet til andre filer. Som følge av dette kan systemet kun brukes til å prosessere filer som i seg selv er selvstendige. Antar at TOS ikke gjør feil. Dette kan medføre at programmet ikke fullfører og stopper opp dersom overføring av en beskjed feiler. Koster dette under teppet og satser på at neste versjon er litt mer stabil. Datafilene som skal prosesseres på inneholder i seg selv ingen feil. Dine valg. Hvorfor, alternativer? Valgte å implementere kontroller og arbeider som utvidelse (Extension) til TOS istedenfor frittstående programmer. Dette ble gjort ettersom funksjonsbeskrivelsen definerte programmer som skulle kjøre som en form for server, og det da virket mer naturlig å implementere dem som utvidelser. I tillegg er de begge avhengig av andre utvidelser, og ved å gjøre det på denne måten virker systemet mer oversiktlig og forståelig. Ved å spesifisere at en povray fil ikke skal kunne være avhengig av andre filer unngår en masse problemer, som for eksempel å rekonstruere ett helt filhierarki fra klient til drone. Alternativet hadde vært å gjøre programmene mer avhengig av andre programmer, og dermed øke kravet til installert program (f.eks. komprimeringsprogram) som må fungere like sømløst som pythonspråket i seg selv på tvers av plattformer Løsningens skalerbarhet, forbedringer? Løsningen kan kun håndtere en jobb av gangen, det vil også si at løsningen kun kan ta hånd om en klient av gangen. Ved å implementere en egen kø for klienter som ønsker å få sine jobber utført eller som antydet tidligere å la alle klienter dele tilgangen til prosesseringsressursene.

7 I kontrolleren er det innstilt at hver jobb skal deles opp i 20 småjobber. Dersom kontrolleren har tilgang til 20 like raske droner, vil det å legge til flere droner gi null i økt ytelse på prosess eringskapasiteten. Dette kan forbedres på ved å enten implementere at flere jobber kan utføres samtidig eller å dynamisk justere dette tallet etter antallet tilgjengelige droner. Løsningens feiltoleranse, forbedringer? Løsningen tolererer ingen feil på de tingene som blir utført av TOS, eller medfølgende utvidelser. Ser ikke at TOS på nåværende tidspunkt implementerer noen funksjon som muliggjør at vi kan gjøre noe med disse feilene, annet enn å kreve kvitteringer for all utvekslet informasjon (noe av poenget med å benytte TOS hadde i så fall delvis opphørt å eksistere). Ingen toleranse ovenfor feil i povray filen som skal raytraces. Dette kan på nåværende tidspunkt oppdages av dronen, men dette burde etter hvert implementeres helt frem til klienten ved å gjøre dette kunne det også muliggjøres at klienten skal kunne spesifisere parametere til povray. Utvidelsen fd ser ut til å feile dersom en krasjet drone startes på nytt igjen innen kort tid (rundt 30s). En mulig grunn til dette er at TOS i seg selv ennå ikke har oppdaget at en nettverkskobling døde og rukket å rydde opp i det før den samme koblingen gjenopptas.