kappale 3 kuljetustaso - lut · kappale 3 kuljetustaso computer networking: a top down approach 6th...

Transport Layer 3-1

Kappale 3Kuljetustaso

Computer Networking: A

Top Down Approach

6th edition Jim Kurose, Keith Ross

Addison-WesleyMarch 2012

Patrik Tikka 2-16Antti Sinkkonen 17-27Esko Mäkelä 54-85Meri Ovaska 86-103Saku Käsnänen 104-120Markus Leppioja 121-142Henri Takki 143-178Ilari Tuomela 179 - 209

Transport Layer 3-2

Chapter 3: Transport Layerour goals: ❖ understand principles

behind transport layer services:▪ multiplexing,

demultiplexing▪ reliable data transfer▪ flow control▪ congestion control

❖ learn about Internet transport layer protocols:▪ UDP: connectionless

transport▪ TCP: connection-oriented

reliable transport▪ TCP congestion control

Transport Layer 3-3

Kappale 3: KuljetuskerrosTavoitteemme: ❖ Ymmärtää

kuljetuskerroksen palveluiden perusperiaatteet:▪ Multiplexaus,

demultiplexaus▪ Luotettava

tiedonsiirto▪ Data virran ohjaus▪ Ruuhkanhallinta

❖ Oppia asioita kuljetuskerroksen protokollista:▪ UDP: Yhteydetön

tiedonsiirto▪ TCP: Yhteys-orientoitunut

luotettava tiedonsiirto▪ TCP Ruuhkanhallinta

Transport Layer 3-4

Chapter 3 outline

3.1 transport-layer services

3.2 multiplexing and demultiplexing

3.3 connectionless transport: UDP

3.4 principles of reliable data transfer

3.5 connection-oriented transport: TCP▪ segment structure▪ reliable data transfer▪ flow control▪ connection management

3.6 principles of congestion control

3.7 TCP congestion control

Transport Layer 3-5

Kappale 3: kehys

3.1 Kuljetuskerroksen palvelut

3.2 Multiplexaus, demultiplexaus

3.3 Yhteydetön tiedonsiirto: UDP

3.4 Luotettavan tiedonsiirron perusteet

3.5 Yhteys-orientoitunut luotettava tiedonsiirto : TCP▪ Segmenttirakenne▪ Luotettava tiedonsiirto▪ Virtauksen ohjaus▪ Yhteyden hallinta

3.6 Ruuhkanhallinnan perusteet

3.7 TCP Ruuhkanhallinta

Transport Layer 3-6

Transport services and protocols❖ provide logical

communication between app processes running on different hosts

❖ transport protocols run in end systems ▪ send side: breaks app

messages into segments, passes to network layer▪ rcv side: reassembles

segments into messages, passes to app layer

❖ more than one transport protocol available to apps▪ Internet: TCP and UDP

applicationtransportnetworkdata linkphysical


Transport Layer 3-7

Kuljetuspalvelut ja -protokollat❖ Tarjoavat loogisen

kommunikoinnin eri solmuissa toimivien sovellusten prosessien välille.

❖ Kuljetusprotokollat pyörivät päätejärjestelmissä▪ Lähettäjä: Paloittelee

lähetettävän tiedon segmentteihin ja lähettää edelleen verkkokerrokselle

▪ Vastaanottaja: Kasaan tiedon segmenteistä ja välittää sovelluskerrokselle

❖ Enemmän kuin yksi protokolla sovelluskerroksen käytettävissä▪ Internet: TCP jaUDP



Transport Layer 3-8

Transport vs. network layer❖ network layer:

logical communication between hosts

❖ transport layer:logical communication between processes▪ relies on, enhances,

network layer services

12 kids in Ann’s house sending letters to 12 kids in Bill’s house:

❖ hosts = houses❖ processes = kids❖ app messages = letters in

envelopes❖ transport protocol = Ann

and Bill who demux to in-house siblings

❖ network-layer protocol = postal service

household analogy:

Transport Layer 3-9

Kuljetus - vs. verkkokerros❖ Verkkokerros:

looginen kommunikaatio solmujen välillä

❖ Kuljetuskerros: Looginen kommunikaatio sovellusten prosessien välillä▪ Nojaa ja ehostaa

verkkokerroksen palveluita

12 lasta Annen talossa lähettää kirjeitä 12:lle lapselle Billin talossa:

❖ Solmut= Talot❖ Prosessit = Lapset❖ Sovellus viestit = Kirjeet

kuorissa❖ Kuljetusprotokolla= Anna

ja Bill, jotka toimittavat viestit lapsille

❖ Verkkokerrosprotokolla= Postipalvelu

Talo analogia:

Transport Layer 3-10

Internet transport-layer protocols❖ reliable, in-order

delivery (TCP)▪ congestion control ▪ flow control▪ connection setup

❖ unreliable, unordered delivery: UDP▪ no-frills extension of

“best-effort” IP❖ services not available: ▪ delay guarantees▪ bandwidth guarantees



networkdata linkphysical





networkdata linkphysical network

data linkphysical


Internetin kuljetuskerroksen protokollat

❖ Luotettava, toimitus-tilauksesta (TCP)▪ Ruuhkanhallinta▪ Virtauksenohjaus▪ Yhteyden alustus

❖ Epäluotettava, tilaamaton-toimitus: UDP▪ Ei mitään erityistä, vaan

“paras mahdollinen” IP❖ Ei saatavilla olevat

palvelut: ▪ Viive takuu▪ Kaistanleveys takuu








networkdata linkphysical network

data linkphysical


Chapter 3 outline









Kappale 3: kehys
















Multiplexing/demultiplexing

process

socket

use header info to deliverreceived segments to correct socket

demultiplexing at receiver:

handle data from multiplesockets, add transport header (later used for demultiplexing)

multiplexing at sender:

transport

application

physicallink

network

P2P1

transport

application

physicallink

network

P4

transport

application

physicallink

network

P3


Multipelxaus/Demultiplexaus

process

socket

Käyttää tunnisteinfoatoimittaakseen tietosegmentit oikeisiin soketteihin

Demultiplexaus vastaanottajalla:Tiedon käsittely monelta eri

soketilta, lisää kuljetustunnisteen(Käytetään myöhemmin DM:ssä)

Multiplexaus lähettäjällä:

transport

application

physicallink

network

P2P1

transport

application

physicallink

network

P4

transport

application

physicallink

network

P3


How demultiplexing works

❖ host receives IP datagrams▪ each datagram has source IP

address, destination IP address▪ each datagram carries one

transport-layer segment▪ each segment has source,

destination port number ❖ host uses IP addresses &

port numbers to direct segment to appropriate socket

source port # dest port #

32 bits

applicationdata

(payload)

other header fields

TCP/UDP segment format


Miten demultiplexaus toimii

❖ Solmu vastaanottaa IP datapaketteja▪ Jokaisessa datapaketissa on

lähteen IP osoite ja päämäärän IP osoite

▪ Jokaisessa datapaketissa on yksi kuljetuskerroksen segmentti

▪ Jokaisessa paketissa on lähteen ja päämäärän porttinumero

❖ Solmu käyttää IP -osoitteita ja porttiennumeroita segmenttien ohjaamiseen oikeille soketeille

Lähde portti# Päämäärä portti#

32 bittiä

Sovelluksen data (Itse kuljetettava viesti)

Muut tunniste kentät

TCP/UDP segmenttimalli


Connectionless demultiplexing❖ recall: created socket has

host-local port #:DatagramSocket mySocket1 = new DatagramSocket(12534);

❖ when host receives UDP segment:▪ checks destination port #

in segment▪ directs UDP segment to

socket with that port #

❖ recall: when creating datagram to send into UDP socket, must specify▪ destination IP address▪ destination port #

IP datagrams with same dest. port #, but different source IP addresses and/or source port numbers will be directed to same socket at dest


Yhteydetön demultiplexaus❖Uudelleenkutsu: luodulla

soketilla on solmu-paikallinen portti#:DatagramSocket mySocket1 = new DatagramSocket(12534);

❖ Kun solmu vastaanottaaUDP segmentin:▪ Tarkastaan päämäärä

portin# segmentistä▪ Ohjaa UDP segmentin

oikealla porttinumerolla vatustettuun sockettiin

❖ Uudelleenkutsu: Luotaessa UDP sockettiin lähetettävää datapakettia, täytyy määrittää:▪ Päämäärän IP▪ Päämäärän portti#

Samoilla PM. Portti#:lla varustetut IP datapaketit, mutta eri IP-lähteet ja/tai lähde porttinumerot, ohjataan samaan sockettiin päämäärässä


Connectionless demux: exampleDatagramSocket serverSocket = new DatagramSocket(6428);

transport

application

physicallink

network

P3 transport

application

physicallink

network

P1

transport

application

physicallink

network

P4

DatagramSocket mySocket1 = new DatagramSocket (5775);

DatagramSocket mySocket2 = new DatagramSocket(9157);

source port: 9157dest port: 6428


source port: ?dest port: ?



Yhteydetän demultiplexaus: esimerkkiDatagramSocket serverSocket = new DatagramSocket(6428);

