Transportni sloj

Transportni sloj Osnovni zadatak transportnog sloja je obezbeđivanje pouzdanog prenosa podataka za sloj aplikacija, bez obzira na fizičke mreže kroz koje se vrši prenos Hardver i softver transportnog sloja se nazivaju transportna jedinica – transport entity Analogno postojanju dve vrste usluga mrežnog sloja, sa i bez uspostavljanja direktne veze, postoje i dve vrste usluga prenosa Transportni sloj i slojevi iznad se izvršavaju samo na krajnjim računarima a ne i na usputnim čvorovima kao slojevi ispod

Odnos transportnog sloja i susednih slojeva

Usluga transportnog sloja Transportni sloj odvaja sloj aplikacije od sloja mreže koji može da bude promenljiv Programeri aplikacija ne moraju da vode računa o mrežama kroz koje podaci prolaze i da se bave pouzdanošću prenosa, to rešavaju protokoli transportnog sloja Transportni sloj ne bi bio potreban kada bi sve mreže radile bez greške, imale iste usluge i kada se ne bi menjale Pošto realne mreže nisu idealne, postojanje transportnog sloj ima smisla

Osnovne operacije u uslugama prenosa Operacije usluge prenosa su interfejs ka usluzi prenosa Interfejs – operacije usluge prenosa omogućavaju uspostavljanje veze, komunikaciju i raskidanje veze

Ugneždeni paketi slojeva TPDU – Transport Protocol Data Unit Server šalje poruku – paket CONNECTION ACCEPTED kojom se uspostavlja veza Komunikacija se vrši operacijama SEND i RECEIVE Operacija RECEIVE blokira primaoca dok se ne prime podaci

Tok veze Transportni sloj vrši potvrdu prijema paketa i eventualno ponovno slanje paketa kada tajmer istekne To se skriveno od korisnika – programera aplikacije koji vide samo pouzdani prenosni kanal koji prenosi bitove koji se razmenjuju Prekid veze se vrši zbog oslobađanja prostora - resursa koji svaka veza rezerviše u transportnim jedinicama Asimetričan prekid operacijom DISCONNECT prekida obe veze, dok simetričan prekid prekida svaki smer veze posebno

Dijagram stanja veze Na dijagramu su prikazana stanja koja se menjaju prelazima, a svaki prelaz je uzrokovan događajem Pri uspostavljanju i prekidanju veze posmatraju se odvojeno stanja servera i klijenta Klijent inicira komunikaciju Događaji su zahtev za uspostavljanjem veze – CONNECT i zahtev za prekid veze - DISCONNECT

Berkli utičnice – TCP sockets Programski inerface za korišćenje komunikacije preko TCP protokola transportnog sloja Implementirane su u raznim OS - UNIX, Linux, Windows preko programskih biblioteka U tabeli su navedene osnovne operacije

Primer TCP sockets za server datoteka Server se prvo inicijalizuje – kreira utičnicu i povezuje IP adresu sa tom utičnicom Poziva se procedura LISTEN – spremnost za uspostavljanje veze sa klijentom Ako se premaši zadat broj konekcija, višak se automatski odbija Server ulazi u petlju u kojoj poziva proceduru ACCEPT Po prihvatanju zahteva klijenta dobija se deskriptor za čitanje i upis sa utičnice - sa, analogno čitanju i upisu u file Na osnovu deskriptora, server čita ime tražene datoteke Sadržaj datoteke šalje klijentu preko iste utičnice Zatvara se datoteka i prekida veza

Serverski kod

Klijentski kod Klijentski kod se poziva se na pr. Client physics.kg.ac.rs/usr/mreze.doc > mreze Client je ime programa a u nastavku su argumenti Proverava se da li ima dovoljno argumenata Slovna IP adresa se pretvara u numeričku Kreira se i inicijalizuje utičnica Procedurom connect se šalje zahtev za vezu Ako se veza uspostavi – server prihvati, klijent šalje ime datoteke write Klijent potom ulazi u petlju u kojoj učitava traženu datoteku blok po blok i upisuje je u file Po završetku učitavanja klijentski program se završava

