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.