INF3190 - Hjemmeeksamen 2 - Vår 2017
Transportlag

Formelt

Denne oppgaven er karaktergivende og skal løses individuelt. Karakteren som gis teller omlag 20 % på sluttkarakteren. Oppgaven blir vurdert etter hvor stor grad kravene i avsnittet "Oppgave" er oppfylt.

Oppgave

Innledning

Målet med denne oppgaven er å implementere MIPTP, en MIP transportprotokoll til pålitelig dataoverføring, og en enkel applikasjon som bruker den. MIPTP baseres på den obligatoriske oppgaven; hvis du har implementert hjemmeeksamen 1 bør det automatisk være mulig å sende data fra hvilken som helst host til en annen med MIPTP. Uten hjemmeeksamen 1 virker MIPTP bare mellom hosts som er direkte naboer. Det er like greit men kanskje litt kjedelig :-)

Du skal skrive tre programmer:

1. En transport daemon, som kjører permanent på alle hostmaskiner. Den daemonen kan:
   • Motta data, et portnummer og en destination-MIP-addresse gjennom IPC med en Unix domain socket fra en applikasjon som kjører på den samme fysiske host (med socket funksjoner som send(..) / recv(..) ). Daemonen tilføyer en header til dataene og sender hele MIPTP pakken gjennom sin lokale MIP daemon til en MIPTP daemon som kjører på en annen host, hvor MIP daemonen har den angitte MIP destination-addressen.
   • Motta MIPTP pakker fra MIP daemonen og gi data videre til en applikasjon som lytter på en lokal Unix domain socket via blokkerende “recv(..)” (eller lignende). Pakker ignoreres ("kastes") hvis ingen applikasjon venter på data fra nettet.

Portnumrene skiller flere applikasjoner på en host. For enkelhetens skyld antas at kilde- og destinasjons-applikasjon bruker det samme portnummeret for en overføring.

Transport daemonen får en timeout-verdi i sekunder som kommandolinjeargument. Hvis transport daemonen kjøres i "debug mode" (også et kommandolinjeargument) skal hver kommunikasjon protokolleres på konsollet med noe status informasjon (pakker som ble sendt eller mottatt, aktuelle vindustørrelser osv.).

2. En file transfer server, som mottar filer gjennom IPC fra dens lokale MIPTP daemon og skriver den til filsystemet med filnavner som inneholder et økende tall (f.eks. receivedFile1, receivedFile2, ..). Når data mottas, hver fil begynner med two bytes som inneholder størrelsen til filen. En eller to portnumre som server lytter på angis som kommandolinjeargumenter. OBS: portnummeret til server må også være portnummeret som brukes av klienten. Dette betyr at å lytte på to porter kan muliggjøre å motta to filer samtidig. File transfer serveren skal ikke kommunisere direkt med MIP daemon, kun med MIPTP daemon.
3. En file transfer client, som leser en fil fra filsystemet og sender størrelsen til filen i bytes (max.65535) som en to-bit melding etterfulgt av selve filen (gjennom IPC til den lokale MIPTP daemonen, som sender den videre). Filnavnet, destination-MIP-addressen og portnummeret angis som kommandolinjeargumenter. File transfer clienten skal ikke kommunisere direkt med MIP daemon, kun med MIPTP daemon.

Det må være mulig å overføre to filer fra den samme source-host til den samme receiver-host samtidig gjennom bruk av to file transfer clienter og en file transfer server.

Detaljer

MIPTP daemonen tilføyer MIPTP headeren før data sendes over nettverket. Headeren inneholder to “Padding Length” (PL) bits, et portnummer og et sekvensnummer (packet sequence number). MIPTP headeren ser slik ut:

Headeren er i big endian format, akkurat som alt annet i MIP (og MIPTP).

Hvis en MIPTP pakke ikke inneholder data, så er den kun en bekreftelsespakke ("ACK"). Den bekrefter å ha mottatt alle pakker opp til det angitte sekvensnummeret. "Payload Length" i MIP headeren av ACK-pakker er 1 (som betyr at lengden er et 32-bit tall, dvs. 4 byte). Siden den største mulige pakken har lengden 1500 bytes, er den største mulige datamengden som kan sendes i en MIPTP pakke 1492 byte (1500 minus lengden av MIP og MIPTP headere).  Lengden av MIPTP payload i bytes kan beregnes gjennom bruk av verdien som står i “payload length” feltet i MIP headeren: den er (MIP_payload_length-1)*4. For eksempel, en pakke med en total størrelse 16 bytes (som inkluderer 4 bytes MIP og 4 bytes MIPTP header) har MIP payload length 3, og den inneholder (3-1)*4 = 8 bytes data etter MIPTP headeren.

Siden lengden av alle MIP pakker må være delbare på 4 kan det oppstå problemer med noen størrelser av datablokken i en pakke. Hvis ikke størrelsen av den overførte datablokken kan deles med 4, så finnes det 1, 2 eller 3 bytes til slutt av pakken som egentlig ikke er en del av data. Disse bytes settes til 0, og kalles for “padding”. PL feltet (2 bits) inneholder lengden av padding i pakken. For eksempel, en 16-byte pakke som inneholder kun 5 bytes data inneholder 8 bytes etter headerne. Av disse 8 er de siste tre "padding". Deres verdiene er 0, og verdien til PL feltet er 3 (binær 11).