Klijentski kod

Elementi transportnih protokola Veza između usmerivača u mrežnom sloju i hostova u transportnom sloju – sličnosti i razlike TSAP – Transport Service Access Point – pristupna tačka usluge prenosa – port – priključak NSAP – Network Service Access Point – pristupna tačka mrežne usluge – IP adresa

Server imena – name ili directory server Nove usluge se registruju na serveru imena Server imena prevodi naziv servisa u TSAP adresu Način da se omogući pozivanje novih ili nestandardnih – custom servisa čiji TSAP-ovi nisu opšte poznati ili standardni Da bi se dobila adresa nove ili nepoznate usluge, mora biti poznata adresa servera imena Analogno, morate znati broj 988 da bi preko njega dobili druge brojeve

Server procesa za inicijalno povezivanje

Uspostavljanje veze Problematika uspostavljanja veze u uslovima zagušenja – zakasneli duplikati Jednokratne transportne adrese – adresa se generiše kada je potrebna i posle se ne koristi Svakoj vezi se pridružuje identifikator veze koji se uvećava za 1 sa svakom novom vezom, pa se prema vrednosti identifikatora u paketu zna da li je paket iz prethodne veze ili iz aktuelne. Brisanje memorije transportne jedinice iz nekog razloga, onemogućava dalju primenu Koristi se životni vek paketa – implementacija preko mreže bez petlji, brojača skokova u paketu i odbacivanje kada dođe na 0, vremensko označavanje paketa

Uspostavljanje veze, Tomlinson 1975 Računari imaju sat realnog vremena, sinhronizovani satovi – brojači, broj bitova >= broj bitova rednog broja paketa. Satovi rade I kada računar otkaže Dve TPDU poruke sa istim brojem, nikada na mreži u isto vreme Kada se veza uspostavi, za početni redni broj prvog paketa se koristi trenutna vrednost brojača sata realnog vremena Kada se sa najvećeg broja brojača pređe na 0, svi paketi sa brojem 0 su davno nestali sa mreže

Vreme i redni brojevi paketa Prebrzo slanje paketa posle otkaza Presporo slanje posle otkaza Dovode do preklapanja rednih brojeva Optimalna brzina slanja paket po otkucaju sata

Izbegavanje slanja duplikata paketa Pre svakog slanja paketa, transportna jedinica treba da proveri na osnovu tekućeg vremena i rednog broja paketa, da li se nalazi u zabranjenoj oblasti, tj. da li dolazi do preklapanja paketa Ako bi se našao u zabranjenoj oblasti sa aspekta korišćenih rednih brojeva paketa i vremena, onda ili čekati vreme T da stari paketi nestanu sa mreže, ili se ponovo sinhronizovati u pogledu izbora rednih brojeva paketa Trenutna vrednost brojača sata služi kao početna vrednost broja paketa pri novoj sinhronizaciji

Problem uspostavljanja veze Upravljački TPDU paketi kojima se uspostavlja veza, takođe mogu da kasne Host 1 šalje hostu 2 TPDU paket CONNECTION REQUEST sa predloženim početnim brojem paketa i brojem priključka Host 2 odgovara sa TPDU paketom CONNECTION ACCEPTED Ako se paket CONNECTION REQUEST izgubi, i primi se njegov zakasneli duplikat, veza će se uspostaviti neispravno Zato se koristi Three way handshake – Trostepeno usaglašavanje

Raskidanje veze Simetrično i asimetrično raskidanje veze Asimetrično raskidanje veze – mogući gubici podataka

Druga varijanta raskidanja veze – simetrično raskidanje veze Simetrično raskidanje veze prekida posebno svaki smer komunikacije dva hosta Problem sa simetričnim raskidom veze ilustruje problem dve vojske – two army problem