transport

application

physicallink

network

P3 transport

application

physicallink

network

P1

transport

application

physicallink

network

P4

DatagramSocket mySocket1 = new DatagramSocket (5775);

DatagramSocket mySocket2 = new DatagramSocket(9157);






Connection-oriented demux

❖ TCP socket identified by 4-tuple: ▪ source IP address▪ source port number▪ dest IP address▪ dest port number

❖ demux: receiver uses all four values to direct segment to appropriate socket

❖ server host may support many simultaneous TCP sockets:▪ each socket identified by

its own 4-tuple❖ web servers have

different sockets for each connecting client▪ non-persistent HTTP will

have different socket for each request


Yhteys-orientoitunut demultiplexaus

❖ TCP socketti tunnistetaan “nelikolla”: ▪ Lähde IP -osoite▪ Lähde portti#▪ PM IP -osoite▪ PM portti#

❖ demux: vastaanottaja käyttää kaikkia neljää arvoa segmentin ohjaamiseen oikealle socketille

❖ Palvelin solmu saattaa tukea monia samanaikaisia TCP socketteja:▪ Jokainen socketti

tunnistetaan niiden omasta “nelikosta”

❖ Web palvelimilla on erilliset socketit jokaiselle yhdistetylle asiakkaalle▪ Ei-pysyvä HTTP varaa eri

socketit jokaiselle pyynnölle


Connection-oriented demux: example

transport

application

physicallink

network

P3 transport

application

physicallink

P4

transport

application

physicallink

network

P2

source IP,port: A,9157dest IP, port: B,80

source IP,port: B,80dest IP,port: A,9157

host: IP address A

host: IP address C

network

P6

P5 P

3

source IP,port: C,5775dest IP,port: B,80

source IP,port: C,9157dest IP,port: B,80three segments, all destined to IP address: B,

dest port: 80 are demultiplexed to different sockets

server: IP address B


Yhteys-orientoitunut demultiplexaus: esimerkki

transport

application

physicallink

network

P3 transport

application

physicallink

P4

transport

application

physicallink

network

P2



solmu: IP osoite A

Solmu: IP osoite C

network

P6

P5 P

3


source IP,port: C,9157dest IP,port: B,80Ko,me segmenttiä, jokainen samaan IP osoitteeseen: B,

PM portti: 80 jokainen segmentti on multiplexattu eri socketteihin

Palvelin: IP osoite

B


Connection-oriented demux: example

transport

application

physicallink

network

P3 transport

application

physicallink

transport

application

physicallink

network

P2



host: IP address A

host: IP address C

server: IP address B

network

P3



P4

threaded server


Yhteys-orientoitunut demultiplexaus: esimerkki

transport

application

physicallink

network

P3 transport

application

physicallink

transport

application

physicallink

network

P2



Solmu: IP osoite A

Solmu: IP osoite C

Palvelin: IP Osoite

B

network

P3



P4

Kierteinen palvelin


Chapter 3 outline









Kappale 3: kehys
















UDP: User Datagram Protocol [RFC 768]❖ “no frills,” “bare bones”

Internet transport protocol❖ “best effort” service, UDP

segments may be:▪ lost▪ delivered out-of-order

to app❖ connectionless:▪ no handshaking

between UDP sender, receiver▪ each UDP segment

handled independently of others

❖ UDP use:▪ streaming multimedia

apps (loss tolerant, rate sensitive)▪ DNS▪ SNMP

❖ reliable transfer over UDP: ▪ add reliability at

application layer▪ application-specific error

recovery!


UDP: Käyttäjä Datapaketti protokolla [RFC 768]

❖ “Ei erikoisuuksia,” “perus” Internet kuljetusprotokolla

❖ “Parasmahdollinen” palvelu, UDP segmentit voivat:▪ hukkua▪ Päätyä epäjärjestyksessä

sovellukselle❖ Yhteydetön:

▪ Ei yhteyden alustusta UDP lähettäjän ja vastaanottajan välillä

▪ Jokainen UDP segmentti käsitellään itsenäisesti erillään muista

❖ UDP käytetään:▪ Strrimaus sovelluksissa

(YLE areena, youtube, yms.)▪ DNS (root hakee

syvemmältä tietoja jne.)▪ SNMP

❖ Luotettava tiedonsiirto käyttäen UDP:tä: ▪ Lisätään sovellustasolla▪ Sovelluskohtainen

palautuminen vikatilanteista.


UDP: segment header


32 bits

applicationdata

(payload)

UDP segment format

length checksum

length, in bytes of UDP segment,

including header

❖ no connection establishment (which can add delay)

❖ simple: no connection state at sender, receiver

❖ small header size❖ no congestion control:

UDP can blast away as fast as desired

why is there a UDP?


UDP: segmenttiotsikko

Lähteen portti#Kohteen portti #

32 bits

sovellusdata(tietosisältö)

UDP segmentti muoto

pituus tarkiste

UDP segmentin, otsikko mukaan

lukien, pituus biteissä

❖ Ei tarvita yhteyttä(mikä voi lisätä viivettä)

❖ yksinkertaista: ei yhteystilaa vastaanottajalla eikä lähettäjällä

❖ Pieni otsikon koko❖ Ei ruuhkakontrollia: UDP

voi painaa eteenpäin niin paljon kuin halutaan

Miksi UDP on olemassa?


UDP checksum

sender:❖ treat segment contents,

including header fields, as sequence of 16-bit integers

❖ checksum: addition (one’s complement sum) of segment contents

❖ sender puts checksum value into UDP checksum field

receiver:❖ compute checksum of

received segment❖ check if computed

checksum equals checksum field value:▪ NO - error detected▪ YES - no error detected.

But maybe errors nonetheless? More later ….

Goal: detect “errors” (e.g., flipped bits) in transmitted segment


UDP tarkiste

lähettäjä:❖ Kohtelee segmentin

sisältöä, otsikko mukaan lukien, 16-bittisinä kokonaislukuina

❖ tarkiste: segmentin sisällön yhteenlasku

❖ Lähettäjä laittaa yhteenlaskun arvon UDP:n tarkisteen kenttään

Vastaanottaja:❖ Laskee vastaanotetun

segmentin tarkisteen❖ Tarkistaa vastaako äsken

laskettu tarkiste vastaanotetun segmentin UDP:n tarkistekentän vastaavaa arvoa:▪ EI– virhe havaittu▪ KYLLÄ – ei havaittu

virhettä.

Tavoite: havaita“virheet” (ts., käännetyt bitit) siirretyssä segmentissä


Internet checksum: example

example: add two 16-bit integers

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 01 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

wraparound

sumchecksum

Note: when adding numbers, a carryout from the most significant bit needs to be added to the result


Internetin tarkiste: esimerkki

esimerkki: lisää kaksi 16-bittistä kokonaislukua

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 01 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

kierre

summatarkiste

Huom: numeroita lisätessä, tärkeimmän bitin suorite täytyy lisätä lopputulokseen


Chapter 3 outline









Kappale 3 kehys

3.1 kuljetustason palvelut








Principles of reliable data transfer❖ important in application, transport, link layers▪ top-10 list of important networking topics!

❖ characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt)


Luotettavan tiedonsiirron periaatteet❖ Tärkeää sovellus-, kuljetus- ja linkkitasoilla▪ top-10 listalla verkon tärkeistä puheenaiheista

❖ Epäluotettavan kanavan tunnusmerkit määrittelevät luotettavan tiedonsiirtoprotokollan monimutkaisuuden (rtd)



Principles of reliable data transfer❖ important in application, transport, link layers▪ top-10 list of important networking topics!



Luotettavan tiedonsiirron periaatteet❖ Tärkeää sovellus-, kuljetus- ja linkkitasoilla▪ top-10 listalla verkon tärkeistä puheenaiheista



❖ important in application, transport, link layers▪ top-10 list of important networking topics!

Principles of reliable data transfer



❖ Tärkeää sovellus-, kuljetus- ja linkkitasoilla▪ top-10 listalla verkon tärkeistä puheenaiheista

Luotettavan tiedonsiirron periaatteet


Reliable data transfer: getting started

sendside

receiveside

rdt_send(): called from above, (e.g., by app.). Passed data to deliver to receiver upper layer

udt_send(): called by rdt,to transfer packet over

unreliable channel to receiver

rdt_rcv(): called when packet arrives on rcv-side of channel

deliver_data():called by rdt to deliver data to upper


Luotettava tiedonsiirto: alkusysäys

Lähetetyspuoli

Vastaanotto

puoli

rdt_send(): kutsutaan yläpuolelta, (esim., sovellus.). Siirretty data

kuljettajalle, jolta vastaanottajalle ylemmälle tasolle

udt_send(): rtd kutsuu,Siirretään paketti

epäluotettavaa kanavaa pitkin vastaanottajalle

rdt_rcv(): kutsutaan kun paketti saapuu vastaanotto-puolelle

deliver_data(): rtd kutsuu, siirretään data

ylemmälle tasolle


we’ll:❖ incrementally develop sender, receiver sides of

