Datalogi 1F rapportopgave K2: Implementering af en datanet protokolstak

Datalogi 1F rapportopgave K2: Implementering af en datanet protokolstak 12. april 2002 Resumé Rapportopgave K2 stilles fredag den 12. april 2002 og skal afleveres senest mandag den 13. maj 2002 kl. 14.00 i DIKU s 1.dels-administration, Universitetsparken 1. Besvarelser, der sendes med posten, skal være DIKU i hænde senest ved afleveringsfristens udløb. Besvarelser kan udarbejdes individuelt eller i grupper på to eller tre deltagere. Den skriftlige fremstilling indgår som en del af bedømmelsen af rapporten. Vigtige meddelelser vedrørende denne opgave vil blive meddelt i kursets nyhedsgruppe (diku.dat1f ) og på kursets WWW side <URL:http://www.diku.dk/teaching/2002f/dat1f/index.html>. Ændringer meddelt på opslagstavlen, i nyhedsgruppen og på hjemmesiden, underskrevet NEL, er obligatoriske. Plan for instruktorvagt vil ligeledes blive slået op elektronisk. Indhold 1 Kort om opgaven 2 2 Baggrund 2 2.1 SRDF Scenarie...................................... 3 3 Designovervejelser 3 4 Forenklende forudsætninger 3 5 Omgivelser 4 5.1 Andre grupper...................................... 4 6 Komponenter 4 6.1 OSI Lag 1 og 2...................................... 4 6.2 OSI Lag 3 og 4...................................... 4 6.3 OSI Lag 5 og 6...................................... 4 6.4 OSI Lag 7 - Applikationer................................ 4 7 Design og implementering 5 7.1 Kerne........................................... 5 7.2 Kerne/brugermodus................................... 5 8 Krav til besvarelsen 5 9 Bilag 6 1

1 Kort om opgaven Formålet med opgaven er dels at give de studerende indsigt i datanet og deres realisering ved at implementere et miniaturenet, dels at give en praktisk opgave og dels at de studerende får erfaring i realisering af et system, der skal være kompatibelt med andre implementeringer og derfor skal overholde nogle standarder. Opgaven går ud på at designe, implementere og dokumentere en simpel, replikeret, distribueret filserver (SRDF). Applikationer, der ønsker at gemme en fil, kalder en SRDF, der sørger for at distribuere filer ud på så mange SRDF er som muligt. Når en applikation skal bruge en fil, kalder den en SRDF. Filer har logiske tidsstempler som styres af applikationerne. Når en fil skal hentes, skaffer SRDF det tilgængelige replika med det største tidsstempel. Hvis der er flere replika med samme tidsstempel kan SRDF en frit vælge et af dem; medmindre et af dem er lokalt, så vælges dette. Da forskellige implementationer skal kunne kommunikere, ligesom det er ønskeligt at en applikationsproces udviklet af andre, kan anvende en given implementering, er det nødvendigt at der fastlægges nogle standardiserede grænseflader og protokoller, og at der stilles minimumskrav af funktionel art. Disse er beskrevet nedenfor. SRDF overfører filer med SFOOP (Simpel ForbindelsesOrienteret Protokol) og bruger DFLUP (Distribueret Fil opslag) til at finde filer på andre hosts. Det er et krav, at det dokumenteres at implementationen kan køre og kommunikere med andre, og rapporten skal have en acceptabel standard, herunder en omhyggelig analyse, jvf. afsnit 8. Den skriftlige fremstilling indgår som en del af bedømmelsen af rapporten. 2 Baggrund Da implementationen skal være modulær og åben, må vi fastlægge visse protokoller og grænseflader på forhånd. Dette er gjort i bilaget Interface- og protokolspecifikationer og præciseret i afsnittene nedenfor. Der anvendes i teksten forskellige forkortelser, som er forklaret her: NA Net Adapter FS Fil Server NE Net Entitet, OSI lag 3. Udgør sammen med TE lag 3,4 stak TE Transport Entitet, OSI lag 4. Udgør sammen med NE lag 3,4 stak TS Transport Service grænseflade PA-xxx Protokol mellem applikationer af typen xxx PDU Protokol Data Unit NETP Net Protokol, lag 3 (a la Internet IP) FOLEP Forbindelsesløs Protokol, lag 4 (a la Internet UDP) SFOOP Forbindelsesorienteret Protokol, lag 4 RUXP Ruteinformations udvekslingsprotokol MALUP MAC adresse opslagsprotokol, lag 2/3 (a la Internet ARP) DFLUP Fil opslagsprotokol FUP FilUdvekslingsProtokol SRDF Simpel, distribueret filserver 2

