INF3190/4190 L�sningsforslag 10: Transportlaget

1. Transportlaget

1. Hvorfor sier vi at transportlaget danner et skille i OSI modellen? Hva er den fundamentale forskjellen p� lagene over og under transportlaget?

   Transportlaget er det f�rste laget med ende til ende kontroll. Lagene fra transportlaget og over finnes typisk bare i endesystemene og ikke i rutere og svitsjer. Over transportlaget finner vi protokoller som underst�tter samvirke mellom distribuerte applikasjoner; disse protokollene beskjeftiger seg ikke med selve overf�ringen av data, men forutsetter at dette ivaretas av underliggende lag. Under transportlaget har vi det fysiske nettet med rammer og ruting. Disse lagene (fysisk, link, nett, transport ) har det kollektive ansvaret for overf�ring av data mellom sender og mottaker, og s�rger for at overf�ringskvaliteten tilsvarer applikasjonenes behov.

2. Hvilke hovedkrav m� transportlaget oppfylle dersom det har det fulle ansvaret for p�liteligheten i kommunikasjonen mellom to transport-bruker entiteter?

   Hvis vi �nsker � oppn�/garantere full p�litelighet i transportlaget kreves f�lgende: P�litelig oppkobling av forbindelser, p�litelig overf�ring av data, dvs at alle meldinger kommer frem, at ingen meldinger dupliseres, at meldinger ikke bytter rekkef�lge og at meldingene ikke inneholder feil (ende-til-ende feilsjekk), p�litielig nedkobling av forbindelser uten tap av datapakker (graceful close ).

3. P� hvilket grunnlag velges transportprotokoll (eks TCP eller UDP i TCP/IP) for en applikasjon? N�r gj�res valget?

   Valget foretas n�r man skal implementere en applikasjon, dvs at man velger n�r det opprettes feks en socket som kan ha parameter UDP eller TCP. Man b�r velge den protokollen man tror best kan oppfylle kravene til nettverkskommunikasjon hhv. effektivitet, hastighet, sikkerhet. Ofte ender man med et kompromiss hvor en bruker den protokollen som har flest av de �nskede egenskapene. UDP vil typisk v�re egnet til � sende mange sm� pakker, lyd/bilde og interaktiv bruk hvor det ikke er vesentlig at alle pakker kommer frem. TCP er derimot velegnet til feks store filoverf�ringer.

4. Beskriv feltene i henholdsvis UDP og TCP headeren. Hvorfor er de s� ulike?

   Se figur side 526 og 537 i Tanenbaum for header layout hhv UDP og TCP. TCP headeren er mer omfattende fordi man trenger � skille mellom ulike typer TPDUer (feks for op- og nedkobling), det trengs sekvensnummer for � sikre at alle bytene leveres i riktig rekkef�lge , og det trengs et felt for � gi melding om mottakervinduet.

5. Transportprotokollen UDP er som IP forbindelsesl�s, hvorfor har vi en forbindelsesl�s transportprotokoll?

   Det er behov for valgmuligheter: i noen situasjoner er det bedre/mer effektivt/raskere med en forbindelsesl�s transport protokoll. Feilh�ndtering etc m� da h�ndteres p� laget over (applikasjonen). Ofte skreddersyr man applikasjoner for � f� bedre ytelse vha. UDP i situasjoner hvor det sendes mange sm� pakker, eller tale/video hvor npen pakker kan bli borte uten � �delegge for resutatet.

6. Beskriv prinsippet for p�litelig etablering av en transportforbindelse ved hjelp av tre-veis h�ndtrykk.

   Se figur side 540 i Tanenbaum. Algoritmen treveis h�ndtrykk brukes av TCP for � etablere og terminere forbindelser. H�ndtryket involverer utveksling av tre beskjeder mellom klient og tjener. Ideen er at de to partene skal enes om et sett parameter for forbindelsen. Ved �pning av forbindelse er det s�rlig viktig � avtale hvilket sekvensnummer man starter med. I tillegg kan det v�re QoS-parametre samt andre opsjoner. F�rst sender klienten en transport protokoll enhet (TPDU) til tjeneren og angir sitt initielle sekvensnummer (>YN) . Tjeneren svarer med en ACK p� klientens sekvensnummer samtidig som den angir eget initielle sekvensnummer (SYN+ACK). Til sist svarer klienten med en tredje TPDU aom bekrefter tjenerens sekvensnummer (ACK). Grunnen til at det ikke brukes forh�ndsdefinerte initielle sekvensnummer er at TCP krever at hver side av forbindelsen selv velger disse tilveldig, for � hindre at to instanser av samme forbindelse gjenbruker de samme sekvensnummer for raskt.

7. Fragmentering og reassemblering blir tatt h�nd om av IP. Betyr det at TCP ikke trenger � bekymre seg om at data kan komme frem feil rekkef�lge?

   Det er kun de separate pakkene som blir satt tilbake til opprinnelig tilstand av IP etter fragmentering. Dvs at IP ikke bes�rger annet enn � ikke levere fragmenterte pakker fra IP og opp til transportlaget. Rekkef�lgen av pakkene er likegyldig for IP, og TCP m� h�ndtere situasjoner hvor pakker kommer frem i en annen rekkef�lge enn de ble sendt i. Eksempelvis TCP sin sliding window algoritme tar seg av � stokke pakkene tilbake i rekkef�lge.

2. Transportlaget - Oppgaver fra Tanenbaum

6-5

Se p� den andre duplikate pakken i figur 6-11(b) . N�r den pakken ankommer, ville det v�re en katastrofe hvis ack p� y fremdeles fl�t rundt.

6-6

Deadlock er mulig. F.eks. en pakke ankommer A fra ingenstedshen og A sender ack p� den. Ack blir borte, men A er n� �pen og B vet overhode ingenting om hva som har skjedd. S� skjer samme senario for B, og begge er �pne men forventer ulike sekvensnummer. Man m� introdusere timeout for � unng� deadlock her.

6-13

Sliding window er enklere med bare ett sett parameter � h�ndtere (vinduskantene). Videre forekommer ikke problemet med at vinduet �kes/reduseres ved TPDUer som ankommer i gal rekkef�lge. Likevel, kredittskjemaet er mer fleksibelt siden det tillater en dynamisk h�ndtering av buffer separat fra ack.