reliable data transfer protocol (rdt)❖ consider only unidirectional data transfer▪ but control info will flow on both directions!

❖ use finite state machines (FSM) to specify sender, receiver

state1

state2

event causing state transitionactions taken on state transition

state: when in this “state” next state

uniquely determined by next event

eventactions

Reliable data transfer: getting started


Me:❖ Inkrementaalisesti kehitämme rtd:n sekä lähettäjä-

että vastaanottopuolta❖ Harkitse vain yksisuuntaista tiedonsiirtoa▪ Mutta kontrollitieto liikkuu molempiin suuntiin!

❖ Käytetään FSM:ää tarkentamaan lähettäjää ja vastaanottajaa

Tila1

Tila2

Tapahtuma aiheuttaa tilan vaihdonTilan vaihdon aiheutamat toimenpiteet

tila: kun ollaan tässä ”tilassa”, seuraava

toiminto määrää itse seuraavan tilan

tapahtumatoimenpiteet

Luotettava tiedonsiirto


rdt1.0: reliable transfer over a reliable channel

❖ underlying channel perfectly reliable▪ no bit errors▪ no loss of packets

❖ separate FSMs for sender, receiver:▪ sender sends data into underlying channel▪ receiver reads data from underlying channel

Wait for call from above packet = make_pkt(data)

udt_send(packet)

rdt_send(data)extract (packet,data)deliver_data(data)

Wait for call from below

rdt_rcv(packet)

sender receiver


rdt1.0: luotettava siirto luotettavan kanavan yli

❖ Alla oleva kanava täysin luotettava▪ Ei bitti virheitä▪ Ei pakettihäviötä

❖ Erilliset FSM:ät lähettäjälle ja vastaanottajalle▪ Lähettäjä lähettää datan alla olevaan kanavaan▪ Vastaanottaja lukee dataa alla olevasta kanavasta

Odotakutsuaylhäältä packet = make_pkt(data)

udt_send(packet)

rdt_send(data)extract (packet,data)deliver_data(data)

Odota kutsua

alapuolelta

rdt_rcv(packet)

lähettäjä vastaanottaja


❖ underlying channel may flip bits in packet▪ checksum to detect bit errors

❖ the question: how to recover from errors:▪ acknowledgements (ACKs): receiver explicitly tells

sender that pkt received OK▪ negative acknowledgements (NAKs): receiver explicitly

tells sender that pkt had errors▪ sender retransmits pkt on receipt of NAK

❖ new mechanisms in rdt2.0 (beyond rdt1.0):▪ error detection▪ receiver feedback: control msgs (ACK,NAK) rcvr-

>sender

rdt2.0: channel with bit errors

How do humans recover from “errors”

during conversation?


❖ Alla oleva kanava voi “pyöräyttää” bittejä▪ Tarkisteen avulla huomataan bittivirheet

❖ kysymys: kuinka palautua virheistä:▪ acknowledgements (ACKs): receiver explicitly tells



❖ new mechanisms in rdt2.0 (beyond rdt1.0):▪ error detection▪ receiver feedback: control msgs (ACK,NAK) rcvr-

>sender

rdt2.0: kanava bittivirheillä

Kuinka ihmisiet palautuvat ”virheistä” keskustelun aikana?


❖ underlying channel may flip bits in packet▪ checksum to detect bit errors

❖ the question: how to recover from errors:▪ acknowledgements (ACKs): receiver explicitly tells



❖ new mechanisms in rdt2.0 (beyond rdt1.0):▪ error detection▪ feedback: control msgs (ACK,NAK) from receiver to

sender

rdt2.0: channel with bit errors


❖ perustana oleva kanava voi kääntää paketeissa olevia bittejä▪ checksum bittivirheiden tarkistusta varten

❖ Tärkein kysymys: kuinka palaudutaan virheistä:▪ kuittaus (ACKs): vastaaottaja kertoo yksiselitteisesti

lähettäjälle, että paketti on vastaanotettu OK▪ kielteinen kuittaus (NAKs): vastaanottaja kertoo

yksiselitteisesti lähettäjälle, että paketissa oli virheitä▪ lähettäjä uudelleenlähettää paketin, josta saatiin NAK

❖ uusi mekanismi rdt2.0:ssa (yli rdt1.0:n):▪ virheen tunnistus▪ palaute: kontrolli viestejä (ACK,NAK) vastaanottajalta

lähettäjälle

rdt2.0: kanava bittivirheillä


rdt2.0: FSM specification

Wait for call from above

sndpkt = make_pkt(data, checksum)udt_send(sndpkt)

extract(rcvpkt,data)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) &&isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) && corrupt(rcvpkt)

Wait for ACK or

NAK

Wait for call from belowsender

receiverrdt_send(data)

Λ


rdt2.0: FSM erittely

Odota kutsua ylhäältä

sndpkt = make_pkt(data, checksum)udt_send(sndpkt)




udt_send(sndpkt)


udt_send(NAK)


Odota ACK tai

NAK

Odota kutsua ylhäältälähettäjä

vastaanottajardt_send(data)

Λ


rdt2.0: operation with no errors


snkpkt = make_pkt(data, checksum)udt_send(sndpkt)




udt_send(sndpkt)


udt_send(NAK)


Wait for ACK or

NAK


rdt_send(data)

Λ


rdt2.0: toimenpide ilman virheitä






udt_send(sndpkt)


udt_send(NAK)


Wait for ACK or

NAK


rdt_send(data)

Λ


rdt2.0: error scenario






udt_send(sndpkt)


udt_send(NAK)


Wait for ACK or

NAK


rdt_send(data)

Λ


rdt2.0: virheskenaario






udt_send(sndpkt)


udt_send(NAK)


Wait for ACK or

NAK


rdt_send(data)

Λ


rdt2.0 has a fatal flaw!

what happens if ACK/NAK corrupted?

❖ sender doesn’t know what happened at receiver!

❖ can’t just retransmit: possible duplicate

handling duplicates: ❖ sender retransmits current

pkt if ACK/NAK corrupted

❖ sender adds sequence number to each pkt

❖ receiver discards (doesn’t deliver up) duplicate pkt

stop and waitsender sends one packet, then waits for receiver response


rdt2.0:ssa on kohtalokas vika!Mitä tapahtuu jo

ACK/NAK on korruptoitunut?

❖ lähettäjä ei tiedä vastaanottajan päässä tapahtui!

❖ ei voi vain uudelleenlähettää: mahdollisiaduplikaatioita

duplikaattien käsittely: ❖ lähettäjä uudelleenlähettää

nykyisen paketin jos ACK/NAK korruptioitunut

❖ lähettäjä lisää järjestysnumeron jokaiseen pakettiin

❖ vastaanottaja hylkää duplikaatti paketetit

pysähdy ja odotalähettäjä lähettää yhden paketin ja odottaa vastaanottajan vastausta


rdt2.1: sender, handles garbled ACK/NAKs

Wait for call 0 from

above

sndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)

rdt_send(data)

Wait for ACK or NAK 0 udt_send(sndpkt)

rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isNAK(rcvpkt) )


rdt_send(data)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt)

udt_send(sndpkt)



Wait forcall 1 from

above

Wait for ACK or NAK 1

ΛΛ


rdt2.1: lähettäjä, käsittelee sotkuisen ACK/NAK


above


rdt_send(data)

Wait for ACK or NAK 0 udt_send(sndpkt)



rdt_send(data)


udt_send(sndpkt)



Wait forcall 1 from

above

Wait for ACK or NAK 1

ΛΛ


Wait for 0 from below

sndpkt = make_pkt(NAK, chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) && not corrupt(rcvpkt) &&has_seq0(rcvpkt)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt)

extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)



extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) && (corrupt(rcvpkt)

sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) && not corrupt(rcvpkt) &&has_seq1(rcvpkt)

rdt_rcv(rcvpkt) && (corrupt(rcvpkt)

sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)

sndpkt = make_pkt(NAK, chksum)udt_send(sndpkt)

rdt2.1: vastaanottaja, käsittelee sotkuisen ACK/NAKs


rdt2.1: discussion

sender:❖ seq # added to pkt❖ two seq. #’s (0,1) will

suffice. Why?❖ must check if received

ACK/NAK corrupted ❖ twice as many states▪ state must “remember”

whether “expected” pkt should have seq # of 0 or 1

receiver:❖ must check if received

packet is duplicate▪ state indicates whether

0 or 1 is expected pkt seq #

❖ note: receiver can notknow if its last ACK/NAK received OK at sender


rdt2.1: keskustelulähettäjä:❖ järjestysnumero #

lisätty pakettiin❖ kaksi järj.num. #’s

(0,1) riittää. Miksi?❖ täytyy tarkistaa jos

vastaanotettu ACK/NAK korruptoitunut

❖ tuplasti enemmän tiloja▪ tilan täytyy “muistaa”

josko “odotetun” paketin järj.num. tulisi olla 0 vai 1

receiver:❖ täytyy tarkistaa, onko

vastaanotettu paketti duplikaatti▪ tila osoittaa indicates