Peti nepovoljni scenario – slučaj raskidanja veze Ako se izgubi i prvi DR TCDU paket, kao pod d) na prethodnoj slici, i ne uspe ni jedan od ponovljenih pokušaja raskida veze, pošiljalac – host 1 na kraju prekida vezu, a host 2 ništa ne zna o tome i nastavlja da šalje – poluuspostavljena veza Prekid veze posle perioda neaktivnosti – nema paketa od druge strane Teoretski, raskid veze bez gubljenja podataka nije trivijalan!

Kontrola toka i privremeno skladištenje Sličnost kontrole toka u sloju veze podataka i u transportnom sloju preko kliznih prozora, da brz pošiljalac ne zatrpa sporog primaoca paketima Razlika je u tome što usmerivač obično ima manje linija, dok računar može da ima puno veza, zbog čega se primenjuje druga strategija privremenog skladištenja za transportni sloj U nepouzdanoj mreži, pošiljalac mora da privremeno uskladišti TPDU poruke koje šalje, zbog eventualne potrebe da ih šalje ponovo Problem izbora veličine bafera u zavisnosti od veličine TPDU poruka – poruke iste dužine, poruke različitih dužina,

Različite organizacije bafera

Problem bafera Problem izbora bafera zavisi i od saobraćaja na mreži Za povremen, mali saobraćaj za datu vezu mogu da se koriste dinamički baferi – po potrebi Za intenzivan saobraćaj sa prenosom datoteka, potrebno je da se svakoj vezi dodeli poseban bafer Pošiljalac treba da ima mogućnost da može da zahteva adekvatne bafere na prijemnoj strani Baferi se mogu dodeljivati po pojedinačnoj vezi, ili zbirno za sve veze između dva računara

Dinamičko dodeljivanje bafera Dodeljivanje bafera je dinamičko zbog stalne promene uslova – uspostavljanje i prekidanje veza, kao i promena intenziteta saobraćaja Pošiljalac zahteva bafere, a primalac šalje potvrdu o rezervisanim baferima posebnim porukama, a ne šlepovanim uz povratne okvire Pošto se upravljačke TPDU poruke – o baferima ne memorišu, zbog mogućeg gubljenja, treba da se periodično emituju – šalju Ako bafera ima uvek dovoljno, ograničenje može biti prenosni kapacitet mreže

Prikaz komunikacije sa baferima

Multipleksiranje Korišćenje samo jedne mrežne adrese za više različitih transportnih veza – uzlazno - upward multiplexing i obrnuto, slanje većeg saobraćaja preko više IP adresa – downward multiplexing

Oporavak posle pada sistema Mogućnost otkaza mrežnog sloja ili računara Otkaz usmerivača kod datagram-ske veze nije problem Kada otkaže usmerivač sa direktnom vezom, uspostavlja se nova veza i utvrđuje se koji su paketi primljeni a koji ne i ponovo se šalju Složenija je situacija kada otkaže računar – server Klijent može da bude u jednom od dva stanja: S1 kada je poslao TPDU i čeka potvrdu, ili S0 ne čeka potvrdu

Oporavak posle pada sistema 2 Server ne vrši u istom trenutku upis primljenog paketa i slanje potvrde. Problem je ako se desi otkaz servera između ova dva događaja Različite varijante strategija servera i klijenta i moguće kombinacije i scenariji Problem oporavka nije trivijalan

Jednostavan primer transportnog protokola – osnovne operacije connum = CONNECT(local TSAP, remote TSAP) – pozivalac blokiran u toku uspostavljanja veze, konačno vreme connum = LISTEN(pristupna TSAP) – primalac blokiran dok neko ne uspostavi vezu status = DISCONNECT(connum) – simetrično raskidanje veze status = SEND(connum, buffer, bytes) – slanje podataka – sadržaja bafera Status = RECEIVE(connum) – prijem podataka sa zadatog broja konekcije

