Transportni sloj Transportni sloj Osnovni zadatak transportnog sloja

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 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 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ča pređe na 0, svi paketi sa brojem 0 su davno nestali sa mreže

Vreme i redni brojevi paketa a) Prebrzo slanje paketa posle otkaza b) 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: S 1 kada je poslao TPDU i čeka potvrdu, ili S 0 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 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čnica 1, utičnica 2) • 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 – 64 KB, tako i sa Maximum Transmission Unit – MTU za datu mrežu kroz koju prolazi (1500 B 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 1. Nedovoljan kapacitet mreže 2. 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 – Re. Transmission 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+4 x. D • 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