joko 0 tai 1 on odotettu pkt järj.num.

❖ huom: vastaanottaja EI voi tietää onko lähettäjä vastaanottanu viimeiseksi lähetetyn ACK/NAK kuittauksen


rdt2.2: a NAK-free protocol

❖ same functionality as rdt2.1, using ACKs only❖ instead of NAK, receiver sends ACK for last pkt

received OK▪ receiver must explicitly include seq # of pkt being ACKed

❖ duplicate ACK at sender results in same action as NAK: retransmit current pkt


rdt2.2: NAK-vapaa protokolla

❖ sama toiminnallisuus kuin rdt2.1, käytetään ainoastaan ACK

❖ NAK:n sijaan vastaanottaja lähettää ACK kuittauksen viimeisestä vastaanotetusta paketista▪ vastaanottajan täytyy yksiselitteisesti sisällyttää paketin

järj.num. joka kuitataan ACK ❖ duplikaatti ACK lähettäjällä johtaa samaan

toimenpiteeseen kuin NAK: uudelleen lähetetään sen kyseinen paketti


rdt2.2: sender, receiver fragments


above


rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||

isACK(rcvpkt,1) )

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0)

Wait for ACK

0sender FSMfragment


extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK1, chksum)udt_send(sndpkt)


rdt_rcv(rcvpkt) && (corrupt(rcvpkt) ||

has_seq1(rcvpkt))

udt_send(sndpkt)receiver FSM

fragment

Λ


rdt2.2: lähettäjä, vastaanottajan kappale


above


rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||

isACK(rcvpkt,1) )


Wait for ACK

0sender FSMfragment


extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK1, chksum)udt_send(sndpkt)


rdt_rcv(rcvpkt) && (corrupt(rcvpkt) ||

has_seq1(rcvpkt))

udt_send(sndpkt)receiver FSM

fragment

Λ


rdt3.0: channels with errors and loss

new assumption:underlying channel can also lose packets (data, ACKs)▪ checksum, seq. #,

ACKs, retransmissions will be of help … but not enough

approach: sender waits “reasonable” amount of time for ACK

❖ retransmits if no ACK received in this time

❖ if pkt (or ACK) just delayed (not lost):▪ retransmission will be

duplicate, but seq. #’s already handles this▪ receiver must specify seq

# of pkt being ACKed❖ requires countdown timer


rdt3.0: kanavia joissa virheitä ja hävikkiä

uusi oletus: perustana oleva kanava voi myös kadottaa paketteja (dataa, kuittauksia)▪ checksum, järj.num . #,

ACK, uudelleenlähetys auttavat … mutta ei tarpeeksi

lähestymistapa: lähettäjä odottaa “kohtuullisen” ajan ACK-kuittausta

❖ uudelleen lähettää jos ACK ei saavu tässä ajassa

❖ jos pkt (tai ACK) vain viivästyy (ei häviä):▪ uudelleen lähetys tulee olemaan

duplikaatti, mutta järj.num. ottaa tämän jo huomioon

▪ vastaanottajan täytyy tarkentaa minkä järj. numn paketti ACK-kuitataan

❖ vaattii lähtölaskenta ajastimen


rdt3.0 sendersndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)start_timer

rdt_send(data)

Wait for

ACK0

rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isACK(rcvpkt,1) )


above

sndpkt = make_pkt(1, data, checksum)udt_send(sndpkt)start_timer

rdt_send(data)




stop_timerstop_timer

udt_send(sndpkt)start_timer

timeout


timeout

rdt_rcv(rcvpkt)

Wait for call 0from

above

Wait for

ACK1

Λrdt_rcv(rcvpkt)

ΛΛ

Λ


rdt3.0 lähettäjäsndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)start_timer

rdt_send(data)

Wait for

ACK0



above

sndpkt = make_pkt(1, data, checksum)udt_send(sndpkt)start_timer

rdt_send(data)




stop_timerstop_timer


timeout


timeout

rdt_rcv(rcvpkt)

Wait for call 0from

above

Wait for

ACK1

Λrdt_rcv(rcvpkt)

ΛΛ

Λ



rcv pkt1

rcv pkt0

send ack0

send ack1

send ack0

rcv ack0

send pkt0

send pkt1

rcv ack1

send pkt0rcv pkt0

pkt0

pkt0

pkt1

ack1

ack0

ack0

(a) ei hävikkiä


rcv pkt1

rcv pkt0

send ack0

send ack1

send ack0

rcv ack0

send pkt0

send pkt1

rcv ack1

send pkt0rcv pkt0

pkt0

pkt0

ack1

ack0

ack0

(b) paketti häviää

pkt1X

hävikki

pkt1

ajastin laukeaat

resend pkt1

rdt3.0 toiminnassa


rdt3.0 toiminnassa

rcv pkt1send ack1

(detect duplicate)

pkt1


rcv pkt1

rcv pkt0

send ack0

send ack1

send ack0

rcv ack0

send pkt0

send pkt1

rcv ack1

send pkt0rcv pkt0

pkt0

pkt0

ack1

ack0

ack0

(c) ACK hävikki

ack1X

loss

pkt1ajastin

laukeaatresend pkt1

rcv pkt1send ack1

(detect duplicate)

pkt1


rcv pkt1

send ack0rcv ack0

send pkt1

send pkt0rcv pkt0

pkt0

ack0

(d) ennenaikainen aikakatkaisu / viivästetty ACK

pkt1

ajastin laukeaat

resend pkt1

ack1

send ack1

send pkt0rcv ack1

pkt0

ack1

ack0

send pkt0rcv ack1 pkt0

rcv pkt0send ack0ack0rcv pkt0send ack0(detect duplicate)


rdt3.0:n suorituskyky❖ rdt3.0 on virheetön, mutta suorituskyky haisee❖ esim..: 1 Gbps yhteys, 15 ms viive, 8000 bitin paketti:

▪ U lähettäjä: käyttöaste – murto-osan ajasta lähettäjä kiireinen lähettämään

▪ Jos RTT=30 msek, 1KB pkt joka 30 msek: 33kB/sec läpimeno yli 1 Gbps yhteys

❖ verkkoprotokolla rajoittaa fyysisten resurssien käyttöä!

Dtrans =LR

8000 bits109 bits/sec= = 8 mikrosekunttia


rdt3.0: stop-and-wait operation

first packet bit transmitted, t = 0

sender receiver

RTT

last packet bit transmitted, t = L / R

first packet bit arriveslast packet bit arrives, send ACK

ACK arrives, send next packet, t = RTT + L / R


rdt3.0: pysähdy-ja-odota toimenpide

ensimmäisen paketin bitti lähetetää

lähettäjär vastaanottaja

RTT

viimeisen paketin bitti läh., t = L / R

viim. pktn bitti saapuu, lähetetää ACK

ACK saapuu, lähetetään seurava pkt, t = RTT + L /

R

ensimmäisen paketin bitti saapuu


Pipelined protocols

pipelining: sender allows multiple, “in-flight”, yet-to-be-acknowledged pkts▪ range of sequence numbers must be increased▪ buffering at sender and/or receiver

❖ two generic forms of pipelined protocols: go-Back-N, selective repeat


Kanavoituprotokollakanavointi: lähettäjä sallii useaman “matkalla”,

mutta-ei-vielä-kuitattu paketin▪ järj. numeroiden joukkoa täytyy kasvattaa▪ puskurointi lähettäjällä ja/tai vastaanottajalla

❖ kaksi geneeristä kanavointiprotokollan muotoa: mene-ja-tule-takaisin (go-Back-N), valikoiva toisto


Pipelining: increased utilization

first packet bit transmitted, t = 0sender receiver

RTT

last bit transmitted, t = L / R

first packet bit arriveslast packet bit arrives, send ACK

ACK arrives, send next packet, t = RTT + L / R

last bit of 2nd packet arrives, send ACKlast bit of 3rd packet arrives, send ACK

3-packet pipelining increasesutilization by a factor of 3!


Kanavointi: hyötykäytön kasvatus

ensimmääisen paketin bittilähetetään, t = 0lähettäjä vastaanotaja

RTT

viim. bitti lähetetty, t = L / R

ensim. pktn bitti saapuuviim. pktn bitti saapuu, läh. ACK

ACK saapuu, läh. seuraava pkt, t = RTT + L /

R

toisen pktn viim. bitti saapuu, läh. ACKkolmannen pktn viim. bitti saapuu, läh. ACK

3-paketin kanavointi lisää hyötykäyttöä

kolminkertaisesti!


Pipelined protocols: overviewGo-back-N:❖ sender can have up to N

unacked packets in pipeline

❖ receiver only sends cumulative ack▪ doesn’t ack packet if

there’s a gap❖ sender has timer for

oldest unacked packet▪ when timer expires,

retransmit all unacked packets

Selective Repeat:❖ sender can have up to N

unack’ed packets in pipeline

❖ rcvr sends individual ackfor each packet

❖ sender maintains timer for each unacked packet▪ when timer expires,

retransmit only that unacked packet


Kanavoidut protokollat: yleiskatsaus