Pretpostavke za mrežni sloj Radi jednostavnosti, pretpostavlja se da mrežni sloj radi sa direktnom pouzdanom vezom Time se postiže da se razmatra problematika karakteristična za transportni sloj – uspostavljanje i raskidanje veze, kao i rad sa kreditima Transportna jedinica može biti deo OS ili deo biblioteke potprograma u ovom slučaju Interfejs ka mrežnom sloju – procedure to_net i from_net

Paketi mrežnog sloja koje koriste procedure to_net i from_net

Stanja transportne jedinice IDLE – nije uspostavljena veza WAITING – izvršeno CONNECT i poslat paket CALL_REQUEST QUEUED – stigao CALL_REQUEST, nije izvršeno LISTEN ESTABLISHED – veza uspostavljena SENDING – čeka se dozvola za slanje paketa RECEIVING – izvršeno RECEIVE DISCONNECTING – izvršen lokalni DISCONNECT

Prelasci iz stanja u stanje Događaji izazivaju prelazak iz stanja u stanje Izvršavanje osnovne operacije Stizanje paketa Isticanje tajmera Sve procedure iz listinga se mogu pozvati iz korisničkog programa osim procedura clock i packet_arrival koje pokreću spoljašnji događaji – stizanje paketa i rad sata. Te dve procedure su prekidne – služe za obradu prekida – interrupt-a

Opis protokola Procedure to_net i from_net predstavljaju interface između transportnog i mrežnog sloja Transportnom sloju su poznatri parametri koji se predaju procedurama to_net i from_net, ali to je sve Ako je bafer / prozor mrežnog sloja popunjen, mrežni sloj blokira proceduru to_net dok se ne oslobodi – to je transparentno za transportni sloj Mrežni sloj takođe podešava veličinu prozora - bafera

Opis protokola (2) Procedurama to_net i from_net se predaje 6 parametara Cin – identifikator veze koji se preslikava na virtuelni kolo – u saglasnosti sa pretpostavkama – direktna pouzdana veza Q bit 1 označava upravljačku poruku – CREDIT za podešavanje prozora, 0 nije upravljačka, već podaci M bit 1 sledi još delova iste poruke, 0 nema više Oznaka tipa paketa koji mrežni sloj treba da pošalje, bira se na osnovu osnovne operacije koja se izvodi Pokazivač na podatke koji se šalju Broj bajtova poruke Transportni sloj samo navodi tipove paketa, dok ih mrežni sloj razmenjuje – predaje / prima, i obavlja sve poslove u vezi toga

Opis protokola (3) Glavna strukura podataka je niz conn čiji su elementi istoimena struktura conn – po jedan element niza – zapis za svaku vezu Stanje svakog elementa niza se inicijalizuje sa IDLE Kada se pozove procedura CONNECT, nalaže se mrežnom sloju da pošalje paket CALL_REQUEST i potom se poziva sleep() Kada paket CALL_REQUEST stigne, sa packet_arrival() – interrupt, se proverava da li se osluškuje data adresa Ako se osluškuje, vraća se paket CALL_ACCEPTED, posle čega se server budi Ako se ne osluškuje CALL_REQUEST se smešta u red čekanja i aktivira se timer sa TIMEOUT Ako se u toku TIMEOUT pozove LISTEN, uspostavlja se veza, ako ne paket se odbacuje i šalje se CLEAR_REQUEST da bi se pozivalac odblokirao

Opis protokola (4) Pošto se može uspostaviti više transportnih veza, jedan od načina za obeležavanje veze je da se oznaka – broj virtuelnog kola iz mrežnog sloja upotrebi kao broj transportne veze, tj. Kao indeks za niz conn. Paket koji stigne virtuelnim kolom k, pripada onda transportnoj vezi conn[k] Poziv procedure RECEIVE šalje transportnoj jedinici pošiljaoca kreditnu poruku Procedura SEND pošiljaoca proverava da li je stigao kredit preko zadate veze – na koju se šalju podaci Ako jeste stigao, poruka se šalje u određenom broju paketa Ako nije stigao, čeka se da stigne SEND ništa ne šalje bez prehodnog RECEIVE sa suprotne strane

