Linklaget

Transcription

Linklaget

Linklaget
Feildeteksjon/feilretting
- pålitelig overføring
Foreleser:
Kjell Åge Bringsrud
E-mail: kjellb
Frank Eliassen/Stein Gjessing, Ifi,
UiO
1
Feildeteksjon/feilretting
Oppgaver:
1. Finne feil
2. Rette feil
⌧To alternativer til å rette feil:
⌧A. Ha nok informasjon til å rette opp feil i de mottatte dataene
⌧B. Be om at dataene (rammen) blir sendt en gang til
⌧(C. Gi blanke, det er ikke så farlig å miste litt data)
Generelt prinsipp i informatikken:
Oppdag feilen så fort som mulig etter at
den har oppstått !
UiO
2
Feil-deteksjon
Bit-feil i rammer
behov for mekanismer som oppdager bit-feil
Teknikker som ofte benyttes i datanett
Cyclic Redundency Check (CRC)
⌧svært utbredt
Paritet - to-dimensjonal paritet
⌧BISYNC ved ASCII overføring
Sjekksum
⌧flere Internett-protokoller
UiO
3
1
Paritet (tverrsum)
Ett paritetsbit:
F.eks. 7 bit data, sendes som 8 bit
Like paritet dvs. et like antall enere i resultatet
0110001 sendes som 01100011
Odde paritet dvs. et odde antall enere i resultatet
Odde paritet: 0110001 sendes som 01100010
Generelt: Jo mer data til redundans, jo flere feil
oppdages.
(RAID: Redundant Array of Inexpensive Disks)
UiO
4
To-dimensjonal paritet
Rad paritet
Kolonne paritet
paritets
biter
Oppdager alle 1,2 og 3 bit feil og
de fleste 4 bit feil
I eksemplet: 14 bit redundant
informasjon, og 42 bit melding
0101001
1101001
1011110
ramme
0001110
0110100
1011111
paritets 1 1 1 1 0 1 1
1
0
1
1
1
0
0
byte
UiO
5
Internett sjekksum algoritme
Se på en melding som en sekvens av 16-biters
heltall
Senderen adderer disse heltallene sammen ved
bruk av 16-bit aritmetikk
Dette 16-bit tallet er sjekksummen
Mottaker utfører samme beregning og
sammenligner resultatet med den mottatte
sjekksum
Får mottaker feil resultat er det bitfeil enten i
dataene eller i sjekksummen
Benyttes ende til ende i Internett
transportlaget
UiO
6
2
CRC: Cyclic Redundancy Check
Generalisering av paritet:
Kodeord
Data (med hode)
Sjekk/CRC
Like paritet: Kodeordet delt på 2 skal ikke gi rest
CRC: Kodeordet delt på et tall, G, skal ikke gi rest
Dette tallet vi deler på kaller vi Generatorpolynomet
Deling foregår med modulo-2 regning, dvs ikke mente
eller låning.
UiO
7
Cyclic Redundency Check
Kodeord
Sjekk/CRC
Data (med hode)
m biter
r biter
CRC: Kodeordet delt på et Generatortall skal ikke gi rest
Hvordan finner vi Sjekk/CRC? Jo, slik:
1. Generatortallet kaller vi G. G er på r+1 biter.
2. Lag et stort tall av Data med r 0-biter bak
Data (med hode)
m biter
Divider dette store tallet på G
Bruk modulo-2 regning (XOR, dvs. ikke noe mente)
3. Resten av divisjonen er alltid på r eller færre biter !
Denne resten blir Sjekk/CRC
000…00
r biter
Da vil Kodeordet være delelig på G (med 0 i rest)
UiO
8
Desimal analogi til CRC-utregning
Kodeord
Data (med hode)
Sjekk/CRC
82532109
0000
Anta G er 3497
825321090000 : 3497 = 236008318 med rest 1954
82532109 - 1954 = 825321088046
82532108
8046
825321088046 : 3497 = 236008318 nøyaktig
(mente i subtraksjonen ødlegger dataene våre)
UiO
9
3
Virkelig CRC-utregning
Kodeord
Data (med hode)
Sjekk
1101011011
0000
Anta G er 10011
11010110110000 : 10011 = 1100001010 med rest 1110
11010110110000 - 1110 = 11010110111110
1101011011
1110
11010110111110 : 10011= 1100001010 nøyaktig
(og subtraksjonen ødela ikke dataene våre)
UiO
10
CRC baserer seg på polynomer
CRC-algoritmen ser på binærtall som polynomer.
F.eks. betraktes 1
0
0
1
1 som polynomet
x 4 + x + 1 = x 4 + x1 + x 0 = 1* x 4 + 0 * x 3 + 0 * x 2 + 1* x1 + 1* x 0
Og
1
1 0 0 0 1
som polynomet
x5 + x4 + 1 = x5 + x4 + x0
NB: Hvis polynomet er av grad r, har binærtallet r+1 biter
UiO
11
CRC: Matematikk og polynomer
n
Data (med hode)
Melding/Kodeord
r
CRC
Bitene i meldingen oppfattes egentlig som koeffesientene i et
polynom, slik at meldingen kan sees på som et polynom
Generatortallet, G, er koeffesientene i et polynom, CRC-polynomet
Matematisk grunnlag: polynom aritmetikk modulo-2
UiO
12
4
Matematisk grunnlag for CRC
Representer en n-bit melding som et n-1 grads polynom
⌧eksempel: Data=10011010 tilsvarer M(x) = x7+ x4 + x3 + x1
La k være graden til generator polynomet G(x)
⌧eksempel: G(x) = x3+ x2 + 1 (dvs. k = 3)
Transmitter polynomet P(x) = M(x) + CRC slik at P(x) er delelig
med G(x), og motta polynomet P(x) + E(x)
⌧E(x)=0 betyr ingen feil
Mottaker dividerer (P(x) + E(x)) med G(x); resten vil være null i
kun to tilfeller:
⌧E(x) var null (dvs. det var ingen feil),
⌧E(x) er nøyaktig delelig med G(x).
Velg G(x) slik at det andre tilfellet opptrer veldig sjeldent
UiO
13
Hvordan beregner vi CRC-feltet?
multipliser M(x) by xk (legg på k nuller)
⌧i vårt eksempel får vi x10 + x7 + x6 + x4 (10011010000)
divider resultet med G(x)
⌧(i vårt eksempel: 1101)
1001101000 : 1101 = 11111001
rest: 101
Send 10011010000 - 101 = 10011010101, siden dette må være
nøyaktig delelig med C(x)
UiO
14
Regneeksemplet
(sender):
10011010000 : 1101 = 11111001
1101
1001
1101
1000
1101
1011
1101
1100
1101
1000
1101
Frank Eliassen/Stein Gjessing,
101 Ifi, rest
UiO
15
5
Regneeksemplet
(mottaker):
10011010101 : 1101 = 11111001
1101
1001
1101
1000
1101
1011
1101
1100
1101
1101
1101
Frank Eliassen/Stein Gjessing,
000 Ifi, rest
UiO
16
Velge CRC polynom
Intuitivt krav:
Hvis rammen forandrer seg (litt), må det være lite sannsynlig at divisjonen
med CRC polynomet går opp
På samme måte som det er regler for hvilke tall bl.a. 2 og 3 går opp i,
er det regler om hvilke tall (forandring av den orginale meldingen)
G går opp i, avhengig av G. Velg derfor G med omhu.
Noen egenskaper ved CRC sjekk mhp. deteksjon av feil:
Alle enkel-bit feil dersom xk and x0 termene har koeffesienter som ikke er
null
Alle dobbel-bit feil dersom C(x) har en faktor med minst tre termer.
Etthvert odde antall feil dersom C(x) inneholder faktoren (x + 1).
Enhver kaskadefeil (dvs. sekvens av etterfølgende bit-feil) med lengde
mindre enn k biter.
De fleste kaskadefeil større enn k biter kan også oppdages.
UiO
17
Vanlige CRC polynom
CRC
C(x)
CRC-8
x8+x2+x1+1
CRC-10
CRC-12
x10+x9+x5+x4+x1+1
x12+x11+x3+x2+x1+1
CRC-16
x16+x15+x2+1
=100000111
=1100000001111
=11000000000000101
=10001000000100001
CRC-CCITT x16+x12+x5+1
x32+x26+x23+x22+x16+x12+x11+x10+
CRC-32
x8+x7+x5+x4+x2+x+1
UiO
18
6
Egenskaper CRC-16
•Alle enkle og doble bitfeil
•Alle feil i et odde antall bit
•Alle kaskadefeil av lengde mindre enn 17
•99,997 % av alle 17 biters kaskader
•99,998 % av alle 18 biters kaskader
UiO
19
Implementasjon CRC
Implementasjon i maskinvare av CRC algoritmene kan
gjøres enkelt og raskt vha. et shift register og XOR
porter
Dolphin (tidliger ND, Skullerud) implementerer i SCI
en CRC-16 fra en 80 byte pakke i en hastighet av
500Mbyte/sek og med noen få nanosekunders
forsinkelse.
NB! CRC må da ligge bakerst i pakken
UiO
20
Hva bør beskyttes av CRC ?
Hele rammen
Hele hodet – ikke data
Deler av hodet
Vikigst: mottakeradresse og pakkelengde
Kast en pakke så fort som mulig i det en CRCfeil oppdages !
UiO
21
7
Feilretting
Når skal vi rette feil ?
Mottakeradresse, pakkelengde mm. i hodet må
eventuelt rettes med en gang.
Data kan rettes med en gang eller vente
Avveiing:
⌧Rette med en gang: Tar tid, ønsker vi at alle noder i nettet
skal bruke tid på dette ?
⌧Vente: Da kan det hende at feilen blir verre slik at det ikke
er mulig å rette den lenger.
UiO
22
Feilretting uten
retransmisjon
Kalles ”Forward Error Correction”
To-dimensjonal paritet og Hammingkoder
kan benyttes
Kan f.eks. sende alle pakker to ganger
UiO
23
Pålitelig overføring
Pakker med feil CRC kastes
Fint om vi kan rette opp feilen
Hvis feilen ikke kan rettes opp, og vi trenger
pakken, da
må den sendes en gang til !
Også her er det en avveiing:
Ende-til ende eller mellom noder ?
(Problemkomplekset med doblet/triplet (mm.) funksjonalitet)
UiO
24
8
Pålitelig overføring
Når omsending av pakker er nødvendig:
To fundamentale mekanismer
kvitteringer (engelsk: acknowledgements, ack)
tidsfrister (timeouts) vha. vekkeklokke (timer)
Husk at også kvitteringer kan bli borte
Ønsker vi at pakkene skal komme frem i riktig
rekkefølge?
UiO
25
Stop-and-Wait (stopp og vent)
Sender
Mottaker
2. ACK
A
B
1. Pakke
Mottaker sender ack tilbake når en ramme er mottatt,
og først når sender mottar ack, sendes ny ramme.
På denne måten blir ikke mottaker oversvømmet av pakker,
og avsender vet at alle pakker er kommet trygt fram.
Men hva hvis pakker blir borte?
UiO
26
Stop-and-Wait (stopp og vent)
Grunnleggende algoritme:
send én ramme og vent på kvittering (ACK ramme)
dersom ACK ikke mottatt innen gitt tidsfrist, send rammen på
nytt.
ram
ram
tidsfrist
me
me
tidsfrist
ACK
ram
tidsfrist
me
ACK
UiO
27
9
Stop-and-Wait
Problem 1 med grunnleggende algoritme:
Men kanskje det var ACK som ble borte
Vi må kunne sende den samme rammen på nytt, selv om den
allerede er kommet riktig frem
ram
tidsfrist
ACK
ram
tidsfrist
me
me
ACK
UiO
28
Stop-and-Wait
Problem 2 med grunnleggende algoritme:
Kanskje vi sendte rammen om igjen for tidlig
Vi må godta at ACK kommer for sent
ram
tidsfrist
tidsfrist
me
ACK
ram
me
ACK
UiO
29
Stop-and-Wait
ram
Må sende
rammen på nytt
og på nytt helt til
ACK kommer
tilbake
Hvordan vet
mottaker at det er
den samme
rammen som
sendes på nytt?
me
tidsfrist
ram
tidsfrist
me
ACK
ram
tidsfrist
UiO
me
ACK
ram
me
ACK
30
10
Løsning: sekvensnummer
ACK (send meg k+1)
k+1
k+1
Mottaker
k+1
A
B
k+1 k
k
k
k
k
Ramme nr. k
Det er nok med en en-bit teller (0 og 1)
k, k+1 regnes da ut modulo 2.
(En buffers “Sliding window” protokoll)
UiO
31
Sekvensnummer som 0 og 1
0 og 1 som sekvensnummere
En bit er nok når vi sender én ramme av gangen og venter
på kvittering
ACK 1: Send ramme med odde sekvensnummer
ACK 0: Send ramme med like sekvensnummer
Altså:
ramme 0, 1, 2, 3, 4, 5, … sendes som
ramme 0, 1, 0, 1, 0, 1, …
Går dette bra?
Hva betyr det at “det går bra”?
UiO
32
0 - 1 sekvensnummer
Egsenskaper til korrekt løsning?
Mottaker leverer aldri samme ramme to eller
flere ganger til laget over (nettlaget)
Ingen rammer går tapt (forutsatt at alle
meldinger før eller siden kommer frem når de
resendes tilstrekkelig antall ganger)
Rammene leveres i samme rekkefølge hos
mottager som de sendes i av senderen
(forutsatt at en ramme leveres straks den er
korrekt mottat og ikke mottat før)
UiO
33
11
0 - 1 sekvensnummerram
Analyse av sender
- like ramme (0) sendes ut
- ignorerer (gamle) ACK 0
- resender like ramme (0)
I det ACK 1 kommer:
- odde ramme (1) sendes ut
- resender odde ramme (1)
I det ACK 0 kommer:
- like ramme (0) sendes ut
- resender like ramme (0)
I det ACK 1 kommer:
osv.
Vanskelig?
me
0
tidsfrist
tidsfrist
tidsfrist
UiO
ram
me
0
K
AC
1
levér
ramme 0
ram
me
0
K1
AC
ram
ramme 0
me
1
K1
AC K 0
C
A
ram
me
0
ignorér
ramme 0
ignorér
ramme 0
levér
ramme 1
34
Tilstandsmaskin for en-bit protokoll
Ta imot
ack 0
Ta imot
pakke 0
Send
pakke 0
Start
Ta imot
ack 0
Ta imot
ack 1
Send
ack 1
Ta imot
pakke 0
Ta imot
pakke 1
Start
Ta imot
ack 1
Ta imot
pakke 1
Sender
Send
pakke 1
UiO
Send
Mottaker ack 0
35
Petrinett:
Generalisert tilstandsdiagram med parallelle aktiviteter
Eksempel 1
Anne
Et kyss
Ole
UiO
36
12
Petrinett:
Generalisert tilstandsdiagram med parallelle aktiviteter
Eksempel 2
Vil gå tur
Anne
Gå tur sammen
Vil gå tur
Ole
UiO
37
Et bit protokoll
ACK (send meg k+1 mod 2)
A
1
k
k+1
k+2
k+3
k+4
k+5
0
1
0
1
0
1
1
0
B
1
0
0
Sender
Mottaker
ACK (send meg k+2 mod 2)
A
k+1
k+2
k+3
k+4
k+5
0
Ramme nr. k
0
1
0
1
0
1
0
1
B
0
1
1
1
Ramme nr. k + 1
UiO
38
Stop-and-Wait
Det gjør ikke noe om
mottaker gjentar en
ACK, men det er ikke
vanlig, dvs. at det er
bare vanlig å sende ACK
når en pakke ankommer.
Ved mye pakketap kan
det være gunstig å
gjenta ACK selv om det
ikke kommer en ny
pakke.
Hvorfor?
ram
tidsfrist
me
0
ACK
ram
tidsfrist
UiO
me
0
1
ACK
ram
tidsfrist
1
me
0
1
CK
rA
am
ram me 0
me
1
0
C
A K
39
13
Stop-and-Wait
Grunnleggende svakhet:
utnytter linjekapasiteten dårlig
⌧senderen kan bare ha én utestående ramme til enhver tid
Eksempel:
1.5Mbps link x 45ms RTT = 67.5Kb (8KB)
⌧dvs. 8KB data kan være underveis på linjen
anta rammestørrelse 1KB
stop-and-wait bruker ca. 1/8 av linjekapasiteten (om ingen feil)
Mål: senderen må kunne sende opp til 8 rammer før den må
vente på en ACK
⌧moralen er: “fyll opp røret”
Avsender
Mottaker
UiO
40
Fyll opp røret
Utnytte linjen bedre.
Sender flere pakker rett etter hverandre:
A
B
Pakker
Pakker
Putte ACK/NAK på ryggen til meldinger som går
den andre veien (“piggyback”)
UiO
41
Hvis vi ikke fyller opp røret
Lange ledninger. Det tar tid før pakken kommer frem og
ACK kommer tilbake. Utnyttelsen av linken kan regnes ut:
Bruk av ledningen (pakkebruk): pakkelengde * sendehastighet
Forsinkelse tur/retur (RTT):
avstand * utbredelseshastighet * 2 + pakkebruk + ACKpakkebruk
Eksempel:
1500m fiber, 1/2 * 3*108 m/s gir 10000 ns hver vei
53 byte pakke, 1G bit/sec, 424 bit gir 424 ns. (samme i ACK)
++
Bruksdel= pakkebruk/RTT = 424/(10000*2 +424+424++) ≈ 2%
A
Sender
B
Pakke
UiO
Mottaker 42
14
Glidende vindu
Idé:
Tillat senderen å sende flere rammer før den mottar ACK for
derved å holde “røret fullt”.
Det må være en øvre grense på antall rammer som kan være
utestående (som det ikke er mottat ACK for).
mottaker
sender
Eksempel:
maks. 5
utestående
rammer
UiO
43
Glidende vindu
Flere bufre hos sender og flere bufre hos mottaker,
mange pakker med forskjellige nummer og mange ack/nack med
forskjellige nummer under veis hele tiden.
ACK/NACK
Pakker
UiO
44
Glidende vindu
Sendt men ikke fått ack,
må kanskje sendes på nytt
Disse tre er motatt
og kvittert (ack sendt)
(vil bli resendt om ack aldri mottas) (men kan ikke sendes
Ikke motatt
videre før x motatt)
ack/nak
x
x
Pakker
UiO
45
15
Glidende vindu: sender
Tilordner sekvensnummer til hver ramme (SeqNum)
Vedlikeholder tre tilstandsvariable
send window size (SWS)
last acknowledgment received (LAR)
last frame sent (LFS)
Vedlikeholder invariant: LFS - LAR ≤ SWS
Rammer som venter
på å bli bekreftet
Rammer som er bekreftet
N
Rammer som ikke er sendt
N+1 N+2 N+3 N+4 N+5 N+6 N+7 N+8 N+9 N+10 N+11 N+12 N+13N+14
≤ SWS
LAR
SWS=8
LFS
Når ACK mottas, økes LAR, og derved kan ny ramme flyt stoppet
sendes slik at LFS økes.
Eliassen/Stein
Gjessing,
Ifi,
Buffer for opptil SWSFrank
rammer,
dvs SWS
rammer
i “røret” samtidig
UiO
46
Glidende vindu: mottaker
Vedlikeholder tre tilstandsvariable (fig 2.23 side 107 har feil navn)
receive window size (RWS)
largest acceptable frame (LAF)
last frame received (LFR) (with all smaller frames also received)
Vedlikeholder invariant: LAF - LFR ≤ RWS
Rammer som er mottat
N
Rammer som kan mottas
(muligens ute av orden)
N+1 N+2 N+3 N+4 N+5 N+6 N+7 N+8 N+9 N+10 N+11 N+12 N+13N+14
LFR
≤ RWS
LAF
UiO
47
Kumulativ kvittering (“go back n” protokoll), dvs. vi ack-er ikke nye
pakker hvis det er hull i sekvensen av mottatte pakker
if LFR < MottatRamme.SeqNum < LAF then
ta-imot-pakken-og-legg-den-på-plass;
beregn-nye-grenser (MottatRamme.SeqNum);
else
kast pakken;
send ACK (LFR + 1)
Rammer som er mottat
N
// se neste lysark
Rammer som kan mottas
(muligens ute av orden)
N+1 N+2 N+3 N+4 N+5 N+6 N+7 N+8 N+9 N+10 N+11 N+12 N+13N+14
LFR
≤ RWS
Frank Eliassen/Stein Gjessing, Ifi,LAF
UiO
48
16
Invariant: LFR + 1 er første pakke som ikke er mottatt
bergen-nye grenser(seqNo)
⌧if seqNo = LFR + 1
{
beregn ny LFR og LAF:
for (i= LFR + 1; ramme i er mottatt; i++) { } ;
LFR = i-1;
LAF = LFR + RWS;
}
første som ikke er mottatt
N+1 N+2 N+3 N+4 N+5 N+6 N+7 N+8 N+9 N+10 N+11 N+12 N+13N+14
N
LFR
Frank Eliassen/SteinSeqNum
Gjessing, Ifi,
UiO
LAF
49
Varianter til “go back n” protokoll
Negativ kvittering (NAK)
⌧mottaker sender NAK på rammer som savnes
Selektiv kvittering (SAK)
⌧mottaker sender ACK på nøyaktig de rammer som mottas
⌧disse behøver da ikke re-sendes
Både SAK og NAK øker kompleksiteten til implementasjonen,
men kan potensielt bedre utnyttelsen av linjen
UiO
50
Glidende vindu:
endelige sekvensnummer
I praksis representeres sekvensnummer med et endelig antall biter.
n biters sekvensnummer => intervall sekv. nr. = (0..2n-1)
I HDLC: n = 3, dvs. sekvensnummerintervall (0..7)
⇒ sekvensnummer må gjenbrukes
0
1
2
3
4
5
6
7
0
1
2
3
4
5
6
Problem
skille mellom ulike inkarnasjoner av samme numre
Minimum krav:
sekvensnummerintervallet må være større enn maks. antall utestående
rammer
UiO
51
17
Glidende vindu:
SWS ≤ MaxSeqNum+1 er ikke tilstrekkelig
anta 3 biters SeqNum felt (0..7)
SWS=RWS=8
senderen transmitterer rammene 0..6
mottas uten feil, men ACK går tapt
senderens tidsfrist utløper, rammene 0..6 sendes på nytt
mottaker forventer 7,0..5, men mottar andre inkarnasjon av
0..5
SWS,RWS ≤ (MaxSeqNum+1)/2 er riktig regel
0
7
1
6
2
5
UiO
3
4
Hindrer overlapp mellom
nedre kant av sendervinduet og
øvre kant av mottakervinduet.
52
Glidende vindu:
Eksempel: SWS, RWS = 4
NFE
7
LAR
0
7
6
1
5
2
send ra
mmer
0.
3
4
1
2
5
3
7
0
send
4
3
er 0..
3
NFE
3
LFS
2
5
ramm
LFA
1
6
0
6
2
4
LFA
4
ACK
LFS
4
1
5
.3
LAR
7
0
6
Hva bør mottaker nå gjøre?
UiO
53
Samtidige logiske kanaler
Multiplekser flere logiske kanaler over en punkt-til-punkt
link; kjører stop-and-wait på hver logiske kanal
Vedlikeholder tre biter tilstand for hver kanal :
boolsk variabel som angir om kanalen er opptatt
sekvens nummer for rammer som sendes på denne logiske
kanalen
neste sekvens nummer som forventes på denne logiske kanalen
ARPANET understøtter åtte logiske kanaler over hver
jord link (16 over hver satellitt link)
UiO
54
18
Linklaget - flytkontroll
UiO
55
Glidende vindu og flytkontroll
Flytkontroll
hindrer en sender i å oversvømme en mottaker med rammer
Glidende-vindu-protokoll oppfyller tre formål
pålitelig overføring
bevarer ordningen av rammene ved overføring (?)
⌧mer relevant for høyere lags protokoller en link-protokoller
understøtter flytkontroll
UiO
56
Flytkontroll
Normalt en feed-back (tilbakemelding) protokoll der
mottaker informerer senderen om sin buffer-kapasitet
Gjerne realisert som et tillegg til glidende vindu
To vanlige tilnærminger:
1. sender stopper når spesiell NAK mottas
2. mottaker informerer senderen om hvor mange pakker/bytes den
har plass til, og sender ikke mer data enn oppgitt inntil den får
ny beskjed (kredittbasert flytkontroll)
UiO
57
19
Flytkontroll - NAK
Tilnærming 1: Eksplisitt NAK (Not acknowledge)
I SCI sender mottaker en ACK eller en NAK for hver eneste pakke
NAK: Kan ikke ta imot mer
Full inn-buffer
UiO
58
Flytkontroll - Kreditt-basert
Tilnærming 2: Kreditter (jeg har til gode hos deg)
Hetrogenous InterConnect (HIC) bruker dette
Jeg har plass til 4 pakker
Sender
Mottaker
Meldingen om at mottakeren har plass til mer kan sendes
som en egen melding eller bakes inn i (“piggybacked” på)
annen melding i motsatt retning.
Mer om flykontroll seinere (ifb. nettverks- og transportprotokoller)
UiO
59
Oppsummering
Pålitelig overføring av rammer krever metoder for
1. Feildeteksjon
2. Feilkorrigering
Metoder for feil-deteksjon
Cyclic Redundency Check (CRC)
Paritet - to-dimensjonal paritet
Sjekksum
Metoder for feilkorrigering
Forward-error-correction (benyttes relativt lite i datanett)
Retransmisjon (stop-and-wait, glidende vindu)
Flykontroll hindrer en sender i å oversvømme en mottaker
glidende vindu basert
feed-back (NAK) eller
kreditt-basert
(credit-message)
Frank
Eliassen/Stein Gjessing,
Ifi,
UiO
60
20

Linklaget

Transcription

Similar documents

INSPIRASJON

Stokhøjvej - Thyholm Lokalarkiv

utstilling rorak

Hus & Hytte - Uke 37

r~r~r~r

klubb.bridge.no - brukermanual.pdf

hva skal til for å forbli aktiv?

Lager barnefestival i Bossekop

Praktisk bruk av RAM og produksjonstilgjengelighet - ITS

ITF20205 Datakommunikasjon - høsten 2014 - Computer

Last ned programmet

Forelesning 3

Introduktion till älvdalska