2.1 SRDF Scenarie 1. En applikation på maskinen Anne opretter filen foo. Det gør den med en skriveoperation på Annes SRDF. 2. Annes SRDF skal nu sende foo til alle kernemaskiner. For at finde de andre maskiner, sender Anne en DFLUP request og venter på svar fra de andre maskiner. 3. Anne kan ikke vente evigt på svar. Men inden der kommer et time-out, har Anne fået svar fra maskinerne Benny, Carl og Dorthe. 4. Anne sender nu foo til Benny, Carl og Dorthe med protokollen FUP. Det mislykkes at sende foo til Carl (Carls SRDF er nok lavet af en anden gruppe), men da foo er gemt på både Benny og Dorthe, returnerer Annes SRDF SUCCES til applikationen. 5. En time senere vil en applikation på maskinen Einar læse foo. Einars SRDF søger efter foo med en DFLUP request. Inden time-out svarer Anne og Benny at de har foo, begge version 42. 6. Einers SRDF vælger Benny, henter filen fra Benny med FUP og returnerer SUCCES til applikationen 3 Designovervejelser Når en DFLUP request er sendt, ventes der på svar. Der kan altid komme et svar med et højere tidsstempel. Da man ikke kan vente evigt, må man på et tidspunkt holde op med at vente og returnere til applikationen. Filsystemet på hver maskine har en begrænset størrelse. Da alle andre maskiner kan sende filer til andre maskiner, kan et filsystem hurtigt blive fyldt. Det kan håndteres ved fx at nægte at modtage filer, slette filer (cache funktionalitet) eller flytte filer til andre maskiner. 4 Forenklende forudsætninger Filserveren kaldes simpel fordi der af hensyn til opgavens størrelse er sat følgende begrænsninger. Kun filer gemmes Dvs, SRDF håndterer ikke kataloger. Filer identificeres ved et navn Hver fil har et navn på højst 128 tegn. Hele Filer SRDF overfører hele filer. Fejlhåndtering på filniveau Hvis der opstår fejl under en filoverførsel, afbrydes hele operationen og genstartes evt. Dvs., der er ingen retransmissioner. Ingen versioner af filer Dvs, hvis filer med samme navn findes på flere servere, antages det at være den samme fil. Applikationer kan undgå navnesammenfald ved at lade et unikt ID indgå i filnavnet (fx gruppenummer). For at holde mængden af kode på et acceptabelt niveau kan der herudover gøres en række forenklende forudsætninger; det er tilladt at forenkle endnu mere med passende vægtig argumentation, hvis resultatet ikke så mister forbindelsen med den virkelige verden. Det kan antages, at de enkelte maskiner kun er lavt belastede det totale system kun omfatter DIKU s kerne-alpha er (max. 10 stk) og det tilhørende dedikerede net 3

fejlsituationer i et vist omfang kan klares ved at kaste pakker væk der ikke skal tages hensyn til exceptions, der opstår ved programmets afvikling Det kan derimod ikke antages, at det er muligt for alle maskiner at nå alle andre (se 6.2). Det kan heller ikke antages, at alle maskiner er oppe på samme tidspunkt, eller at de er stabilt i drift i længere perioder. 5 Omgivelser Udviklingsomgivelserne fra rapportopgave K1 benyttes uforandret. Der må på stærkt belastede tidspunkter kun anvendes én kerne-alpha ad gangen pr. gruppe, medmindre det er nødvendigt for at afprøve protokolstakken. Da DEBUG ikke er velegnet til andet end post-mortem analyser i denne opgave, bør der anvendes andre testværktøjer ved indkøringen, fx sporing i intern buffer eller udskrift på COM port. 5.1 Andre grupper Der opfordres til at grupperne samarbejder om afprøvning af protokollerne. Dels giver det mindre belastning af kernemaskinerne, dels kan det øge tilliden til at implementationerne overholder protokollerne. 6 Komponenter 6.1 OSI Lag 1 og 2 Da der anvendes et netkort, som kan lag 1 og 2, er der ingen særskilte krav, ud over at de benyttede MAC adresser skal være korrekte. 6.2 OSI Lag 3 og 4 NETP, FOLEP og SFOOP skal implementeres. Beregning og check af NETP checksum skal ikke understøttes. Beskeder modtages enten fra en lokal applikation via TS grænsefladen eller fra en fjern applikation i protokollerne NETP og FOLEP/SFOOP via netadapteren. På grundlag af modtageradressen afleveres beskeden enten lokalt, eller den sendes til en anden maskine, der er nærmere bestemmelsesstedet. Den skitserede algoritme skal styres af en tabel over afstande eller lignende, og fungere uafhængigt af nettets topologi. Tabellen kan i denne opgave være statisk og lokal. 6.3 OSI Lag 5 og 6 Disse lag er tomme. 6.4 OSI Lag 7 - Applikationer Der er mange mulige applikationer, idet systemet er et generelt system til interproceskommunikation. SRDF er det eneste, der skal implementeres. Der udleveres (som kildekode) EKKO, SINK, SOURCE og TELEX. Her er en kort liste, sorteret alfabetisk. Applikationerne mærket ja i søjlen Afprøvning? kan bruges til test af implementationen, og protokollerne skal understøtte dem fuldt ud. For applikationer mærket * udleveres der C kode. 4