En MIPTP sender implementerer Go-Back-N strategien for å sende data med en fast vindustørrelse på 10 pakker. Sekvensnummerne tilsvarer pakker, dvs. pakke 1 får nummer 0, pakke 2 får nummer 1 osv. Hvis ingen ACK pakker kommer fram innenfor et gitt tidsrom (kommandolinjeargument "timeout"), antas alle pakker som ikke er bekreftet mottatt som tapte, og de sendes på nytt.

En MIPTP mottaker gir data i riktig rekkefølge til applikasjonen som lytter på den porten som tilsvarer nummeret i pakkeheaderen. Hvis pakker kommer fram i feil rekkefølge, er det et tegn på pakketap eller endring av rekkefølgen i nettet. MIPTP mottakeren skal i så fall ikke bekrefte noe, og kan kaste disse pakkene.

OBS: det er mulig at operativsystemet endrer rekkefølgen til pakker, og det kan unngås med å vente f. eks. 10ms med sleep(..) før en pakke sendes.

Du skal levere følgende:

1. Et designdokument som inneholder:

   • En frontside med kandidatnummer, oppgavetittel, kurs og semester. Vi vil ikke ha navn eller brukernavn.
      

   • Detaljerte svar til disse spørsmålene:
     • Hvilket problem oppstår dersom to filer sendes samtidig fra to forskjellige kilder til den samme mottakeren med bruk av port 30? Hvorfor? Hvordan kan problemet løses?
     • Hvordan løses problemet i Internett, f.eks. med tanke på en webserver som lytter på den samme porten (80) uansett hvor forbindelser kommer fra?
     • Hvordan kan timeout verdien beregnes automatisk, slik at den ikke trengs som kommandolinjeargument?

   • Hvordan programmet er designet. Gjerne med en tegning (flytdiagram) som viser i hvilken rekkefølge de forskjellige funksjonene blir kalt.

   • En dokumentasjon av hvordan programmet skal startes evt. avsluttes.

   • Hvilke filer programmet består av (C-filer, headerfiler osv.).

   • Eventuelle andre særegenheter.

2. Programfilene, hvor koden er fyldig kommentert (der det er nødvendig), og en README fil som inneholder kort informasjon om hvordan programmen kjøres. Dokumenter alle variable og definisjoner. For hver funksjon i programmet skal følgende dokumenteres:

   • Hva funksjonen gjør

   • Hva inn og ut parametre betyr og brukes til

   • Hvilke globale variable funksjonen endrer

   • Hva funksjonen returnerer

Om poengfordelingen:

• Det gis ikke poeng for delene av obligen som brukes (f.eks. ARP - men det er greit å erstatte ARP med statiske tabeller).

• Ekstra poeng:

  • Det er mulig men ikke veldig effektiv at mottakeren kaster pakker som kommer fram i feil rekkefølge. Det gis ekstra poeng hvis mottakeren ikke kaster dem, men setter senere pakker inn på riktig plass. Det gis enda mer ekstra poeng hvis dette kombineres med Selective Repeat istedenfor Go-Back-N for å forbedre ytelsen.

Spesifikke krav til koden

Koden din skal kompileres og vil bli testet med denne virtuelle maskinen.

Orakeltjeneste og administrative spørsmål

Får du problemer under implementasjonen anbefaler vi deg å sjekke FAQ på orakelsiden som ligger under INF3190 sin hjemmeside. Du kan også sende en mail til orakel med addressen inf3190-orakel [at] ifi.uio.no

For administrative spørsmål rundt hjemmeeksamen, ta kontakt med runabk [at] ifi.uio.no

Besvarelse

Designdokumentet skal skrives vha. et egnet verktøy, f.eks. LaTeX, OpenOffice, Word, osv. Dokumentet skal inneholde besvarelsen og alle etterspurte detaljer, samt ha en forside hvor følgende opplysninger er angitt: kandidatnummer, oppgavetittel, kurs og semester.
Før levering skal dokumentet konverteres til PDF format.

Omfanget av dokumentet trenger ikke nødvendigvis være så stort, men må inneholde tilstrekkelig informasjon til å oppfylle kravet som beskrevet under avsnittet oppgave. Det som er viktig er å kunne dokumentere forståelse for de emnene oppgaven berører, i tillegg til selve gjennomføringen. Vi stiller krav til ryddighet og struktur.

Elektronisk innlevering

Eksamen er anonym. Bruk idchecker.sh for å undersøke om navnet ditt er i koden (./idchecker.sh dittBrukernavn og ./idchecker.sh enLitenDelAvDittNavn). Scriptet undersøker om navnet ditt eksisterer i .tex, .c, .h og .txt-filer i mappa (husk å legge til eventuelle andre filformater du bruker). Det er ditt ansvar ansvar at din innlevering ikke inneholder personlig informasjon.

Alt skal leveres elektronisk hvor alle filer (Makefile, *.c, *.h, design.pdf, README.txt, etc.) er samlet i en katalog med kandidatnummeret som navn. Av denne katalogen lager du en komprimert tar-ball. Den elektroniske innleveringen skal leveres via web. Linken Innlevering av oppgaven finnes på kursets hjemmeside.

Etter innlevering anbefales det å laste ned arkivet du leverte inn, extracte det og undersøke at alt fungerer (inkludert at README og design er med). Det anbefales også å levere inn utkast av eksamnen i god tid før fristen i tilfelle du får tekniske problemer eller gjør en alvorlig feil rett før innlevering.

Innleveringsfrist: Torsdag 27. april 2017 kl 23:59:59

Merk at denne tidsfirsten er HARD, oppgaver levert etter fristen vurderes med karakteren "F", altså stryk.

Det forutsettes at studenten har lest forskrift om studier og eksamener ved Universitetet i Oslo for karaktergivende oppgaver.