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.).

2. 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.
3. 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:

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:

• Det gis ikke poeng for delene av obligen som gjenbrukes (f.eks. ARP).

• Ekstrapoeng:

  • Det er ikke veldig effektivt at mottakeren kaster pakker som kommer fram i feil rekkef?lge. Det gis ekstrapoeng hvis mottakeren ikke kaster dem, men heller setter slike pakker inn p? riktig plass i et mottaksbuffer. Det gis ytterligere ekstrapoeng hvis dette kombineres med Selective Repeat istedenfor Go-Back-N for ? forbedre ytelsen til systemet.

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.