Betegnelse Afprøvning? Beskrivelse EKKO ja* Sender besked tilbage (med tilføjelse af stempel) SRDF klient ja replikeret filsystem SINK ja* Aftager af beskeder - de smides væk SOURCE ja* Kilde til en stadig strøm af beskeder TELEX ja* Interaktivt program, der kan sende en besked Uendeligt cirkulerende beskeder og ukontrolleret mangfoldiggørelse af beskeder er i al almindelighed noget, der skal undgås. Applikationer kan enten realiseres som processer, der kommunikerer med transport-entiteten gennem TS (kaldet eksterne applikationer), eller de kan implementeres i direkte tilknytning til transport-entiteten (interne), og så er der ikke krav om at TS overholdes. TS skal imidlertid implementeres, således at applikationer fra andre grupper kan lænkes sammen med ens egen gruppes transport-entitet og køres. Der skal skrives en SRDF klient, som kan bruges til at afprøve SRDF og DFLUP. 7 Design og implementering 7.1 Kerne Kerne og grænseflade fra K1 skal benyttes. Kernen må gerne ændres så længe grænsefladen overholdes. For grupper, der ikke har en stabilt kørende kerne, vil der blive stillet en til rådighed. 7.2 Kerne/brugermodus Protokolstakken og applikationerne afvikles i brugermodus, så kun kernen kører i kerne-modus. En komponent vil ikke nødvendigvis svare til en proces. Der er ikke foreskrevet en bestemt processtruktur i løsningen, men hvis applikationer skal kunne flyttes eller udskiftes, er det naturligt at implementere hver som en proces (evt. flere). Dette er dog ikke et krav. Den valgte processtruktur skal begrundes. Det skal fastlægges, hvorledes processer kommunikerer indbyrdes. I bilaget Valg af antal processer skitseres nogle mulighed for antallet af processer. Det anbefales at anvende beskedsemaforer til kommunikation mellem processerne. For at undgå kontekstskift kan man bruge mulighed N fra bilaget: én proces pr. hændelse. 8 Krav til besvarelsen De ovenfor nævnte obligatoriske elementer NETP, FOLEP, SFOOP og TS skal designes, implementeres og dokumenteres. Applikationerne EKKO, SINK, SOURCE og TELEX skal kunne afvikles. SRDF og DFLUP skal implementeres og dokumenteres. En implementation skal kunne kommunikere på acceptabel vis (dvs. uden at omgivelserne generes). Det skal af rapporten tydeligt fremgå, hvilken fremgangsmåde, der er anvendt ved afprøvningen. Der skal skrives en rapport (højst 30 sider) og hertil de nødvendige bilag med hovedvægt på design, analyse og overordnet dokumentation af implementationen. Afprøvning skal beskrives uden detaljer (men dog med screendumps) og med angivelse af overordnet metode og med en klar konklusion med hensyn til hvad der virker og implementationens begrænsninger, fejl og funktionsduelighed. Der skal være kortfattede brugsvejledninger for udviklede programmer, i det omfang det er relevant. Herudover lægges der vægt på at der i rapporten er overvejelser om: 5

9 Bilag Processtruktur, dvs. antal og funktionsmæssig berettigelse; hertil angivelse af ventepunkter (hvor en proces blokerer) og den opnåede parallelitet og mulige flaskehalse ved høj belastning Dataflow i implementationen, dvs. en buffers vej gennem systemet med angivelse af køer og kopiering af data; herudover valg af antal buffere, allokering og deallokering af buffere Der skal redegøres for de trufne valg, hvor specifikationen lader detaljer stå åbent (fx i SFOOP og SRDF) Det valgte design for TS-modulet skal omhyggeligt begrundes Egenskaber ved SRDF skal vurderes. Redegør for konsistensproblemer i SRDF og overvej hvad SRDF kunne anvendes til. HTML-dokumentet Interface- og protokolspecifikationer er vedlagt. Ligeledes de to dokumenter Skitse af en klassestruktur og Valg af antal processer. Kildetekster med forskellige hjælpefunktioner, applikationer samt kørende kerne mv. offentliggøres via URL: http://www.diku.dk/teaching/2002f/dat1f/index.html. 6