FAQ - Hjemmeeksamen 2

Q) Kan jeg få et eksempel til på hvordan ackingen og det der fungerer?

A) Mottaker sender ack for alle pakker, men ack-nr er hele tiden det siste som ble mottatt i en sammenhengende strøm av data.
Altså hvis mottaker får pakke 0 1 2 3 4 6 7 8 (5 mangler), sendes ack 0 1 2 3 4 4 4 4.
Når disse ackene kommer, slettes 0 1 2 3 4 fra sendebufferet.
Retransmiteringstimer fører da etter hvert til at pakke 5 timer ut. Da sendes 5 6 7 8 på nytt (alle de som ligger i sendebufferet, som ikke er acket).
Hvis alle disse kommer fram, sendes ack 5 6 7 8.

En ack gjelder for alle pakker med lavere nummer også, ikke bare den ene pakken. Så hvis de fire siste ackene (5 6 7 8) hadde kommet fram som bare (5 7 8) ville fortsatt pakke 6 vært acket, siden 7 og 8 gjelder for 6 også. Acker for pakker som allerede er acket (kan skje ved forsinkelse eller ombytting av rekkefølge på pakker) skal bare ignoreres.

Hver gang du sender en pakke, og det ikke er noen timer kjørende, starter du en timer for den pakken.
Når timeren går ut, sender du *alle* pakker som ligger i sendebufferet og sletter så alle pakkene. Neste gang du sender en pakke, vil det da startes en ny timer for den pakken.
[Dette avsnittet er oppdatert, opprinnelig tekst ga samme resultat på en mer tungvindt måte.]

Q) Kan vi endre headeren som står i oppgaven?

A) Nei. Men se på det som at headeren vist der er del av en egen transportprotokoll, som ligger oppå UDP i en nettverkstack som har to transportprotokoller. La den være som den er. Derimot kan du lage din egen protokoll oppå der igjen, med din egen header som inneholder alt du trenger. I praksis blir jo det som at du utvider den headeren du ser med flere felt etter de som er vist, men det er en viktig forskjell i at det er to separate protokoller som kan behandles i forskjellige steg.
 

Q) Skal klienten også bruke Reliable-UDP på det den sender?

A) Ja, både server og klient skal sende og motta alt over UDP med Reliable-UDP-laget oppå. Begge sender altså ack-er på det den andre sender, osv.

Q) Hva skjer hvis en kommandopakke ikke kommer fram?

A) Da blir ikke kommandoen utført.

Q) Må vi beholde implementasjonen fra H1 som gjør at klient og server støtter flere klienter/servere? Eller kan vi fjerne denne funksjonaliteten, slik at vi bare støtter en-til-en-tilkoblinger?

A) Dere kan redusere funksjonaliteten. Det holder at serveren tar i mot én klient, og at klienten kun kan kobles opp mot én server.

Q) Hvis en pakke blir tapt to ganger stopper jo mottakeren helt opp?

A) Korrekt. Det ble sendt ut epost om dette. Dere trenger ikke ta hensyn til det, men vil få ekstrapoeng hvis dere gjør det. Det finnes flere mulige løsninger, og det er i så fall opp til dere hvordan dere løser det. Vær kreative!

Q) Protokollen som er beskrevet i oppgaven kalles "Reliable-UDP", men den er vel ikke pålitelig?

A) Nei, den er ikke pålitelig i det hele tatt. Den er bare litt mer pålitelig enn ren UDP.

Q) Hvordan skal vi nå kunne la serveren håndtere mange klienter, når vi ikke skal bruke listen() og accept()? Kan vi ikke forke?

A) Dere trenger ikke støtte flere klienter i det hele tatt. Men det er to måter å gjøre det på hvis dere vil.
- Dere kan gjøre det som før, der serveren forker en ny prosess som håndterer hver klient. Det må bare gjøres litt anderledes, siden dere nå ikke skal bruke listen og accept. I stedet har dere en UDP-port hvor serveren kontinuerlig lytter etter pakker. Når det kommer en "tilkoblingspakke" (som du definerer) fra en klient, forker serveren og oppretter en ny UDP-port den starter å lytte på, og sender portnummeret til klienten som deretter sender data dit.
- Dere kan også la serveren ha én port som alle pakker går til, og så se på pakkenes avsenderadresse og -portnummer for å skille mellom klientene.
 

Q) Må vi fortsatt ha to socketer, en for data og en for kontrollmeldinger?

A) Nei. Data og kontrollmeldinger kan sendes om hverandre på samme UDP-socket, så lenge du har en protokoll som skiller dem.

Q) Hvordan bruker man 'tc'?

A) Se feks http://www.topwebhosts.org/tools/traffic-control.php. Men man må være root, så det fungerer bare på egen maskin, ikke på ifi.

Et godt alternativ er å lage en egen versjon av sendto(), feks kalt sendo_unstable(), som tar de samme parameterene som sendto(). Den skal bare kalle på den ekte sendto() med de samme parameterene, men du kan da bruke rand() til å droppe å kalle på sendto() for tilfeldig pakker, og evt også ha en kø og en timer for å forsinke og/eller endre rekkefølgen på pakker.