Transportni protokol kao mašina konačnih stanja Pošto je transportni protokol i u pojednostavljenoj varijanti složen, korisno je da se predstavi mašinom konačnih stanja radi lakšeg pregleda, opisa, uvida, dokumentacije Postoji ukupno 7 mogućih stanja po svakoj vezi Ukupno 12 događaja koji dovode do prebacivanja veze iz jednog stanja u drugo 5 su osnovne operacije usluga Pristizanje 6 vrsta paketa od mrežnog sloja Isticanje roka timer-a

Diskusija stanja Laka sistematska provera svake kombinacije stanja Nema razlike između nemogućih i nedozvoljenih stanja, ni jedna ni druga nisu pokazana U prethodnoj tabeli ne postoji stanje LISTENING, zato što se to stanje ne beleži u conn nizu Zašto? Jer nema uspostavljene virtuelne veze čija oznaka predstavlja indeks niz conn Oznaka virtuelne veze je poznata tek po uspostavljanju veze, kada stanje više nije LISTENING

Transportni protokoli za Internet UDP i TCP Dva glavna protokola Interneta u transportnom sloju UDP – User Datagram Protocol – bez uspostavljanja direktne veze TCP – Transport Control Protocol – sa uspostavljanjem direktne veze

UDP protokol Protokol UDP šalje kapsulirane IP datagrame bez prethodnog uspostavljanja veze Zaglavlje UDP paketa 8 byte-ova UDP length je ukupna dužina – zaglavlje + podaci UDP kontrolna suma nije obavezna, 0 ukoliko je to izostavljeno UDP ne upravlja tokom, ne kontroliše greške i ne šalje ponovo pakete sa greškom Interfejs ka IP protokolu, demultipleksira procese koji koriste isti priključak – port Sve ostalo se prepušta aplikaciji koja koristi ovaj protokol

Primena UDP Kratka komunikacija tipa klijent server Ako se paket izgubi, šalje se ponovo, kada istekne timer DNS koristi UDP – zahtev za IP adresom koja odgovara slovnoj adresi, a odgovor je samo ta adresa Daljinsko pozivanje procedure – RPC (Remote Procedure Call) kada proces na jednom računaru – klijent, poziva proces – program na drugom računaru – server, preko mreže Transparentno za programere, analogno pozivu lokalne procedure Client stub – klijentska vezivna procedura koja predstavlja serversku - udaljenu proceduru u adresnom prostoru klijenta Server stub – serverska vezivna procedura koja predstavlja klijentsku - udaljenu proceduru u adresnom prostoru servera Vezivne procedure imitiraju lokalne pozive – skrivaju od pozivajućih procedura da se radi o pozivima preko mreže

RPC Neophodna su ograničenja koja se tiču prenosa parametara pri pozivu preko RPC

Protokol za prenos u realnom vremenu RTP – Real-time Transport Protocol RTP se nalazi između aplikacije koja generiše multimedijalni sadržaj i UDP protokola koji koristi Više različitih multimedijskih tokova se multipleksira u UDP pakete koji se emituju jednosmerno ili višesmerno RTP paketi se numerišu sekvencijalno da bi se na odredištu videlo da li su svi paketi stigli Ako paket nedostaje, ne šalje se ponovo, jer bi naverovatnije stigao prekasno za upotebu RTP ne upravlja tokom, ne kontroliše greške, ne potvrđuje pakete, nešalje pakete ponovo Mogućnost sinhronizovanja različitih tokova digitalna TV slika sa audio tokovima – stereo ili prevod

