IN4230 - Hjemmeeksamen 2 - Høst 2019
Transportlag


 

Formelt

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

 

Oppgave

Innledning

Målet med denne oppgaven er å implementere MIPTP, en transportprotokoll for pålitelig dataoverføring over MIP, og en enkel applikasjon som benytter MIPT. 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.

Du skal skrive tre programmer:

  1. Et transportdaemon, som kjører permanent på alle hostmaskiner. Dette daemonet kan:
    • Motta data, et portnummer og en destinasjons-MIP-adresse over IPC med en Unix domain socket fra en applikasjon som kjører på samme fysiske host (med socketfunksjoner som send(..) / recv(..) ). Daemonet tilføyer en header til dataene og sender hele MIPTP pakken gjennom sin lokale MIP daemon til MIPTP-daemonet som kjører på den angitte MIP-destinasjonshosten.
    • Motta MIPTP-pakker fra MIP-daemonet 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å samme host. For enkelhetens skyld antas at kilde- og destinasjonsapplikasjon bruker det samme portnummeret for én overføring.

Transportdaemonet får oppgitt en timeoutverdi i sekunder som kommandolinjeargument. Hvis transportdaemonet kjøres i debugmodus (også et kommandolinjeargument) skal hver kommunikasjonshendelse loggføres i konsollen sammen med relevant statusinformasjon (pakker som ble sendt eller mottatt, aktuelle vindusstørrelser osv.).

  1. En filoverføringsserver, som mottar filer over IPC fra dens lokale MIPTP daemon og skriver den til filsystemet med filnavn som inneholder et økende tall (f.eks. receivedFile1, receivedFile2, ..). Hver overføring begynner med to bytes som inneholder størrelsen til filen. Ett portnummer som serveren vil lytte på angis som kommandolinjeargument. OBS: portnummeret til serveren må være samme portnummeret som brukes av klienten. Dette betyr at å lytte på to porter kan muliggjøre å motta to filer samtidig. Filoverføringsserveren skal ikke kommunisere direkte med MIP-daemonet, kun med MIPTP-daemonet.
  2. En filoverføringsklient, som leser en fil fra filsystemet og sender størrelsen til filen i bytes (maksimum 65535) som en to byte lang melding etterfulgt av selve filen (over IPC til den lokale MIPTP daemonen, som sender den videre). Filnavnet, destination-MIP-addressen og portnummeret angis som kommandolinjeargumenter. Filoverføringsklienten skal ikke kommunisere direkte med MIP-daemonet, kun med MIPTP-daemonet.

Det må være mulig å overføre to filer fra samme kildemaskin til samme mottakermaskin samtidig ved hjelp av to klienter og servere.

 

Detaljer

MIPTP-daemonet 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:

MIPTP header: 2 PL bits, followed by 14 port bits, followed by 16 bit sequence number.

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.

Siden den største mulige pakken som kan sendes over Ethernet 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-nyttelast i bytes kan beregnes ved hjelp av verdien angitt i “payload length”-feltet i MIP-headeren: den er (MIP_payload_length-1)*4.

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 dersom størrelsen av MIPTP-nyttelasten ikke resulterer i en slik en pakke. Hvis ikke størrelsen av den overførte datablokken kan deles med 4, så må det legges til 1, 2 eller 3 bytes i slutten av pakken som egentlig ikke er en del av nyttelasten. Disse bytene 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". De skal settes lik 0, og verdien til PL feltet skal være 3 (binær 11).

En MIPTP-sender implementerer Go-Back-N strategien med en fast vindustørrelse på 10 pakker for å sende data. 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 angitt i pakkeheaderen. Hvis pakker kommer frem til MIPTP-daemonet 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 ved rask utsendelse, det kan unngås ved å vente f. eks. 10ms med sleep(..) mellom hver gang en pakke sendes.

 

Du skal levere følgende:

  1. Et designdokument som inneholder:

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

    • Detaljerte svar på disse spørsmålene:
      • Hvilket problem oppstår dersom to filer sendes samtidig fra to forskjellige kilder til den samme mottakeren og 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 timeoutverdien beregnes automatisk, slik at den ikke trengs som kommandolinjeargument?
    • En beskrivelse av hvordan programmet er designet. Gjerne med en tegning (flytdiagram) som viser i hvilken rekkefølge de forskjellige funksjonene blir kalt.

    • 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 programmene kjøres. Dokumentér alle variabler og definisjoner. For hver funksjon i programmet skal følgende dokumenteres:

    • Hva funksjonen gjør.

    • Hva inn- og utparametre betyr og brukes til.

    • Hvilke globale variabler funksjonen endrer.

    • Hva funksjonen returnerer.

Om poengfordelingen:

 

Spesifike krav til koden

Koden din skal kompileres på og vil bli testet i samme miljø som den obligatoriske oppgaven og hjemmeeksamen 1, på UH-IaaS.

 

Administrative spørsmål

Får du problemer under implementasjonen anbefaler vi deg å benytte deg godt av orakeltimene, samt sjekke FAQ på emnesiden.

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

 

Besvarelse

Designdokumentet skal skrives vha. et egnet verktøy, f.eks. LaTeX, OpenOffice, Word, el. Dokumentet skal inneholde 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 for å oppfylle kravene som beskrevet under avsnittet "oppgave". Det som er viktig er å kunne dokumentere forståelse for de faglige temaene 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 én katalog med kandidatnummeret som navn. Av denne katalogen lager du en komprimert tar-ball. Den elektroniske innleveringen skal leveres i Inspera.

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

NB: Inspera har problemer med filnavn som ender på ".tar.gz", bruk filendingen ".tgz" istedenfor for å unngå problemer ved innlevering.

Innleveringsfrist: tirsdag 12. november 2019 kl 23:59.

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

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