Go-back-N:❖ lähettäjällä voi olla N

kuitattujen pakettien putki

❖ vastaanotin lähettää vain kumulatiivisen ack:n▪ ei ole ack jos on aukko

❖ lähettäjällä on ajastin vanhimpaan kuitattuun pakettiin▪ kun aika on kulunut,

lähetetään uudestaan kaikki kuittaamattomat paketit

Valikoiva uudelleenlähetys:❖lähettäjällä voi olla N kuitattujen pakettien putki

❖ rcvr lähettää yksittäisen ack: jokaisesta paketista

❖ lähettäjä ylläpitää ajastinta jokaiseen kuittaamattomaan pakettiin▪ kun ajastin on kulunut,

uudelleenlähetetään vain kuittaamaton paketti


Go-Back-N: sender❖ k-bit seq # in pkt header❖ “window” of up to N, consecutive unack’ed pkts allowed

❖ ACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK”▪ may receive duplicate ACKs (see receiver)

❖ timer for oldest in-flight pkt❖ timeout(n): retransmit packet n and all higher seq # pkts in

window


Go-Back-N: lähettäjä❖ k-bit seq # paketin ylätunniste❖ “ikkuna” jopa N, peräkkäistä kuittaamatonta pakettia sallittu

❖ ACK(n): ACKs kaikki paketit, mukaanlukien seq # n -“kumulatiivinen ACK”▪ voi saada duplikaatti-ACKs (kts vastaanotin)

❖ ajastin vanhimmalle menossa olevalle paketille❖ timeout(n): uudelleenlähettää paketin n ja kaikki korkeammat

seq # paketit ikkunasta


GBN: sender extended FSM

Wait start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])…udt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum < base+N) {sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum)udt_send(sndpkt[nextseqnum])if (base == nextseqnum)

start_timernextseqnum++}

elserefuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum)

stop_timerelse

start_timer


base=1nextseqnum=1


Λ


GBN: lähettäjä laajennettu FSM

Wait start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])…udt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum < base+N) {sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum)udt_send(sndpkt[nextseqnum])if (base == nextseqnum)

start_timernextseqnum++}

elserefuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum)

stop_timerelse

start_timer


base=1nextseqnum=1


Λ


ACK-only: always send ACK for correctly-received pkt with highest in-order seq #▪ may generate duplicate ACKs▪ need only remember expectedseqnum

❖ out-of-order pkt: ▪ discard (don’t buffer): no receiver buffering!▪ re-ACK pkt with highest in-order seq #

Wait

udt_send(sndpkt)default

rdt_rcv(rcvpkt)&& notcurrupt(rcvpkt)&& hasseqnum(rcvpkt,expectedseqnum)

extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(expectedseqnum,ACK,chksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt =

make_pkt(expectedseqnum,ACK,chksum)

Λ

GBN: receiver extended FSM


ACK-vain: aina lähettää ACK oikein vastaanotettu paketti suurimmassa seq # järjestyksessä▪ voi tuottaa päällekkäisiä ACKseja▪ täytyy vain muistaa expectedseqnum

❖ viallinen paketti: ▪ hylkäys (ei puskurointia): ei vastaanottajan puskurointia!▪ uudelleen-ACK paketti suurimmassa seq # järjestyksessä

Wait

udt_send(sndpkt)default

rdt_rcv(rcvpkt)&& notcurrupt(rcvpkt)&& hasseqnum(rcvpkt,expectedseqnum)

extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(expectedseqnum,ACK,chksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt =

make_pkt(expectedseqnum,ACK,chksum)

Λ

GBN: vastaanottajan laajennettu FSM


GBN in action

send pkt0send pkt1send pkt2send pkt3

(wait)

sender receiver

receive pkt0, send ack0receive pkt1, send ack1

receive pkt3, discard, (re)send ack1rcv ack0, send pkt4

rcv ack1, send pkt5

pkt 2 timeoutsend pkt2send pkt3send pkt4send pkt5

Xloss

receive pkt4, discard, (re)send ack1


rcv pkt2, deliver, send ack2rcv pkt3, deliver, send ack3rcv pkt4, deliver, send ack4rcv pkt5, deliver, send ack5

ignore duplicate ACK

0 1 2 3 4 5 6 7 8

sender window (N=4)

0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8

0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8

0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8


GBN toiminnassa

lähettää pkt0lähettää pkt1lähettää pkt2lähettää pkt3

(wait)


vastaanottaa pkt0, lähettää ack0vastaanottaa pkt1, lähettää ack1

receive pkt3, hylkää, uudelleen lähettää ack1

vast.ottaa ack0, lähettää pkt4

rcv ack1, send pkt5

pkt 2 timeoutlähettää pkt2lähettää pkt3lähettää pkt4lähettää pkt5

Xloss


receive pkt5, discard, (re)send ack1vast.o pkt2, toimittaa,

lähettää ack2rcv pkt3, deliver, send ack3rcv pkt4, deliver, send ack4rcv pkt5, deliver, send ack5

ignore duplicate ACK

0 1 2 3 4 5 6 7 8

lähettäjän ikkuna (N=4)

0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8

0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8

0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8


Selective repeat❖ receiver individually acknowledges all correctly

received pkts▪ buffers pkts, as needed, for eventual in-order delivery

to upper layer❖ sender only resends pkts for which ACK not

received▪ sender timer for each unACKed pkt

❖ sender window▪ N consecutive seq #’s▪ limits seq #s of sent, unACKed pkts


Valikoiva uudelleenlähetys❖ vastaanotin erikseen kuittaa kaikki oikein

vastaanotetut paketit▪ puskuroidaan paketteja tarpeen mukaan, lopulta

järjestykseen ylemmälle kerrokselle❖ lähettäjä uudelleenlähettää vain paketit, joiden

ACK ei vastaanoteta▪ lähettäjän ajastin jokaiselle kuittaamattomalle paketille

❖ lähettäjän ikkuna▪ N peräkkäinen seq #’s▪ rajoitukset seq #s lähettämisessä, unACKed pkts


Selective repeat: sender, receiver windows


Valikoiva uudelleenlähetys: lähettäjä, vastaanottaja ikkuna


Selective repeat

data from above:❖ if next available seq # in

window, send pkttimeout(n):❖ resend pkt n, restart timerACK(n) in [sendbase,sendbase+N]:❖ mark pkt n as received❖ if n smallest unACKed

pkt, advance window base to next unACKed seq #

senderpkt n in [rcvbase, rcvbase+N-1]❖ send ACK(n)❖ out-of-order: buffer❖ in-order: deliver (also

deliver buffered, in-order pkts), advance window to next not-yet-received pkt

pkt n in [rcvbase-N,rcvbase-1]❖ ACK(n)otherwise:❖ ignore

receiver


Valikoiva uudelleenlähetys

data ylhäältä:❖ jos seuraava saatavissa

oleva seq #ikkunassa, lähetä paketti

timeout(n):❖ uudelleen lähetä paketti,

ajastin alkaa alustaACK(n) in [sendbase,sendbase+N]:❖ merkitse paketti

vast.otetuksi❖ jos pienin unACKed

paketti, etukäteen ikkunaan seuraava unACKed seq #

lähettäjäpkt n in [rcvbase, rcvbase+N-1]❖ lähetä ACK(n)❖ viallinen: puskuroi❖ toimiva: toimita (myös

toimita puskuroidut, toimivat paketit), etene ikkuna seuraavaan ei vielä toimitettuun pakettiin

pkt n in [rcvbase-N,rcvbase-1]❖ ACK(n)otherwise:❖ ignooraa

vastaanottaja


Selective repeat in action

send pkt0send pkt1send pkt2send pkt3

(wait)

sender receiver

receive pkt0, send ack0receive pkt1, send ack1

receive pkt3, buffer, send ack3rcv ack0, send pkt4

rcv ack1, send pkt5

pkt 2 timeoutsend pkt2

Xloss

receive pkt4, buffer, send ack4


rcv pkt2; deliver pkt2,pkt3, pkt4, pkt5; send ack2

record ack3 arrived

0 1 2 3 4 5 6 7 8

sender window (N=4)

0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8

0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8

0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8

record ack4 arrivedrecord ack5 arrived

Q: what happens when ack2 arrives?


Valikoiva uudelleenlähetys toiminnassa

lähetä pkt0lähetä pkt1lähetä pkt2lähetä pkt3

(odota)


vast.ota pkt0, läh ack0vast.ota pkt1, läh ack1

vast.ota pkt3, puskuroi, lähetä ack3rcv ack0, läh pkt4

rcv ack1, läh pkt5

pkt 2 timeoutsend pkt2

Xloss



rcv pkt2; deliver pkt2,pkt3, pkt4, pkt5; send ack2

rekisteröi ack3 saapuneeksi

0 1 2 3 4 5 6 7 8

lähettäjän ikkuna (N=4)

0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8

0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8

0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8

record ack4 arrivedrecord ack5 arrived

Q: Mitä tapahtuu kun ack2 saapuu?


Selective repeat:dilemmaexample: ❖ seq #’s: 0, 1, 2, 3❖ window size=3

receiver window(after receipt)

sender window(after receipt)

0 1 2 3 0 1 2

0 1 2 3 0 1 2

0 1 2 3 0 1 2

pkt0pkt1pkt2

0 1 2 3 0 1 2 pkt0

timeoutretransmit pkt0

0 1 2 3 0 1 2

0 1 2 3 0 1 2

0 1 2 3 0 1 2XXX

will accept packetwith seq number 0(b) oops!

0 1 2 3 0 1 2

0 1 2 3 0 1 2

0 1 2 3 0 1 2

pkt0pkt1pkt2

0 1 2 3 0 1 2pkt0

0 1 2 3 0 1 2

0 1 2 3 0 1 2

0 1 2 3 0 1 2

Xwill accept packetwith seq number 0

0 1 2 3 0 1 2 pkt3

(a) no problem

receiver can’t see sender side.receiver behavior identical in both cases!

something’s (very) wrong!

❖ receiver sees no difference in two scenarios!

❖ duplicate data accepted as new in (b)

Q: what relationship between seq # size and window size to avoid problem in (b)?


Valikoiva uudelleenlähetys:ongelmaeseimerkki: ❖ järjestysnrot: 0, 1, 2, 3❖ ikkunan koko=3

vastaanottoikkuna(kuitin jälkeen)

lähetysikkuna(kuitin jälkeen)

0 1 2 3 0 1 2

0 1 2 3 0 1 2

0 1 2 3 0 1 2

pkt0pkt1pkt2

0 1 2 3 0 1 2 pkt0

aikakatkaisu-uudelleenlähetys pkt0

0 1 2 3 0 1 2

0 1 2 3 0 1 2

0 1 2 3 0 1 2XXX

hyväksyy paketin järj. numerolla 0(b) Ups!

0 1 2 3 0 1 2

0 1 2 3 0 1 2

0 1 2 3 0 1 2

pkt0pkt1pkt2

0 1 2 3 0 1 2pkt0

0 1 2 3 0 1 2

0 1 2 3 0 1 2

0 1 2 3 0 1 2

Xhyväksyy paketin järj.numerolla 0

0 1 2 3 0 1 2 pkt3

(a) ei ongelmiavastaanottaja ei näe lähettäjän puolta.

vastaanottajan käytös identtistä molemmissa tapauksissa.jotain pahasti pielessä!

❖ vastaanottaja ei näe eroa 2 skenaarion välillä!

❖ duplikoitunut data hyväksytään uutena b:ssä

Q: mikä on suhde järjestysnumeron ja ikkunan koolla välttääkseen ongelmaa b:ssä?


Chapter 3 outline









TCP: Overview RFCs: 793,1122,1323, 2018, 2581

❖ full duplex data:▪ bi-directional data flow

in same connection▪ MSS: maximum

segment size❖ connection-oriented:▪ handshaking (exchange

of control msgs) inits sender, receiver state before data exchange

❖ flow controlled:▪ sender will not

overwhelm receiver

❖ point-to-point:▪ one sender, one receiver

❖ reliable, in-order byte steam:▪ no “message boundaries”

❖ pipelined:▪ TCP congestion and flow

control set window size


TCP: Yleiskatsaus RFC:t 793,1122,1323, 2018, 2581

❖ täysin dupleksinen data:❖kaksisuuntainen

tiedonvirtaus samassa yhteydessä▪ MSS: maksimaalinen

segmentin koko❖ yhteys-orientoitunut:

▪ tervehtiminen (kontrolliviestien vaihto) määrittää lähettäjän ja vastaanottajan tilan ennen tiedonvaihtoa

❖ virta hallittuna:▪ lähettäjä ei pysty

valtaamaan vastaanottajaa täysin

❖ pisteestä pisteeseen:▪ yksi lähettäjä, yksi

vastaanottajaa❖ luotettava, käytössä

pysyvä “datavirta”:▪ ei ”viestirajoja”

❖ putkitettu:▪ TCP:n ruuhkan ja virran

hallinta asettaa ikkunalle koon


TCP segment structure


32 bits

applicationdata

(variable length)

sequence numberacknowledgement number

receive window

Urg data pointerchecksumFSRPAUheadlen

notused

options (variable length)

URG: urgent data (generally not used)

ACK: ACK #valid

PSH: push data now(generally not used)

RST, SYN, FIN:connection estab(setup, teardown

commands)

# bytes rcvr willingto accept

countingby bytes of data(not segments!)

Internetchecksum

(as in UDP)

Kuljetuskerros 3-110

TCP segmentin rakenne

lähtöportin nro saapumisportin nro

32 bits

sovelluksen data

(vaihteleva pituus)

järjestysnumerotunnistautumisnumero

vast.ottoikkunaKiireellisen

datan osoitinchecksumFSRPAUots.pit.

ei käyt.

vaihtoehdot(vaihteleva pituus)

URG: kiireinen data (yleensä ei käytetä)

ACK: ACK numero ok

PSH: työnnä dataa nyt

(ei käytetä usein)RST, SYN, FIN:

yhteyden perustus

(asennus, purkukäskyt)

määrä tavuja, jonka vastaanottaja on valmis hyväksymään

laskettu tavuina dataa (ei segmentteinä)

Internetintarkistussu

mma (UDP-

muodossa)


TCP seq. numbers, ACKssequence numbers:▪ byte stream “number” of

first byte in segment’s data

acknowledgements:▪ seq # of next byte

expected from other side▪ cumulative ACK

Q: how receiver handles out-of-order segments▪A: TCP spec doesn’t say,

- up to implementor source port # dest port #sequence number

acknowledgement number

checksum

rwndurg pointer

incoming segment to sender

A

sent ACKed

sent, not-yet ACKed(“in-flight”)

usablebut not yet sent

not usable

window sizeN

sender sequence number space


sequence numberacknowledgement number

checksum

rwndurg pointer

outgoing segment from sender


TCP järjestysnumerot, ACK:tjärjestysnumerot:▪ datavirran ensimmäisen

tavun “numero” segmentin datassa

Tunnistautumiset:▪ edellisen tavun järj.nro

odotetaan toiselta puolelta▪ kumulatiivinen ACK

K: kuinka vastaanottaja käsittelee toiminnassa olemattomia segmenttejä?▪ V: TCP:n tiedot ei kerro, -

vastuu tulkitsijallalähtöportti # v.o.portti #

järjestys numerotunnistautumisnumero

t.summa

v.o.ikiireellis-o.

saapuva segmentti

A

lähetetty kuitattu

lähetetty, ei vielä kuitattu(‘matkalla’)

käytettävissä, ei vielälähetetty

ei käytettävissä

ikkunan kokoN

lähettäjän järjestysnumerotila

lähtöportti # v.o.portti #

järjestysnumerotunnistautumisnumero

t.summa

v.o.ikiireellis-o.

lähtevä segmentti


TCP seq. numbers, ACKs

Usertypes

‘C’

host ACKsreceipt

of echoed‘C’

host ACKsreceipt of‘C’, echoesback ‘C’

simple telnet scenario

Host BHost A

Seq=42, ACK=79, data = ‘C’

Seq=79, ACK=43, data = ‘C’

Seq=43, ACK=80


TCP järjestysnumerot, ACK:t

Käyttäjä kirjoittaa

‘C’

isäntä kuittaa

kirjauksen

toistetusta ‘C’:stä.

isäntä kuittaa kirjauksen ‘C’:stä, toistaa takaisin ‘C’

yksinkertainen telnet skenaario

Isäntä B

Isäntä A

järj=42, ACK=79, data = ‘C’

järj=79, ACK=43, data = ‘C’

järj=43, ACK=80


TCP round trip time, timeoutQ: how to set TCP

timeout value?❖ longer than RTT▪ but RTT varies

❖ too short: premature timeout, unnecessary retransmissions

❖ too long: slow reaction to segment loss

Q: how to estimate RTT?❖ SampleRTT: measured

time from segment transmission until ACK receipt▪ ignore retransmissions

❖ SampleRTT will vary, want estimated RTT “smoother”▪ average several recent

measurements, not just current SampleRTT


TCP edestakaisen matkan aika(RTT), aikakatkaisuK: kuinka asetetaan

TCP:n aikakatkaisuarvo ?

❖ pidempi kuin RTT▪ mutta RTT vaihtelee

❖ liian lyhyt:ennenaikainen aikakatkaisu, tarpeettomia uudelleenlähetyksiä

❖ liian pitkä: hitaat reaktiot segmenttihävikkiin

K: kuinka arvioida RTT:tä?

❖ MitattuRTT: mittaa ajan segmentin siirrosta ACK kuittaukseen▪ ei huomioi

uudelleenlähetyksiä❖ MitattuRTT vaihtelee,

halutaan arvioitu RTT “pehmeämmäksi”▪ keskiarvo useista

viimeaikaisista mittauksista, ei hetkellistä MitattuaRTT:tä


EstimatedRTT = (1- α)*EstimatedRTT + α*SampleRTT

❖ exponential weighted moving average❖ influence of past sample decreases exponentially fast❖ typical value: α = 0.125

TCP round trip time, timeoutRT

T (m

illise

cond

s)

RTT: gaia.cs.umass.edu to fantasia.eurecom.fr

sampleRTTEstimatedRTT

time (seconds)


ArvioituRTT = (1- α)*ArvioituRTT + α*MitattuRTT

❖ eksponentiaalinen painotettu liikkuva keskiarvo❖ vanhan mittauksen vaikutus vähenee eksponentiaalisesti❖ tyypillinen arvo α = 0.125

TCP edestakaisenmatkan aika(RTT), aikakatkaisu

RTT

(mill

iseku

ntia

)

RTT: gaia.cs.umass.edu:sta osoitteeseenfantasia.eurecom.fr

MitattuRTTArvioituRTT

aika (sekuntia)


❖ timeout interval: EstimatedRTT plus “safety margin”▪ large variation in EstimatedRTT -> larger safety margin

❖ estimate SampleRTT deviation from EstimatedRTT: DevRTT = (1-β)*DevRTT +

β*|SampleRTT-EstimatedRTT|

TCP round trip time, timeout

(typically, β = 0.25)

TimeoutInterval = EstimatedRTT + 4*DevRTT

estimated RTT “safety margin”


❖ aikakatkaisun väli: ArvioituRTT + “turvaväli”▪ suuri vaihtelu ArvioituRTT:ssä -> suurempi turvaväli

❖ arvioi MitattuRTT:n vaihtelu ArvioituRTT:stä: MuuttuvaRTT = (1-β)*MuuttuvaRTT +

β*|MittausRTT-ArvioituRTT|

TCP edestakaisen matkan aika (RTT), aikakatkaisu

(tyypillisesti, β = 0.25)

aikakatkaisun väli = ArvioituRTT + 4*Muuttuva RTT

estimated RTT “safety margin”


Chapter 3 outline









TCP reliable data transfer❖ TCP creates rdt service

on top of IP’s unreliable service▪ pipelined segments▪ cumulative acks▪ single retransmission

timer❖ retransmissions

triggered by:▪ timeout events▪ duplicate acks

let’s initially consider simplified TCP sender:▪ ignore duplicate acks▪ ignore flow control,

congestion control


TCP luotettava datan siirto❖ TCP luo rdt palvelun

IP:n epäluotettavan palvelun päälle

▪ kanavoidut segmentit▪ kumulatiiviset kuittaukset▪ yksittäinen

uudelleenlähetys ajastin❖ uudellenlähetyksen

laukaisevat:▪ aika loppu tapahtumat▪ duplikaattikuittaukset

aluksi hulehditaan yksinkertaistusta TCP lähettäjästä▪ ei huomio

duplikaattikuittauksia▪ ei huomio ruuhka, eikä

flow tarkkailua


TCP sender events:data rcvd from app:❖ create segment with

seq #❖ seq # is byte-stream

number of first data byte in segment

❖ start timer if not already running ▪ think of timer as for

oldest unacked segment▪ expiration interval: TimeOutInterval

timeout:❖ retransmit segment

that caused timeout❖ restart timerack rcvd:❖ if ack acknowledges

previously unacked segments▪ update what is known

to be ACKed▪ start timer if there are

still unacked segments


TCP lähettäjän tapahtumat:data vastaanotetaan

sovellukselta:❖ tee segmentti seq #

kanssa❖ seq # on bitti virran

ensimmäisen bitin numero

❖ aloita ajastus jos ei vielä aloitettu▪ ajattele ajastin

vanhimman kuittaamattoman segmentin mukaan▪ expiration interval: TimeOutInterval

aika loppu:❖ lähetä segmentti joka

aiheutti ajan loppumisen uudelleen

❖ aloita ajastus alustakuittaus vastaanotettu:❖ jos kuittaus kuittaa

aiemmin ei kuitatun segmentin▪ päivitä ne mitkä

tiedetään että tullaan kuittaamaan▪ aloita ajastin jos jäljellä

on kuittaamattomia segmenttejä


TCP sender (simplified)

waitfor

event

NextSeqNum = InitialSeqNumSendBase = InitialSeqNum

Λ

create segment, seq. #: NextSeqNumpass segment to IP (i.e., “send”)NextSeqNum = NextSeqNum + length(data) if (timer currently not running)

start timer

data received from application above

retransmit not-yet-acked segment with smallest seq. #

start timer

timeout

if (y > SendBase) { SendBase = y /* SendBase–1: last cumulatively ACKed byte */if (there are currently not-yet-acked segments)

start timerelse stop timer

}

ACK received, with ACK field value y


TCP lähettäjä (yksinkertaistettu)

odota tapahtumaa

NextSeqNum = InitialSeqNumSendBase = InitialSeqNum

Λ

luo segmentti, seq. #: NextSeqNumsiirrä segmentti IP:lle (i.e., “lähetä”)NextSeqNum = NextSeqNum + length(data) jos (ajastin ei käynnissä)

käynnistä ajastin

data vastaanotettu sovellukselta yläpuolelta

uudelleen lähetys ei vielä kuitattu segmenttiin jolla pienin seq. #käynnistä ajastin

aika loppu

if (y > SendBase) { SendBase = y /* SendBase–1: last cumulatively ACKed byte */jos (ei ole vielä ei kuitattuja segmenttejä jäljellä

)käynnistä ajastin

muuten pysäytä ajastin}

ACK vastaanotettu, with ACK field value y


TCP: retransmission scenarios

lost ACK scenario

Host BHost A

Seq=92, 8 bytes of data

ACK=100


Xtimeo ut

ACK=100

premature timeout

Host BHost A


ACK=100

Seq=92, 8bytes of data

timeo ut

ACK=120


ACK=120

SendBase=100

SendBase=120

SendBase=120

SendBase=92


TCP: uudelleenlähetys skenaariot

hävinnyt ACK skenaario

Host BHost A


ACK=100


Xtimeo ut

ACK=100

ennenaikainen aika loppu

Host BHost A


ACK=100

Seq=92, 8bytes of data

timeo ut

ACK=120


ACK=120

SendBase=100

SendBase=120

SendBase=120

SendBase=92


TCP: retransmission scenarios

X

cumulative ACK

Host BHost A


ACK=100


timeo ut


ACK=120


TCP: uudelleenlähetys skenaariot

X

kumulatiivinen ACK

Host BHost A


ACK=100


timeo ut


ACK=120


TCP ACK generation[RFC 1122, RFC 2581]

event at receiver

arrival of in-order segment withexpected seq #. All data up toexpected seq # already ACKed

arrival of in-order segment withexpected seq #. One other segment has ACK pending

arrival of out-of-order segmenthigher-than-expect seq. # .Gap detected

arrival of segment that partially or completely fills gap

TCP receiver action

delayed ACK. Wait up to 500msfor next segment. If no next segment,send ACK

immediately send single cumulative ACK, ACKing both in-order segments

immediately send duplicate ACK,indicating seq. # of next expected byte

immediate send ACK, provided thatsegment starts at lower end of gap


TCP ACK generointi [RFC 1122, RFC 2581]

tapahtuma vastaanottajalla

in-order segmentin saapuminen odotetulla seq #. kaikki data odotetulla seq # jo kuitattuin-order segmentin saapuminen odotetulla seq #. yhdellä toisella segmentillä on kuittaus odottamassaout-of-order segmentin saapuminen liian korkealla seq. # .aukko havaittu

segmentin saapuminen joka kokonaan tai osittain täyttää aukon

TCP vastaanottajan toiminta

viivästynyt ACK. Odota 500msseuraavaa segmenttiä. Jos ei seuraavaa segmenttiä. lähetä ACK

lähetä heti yksittäinen kumulatiivinenACK, ACKing molemmat in-order segmentit

lähetä heti duplikaatti ACK,viitaten seq. # seuraavan odotetun bitin

lähetä heti ACK, tarjota että segmentti alkaa matalammalta aukon lopusta


TCP fast retransmit❖ time-out period often

relatively long:▪ long delay before

resending lost packet❖ detect lost segments

via duplicate ACKs.▪ sender often sends

many segments back-to-back▪ if segment is lost, there

will likely be many duplicate ACKs.

if sender receives 3 ACKs for same data(“triple duplicate ACKs”),resend unacked segment with smallest seq #▪ likely that unacked

segment lost, so don’t wait for timeout

TCP fast retransmit

(“triple duplicate ACKs”),


TCP nopea uudelleenlähetys❖ aika loppu periodi

suhteellisen pitkä :▪ pitkä viive ennenkuin

hävinnyt paketti uudellen lähetetään

❖ havaita hävinneet segmentit duplikaatti ACK:n avulla

❖ lähettäjä lähettää monia paketteja back-to-back▪ Jos paketti katoaa, luultavasti saadaan monia duplikaatti ACK:ta

jos lähettäjä saa kolme kuittausta(“kolme duplikaatti ACKs”), uudelleen lähetä ei kuitatut segmentit pienimmästä seq #▪ todennäköistä että ei

kuitattu segmentti hävinnyt, ei tarvitse odottaa ajan loppumista

TCP nopea uudelleenlähetys

,


X

fast retransmit after sender receipt of triple duplicate ACK

Host BHost A


ACK=100

timeo ut

ACK=100

ACK=100ACK=100

TCP fast retransmit




X

nopea uudelleenlähetys kun vastaanottaja on saanu

kolme duplikaatti

Host BHost A


ACK=100

timeo ut

ACK=100

ACK=100ACK=100

TCP nopea uudelleenlähetys




Chapter 3 outline









TCP flow controlapplicati

onprocess

TCP socketreceiver buffers

TCPcode

IPcode

applicationOS

receiver protocol stack

application may remove data from

TCP socket buffers ….

… slower than TCP receiver is delivering(sender is sending)

from sender

receiver controls sender, so sender won’t overflow receiver’s buffer by transmitting too much, too fast

flow control


TCP liikenteen hallintaapplicati

onprocess

TCP socketreceiver buffers

TCPcode

IPcode

sovellusOS

vastaanottajan protokolla pino

sovellus voi siirtää dataa pois TCP sokettien puskureista ….

…hitaampi kuin TCP vastaanottaja

toimittaa (lähettäjä lähettää)

from sender

vastaanottaja kontrolloi lähettäjää, jotta lähettäjä ei ylikuormita vastaanottajan puskuria lähettämällä liian paljon, liian nopeasti

liikenteen hallinta


TCP flow control

buffered data

free buffer spacerwnd

RcvBuffer

TCP segment payloads

to application process❖ receiver “advertises” free

buffer space by including rwnd value in TCP header of receiver-to-sender segments▪ RcvBuffer size set via

socket options (typical default is 4096 bytes)

▪ many operating systems autoadjust RcvBuffer

❖ sender limits amount of unacked (“in-flight”) data to receiver’s rwnd value

❖ guarantees receive buffer will not overflow

receiver-side buffering


TCP liikenteen hallinta

puskuroitu data

ilmaista puskurointi tilaa

rwnd

RcvBuffer

TCP segmentin tietosisältö

sovellusprosessiin❖ vastaanottaja mainostaa ilmaista

puskuri tilaa sisällyttämällä rwnd arvon vastaanottajalta lähettäjälle segmentin TCP otsikkoon

▪ RcvBuffer koko asetettu soketti asetusten perusteella(tyypillinen oletus 4096 bittiä

▪ monet operaatiot säätävät automaattisesti RcvBuffer

❖ lähettäjä rajoittaa ei kuitattua dataa rwnd arvolla

❖ lupaa, että vastaanottajan puskuri ei ylikuormitu

vastaanottajan puoli puskurointi


Chapter 3 outline









Connection Managementbefore exchanging data, sender/receiver “handshake”:❖ agree to establish connection (each knowing the other willing to

establish connection)❖ agree on connection parameters

connection state: ESTABconnection variables:

seq # client-to-serverserver-to-client

rcvBuffer sizeat server,client

application

network

connection state: ESTABconnection Variables:



application

network

Socket clientSocket = newSocket("hostname","port number");

Socket connectionSocket = welcomeSocket.accept();


Yhteyden johtoporrasennen datan vaihtamista, lähettäjä/vastaanottaja

“kättely”:❖ hyväksyy yhteyden muodostamisen (kummatkin tietävät

molempien halukkuuden yhteyden muodostamiseen)❖ hyväksyminen yhteyden parametreistä

yhteyden tila: ESTAByhteyden vaihtoehdot:



hakemus

verkko

yhteyden tila: ESTAByhteyden vaihtoehdot:



hakemus

verkko




Q: will 2-way handshake always work in network?

❖ variable delays❖ retransmitted messages (e.g.

req_conn(x)) due to message loss

❖ message reordering❖ can’t “see” other side

2-way handshake:

Let’s talk

OKESTAB

ESTAB

choose x req_conn(x)ESTAB

ESTABacc_conn(x)

Agreeing to establish a connection


K: Toimiiko 2-osainen kättely aina verkossa?

❖ vaihtelevat viiveet❖ uudelleenvälitetyt viestit

(e.g. req_conn(x)) johtuen viestin menetyksestä

❖ viestin uudelleentilaus❖ ei voi “nähdä” toista puolta

2-osainen kättely:

jutellaan

OKESTAB

ESTAB

valitse x req_conn(x)ESTAB

ESTABacc_conn(x)

Hyväksyminen yhteyden muodostamiseen


Agreeing to establish a connection2-way handshake failure scenarios:

retransmitreq_conn(x)

ESTAB

req_conn(x)

half open connection!(no client!)

client terminates

serverforgets x

connection x completes


ESTAB

req_conn(x)

data(x+1)

retransmitdata(x+1)

acceptdata(x+1)

choose xreq_conn(x)

ESTAB

ESTAB

acc_conn(x)

client terminates

ESTAB

choose xreq_conn(x)

ESTABacc_conn(x)

data(x+1) acceptdata(x+1)

connection x completes server

forgets x


Hyväksyminen yhteyden muodostamiseen

2-osaisen kättelyn epäonnistumis skenaariot:


ESTAB

req_conn(x)

half open connection!(no client!)

client terminates

serverforgets x

connection x completes


ESTAB

req_conn(x)

data(x+1)

retransmitdata(x+1)

acceptdata(x+1)

choose xreq_conn(x)

ESTAB

ESTAB

acc_conn(x)

client terminates

ESTAB

choose xreq_conn(x)

ESTABacc_conn(x)

data(x+1) acceptdata(x+1)

connection x completes server

forgets x


TCP 3-way handshake

SYNbit=1, Seq=x

choose init seq num, xsend TCP SYN msg

ESTAB

SYNbit=1, Seq=yACKbit=1; ACKnum=x+1

choose init seq num, ysend TCP SYNACKmsg, acking SYN

ACKbit=1, ACKnum=y+1

received SYNACK(x) indicates server is live;send ACK for SYNACK;

this segment may contain client-to-server data received ACK(y)

indicates client is live

SYNSENT

ESTAB

SYN RCVD

client state

LISTENserver state

LISTEN


TCP 3-osainen kättely

SYNbit=1, Seq=x

valitse ensi seq num, x

lähetä TCP SYN msg

ESTAB

SYNbit=1, Seq=yACKbit=1; ACKnum=x+1

valitse ensi seq num, ylähetä TCP SYNACKmsg, acking SYN

ACKbit=1, ACKnum=y+1

vastaanotettu SYNACK(x) osoittaa serverin

läsnäolon;lähetä ACK for SYNACK;

tämä serveri voi ylläpitää client-to-server dataa vastaanotettu ACK(y)

osoittaa käyttäjän läsnäolon

SYNSENT

ESTAB

SYN RCVD

nykyinen tilaLISTEN

serverin tila

LISTEN


TCP 3-way handshake: FSM

closed

Λ

listen

SYNrcvd

SYNsent

ESTAB


SYN(seq=x)


SYN(x)SYNACK(seq=y,ACKnum=x+1)

create new socket for communication back to client

SYNACK(seq=y,ACKnum=x+1)ACK(ACKnum=y+1)ACK(ACKnum=y+1)

Λ


TCP 3-osainen kättely: FSM

suljettu

Λ

kuuntelu

SYNvastotett

u

SYNlähetetty

ESTAB


SYN(seq=x)


SYN(x)SYNACK(seq=y,ACKnum=x+1)

luo uuden soketin käyttäjän kommunikointiin

SYNACK(seq=y,ACKnum=x+1)ACK(ACKnum=y+1)ACK(ACKnum=y+1)

Λ


TCP: closing a connection❖ client, server each close their side of connection▪ send TCP segment with FIN bit = 1

❖ respond to received FIN with ACK▪ on receiving FIN, ACK can be combined with own FIN

❖ simultaneous FIN exchanges can be handled


TCP: yhteyden sulkeminen❖ käyttäjä ja serveri sulkevat omalta osaltaan

yhteyden▪ lähetä TCP segmenttiin FIN bitillä = 1

❖ vastataan vastaanotettuun FIN:iin ACK:illa▪ vastaanotettaessa FIN:iä, ACK voidaan yhdistää omaan

FIN:iin❖ samanaikaiset FIN vaihdot voidaan handlata


FIN_WAIT_2

CLOSE_WAIT

FINbit=1, seq=y

ACKbit=1; ACKnum=y+1

ACKbit=1; ACKnum=x+1wait for server

close

can stillsend data

can no longersend data

LAST_ACK

CLOSED

TIMED_WAIT

timed wait for 2*max

segment lifetime

CLOSED

TCP: closing a connection

FIN_WAIT_1 FINbit=1, seq=xcan no longersend but canreceive data

clientSocket.close()

client state server state

ESTABESTAB


FIN_WAIT_2

CLOSE_WAIT

FINbit=1, seq=y

ACKbit=1; ACKnum=y+1

ACKbit=1; ACKnum=x+1odottaa serverin

kappale 3 kuljetustaso - lut · kappale 3 kuljetustaso computer networking: a top down approach 6th...

Documents