Položaj RTP protokola i paketa

TCP protokol Obezbeđuje pouzdan tok podataka s kraja na kraj veze kroz nepouzdanu kombinovanu mrežu za aplikacije kojima to treba Kombinovane mreže između krajeva veze mogu da se veoma razlikuju u pogledu topologije, propusnog opsega, kašnjenja, veličine paketa Od nastanka, TCP se menjao, u smislu otklanjanja uočenih grešaka, nedoslednosti ali i prilagođavanje novim zahtevima TCP garantuje prenos i isporuku podataka – na osnovu svojih timer-a se vrši ponovno slanje paketa Paketi se i uređuju u potreban redosled

Model TCP usluge TCP usluga se koristi preko utičnica – krajnjih tačaka veze Utičnica ima oznaku IP adrese i port-a 2 byte-a Više veza može da koristi istu utičnicu Veze se razlikuju prema identifikatorima utičnica na oba kraja veze (utičnica1, utičnica2) Brojevi utičnica manji od 1024 su rezervisani za standardne usluge i nazivaju se opštepoznati priključci – well known ports Za te usluge se ne moraju navoditi oznake portova jer se podrazumevaju

Opštepoznati – well known ports

TCP veze TCP veze su dupleksne – saobraćaj istovremeno u oba smera Od tačke do tačke –znači da svaka veza ima samo dve tačke TCP ne podržava višesmerno i difuzno – broadcast emitovanje TCP prenosi byte-ove a ne poruke što znači da pakovanje u pakete kod pošiljaoca može da stigne kod primaoca drugačije upakovano

TCP protokol TCP jedinice razmenuju podatke u obliku segmenata TCP segment ima 20 byte-no zaglavlje, plus neobavezan deo i podatke kojih ne mora biti Veličinu TCP segmenta određuje TCP software i ne mora da bude ista kod pošiljaoca i primaoca Max veličina segmenta je ograničena kako IP paketom – 64KB, tako i sa Maximum Transmission Unit – MTU za datu mrežu kroz koju prolazi (1500B za Ethernet) Svaki byte unutar TCP toka – veze, ima svoj redni broj TCP jedinice koriste protokol kliznih prozora, slanjem segmenta se aktivira timer Pošto segmenti mogu da budu različiti, proverava se koji su byte-ovi stigli

Zaglavlje TCP segmenta

Uspostavljanje TCP veze

Raskidanje TCP veze Dupleksna TCP veza kao dve paralelne jednosmerne veze Svaka jednosmerna veza se raskida nezavisno od one druge veze Slanjem i potvrdom segmenta sa FIN bitom se zatvara dati smer veze, pri čemu podaci mogu da idu onim drugim smerom Veza se potpuno raskida kada se zatvore oba njena smera Treba poslati četiri segmenta – 2 x FIN i ACK Može i tri ako se kombinuju prvi ACK i drugi FIN Problem dve vojske se rešava timer-ima

Modelovanje rada sa TCP vezom

Pravila TCP prenosa

Silly window syndrome

TCP kontrola zagušenja TCP je veoma važan u borbi – kontroli zagušenja Pravo rešenje zagušenja je smanjenje brzine emitovanja podataka Ne treba slati novi paket dok prethodni ne bude isporučen Otkrivanje zagušenja se vrši detektovanjem isticanja timer-a Danas se sa visoko pouzdanim optičkim mrežama paketi gube prvenstveno zbog zagušenja TCP algoritmi prepostavljaju da se timer-i isključuju prvenstveno zbog zagušenja

Analogno predstavljanje zagušenja

Problem zagušenja Dva su osnovna problema u vezi zagušenja Nedovoljan kapacitet mreže Nedovoljan kapacitet primaoca Za rešenje se koriste dva prozora koje održava pošiljalac i to prozor koji odobri primalac i tzv. prozor zagušenja – congestion window Pošiljalac – TCP jedinica pošiljaoca stavrno šalje segment veličine koji odgovara manjem od ta dva prozora

