KTN1 - Design av forbindelsesorientert protokoll Beskrivelse av A1 A1 skal tilby en pålitelig, forbindelsesorientert tjeneste over en upålitelig, forbindelsesløs tjeneste A2. Det er flere ting A1 må implementere for å få til dette: 1. A1 må kunne opprette en forbindelse til en annen A1-instans 2. A1 må sikre at pakker mottas i riktig rekkefølge. 3. A1 må håndtere feil i A2. Feil kan være enten pakketap eller bitfeil. Forbindelse A1-instanser kan opprette forbindelse mellom hverandre ved å starte en "three way handshake". En A1-instans sender en SYN-melding for å signalisere at den er interessert i å kommunisere med mottaker. Mottakeren er en annen A1-instans som ligger å lytter på nettverket. Den fanger opp SYN-meldingen og responderer med en SYNACK. Sender responderer med en ACK, kommunikasjonen kan starte. Rekkefølge Vi bruker sekvensnummer på pakkene (KTNDatagram) for at mottaker skal kunne levere data til applikasjonen i riktig rekkefølge. Mottaker sender en bekreftelse (ACK) på siste mottatte pakke, og signaliserer da hvilket sekvensnummer på pakken den forventer neste gang. Bruk av buffere A1 skal benytte seg av selective repeat for forbedret overføringshastighet. Det vil si at A1 skal ta vare på mottatte pakker som er større enn det sekvensnummeret som forventes neste gang, og som har plass i A1 sitt buffervindu.
A1 må altså implementere en bufferfunksjonalitet for å ta vare på pakker som forventes senere, men ikke neste gang. Senderen skal hele tiden sende den neste pakken som den ikke har fått en ACK fra. Mottakeren skal hele tiden ACK-e den første pakken i sekvensen hvor neste pakke ikke er mottatt. Dersom A1 mottar 1 2 4 5 6 3 sendes ACK på 1, 2, deretter buffres 4, 5 og 6 samtidig som det sendes ACK på 3, og til slutt sendes ACK på 6, siden 3 tettet "hullet" i sekvensen. Dersom sekvensnummeret er for høyt til å få plass i bufferet må pakken forkastes. For hver pakke som mottas må vi sjekke om neste pakke ligger lagret i bufferen fra før. Hvis pakken ikke befinner seg i bufferet ber vi om den neste i sekvensen. Hvis den neste pakken allerede er mottatt går vi igjennom bufferet og sjekker hvilken pakke vi trenger. Pakketap Pakker kan forsvinne i nettverket, da må A1 som sender skjønne dette og sende pakken på nytt. Dette krever at en annen A1-instans, mottaker, sender en bekreftelse (ACK) på at pakken faktisk er mottatt. For at dette ikke skal gå i en evik løkke med bekreftelser på at ting er mottatt, må sender også ha en timer. Når en pakke er sendt og timeren når 0 uten at ACK er mottatt, antar sender at pakken er tapt (men ACK-en kan også være tapt!) og sender på nytt. Dette betyr at A1 kan risikere å motta duplikater av pakker, som forkastes av mottaker. Bitfeil En enkel måte å detektere bitfeil på er ved hjelp av en checksum. Det eksisterer et checksumfelt i headeren til pakkene (KTNDatagram), som mottakeren kan bruke til å avgjøre om pakken er korrekt sendt. Dersom feil oppdages kan mottaker ignorere den, og sender vil etter hvert prøve å sende pakken på nytt siden den tolkes som tapt. Eventuelt kan mottaker sende en ACK som om pakken ikke var mottatt, altså en ACK på forrige korrekt mottatte pakke. Å sende en pakke som sier at pakken ikke var ok, altså en NACK, er også en mulighet. Å sende et svar tilbake til senderen gjør at sender tidligere finner ut at noe må sendes på nytt. Sender slipper da å vente til timeren når 0 før den kan sende på nytt.
Tilstandsdiagram Figur 1 og 2 viser A1 sine tilstander hhv. for sender og mottaker. Figur 1: Sender. I utgangspunktet er det ingen forbindelse; CLOSED. A1 initierer en forbindelse med en annen instans av A1 gjennom å sende en SYN-melding. Når A1 har mottatt en bekreftelse på at SYN er mottat (SYNACK), og sendt en ACK på det, er forbindelsen opprettet (ESTABLISHED). For å lukke forbindelsen sender A1 en FIN-pakke. Etter en bekreftelse på at denne er mottatt venter A1 på at mottaker også sender FIN, forbindelsen er avsluttet. Figur 2: Mottaker. I det øyeblikket en applikasjon lager en socket i form av en A1-instans går A1 i LISTENmodus. En SYN-melding blir akseptert og etter samme "three way handshake" som beskrevet overfor går A1 i ESTABLISHED tilstand. A1 avlutter tilkoblingen idet den mottar en FIN-melding.
Interaksjon med A2 Figurene 1 til 6 viser scenarioer for oppkobling, sending og nedkobling både for serverside og klient. Merk at vi har droppet en del mindre vesentlige metodekall, blant annet alle new-kallene til ClSocket (A2) og Timer-klassen. Hovedpoenget er uansett å få fram hvordan applikasjonen går via A1 og hvordan A2 bruker metoder i A2. Vi har sett bort ifra feiltilfeller her, alle pakker som sendes kommer fram, uten bitfeil. Dersom feil oppstår skal A1 ta seg av det, det vil være usynlig for applikasjonen. Figur 3: Koble til host Applikasjonen vil koble til oppgitt host-ip og -port. A1 sender en SYN-melding og mottar bekreftelse på at denne er mottatt.
Figur 4: Applikasjon aksepterer tilkobling Applikasjonen kaller accept() på A1, som venter på en SYN-melding via en ClSocketReceiver-instans. Når den er mottatt sendes en SYNACK-melding tilbake.
Figur 5: Applikasjon sender data Applikasjonen vil sende en streng med data. A1 kaller sin egen senddatapacketwithretransmit(...) som sender på nytt og på nytt hvis ACK ikke dukker opp. En egen prosess (SendTimer) sørger for å sende, mens en annen prosess tar imot ACK.
Figur 6: Applikasjon mottar data Applikasjonen kaller receive() på A1. A1 fyrer opp en tråd (ClSocketReceiver) som kaller receive() på A2, helt til A2 svarer med et KTNDatagram. A1 henter datagramet, sender ACK og leverer innholdet til applikasjonen.
Figur 7: Klient kobler fra Applikasjonen caller close() på A1, som lager en pakke med flagg FIN og sender denne til A2, ved hjelp av SendTimer, og venter på en ACK ved å sende recieve() til A2. Deretter venter A1 på en FIN-pakke i retur, og responderer ved å sende en ACK til A2.
Figur 8: Tjener kobler fra Tjeneren (A1) mottar en FIN-pakke, som den henter ved å kalle recieve() på A2. A1 sender en ACK i retur ved å kalle send(...) på A2. En FIN-pakke opprettes vha. constructinternaldatapacket(...) og sendes ved hjelp av en SendTimer som kaller send(...) på A2, og venter på en ACK ved å kalle recieve() på A2.
Interaksjon med Admin Under utvikling og testing kan vi sette parametre på de forskjellige feiltypene gjennom Admin. Logging av hendelser i A1 og A2 går gjennom Admin. Feilhåndtering Nedenfor har vi kort oppsumert hvilke feil A2 kan gi, og hva vi har tenkt å gjøre med A1 for å fikse det. Feil Årsak Løsning Pakketap Forsinket pakke Pakken har feil "Ghost"-pakke Pakken kommer ikke fram, blir tapt i nettverket. Pakken ble forsinket, men kommer fram etter en viss tid. Pakken ble endret under overføring i nettverket, noen bit er forandret. En pakke dukker opp, med protokollhode som tilsier at den er ment for denne maskinen. Den blir tatt i mot. A1 har en timer for hver pakke. Hvis ingen ACK mottas sendes pakken på nytt etter timeout. A1 buffrer pakker som ikke kommer in-order, men fortsetter å sende ACK på første pakke den mangler. Hvis A1 har pakkene 1 2 4 5 6, og 3 kommer etter en stund, kan A1 sende ACK på 6. Duplikater forkastes. Beregn checksum og sammenlign med eget checksum-felt i protokollhode. Dersom det er feil, send ACK på forrige riktig mottatte. Checksum er derimot ikke garantert å oppdage bitfeil. Når ghost pakke ankommer må vi sjekke hvor den kom fra, og hvilken adresse den var ment til. Videre må vi sjekke om portnummeret stemmer. Men som regel vil ghost packet ha feil checksum. Hvis sekvensnummer er helt galt, og A1 kan utelukke forsinket pakke, forkastes pakken. Dersom alt virker greit har ikke A1 noe annet valg enn å godta pakken.
Testplan Testene 1 til 6 tester om A1 fungerer som den skal uten feil i A2. id Formål med testen 1 Be om en oppkobling mot en annen maskin (server) 2 3 4 5 6 Respondere på en SYN_ACKpakke fra server Be om en datapakke fra server til klient Klient starter avslutning av oppkobling til server Server responderer på avslutningen Klient kan avslutte oppkobling mot tjener Systemets tilstand To instanser av A1 er opprettet Klient er i status SYN_SENT To instanser av A1 er opprettet og koblet sammen To instanser av A1 er opprettet og koblet sammen Server er i CLOSE_WAIT og har ventet en definert tid Klient er i status FIN_WAIT2 Input (handlinger) 1. IP-adresse og portnummer til en annen maskin. Sender en SYN-pakke til server 1. Klient mottar en SYN_ACK-pakke fra server 1. Klient sender en pakke med seq = det neste sekvensnummeret klient forventer 1. Klient sender en FIN-pakke Server sender en FINpakke til klient, setter seg i LAST_ACK 1. Mottar en FIN-pakke fra server Respons (handlinger) 1. Mottar en SYN_ACK-pakke fra server 1. Returnere en ACK, setter seg selv i ESTABLISHED 1. Den riktige datapakken fra server (riktig seqnummer). 2. Checksum matcher 1. Klient mottar en ACK-pakke tilbake, setter seg selv i CLOSE_WAIT Mottar en ACK fra klient, avslutter oppkoblingen. 1. Klient sender en Ack tilbake til server. 2. Klient setter seg i TIME_WAIT 2. Klient venter en definert tid og avslutter så oppkobling
Testing med feil Vi tester om A1 håndterer feil ved å lage en applikasjon som sender 100 pakker, og verifiserer at alt kommer fram med riktig innhold. Forventet resultat er i alle tilfeller, med mindre spesifisert, at alle pakkene kommer fram i riktig rekkefølge, uten feil. Dersom det oppstår feil under testen, eller vi får feil resultater, skjekkes loggen for A2. Feil i implementasjonen identifiseres og eventuell refactoring av A1 utføres. Alle testene kjøres på nytt. Feil Feilrate Forventet resultat Begrunnelse Pakketap 10%, 50% & 100% På 100% skal vi få IOException. Forsinket pakke 10% & 50% Pakken har feil 10% & 50% & 70% Vi kan oppleve at dataene applikasjonen mottar er korrupte på grunn av bitfeil som ikke oppdages av checksum. "Ghost"-pakke 10% & 50% På 100 pakker bør ingen ghost-pakker slippe gjennom validering. La til 100% for å se om vi får connection timeout La til 70% for å øke sannsynlighet for å motta feil data. Pakketap Pakken har feil Pakketap Forsinket pakke Pakken har feil "Ghost"-pakke Pakketap Forsinket pakke Pakken har feil Forsinket pakke Pakken har feil Pakketap Forsinket pakke 10% & 70% 10% & 70% Velger 10% for dette er mer realistisk, men også 70% for å bekrefte at kombinasjonen av feil blir fanget opp. 10%, 50% Vi må ha en test hvor alt kan gå galt. 10%, 50% "Ghost" er litt mystisk, så det kan være greit å luke ut om det er det som gir oss trøbbel. 10% & 40% 10% & 50% 10% & 50% 10% & 50% Pakken kan nå være både forsinket og inneholde feil. Interessant å teste med veldig trege og ustabile pakker.