Prozor zagušenja Prozor zagušenja se od početne veličine jednake najvećem segmentu na mreži, po određenom algoritmu – eksponencijalno uvećava, dok se ne desi gubljenje paketa Onda se za prozor zagušenja uzima prethodna veličina pri kojoj nije dolazilo do gubljenja paketa Ako se pre gubljenja paketa dostigne veličina prozora primaoca, ostaje se na toj veličini prozora zagušenja Prethodni postupak se naziva spori algoritam

Algoritam za kontrolu zagušenja Osim dva prozora, koristi se i treći parametar, prag – treshold koji se inicijalizuje na 64 KB – najveća veličina IP paketa Kada se isključi timer, prag se smanjuje na polovinu tekuće veličine prozora zagušenja, a prozor zagušenja se podešava na vrednost jednog segmenta. Posle toga se ponovo sporim algoritmom utvrđuje max propusna moć mreže Pri tome se eksponencijalno povećanje veličine prozora prekida posle prelaženja veličine praga i nastavlja se sa linearnim povećanjem veličine prozora Algoritam pretpostavlja da se sa smanjenjem veličine prozora na polovinu i postepenim daljem povećavanjem rešava problem zagušenja

Grafički prikaz algoritma

Upravljanje timer-ima TCP koristi više timer-a Najvažniji je RTT – ReTransmission Timer – timer za ponovno slanje segmenta Po isključivanju tog timer-a koji odbrojava unazad do 0, ponovo se šalje segment Timer se isključuje ukoliko prethodno ne stigne potvrda Koju vrednost dodeliti timer-u? Taj zadatak je složeniji nego u sloju podataka gde je uska raspodela verovatnoće vremena pristizanja potvrda

Raspodela verovatnoće vremena pristizanja

Algoritam za dinamičko podešavanje timer-a Za svaku vezu TCP jedinica održava promenljivu RTT – najbolja tekuća procena vremena obilaska veze Ako potvrda stigne pre isključivanja timer-a meri se kašnjenje M Na osnovu M se koriguje vrednost RTT RTT=αRTT+(1-α)M α je koeficijent izglađivanja = 7/8 najčešće Jedna mogućnost je da se za timer odabere vrednost βRTT, gde je β=2, ali je bolje da se dinamički određuje Timer=RTT+4xD D=αD+(1-α)|RTT-M|

Dinamički timer (2) Ako segment zakasni i timer se isključi, onda se ne vrši ažuriranje RTT, jer se ne može izmeriti M, pa se vreme timer-a udvostručava, dok se ne dobije potvrda Timer za ograničenje čekanja – persistence timer Timer za proveru stanja veze keepalive timer – kada nema komunikacije, prekida se veza Timed wait jednak dvostrukom max životu na mreži – primenjuje se kod raskidanja veze da bi svi paketi “izumrli” pre raskidanja veze

Bežični TCP i UDP protokoli TCP i UDP ne bi trebalo da zavise od mreže Ali... Ako se ne uzmu u obzir specifičnosti mreže, rezultat su očajne – loše performanse Problem je algoritam za kontrolu zagušenja U bežičnim mrežama gubljenje paketa nije indikacija zagušenja Izgubljeni paket treba poslati što pre – sasvim suprotno nego kod kablovskih mreža Kako prepoznati mrežu, kada paket može da putuje kroz razne mreže – kroz kablovske i bežične

Deljenje TCP veze na dve Narušavanje semantike TCP-a. Bazna stanica potvrđuje pakete, ali to ne znači da ih je dobio primalac, već bazna stanica Potrebno je bolje rešenje – sa agentom za osmatranje – snooping agent koji ponovo šalje segmente, ne obaveštavajući izvorišni računar Kod UDP protokola takođe dolazi do problema, jer se naglo pogoršavaju performanse u bežičnim mrežama