2_Kapitulli 2.pdf

7/27/2019 2_Kapitulli 2.pdf

http://slidepdf.com/reader/full/2kapitulli-2pdf 1/86

KAPITULLI 2-Shtresa e aplikacionit

Faqe 1

KAPITULLI 2

Shtresa e aplikacionit

Aplikacionet në rrjeta janë arsyeja e ekzistimit të rrjetave kompjuterike — nëse ne nuk mund tëmendojmë për ndonjë aplikacion të nevojshëm, nuk do të kishim arsye pse të projektojmë

protokollet e rrjetave që të mbështesin ato. Në 40 vitet e fundit, shumë aplikacione të

mrekullueshme janë krijuar. Këtu bëjnë pjesë aplikacionet klasike për shkrimin e teksteve që u

bënë të famshme në vitet 70’ dhe 80’: e-mail me tekst, çasja nga largësia e kompjuterëve,

transferimi i dokumenteve, grupet e lajmeve dhe bisedat ne Chat. Këtu bënë pjesë edhe

aplikacioni shkatërrues i viteve të 90’: the World Wide Web, duke përfshirë shfletimin në Web,

kërkimi dhe marketingu elektronik. Gjithashtu bëjnë pjesë dhe 2 aplikacionet marramendëse të

paraqitura në fundit të mijëvjeçarit të kaluar — komunikimi instant me listë të shokëve, dhe P2P

shpërndarja e dokumenteve. Këtu përfshihen dhe shumë aplikacione të suksesshme të video dhe

audio`, telefoni me internet, shpërndarja dhe marrja e video dokumenteve, radio në internet, dhetelevizioni me IP (IPTV). Për më tepër, rritja e gjithanshme e çasjes në internet pa kabllo

(wireless) janë duke përgatitur skenën për shumë aplikacione të reja në të ardhmen.

Në këtë kapitull studiojmë aspektin konceptual dhe atë të implementimit të aplikacioneve në

rrjeta. Fillojmë duke definuar konceptet kryesore të shtresës së aplikacionit, duke përfshirë

shërbimet e rrjetave që kërkohen nga aplikacionet, klientët dhe serverët, proceset, dhe

ndërlidhjet e shtresës së transportit. Ne do të testojmë disa aplikacione të rrjetave në detaje, duke

përfshirë këtu Web-in, e-mail, DNS, P2P (peer-to-peer) shpërndarja e dokumenteve, dhe P2P

telefonimi me internet. Pastaj do të përfshijmë dhe zhvillimin e aplikacioneve të rrjetave në TCP

dhe UDP. Në veçanti, do të studiojmë soketat e API dhe do të shohim disa aplikacione të

thjeshta të klient-serverit në Java. Në gjithashtu kemi përmbledhur disa detyra interesante për studentë me programim të soketave në fund të kapitullit.

Shtresa e aplikacionit është veçanërisht një vend i mirë që të fillojmë të mësojmë

protokollet,është rreth i njohur për ne. Ne jemi përballur me shumë nga aplikacionet që

mbështeten në protokollet që do ti studiojmë. Do ta kuptoni shumë më mire se për çka janë

protokollet dhe do të njoftohemi me shumë çështje që do ti shohim prapë kur të arrijmë te

protokollet e shtresave të transportit, rrjetave dhe linçeve.

2.1 Principet e Aplikacioneve të Rrjetave

Supozojmë se keni një ide për një aplikacion të ri të rrjetave. Ndoshta ky aplikacion do të jetë

një shërbim i madh për njerëzimin, apo do të kënaq profesorin tuaj, apo do të të bëjë të pasur,apo thjesht do të jetë kënaqësi që ta zhvillosh. Pa marrë parasysh motivimin, le të shikojmë se si

mund ta ktheni një ide në një aplikacion të vërtetë të rrjetave.Zhvillimi i aplikacioneve të

rrjetave kryesisht përqendrohet që të shkruaj programe që mund të përdoren në sisteme të

ndryshme dhe që të mund të komunikojnë me njëra tjetrën përmes rrjetave. Marrim shembull

Web aplikacionet, aty janë dy programe të ndryshme që komunikojnë me njëra tjetrën: programi

i shfletuesit që punon tek përdoruesi ( në kompjuter, laptop, PDA, telefon mobil etj.), dhe

programi i Web serverit që punon te hosti i Web serverit. Shembull tjetër, në P2P sistemet është



2.1 Principet e aplikacioneve të rrjetës

Faqe 2

një program në secilin host që merr pjesë në komunitetin e shpërndarjes se dokumenteve. Në

këtë rast, programet në host-a të ndryshëm mund të kenë programe të ngjashme ose

identike.Mirëpo, gjatë zhvillimit të aplikacionit të ri, ju duhet të shkruani një program që mund

të punoj në lloje të shumta sistemesh. Ky program mund të shkruhet psh në gjuhën C, Java apo

Python.

Mbani mend që nuk ju duhet të shkruani programe për pajisje të rrjetave si psh. router aposwitch. Edhe nëse duhet të shkruash programe për këto pajisje, ju nuk mund ta bëni atë. Siç

mësuam në kapitullin e parë, dhe siç mund të shihni në fig 1.24, pajisjet e rrjetave nuk hyn në

punë në shtresën e aplikacionit, por më poshtë, më specifikisht te shtresa e rrjetit dhe më poshtë.

Ky dizajn ,i cili i lidh programet e aplikacioneve me sistemet që i përdorin (siç shihet në fig.

2.1), e ka bërë më të lehtë zhvillimin e shpejtë dhe shpërndarjen të një grupi të gjerë

aplikacionesh të rrjetit.

2.1.1 Arkitektura e Aplikacioneve të Rrjetave

Para se të hyjmë në shkrimin e kodit të programit, ju duhet të keni një plan te gjerë arkitektural

për aplikacionin tuaj. Mbani në mend se arkitektura e një aplikacioni dallon shumë nga ai iarkitekturës së rrjetave (psh. Arkitektura prej pesë shtresave e Internetit që diskutuam në

Kapitullin 1).Nga perspektiva e zhvilluesit të aplikacionit, arkitektura e rrjetave e caktuar dhe na

siguron një grup specifik shërbimesh për aplikacione.




Faqe 3

Figura 2.1 Komunikimi për aplikacione të rrjetës vendoset në mes të end system-it në

shtresën e aplikacionit.

Arkitektura e aplikacionit, në anën tjetër, bëhet nga zhvilluesi i tij dhe na dikton se sa

aplikacioni është i strukturuar nëpër llojet e ndryshme të sistemeve. Në përzgjedhjen e

arkitekturës së aplikacionit, një zhvillues i aplikacionit në të shumtën e rasteve do të vizatojënjërin nga dy modelet dominuese arkitekturale : arkitektura klient-server dhe arkitektura peer-to-

peer (P2P).Në arkitekturën klient-server, është një host që rri gjithë i ndezur që quhet server dhe

kryen shërbimet që i kërkon cilido host tjetër që quhet klient. Hosti i klientëve mund të qëndrojë

gjithë i ndezur por mund të jetë edhe i ndalur. Një shembull klasik është aplikacioni i Web-it,

tek i cili Web serveri është gjithë i ndezur që të pranojë kërkesa nga shfletuesit që përdorin

postat klient. Kur një Web server pranon një kërkesë për një objekt nga një host klient, i

përgjigjet duke ia dërguar objektin e kërkuar hostit klient. Vini re se në arkitekturën klient-




Faqe 4

server klientët nuk komunikojnë direkt me njëri tjetrin, psh në një Web aplikacion dy shfletues

nuk komunikojnë direkt me njëri tjetrin. Një karakteristikë tjetër e arkitekturës klient-server

është se serveri ka një adresë fikse që e dimë të gjithë, që quhet IP adresa (për të cilën do të

flasim pak më vonë). Pasi që serveri ka një adresë të njohur dhe fikse, dhe për shkak që është

gjithë i ndezur(ON), klienti mund të kontaktoj gjithë me serverin duke ia dërguar një paketë në

adresën e serverit. Disa aplikacione tjera të njohura me arkitekturë klient-server janë : Web,FTP, Telnet, dhe e-mail. Arkitektura klient server shihet në figurën 2.2(a).Shpesh në

arkitekturën klient-server, një host i vetëm server nuk mund të merret me të gjitha kërkesat e

klientëve. Shembull, një faqe e njohur në internet mund shpejtë të bllokohet nëse ka vetëm një

server që i kryen kërkesat e saj. Për këtë arsye, një grumbull i madh hostash - të cilës nganjëherë

i referohemi si qendër e të dhënave - përdoret shpesh për të krijuar një server virtual të

fuqishëm të arkitekturës klient-server. Shërbimet e aplikacioneve që bazohen në arkitekturën

klient-server janë shpesh infrastrukturë intenzive, ngaqë ua kërkojnë shërbyesve të ndryshëm

që të blejnë, instalojnë dhe mirëmbajnë ferma serveri.

Si pasojë e kësaj, këta shërbyes duhet të paguajnë dhe shfrytëzimin e Internetit për pranimin dhe

dërgimin e të dhënave në internet. Disa shërbyes të njohur si makinat kërkuese (Google),

marketingu në internet (Amazon, E-bay), shpërndarësit e videove (YouTube), e-mail i bazuar

në Web( Yahoo Mail) dhe rrjetet sociale (Facebook, MySpace) janë infrastruktura intenzive dhe

me kosto të lartë.

Në arkitekturën P2P, ka siguri minimale (ose s’ka fare) në serverët që janë gjithë të ndezur. Në

vend të kësaj, aplikacioni përdor një lidhje direkt ndërmjet palëve të postave që janë të lidhura

pandërprerë, që quhen peers(pal ë). Këto peers nuk janë pronë e asnjë shërbyesi, por e laptopave,

desktopave që i takojnë përdoruesve, shumë nga të cilat gjenden në shtëpi, universitete, dhe

zyra. Pasi që këto peers komunikojnë pa kaluar nëpër ndonjë server, arkitektura quhet peer-to-

peer.

Shumë nga aplikacionet më të njohura të kësaj kohe bazohen në arkitekturën P2P. Këtu

përshihen dhe aplikacionet për shpërndarje të dokumenteve (BitTorrent, LimeWire, eMule),

telefonia me internet (Skype) dhe IPTV (PPLive). Këtë arkitekturë e keni në figurën 2.2(b). Disa

aplikacione kanë arkitekturë të përzier (hibride), duke përzier elementet e që të dy arkitekturave.




Faqe 5

Figura 2.2 (a) Arkitektura klient-server ; (b) Arkitektura P2P

Shembull, shumë aplikacione të komunikimit instant, serverët përdoren për gjetur gjurmët e IP

adresave të klientëve, ndërsa klientët komunikojnë direkt me njëri tjetrin ( pa kaluar nëpër

serverë). Një nga vetitë më interesante të P2P arkitekturave është vetia e vetë-skalimit të tyre.

Shembull, në një aplikacion për shpërndarjen e dokumenteve, edhe pse secila peer shton sasi të

punës duke kërkuar dokumente, ato gjithashtu i rrisin kapacitetin e shërbimit sistemit, duke

shpërnda dokumente për peers të tjerë. Arkitektura P2P ka kosto më të ulët, për shkak se nuk

kërkon infrastrukturë reale të serverit, dhe nuk paguan as për internet. Në mënyrë që të ulen

çmimet e produkteve të tyre, disa shërbyes (si MSN, Yahoo dhe shumë të tjerë) janë shumë e më

shumë të interesuar të përdorin arkitekturën P2P për aplikacionet e tyre (Chuang 2007). Mirëpo,aplikacionet e të ardhmes me P2P do të ballafaqohen me tri probleme kryesore:

1. ISP Friendly. Shumë ISP shtëpiake(këtu përfshijmë DNS dhe ISP kabllor) janë

dizajnuar për përdorim “asimetrikë” të rrjetit, kjo sepse, më shumë përdoret shkarkimi

nga rrjeti se ngarkimi i të dhënave në rrjet. Por te shpërndarja e videove me P2P dhe

aplikacionet për shpërndarje të dokumenteve, ngarkimin e të dhënave në rrjet që duhet ta

bëjë një server, bëhet në ISP shtëpiake duke i bërë stres ISP-ve. Aplikacionet e ardhshme

me P2P duhet të dizajnohen ashtu që të jenë më të sjellshme ndaj ISP-ve (Xie 2008).

2. Siguria. Duke u nisur nga natyra e tyre tepër e hapur, P2P aplikacionet mund të jenë një

sfidë për siguri ( Doucer 2002, Yu 2006, Liang 2006, Naoumov 2006, Dhungel 2008).3. Simulimi. Suksesi i P2P aplikacioneve të së ardhmes gjithashtu varet edhe nga aftësia e

bindjes së përdoruesve që vullnetarisht të ndajnë nga pak hapësirë dhe rrjet për

aplikacionet, e cila është dhe sfida e dizajnëve simuluese [Feldman 2005, Piatek 2008,

Aperjis 2008].

2.1.2 Proceset e komunikimit




Faqe 6

Para se të ndërtojmë aplikacionin tonë për rrjet, gjithashtu ju nevojitet dituria themelore për atë

se si programet, duke vepruar në sistemet skajore të shumëfishta, komunikojnë me njëra tjetrën.

Në zhargonin e sistemeve operuese, në të vërtetë nuk janë programet ato që komunikojnë por

janë proceset. Procesin mund të paramendojmë si program i cili funksionon përbrenda sistemit

skajor. Kur proceset funksionojnë në të njëjtin sistem skajor, ata mund të komunikojnë me njëri

tjetrin me komunikim ndërprocesor, duke përdorur rregullat të vendosura nga sistemi operativ isistemit skajor. Por në këtë libër ne nuk jemi të interesuar pikërisht në atë se si komunikojnë

proceset e të njëjtit host(nikoqir), por në vend të saj na intereson se si proceset që funksionojnë

në hostat e ndryshëm (potencialisht me sisteme të ndryshme operuese), komunikojnë mes

vetes.Proceset në dy sisteme të ndryshme skajore komunikojnë me njëri tjetrin përmes

shkëmbimit të mesazheve ndërmjet rrjeteve kompjuterike. Procesi dërgues krijon dhe dërgon

mesazhet në rrjet; procesi pranues i pranon këto mesazhe dhe mundësisht përgjigjet duke

dërguar mesazhet prapa. Fig. 2.1 ilustron se proceset komunikojnë me njëra tjetrën duke

shfrytëzuar shtresën e aplikacionit të protokolit të stakut (pirgut) pesë-shtresor.

Proceset Klient dhe Server

Aplikacioni i rrjetit përbëhet prej palëve të proceseve ku dërgojnë mesazhet njëri tjetrit ndërmjet

rrjetit.P.sh.Në Web aplikacione procesi i shfletuesit të klientit shkëmben mesazhe me procesin e

një Web serveri. Në sistemin P2P të shpërndarjes së fajllave, një fajll transferohet nga një proces

në një Peer në një proces tjetër tek Peer tjetër. Për të gjitha palët e proceseve të komunikimit

thjesht njërën nga proceset emërojmë si klient dhe procesin tjetër si server. Në web, browseri

është procesi klient kurse web serveri është procesi server. Me shpërndarjen e fajllave me

sistemin P2P, peer i cili downloadon(shkarkon) fajllin e emërojmë si klient, kurse peer i cili

uploadon(ngarkon) fajllin e emërojmë si server.

Ju mund ta keni vërejtu se në disa aplikacione, si sistemi P2P për shpërndarjen e fajllave, një

proces mund të jetë edhe klient edhe server. Në fakt një proces në sistemin P2P të shpërndarjes

së fajllave njëkohësisht mun të uploadojë dhe downloadojë fajllat. Sidoqoftë, në kontekstin e

cilitdo sesion komunikimi mes procesit të palëve të proceseve, ne ende mund të shënojmë njërin

proces si klient dhe tjetrin si server. Ne mund të definojmë proceset klient dhe server si në vijim.

Në kontekstin e sesionit të komunikimit në mes të palëve të proceseve, procesin i cili

fillon(inicon) komunikimin (i cili fillimisht kontakton tjetrin në fillim të sesionit) shënohet si

KLIENT . Procesi i cili pret që të kontaktohet për të filluar sesionin është SERVERI .

Në web, procesi browser inicon kontaktin me procesin e web serverit, për këtë arsye procesi i

browserit është klient dhe procesi server i web-it është serveri. Në P2P, kur peer A kërkon nga

peer B ti dërgoj fajllin specifik, peer A është klient, dhe peer B është server në kontekstin e këtij

sesioni specifik të komunikimit. Kur këtu nuk ka konfuyion, ne ndonjëherë, gjithashtu e

përdorim terminologjinë “ana e klientit dhe ana e serverit të aplikacionit”. Në fund të këtij

kaputlli ne do të spjegojmë përmes kodeve të thjeshta për anët e klientit dhe të serverit të

aplikacioneve të networkut.

Interfejsi në mes të Procesit dhe Rrjetit kompjuterik




Faqe 7

Siq është cekur më lartë, shumica e aplikacioneve përbëhen nga palët e komunikimeve të

proceseve, nga 2 procese në çdo palë dërgojnë mesazhe njëri tjetrit. Çfarëdo mesazh që dërgohet

nga një proces së pari duhet të kalojë nga një rrjet themelor. Një proces dërgon mesazhe, pranon

mesazhe, nga një rrjet me anë të një interfejsi softverik të ashtuquajtur – socket-. Të konsidojmë

një analogji për të kuptuar proceset dhe soketët. Procesi është i ngjashëm me shtëpinë kurse

soketi i tij është i ngjashëm me derën e shtëpisë. Kur një proces dëshiron të dërgoj një mesazh

në një proces tjetër në një host tjetër ai e shtyn mesazhin jashtë derës(soketit) të tij. Ky proces idërgimit supozon se ekziston një infrastrukturë të transportit në anën tjetër të derës që do të

transportoj mesazhin në destinacionin e derës së procesit tjetër. Pasi që mesazhi arrin tek

destinacioni i hostit mesazhi kalon nga soketi i procesit pranues pastaj procesi përpunon

mesazhin.Fig. 2.3 ilustron komunikimin e dy proceseve, të lidhura përmes internetit, me anë të

soketëve.(Fig. 2.3 supozon se protokoli themelor të transportit që përdoret nga procesi është

TCP protokoli i Internetit). Siq paraqitet në këtë fig. Soketi është ndërmjetsuesi në mes të

shtresës së aplikacionit dhe shtresës së transportit në host.

Figura 2.3 Proceset e aplikacionit,socket-at dhe protokolli i transportit

Ajo gjithashtu i referohet si: Application Programming Interface(API)(Programimi i

interfejsit të aplikacionit) ndërmjet aplikacionitdhe rrjetës, pasi që soketi është programimi i

interfejsit me anë të cilit aplikacionet të bazuara në rrjet janë të ndërtuara. Zhvilluesi i

aplikacionit posedon kontroll të plotë në anën e shtresës së aplikacionit të soketit por ka pak

kontroll në anën e shtresës së transportit të soketit.Kontrolla e vetme që zhvilluesi posedon në

anën e shtresës së transportit është:1) zgjedhja e protokolit të transportit, 2) dhe ndoshta

mundësia për të ndrequr disa parametra në shtresën e transportit si p.sh. baferi maksimal, dhe

madhësia maksimale të segmentit(në kapitullin e 3 do të përfshihen). Pasi zhvilluesi iaplikacionit përzgjedh protokolin transportues(nëse ka mundësi të zgjedhjes), aplikacioni

ndërtohet duke shfrytëzuar servisin e shtresës së transportit, që ofrohet nga ai protokol. Ne do të

hulumtojmë disa detale të soketëve në pjesën 2.7 dhe 2.8.

2.1.3 Shërbimet transportuese në dispozicion për aplikacione




Faqe 8

Përkutohuni që soketi është ndërmjetsues mes procesit të aplikacionit dhe shtresave

transportuese të protokolit. Prej anës dërguese, aplikacioni shtyn mesazhet përmes soketit. Në

anën tjetër të soketit protokoli shtresor transportues ka përgjegjësi për marrjen mesazhit në

“derën” e soketit pranues.Shumë rrjeta duke përfshirë edhe Internetin, ofrojnë më shumë se një

protokol shtresor transportues. Kur ju zhvilloni një aplikacion, ju duhet të zgjedhni një nga

protokolet shtresore transportuese. Si do ta bëni këtë zjedhje.sipas të gjitha gjasave ju do tëstudjoni shërbimet të cilat janë ofruar nga protokolet e disponueshme shtresore transportuese,

dhe do të zgjedhni protokolin me shërbimet që përputhen me nevojat e aplikacionit tuaj. Është e

ngjashme si me përzgjedhjen e aeroplanit apo trenit për të udhëtuar nga një qytet në tjetrin. Ju do

ta zgjedhni njërin prej tyre dhe secili lloj transporti ju ofron shërbime të ndryshme(p.sh. treni

ofron hipje dhe zbritje në qendër të qytetit, përderisa aeroplani ofron udhëtim me kohëzgjatje më

të shkurtë).Cilat janë shërbimet të cilat protokoli shtresor transportues mund të ofroj që të

mbështes aplikacioni? Ne mund të klasifikojmë shërbimet e mundshme gjerësisht në katër

dimensione: transferi i besueshëm i të dhënave, throughput, kohëzgjatja dhe siguria.

Transferi i besueshëm i të dhënave

Siq edhe e diskutuam në kapitullin 1, pakot mund të humben brenda rrjetit të kompjuterit. P.sh.

pakoja mund të tejkaloj baferin në ruter, ose mund të refuzohet nga hosti apo ruteri pasi që të

ketë disa bita të korruptuar. Për shumë aplikacione si posta elektronike, transferi i fajllave, qasja

remote e hostit, transfere dokumentesh në Web dhe aplikacione financiare, humbja e të dhënave

mund të ketë pasoja shkatërruese(si për bankën, ashtu edhe për klientin!). Pra, për të mbështetu

këto aplikcione duhet bërë diçka për të garantuar që të dhënat e dërguara nga njëra anë e

aplikacionit, të dorëzohet komplet dhe korrekt në anën tjetër të aplikacionit. Nëse protokoli

ofron shërbim dorëzues të garantuar atëhere thuhet se ofron TRANSFER TË BESUESHËM TË

TË DHËNAVE. Një shërbim i rëndësishëm që protokoli shtresor transportues potencialisht

mund t’ia ofroj aplikacionit është transferi i besueshëm i të dhënave nga procesi në proces. Kur

protokoli transportues ofron këtë shërbim, procesi i dërgimit mund të dorëzoj të dhënat e tij në

soket dhe me konfidencë totale e di se të dhënat do të arrijnë pa gabime në procesin e pranimit.

Kur protokoli shtresor transportues nuk ofron transfer të besueshëm, të dhënat e dërgueara gjatë

procesit të dërgimit, mund të mos arrijnë fare te procesi i pranimit. Kjo mund të jetë e

pranueshme për aplikacionet TOLERANTE NDAJ HUMBJES, më së shpeshti vërehet tek

aplikacionet multimediale si Real-time audio/video të cilat mund të tolerojnë humbjen e një

pjese të të dhënave. Në këto aplikacione multimediale, humbja e të dhënave mund të rezultoj me

glitch(gabime) të vogla në pjesën audio/video që luhet- një dëmtim jo krucial.

Throughput

Në kapitullin 1 ne prezantuam konceptin e throughput-ëve në dispozicion, të cilët në kontekstin

e sesionit (seancës) komunikuese mes dy proceseve përgjatë shtegut të rrjetit është rate(vlerë) në

të cilën procesi dërgues mund të dorëzoj bit-at në procesin e

pranimit. Për shkak se sesionet tjera mund të shkëmbejnë bandwidth(kapaciteti i linjës) përgjatë

shtegut të rrjetit si dhe për shkak se këto sesione do të vijn dhe shkojnë, throughput-i mund të




Faqe 9

pësojë luhatet me kohë. Këto vrojtime qojnë te shërbime tjera natyrore të cilat protokoli shtresor

transportues mund të ofroj, të emërtuar, throughput të garantuara të disponueshme në një ratë të

specifikuar. Me këtë lloj shërbimi aplikacioni mund të kërkoj throughput të garantuar të r

bit/sekokndë dhe protokoli transportues atëherë mund të siguroj se throughput i disponueshëm

është gjithnjë bile r bite/sekondë.Një shërbim i tillë i throughputit të garantuar mund të apeloj

tek shumë aplikacione. P.sh. nëse një aplikacion telefonik i Internetit, enkodon zërin në 32 kbps,

atij i nevojitet të dërgoj të dhëna në rrjet dhe të ketë të dhëna të dorëzuara tek aplikacioni pranues në këtë ratë. Nëse protokoli transportues nuk mund të ofroj këtë throughput, aplikacioni

duhet të enkodoj në ratë më të ulët(dhe pranon throughput të mjaftueshme të mbështes këtë ratë

të ulët enkoduese) ose duhet të heq dorë, pasi pranimi i gjysmës së throughputëve të duhur është

i vogël apo i padobishëm për këtë aplikacion telefonike të Internetit. Aplikacionet që kanë

kërkesë për throughput, thuhet të jenë Aplikacion të Ndjeshëm-për-Bandwidth. Shumë

aplikacione aktuale janë ndjeshëm ndaj bandwidth, edhe pse disa aplikacione multimediale,

mund të shfrytëzojnë teknika kodike adaptuese për të enkoduar në ratë që përputhet me

throughputet aktualisht në dispozicion.

Përderisa aplikacionet e ndjeshëm ndaj bandwidth-it kanë kërkesa specifike të throughput,

aplikacionet elastike mund të përdorin sado pak a shumë, që throughput të jetë edisponueshme. Posta elektronike, transferi i fajllave dhe web transferet janë që të gjitha

aplikacione elastike.

Natyrisht sa më shumë throughput, aq më mirë. Ekziston thënja se askush nuk mund të jetë tepër

i pasur, tepër i dobët apo të ketë tepër throughput-a.

Kohëzgjatja

Protokoli shtresor-transportues gjithashtu mund të jap garancione kohore. Ashtu si throughput

garancionet, edhe garancionet kohore mund të jetë në forma të ndryshme. Një shembull garancie

mundtë jetë ajo se secili bit që dërguesi e pompon në soket arrin në soketin e pranuesit jo më

vonë se 100msek. Ky lloj shërbimi mund të apeloj në real-time aplikacionet, si telefonia e

Internetit, ambientet virtuale, telekonferencat dhe lojërat me më shumë lojtarë, të gjitha këto që

kërkojnë kufizime strikte kohore me qëllim që të jenë efektive(kapitulli 7, [Gauthier 1999;

Ramjee 1994].) Vonesat e gjata në telefonin e Internetit, për shembull, rezulton në pauza

jonatyrale në bisedë; në lojërat me shumë lojtar apo ambient virutal interaktiv, vonesë e gjatë

mes veprimit dhe përgjegjes që vjen nga ambienti(p.sh. nga lojtari në fund të lidhjes end-to-

end(skaj-më-skaj)) bën që aplikacioni të ndjehet më pak real. Për aplikacionet non-real-

time(kohën jo reale), vonesa e ulët është më preferueshme se vonesat e larta, por nuk janë të

vendosura kufizimet të strikte në vonesat end-to-end.

2.1.4 Shërbimet transportuese të ofruara nga Interneti

Deri më tash, ne konsideruam shërbimet transportuese se çfarë ofron rrjeta kompjuterike në

përgjithësi. Tani të jemi më specifik dhe të studjojmë llojin e mbështetjes së aplikacioneve të

ofruara nga Interneti. Interneti(dhe në përgjithësi TCP/IP rrjetat) krijojnë dy protokole të

disponueshme tek aplikacionet, UDP dhe TCP. Kur ju(si zhvillues i aplikacioneve) krijoni një

aplikacion të ri për rrjeta për Inter, një nga vendimet e para që duhet të mirren është se a të




Faqe 10

përdorësh UDP apo TCP. Të gjitha këto protokole ofrojnë sete të ndryshme të shërbimeve për

forcimin e aplikacionit. Fig. 2.4 tregon kërkesat e shërbimit për disa aplikacione të përzgjedhura.

TCP shërbimet

Modeli i shërbimeve TCP përfshin shërbimin e orientuar-në-lidhje dhe shërbim të transferit të besueshëm të të dhënave. Kur një aplikacion nxit TCP si protokol transporti, aplikacioni pranon

të dyja këto shërbime nga TCP-ja:

Shërbimi i orientuar-në-lidhje. TCP ka informatën kontrolluese të shkëmbimit

transportues-shtresor mes klientit dhe serverit me të dyjat para se të fillojë të rrjedhë

mesazhet në nivel-të-aplikacionit.

Figura 2.4 Kërkesat e selektuara të aplikacioneve të rrjetës

Kjo e ashtuquajtura procedura duarshtrëngim tërheq vërejtjen e klientit dhe serverit,duke u lejuar atyre të përgatiten për ndarjen e paketeve. Pas fazës së duarshtrëngimit,

Lidhja TCP thuhet se ekziston në mes të soketëve të dy proceseve. Lidhja është lidhje

full-dupleksnë atë se dy proceset mund të dërgojnë mesazhe njëra tjetrës përmes lidhjes

në të njëjtën kohë. Kur aplikacioni përfundon me dërgimin e mesazheve, duhet të

shkëput lidh jen. Shërbimi referohet në shërbimin “orientuar në lidhje” më parë se në

shërbimin “e lidhjes” sepse të dy proceset janë të lidhura në një mënyrë shumë të lirë.

Në kapitullin 3 ne do të diskutojmë shërbimet të orientuara në lidhje më detalisht dhe të

studjojmë se si implementohet.

Shërbimi i transferit të besueshëm të të dhënave. Proceset komunikuese mund të

mbështeten në TCP për të dorëzuar të gjitha të dhënat e dërguara pa gabime dhe merradhitje të duhur. Kur njëra anë e aplikacionit përcjellë rrjedhën e bajtave në soket,

mund të llogaris në TCP që do të dorëzoj të njëjtën rrjedhë të bajtave në soketin

pranues, pa bajta të mangët ose të dyfishuar.

TCP gjithashtu përfshin mekanizmin e kontrollit të ngatërrimeve, shërbim për mirëqenien e

përgjithshme të Internetit më parë se sa për dobinë direkte të proceseve të komunikimit.

Mekanizmi për kontrollin e ngatërrimit e TCP përmbys një proces të dërgimit(klientit ose




Faqe 11

serverit) kur rrjeta është i mbushur ndërmjet dërguesit dhe pranuesit. Si do të shohim në

kapitullin 3, kontrolli për mbushjen e TCP gjithashtu tenton për të limituar çdo TCP lidhje

në pjesën e bandwidthit të tij. Përmbysja e ratës së transmetimit mund të ketë një efekt

dëmtues në real-time audio dhe video aplikacione që kanë kërkesa minimale të throughput-

it. Për më tepër, real-time aplikacionet janë tolerant-ndaj-humbjes dhe nuk i nevojitet një

shërbim transporti komplet të besueshëm. Për këto arsye, zhvilluesit e real-time

aplikacioneve më shpesh zgjedhin të startojnë aplikacionet e tyre me UDP se me TCP.

Sherbimet UDP

UDP eshte nje no-frill,protokoll i lehte transporti, qe siguron sherbimet minimale.UDP eshte nje

lidhje e ulet,keshtu qe nuk ka ``duarshtrengime`` perpara se te dy proceset te fillojne

komunikimin.UDP ofron nje sherbim te transmetimit te te dhenave te pabesueshem-qe eshte, kur

nje proces dergon nje mesazh brenda nje baze te UDP. UDP nuk jep asnje garancion qe mesazhi

do të arrije ta kryeje procesin e marrjes.Per me

teper, mesazhet qe nuk arrijne ne procesin e marrjes mund të arrijne jashte rendit.

UDP nuk perfshin nje mekanizem te kontrollit-ngjeshes, keshtu qe ne anen e dergimit UDPmund te bej shtypjen e te dhenave ne shtresen e poshtme( shtresen e rrjetit) e qe ne cdo rast te

kenaq.

(Shenojme, megjithate, se ne fund aktuale per t`i dhene fund xhiros mund te jete me pak se kjo

norme per shkak te gjersise se shiritit i cili eshte i kufizuar ose per shkak te mbingarkeses).Sepse

ne kohe reale kerkesave shpesh mund te ju tolerohen humbje, por kerkojne nje norme minimale

qe te jete efektive, zhvilluesit e aplikacioneve ne kohe reale nganjehere zgjedhin per te drejtuar

kerkesat e tyre mbi UDP, duke i shmangur TCP-se mekanizmin ngjeshes-kontrollues dhe pakon

e shpenzimeve me fletengarkese.Nga ana tjeter, per shkak se jane konfiguruar firewalls per te

bllokuar trafikun UDP,dizajneret kanë zgjedhur gjithnje per te drejtuar multimediat dhe

aplikacionet e verteta mbi TCP.

Sherbimet te cilat nuk ofrohen nga protokollet e transportit ne internet

Ne kemi organizuar transport te mundshem protokollesh te sherbimeve se bashku me kater

dimensione:te dhena te besueshme , transferim te xhiros, kohen dhe sigurine.Secila nga keto

sherbime jane te kushtezuaranga TCP dhe UDP? Ne cdo here e kemi cekur se TCP ofron te

dhena transferuese te besueshme ne fund.Dhe ne gjithashtu dime se TCP mund te rritet lehte ne

shtresat aplikative per te ofruar sherbime të sigurta.Por ne nje pershkrim me te shkurte te TCP

dhe UDP, mungesa dukshem ishte ndonje permendje e xhiros apo koha qe garanton sherbimet e

ofruara nga protokollet e sotme nuk mbeshtesin transportin ne internet.A do te thote kjo se

aplikimet të ndjeshme ne kohe te tilla si telefonia e internetit nuk mund te kandidojne në

interentin e sotem.Pergjigja eshte e qarte se jo-interneti do të jete aplikacion i ndjeshem ne kohe

per vite me radhe.Keto zbatime shpesh punojne mjaft mire, sepse ato kane qene te dizajnuara

per te perballuar, per aq sa eshte e mundur, me kete mungese te garancise.

Ne do të hetojme disa prej ketyre dizajn mashtrimeve ne kapitullin e 7.Megjithate, dizajni i

zgjuar ka kufizimin e tij kur vonesa eshte e tepruar, sic ndodh shpesh ne internetin publik.Ne

përmbledhje te gjithe kesaj, sot interneti shpesh mund




Faqe 12

te jape te dhena te kendshme te kerkesave te ndjeshme ne kohe, por kjo nuk mund te jape ndonje

siguri per kohen apo per gjeresine e shiritit.

Figura 2.5 tregon transportin e protokollit te perdoruara nga disa aplikacione te popullarizuara te

internetit.Ne shohim se ajo e-mail, me qasje terminali te larget, web-i, dhe fajll transferat te

gjitha perdorin TCP.Keto zbatime i kanë zgjedhur TCP kryesisht per shkak se ofron nje sherbim

te besueshëm per transferimin e te dhenave, duke garantuar se të gjitha te dhenat ne fund do temarrin nje drejtim(destinacion).Ne gjithashtu shohim se telefonia e internetit ne menyre tipike

shkon mbi UDP.Cdo ane e kerkeses se telefonit ne internet ka nevoje per te derguar te dhenat ne

te gjithe rrjetin ne nje norme minimale(shih audion ne kohe reale ne figuren 2.4), kjo ka me

shume gjasa te jete e mundur me UDP sesa me TCP.

Gjithashtu, aplikacionet e telefonit ne internet kane nje humbje tolerante, keshtu qe ata nuk u

besojne transferimit te sherbimeve te te dhenave qe ofrohet nga TCP.

Figura 2.5 Aplikacionet e njohura të Internetit,protokollet e tyre të shtresës së aplikacioneve dhe

protokollet e transportit.

Adresimi i proceseve Ne diskutimin tone me larte jemi fokusuar ne sherbimet e transportit midis dy proceseve te

komunikimit. Por si mund të jete nje proces qe tregon se me cilin proces deshiron te komunikoje

me perdorimin e ketyre sherbimeve?Si nje proces dergon nje mori hostesh ne

Amherst,Massachusetts USA qe specifikon se deshiron te komunikojë me nje proces te vecante

hostesh ne Bangkok,Thailand? Per te identifikuar procesin e marrjes, 2 pjese te informacionit

nevoitet te specifikohen: (1) emri ose adresa e hostit dhe(2) nje identifikues qe specifikon

procesin e marrjes ne destinacionin e hostit.

Ne internet, hosti eshte identifikuar me IP adresen e tij. Ne do të pershkruajme IP adresat ne

menyre te qarte ne kapitullin 4. Per tani, e gjitha cka ne duhet të dime eshte se nje IP adrese

është me sasi 32-biteshe qe ne mund te mendojme si nje identifikimunik te hostit.(Sidoqofte, ne do te shohim edhe ne kapitullin 4, vendosjen e gjere te rrjetit te

adreses perkthyese (NATs) qe do të thote se, ne praktike, nje IP adrese 32 biteshe nuk ka nje

adrese unike te hostit).Pervec njohjes së adresës së hostit për të

cilat një mesazh është destinuar, hosti i dërguar gjithashtu duhet të identifikojë procesin e

marrjes ne drejtimin e hostit.Kjo informate eshte e rendesishme sepse hosti gjeneral mund te

drejtohet ne shumicen e aplikacioneve te rrjetit. Destinacioni ``port number``i sherben ketij

qellimi.Aplikacionet e popullarizuara kane qene te caktuara me numra portesh te vecanta.Per




Faqe 13

shembull, nje web server ka qene i caktuar me numrin e portes 80. Nje mail proces server (qe

perdor SMTP protokoll) eshte caktuar me numrin e portes 25.Nje liste me njohjen e mire te

numrave te porteve per te gjitha protokollet standarde ne internet mund te gjindet ne

http://www.iana.org.Kur nje zhvillues krijon nje aplikacion rrjeti te ri, aplikacionet mund te

caktohen me nje numer porte te ri.Ne kemi shpjeguar numrin e porteve ne detale ne kapitullin 3.

2.1.5 Protokollet e shtresës së aplikacionit

Ne kemi mesuar se procesi rrjetor mundeson komunikimin me njeri tjetrin doke derguar

mesazhe brenda bazes. Por si jane te strukturuara

keto mesazhe? Cili eshte kuptimi i fushave te ndyshme tek mesazhet? Kur proceset i dergojne

mesazhet? Keto pyetje na sjellin brenda nje

fushe te protokolleve kerkese-shtrese. Nje Protokoll kerkese-shtrese definon si nje proces

kerkues, vepron ne mbarimin e sistemeve te

ndyshme, dergon mesazhet tek njeri tjetri.Praktikisht,nje protokoll kerkese-shtrese definon:

Llojin e shkembimit te mesazheve, per shembull, mesazhi kerkues dhe mesazhi

pergjegjes Sintaksen e llojeve te ndryshme te mesazheve, te tilla si fushat ne mesazh dhe menyra

se si jane percaktuar keto fusha

Semantiken e fushave, qe eshte , ne kuptimin e informacionit te fushes

Rregullat per determinimin kur dhe si procesi dergon mesazhe dhe pergjigjet ne

mesazhe

Disa protokolle kerkese-shtrese jane te specifikuara ne RFC dhe prandaj jane ne domenin

publik. Per shembull, nje web protokoll

kerkese-shtrese aplikim, HTTP (HyperText Transfer Protocol) eshte ne dispozicion si nje

RFC.Ne qofte se nje zhvillues kerkimi ndjek rregllat e HTTP RFC, kerkuesi do te jete ne gjendje

te rifitoj faqet e internetit nga ndojne server i internetit qe ka ndjekur edherregullat e HTTP RFC.Shume protokolle tjera kerkese-shtrese jane te pronesuara dhe

nderkombetare e nuk jane te disponueshme ne domenin publik.Per shembull, shume sisteme

ekzistuese fajll-shperndarese P2P perdorin pronesimin ne protokollin kerkese-shtrese.Eshte e

rendesishme te behet krahasimi mes kerkeses se rrjetit dhe protokollit kerkese-shtrese. Nje

protokoll kerekese-shtrese eshte vetem nje pjese e kerkeses se rrjetit. Le ti shohim disa cifte

shembujsh.Web-i eshte nje kerkese(aplikacion) klient-server qe i lejon perdoruesve te marrin

dokumente nga serveret mbi kerkesen. Aplikacioni web perbehet nga shume komponente, duke

perfshire edhe nje standard

per formate te dokumetit (qe eshte HTML), shfletuesin web (per shembull, Firefox dhe

Microsoft Internet Explorer),web server(per shembull Apache dhe serveri Microsoft) dhe protokollin kerkese-shtrese.Web-at e protokollit kerkese-shtrese, HTTP, definon formatin dhe

sekuencat e mesazheve qe jane kaluar brenda shfetuesit dhe web serverit.Prandaj, HTTP eshte

vetem nje pjese e kerkeses web. Nje shembull tjeter, nje e-mail kerkese ne internet poashtu ka

disa komponente, duke perfshire mail serveret qe

perdorin shtepite per kuti te mail-ave; mail lexuesit qe lejojne perdoruesit te lexojne dhe te

krijojne mesazhet, nje standard per percaktimin e struktures se nje e-mail mesazhi, dhe qe

protokolli kerkese-shtrese percakton se si mesazhet jane miratuar mes servereve, dhe si behet




Faqe 14

permbajtja e pjeseve te caktuara te mail mesazhit(per shembull, nje mesazh koke-mail) dhe te

interpretimi.Aplikacioni kryesor i protokollit kerkese-shtrese per poste elektronike(mail) eshte

SMTP(Simple Mail Transfer Protocol).

Keshtu, email-a eshte protokolli kryesor kerkese-shtese. SMTP, eshte vetem nje pjese (edhe pse,

nje pjese e rendesishme) e aplikacionit e-mail.

2.1.6 Aplikacionet e rrjetit te mbuluara në kete liber

Domeni i ri publik dhe kerkesat e pronarit te internetit jane duke u zhvilluar cdo dite. Me teper

se sa qe mbulon nje numer te madh te aplikacioneve te internetit ne nje

menyre enciklopedike, ne kemi zgjedhur qe te perqendrohemi ne nje numer te vogel te

kerkesave qe jane te dyja te perhapura dhe te rendesishme.Ne kete kapitull ne kemi perfshire 5

aplikacione te rendesishme: Web-i, fajllat transferues, mail-i elektronik,lista e sherbimeve , dhe

aplikacioni P2P. Ne se pari kemi pershkruar Web-in, jo vetem qe eshte nje aplikacion shume i

popullarizuar, por poashtu protokolli i saj, HTTP, eshte i drejte dhe I lehte per ta kuptuar.Pas

mbulimit te web-it, shqyrtojme shkurtimisht FTP, sepse ai ofron nje kontrast te mire per HTTP.

E-mail-i eshte me kompleks se sa web-i dhe me kete kuptojme se ai ben perdorimin e jo nje por

disa protokolleve kerkese-shtrese. Pas email-it, ne kemi mbuluar DNS, i cili ofron nje sherbim

direkt te internetit. Shumica e perdoruesve nuk nderveprojne direkt me DNS; ne vend te kesaj,

perdoruesit e adhurojne DNS indirekte permes kerkesave tjera( duke perfshire Web-in, fajllin

transferues, dhe mail-in elektronik). DNS ilustron mire se si nje pjese funksionale e berthames

se rrjetit(perkthimi i emrit te rrjetit tek emri i adreses) mund te implementohet tek shtresat

aplikative ne internet. Ne fund, ne kemi pershkruar aplikacionin P2P, duke përfshirë

shpërndarjen e fajll-ave, shpërndarjen e databazës dhe IP telefoninë.

2.2 Web-i dhe HTTP

Deri ne fillim te vitit 1990 Interneti ishte perdorur kryesisht nga studiuesit, akademiket dhe

studentet e universiteteve per tu qasur ne largesi ne Hostet, per te transferuar fajlle nga Hostet

lokale ne Hostet ne largesi dhe anasjelltas, per te pranuar dhe derguar lajme dhe per te pranuar

dhe derguar mesazhe elektronike.Ndonese keto aplikacione ishin (dhe vazhdojne te jene)

ekstremisht shume te perdorura, Interneti ishte thelbesisht i panjohur jasht komunitetit të

akademikeve dhe studiueseve.

Pastaj, ne fillim te viteve te 90-ta, nje aplikacion i ri madheshtor arriti ne skene World Wide

Web (Berners-Lee 1994). Web-i ishte aplikacioni i pare i Internetit qe zuri nje vend te

rendesishem per syrin e publikut. Ai dramatikisht ndryshoi, dhe vazhdon te ndryshon, si njerezit

qe bashkeveprojne brenda dhe jashe mjedisit te tyre te punes. Interneti ishte ngritur vetem nga

nje njesi e disa te dhenave te rrjetave ne thelb nje dhe e vetmja e dhene e rrjetit.Ndoshta ankesat

me te medha te perdoruesve jane se Web-i operon ne mbi kerkesen.Perdoruesit marrin ate se cka

dëshirojne dhe kur deshirojne. Kjo eshte ndryshe nga transmetimi i radiove dhe televizioneve, e

cila i detyron me force perdoruesit per te kapur permbajtjen te cilën e leshon sherbyesi dhe qe e

ve ne dispozicion. Ne menyre per te qene ne dispozicion mbi kerkesen, Web-i ka me shume




Faqe 15

tipare të mrekullueshme që njerezit i deshirojne dhe favorizojne. Kjo eshte jashtezakonisht lehte

per shume individ per te marrë informacione ne dispozicion nepermjet Web-it, cdokush mund te

behet nje publikues me kosto jashtezakonisht te ulet. Hiperlinket dhe makinat e kerkimit na

ndihmojne neve per te naviguar ne nje oqean Web Sajte. Grafikat na stimulojne shqisat tona.

Format, programi Java, dhe pajisje tjera na mundesojne neve te interaktojme me faqe dhe sajte.

Dhe me teper, Web-i siguron nje meny per te nderlidhur nje sasi te madhe te audio dhe video

materialeve qe jane te ruajtura ne Internet- multimedia qe mund te qasemi me ane te kerkeses.

2.2.1 Pamja e pergjithshme e HTTP-se

Hyper Text Transfer Protocol(HTTP), protokolli i shtreses se programit te Web-it , eshte

zemra e Web-it .Eshte percaktuar ne (RFC 1945) dhe (RFC 2616). HTTP eshte implementuar

ne dy programe: nje program si klient dhe tjetri si server. Klient programi dhe server programi

ekzekutohen ne sisteme te ndryshme, komunikojne ne mes vete duke shkembyer HTTP

mesazhe. HTTP percakton strukturen e ketyre mesazheve, dhe se si klienti dhe serveri

shkembjene mesazhe. Para se te gjurmojme HTTP ne detaje, ne duhet te shikojme disa

terminologji te Web-it. Nje Web Faqe (e njohur edhe si dokument) perbehet nga objektet. Nje objekt eshte thjesht nje

fajll- sic eshte HTML fajlli, JPEG imazhi, Java programi, ose nje video-klip qe adresohet nga

nje URL e vetme. Shumica e Web Faqe-ve perbehen nga baza e fajlleve HTML dhe ca objekte

te referuara. Per shembull, nese nje Web Faqe permban tekst HTML dhe 5 imazhe JPEG, pastaj

Web Faqja ka 6 objekte: baza e fajllit HTML dhe 5 imazhe. Baza HTML i referohet objekteve

tjera ne faqe me objekte URL. Secila URL ka dy komponente, Hostname e serverit që përmban

objektin dhe emrin e rrugës së objektit, psh: URL

http://www.someschool.edu/someDepartment/picture.gif

e ka www.someschool.edu per nje hostname dhe someDepartment/picture.gif per emrin e

rruges. Sepse Web Shfletuesit (siq jane Internet Explorer dhe Firefox) implementojne anen e

klientit te HTTP-se, ne kontekst te Web-it, ne do ti perdorim fjalet Shfletues dhe Klient njeri-

tjetri. Web serveret, te cilet implementojne anën e serverit te HTTP-se, shtepitë e Web

objekteve, secila të adresuara me nga një URL. Web serveret e popullarizuar perfshijne Apache

dhe Microsoft Internet Information Server.

HTTP percakton se si Web klienti kerkon Web faqe nga Web server-at dhe se si serveri

transferon Web faqe te klienti. Ne do te diskutojme interaksionin ndermjet klientit dhe serverit

ne detaje më vone, por ne pergjithesi idea eshte ilustruar ne Figuren 6.2. Kur nje perdorues

kerkon nje Web faqe (psh: klikon në nje Hiperlink), shfletuesi e dergon mesazhin qe e kerkon

me HTTP per objektet ne faqet e serverit. Serveri pranon kerkesen dhe i pergjigjet me HTTP

mesazh pergjigjes qe e permban objektin.

HTTP perdor TCP si protokoll themelor transporti (me teper se drejtimi i kryesuar nga UDP).

Klienti HTTP ne fillim inicion nje lidhje TCP me serverin. Kur lidhja eshte bere me sukses,

shfletuesi dhe serveri procesojne qasjen e TCP nepermjet vrimave te interfejsit. Si e pershkruam

ne Seksionin 2.1, ne anen e klientit vrima e interfejsit eshte dera ndermjet procesit te klientit

dhe lidhjes TCP: ne anen e serverit eshte dera ndermjet procesit te serverit dhe lidhjes TCP.

Klienti e dergon HTTP kerkesen si mesazh ne vrimat e interfejsit te tij dhe e pranon HTTP

pergjigjen nga vrimat e tij te interfejsit.







Faqe 16

Figura 2.6 Sjellja e HTTP kerkeses – pergjigjes

Njejte, serveri HTTP pranon nje mesazh kerkues nga vrima e interfejsit te tij dhe dergon mesazh

pergjigjes ne vrimen e interfejsit te tij. Njehere klienti e dergon nje mesazh ne vrimen e

interfejsit, mesazhi eshte jashte duarve te klientit dhe eshte “ne duart” e TCP. Kujtojme ngaSeksioni 2.1 qe TCP siguron nje sherbim te sigurt per transferimin e te dhenave deri te HTTP.

Kjo nenkupton qe cdo mesazh kerkues i HTTP i derguar nga nje klient procesi perfundimisht

arrin i paprekur te server: njejte, mesazhi pergjigjies HTTP derguar nga server procesi

perfundimisht arrin i paprekur te klienti. Ketu ne shohim nje nga avantazhet e medha te

arkitektures se shtresave - HTTP nuk duhet te brengoset per humbjen e te dhenave ose detajeve

se si TCP rikthen nga te humbura ose te riurdheruara te dhenat brenda rrjetit.

Kjo eshte detyra e TCP dhe protokolleve ne shtresat me te ulta te renditjes se shtresave.

Eshte e rendesishme te shenojme qe serveri dergon fajlle kerkese te klienti pa ruajtur ndonje

informacion kryesor per klientin. Nese nje klient i vecante pyet per te njejtin objekt dy here ne

nje periudhe prej disa sekondave, serveri nuk i pergjigjet duke thene se eshte servuar objekti teklienti: por prap, serveri i ri dergon objektin, duke harruar teresisht se cka ka vepruar me pare.

Sepse nje HTTP server nuk permban informacione rreth klientit, HTTP thuhet të jete stateless

protocol.Ne gjithashtu rimarkojme qe Web-i perdor arkitekturen e aplikacionit klient-server, siq

pershkruhet ne seksionin 2.1. Nje Web server eshte gjithnje i ndezur, me një IP adrese fikse dhe

sherben kerkesa potencialisht nga miliona shfletues te ndryshem.

2.2.2 Lidhjet e Paqëndrueshme dhe të Qëndrueshme

Ne shumicen e aplikacioneve te internetit, klienti dhe serveri komunikojne per nje periudhe te

gjere kohore, klienti eshte ai i cili bene kerkesa te njepasnjeshme ndersa serveri i pergjigjetseciles kërkese.Duke u varur ne aplikacion dhe ne menyren se si aplikacioni perdoret, serite e

kerkesave mund te jene te bera ne menyre(back-to-back).Kur ky bashkepunim ne mes te klientit-

serverit ze vend ne TCP, hartuesi i aplikacionit duhet te merr nje vendim te rendesishem, duhet

qe cdo pale e kerkeses/pergjigjes te dergohet ne lidhje te ndryshme te TCP, ose duhet qe te

gjitha kerkesat dhe pergjigjet perkatse te dergohen ne te njejten lidhje te TCP.

Ne qasjen e fundit, aplikacioni duhet te përdor lidhje jo te qendrushme ndersa me vone ne qasjen

e fundit te perdor lidhje te qendrueshme.Per te arritur nje kuptim te thelle te kesaj menyre




Faqe 17

dizajnimi duhet te ekzaminojme avantazhet dhe te metat e lidhjeve te qendrueshme ne konteks te

nje aplikacioni specifik, te quajtur HTTP, i cili mund te perdoret ne te dy lidhjet e qendrueshme

dhe te pa qendrueshme. Megjithate HTTP perdor lidhje te qendrueshme ne menyren e vet

fillestare, klientet dhe serveret HTTP mund te konfigurohen duke perdorur me mire lidhje jo te

qendrueshme.

HTTP me lidhje te paqendrueshmeLe t’i shikojme hapat e transferimit te nje Web-faqe nga serveri te klienti ne rastin e lidhjeve te

paqendrushme. Te supozojme se faqja permban nje fajll me baze HTML dhe 10 imazhe JPEG,

dhe te gjitha keto 11 objekte gjenden ne serverin e njejte.

Me poshte supozojme URL per fajllin me baze HTML,eshte:

http://www.someschool.edu/somedepartment/home.index

ja qfare ndodhe :

1) Procesi i klientit HTTP inicion nje lidhje TCP te serveri www.someschool.edu ne portin nr

80, ky port eshte i caktuar për HTTP. Asocion me lidhjen TCP, do te jete nje vrime per

klientin,dhe një vrime do te jete per serverin

2) Klienti HTTP i dergon nje mesazh HTTP kerkese ne serverin me ane te vrimes se tij.Mesazhi kerkues permban emrin e rruges /someDepartment/home.index (do ta diskutojme )

3) Procesi HTTP serverit pranon mesazhin kerkues me ane te vrimes se tij, nxjerr objektin

/someDepartment/home.index nga magazina (RAM-i ose Disku) e depaketon objektin ne nje

mesazh HTTP pergjigjes, dhe e dergon te klienti me ane te vrimes se caktuar.

4) Procesi HTTP serverit e udhezon TCP te mbyll lidhjen TCP. Por TCP jo ne te vertet do ta

perfundoj lidhjen derisa te behet e sigurt se klienti e ka pranuar mesazhin pergjigjes. 5) HTTP

klienti e pranon mesazhin e pergjigjes. Lidhja TCP perfundon. Mesazhi tregon se objekti i

paketuar eshte ne fajll HTML. Klienti e nxjerr fajllin nga mesazhi i pergjigjes, e ekzaminon

HTML fajllin dhe i gjen referencat e 10 objekteve qe jane JPEG.

6) Kater hapat e pare perseriten per cdo objekt JPEG te referuar.

Sic e pranon shfletuesi Web-faqen, ai e shfaq faqen te perdoruesi. Dy shfletues te ndryshem

mund te interpretojne(qe eshte shfaqur te perdoruesi) nje Web-faqe ne rruge te ndryshem. HTTP

nuk ka asgje per te bere se si nje Web-faqe eshte interpretuar te klienti.Specifikacionet e

HTTP(RFC1945)dhe(RFC2616) definojne vetem protokollin komunikues ndermjet programit

HTTP te klientit dhe programit HTTP te serverit.

Hapat me larte ilistruan per te perdorur lidhjet e pa qendrueshme ku cdo TCP lidhje eshte

mbyllur pasi qe serveri e dergon objektin-lidhja nuk vazhdon per objektet tjera.

Mbani mend qe cdo lidhje TCP transporton vertem nje mesazh per kerkes dhe nje mesazh.

Keshtu qe, ne ket shembull, kur nje perdorues i kerkon ne Web-faqe lidhjet TCP 11 jane

gjeneruar.Ne hapat e pershkruar me larte, ne ishim qellimisht te paqarte nese klinti i merr 10

JPEG neper 10 seriale te lidhjeve TCP. Me te vertete perdoruesi mund te konfiguroje shfletues

modern per te kontrolluar shkallen e ngjashmerise.Ne menyrat e caktuara shumica e shfletuesve

hapin 5 deri 10 lidhje TCP te ngjashme, dhe secila nga keto lidhje trajton nje transaksion

kerkese-pergjigje.

Nese perdoruesi preferon maksimumin e lidhjeve te njejta qe mund te dergohen ne nje,



http://www.someschool.edu/







Faqe 18

ne secilin rast 10 lidhjet jane te vendosura serialisht. Si do te shohim ne ne kapitullin tjeter,

perdorimin e lidhjeve te ngjashme ne kohe te shkurter.

Para se te vazhdojme, ta bejme back-of-the envelope kalkulimin per te vlersuar sasine e kohes

qe kalon nga nje klient qe kerkon nje fajll me baze HTML deri kur pranohet komplet fajlli te

klienti. Deri te fundi, ne e definojme Kohen e Udhetimit te Rundit (RTT), eshte kjo koh qe kalon

nga nje pako e vogel per te udhetuar nga klienti te serveri dhe pastaj te kthehet te klienti. RTT perfshin vonimin e shumimit te pakos, pritjen e pakos ne ndermjetsim te ruterave dhe switchave,

dhe vonesen e procesimit te pakove.(Keto vonesa jane diskutuar ne Seksionin 1.4).

Tani konsiderojme qka ndodhe kur nje perdorues klikon ne nje hiperlink. Sic shiheht ne Figuren

2.7, shkaku qe shfletuesi te inicion nje lidhje TCP ndermjet shfletuesit dhe Web serverit: kjo

involvon (three-way-handshake), klienti dergon nje segment te vogel TCP te serveri, serveri e

pranon dhe i’a kthen me nje segment te vogel TCP, dhe perfundimisht, klienti e pranon kthimin

nga serveri. Dy pjeset e para te (three-way-handshake) bejne nje RTT.

Pas kompletimit te dy pjeseve te para te hand-shake, klienti e dergon kerkesen HTTP te

kombinuar me pjesen e tret te three-way-handashake (e pranon) ne lidhjen TCP. Njehere

mesazhi kerkues arrin te serveri, serveri e dergon fajllin HTML ne lidhjen TCP. Kjo

kerkes/pranese HTTP eshte nje tjeter RTT. Keshtu qe afersisht koha totale e pergjigijes eshte dy

RTT plus koha transmetuese te serveri i fajllit HTML.

Figura 2.7 Kalkulimi i kthimit te zarfit per kohen qe i nevojitet per te kerkuar dhe pranuar nje

HTML file

HTTP me lidhje te qendrueshme




Faqe 19

Lidhjet e pa qendrueshme kan disa mangesi. Ne fillm nje model i ri i lidhjes duhet te vendoset

dhe te mbaj per secilin objekt te kerkuar. Per secilen nga keto lidhje amortizimet e TCP duhet te

mblidhen dhe ndryshoret e TCP duhet te mbahen te klienti dhe serveri. Kjo mund te barte nje

barre ne Web server, e cila mund te sherben si kerkes nga qindra klient te ndyshem njekohesisht.

Se dyti, sic e pershkruam, secili objekt shperndan nje kerkes te te dy RTT, njeri RTT qe e

krijone lidhjen TCP dhe tjetri RTT te kerkon dhe pranon nje objekt.Me lidhje te qendrueshme,

serveri e len lidhjen TCP te hapur pas dergimit te mesazhit. Kerkesa dhe pergjigjia pasuesendermjet klientit dhe serverit mund te dergohet ne lidhjen e njejt. Vecanerishte, nje Web faqe

komplet(ne shembullin e mesiperm, me baze HTML fajll dhe 10 imazhe) mund te dergohet

neper nje lidhje TCP te qendrueshme. Me teper, shume Web faqe gjenden ne te njejtin server qe

mund te dergohen nga serveri te klienti i njejt neper nje lidhje TCP te qendrueshme. Keto

kerkesa per objekte mund te behen (back-to-back) pa pritje per rikthime per te pritur

kerkesen(pipelining). Ne menyre tipike HTTP serveri e mbyll nje lidhje kur ajo nuk perdoret per

nje koh te gjate(a configurable timeour interval). Kur serveri e pranon kerkesen(back-to-back) ,

ai e dergon objektin (back-to-back). Menyra e konfiguruar HTTP perdor lidhje te qendrueshme

ne linje gypore. Ne do ta krahasojme ne menyr sasiore performacen e lidhjeve jo te

qendrueshme dhe lidhjeve te qendrueshme ne problemet e detyrave te shtepis ne Kapitullin 2dhe 3.

2.2.3 Formati i HTTP mesazhit

Specifikimet e HTTP-së [RFC 2616] përfshijnë definimet e formateve të HTTP mesazhit.Ka dy

tipe te HTTP mesazheve,mesazhet kërkuese dhe përgjigjëse,të dyja prej të cilave janë të

diskutuara më poshtë.

HTTP mesazhet kërkuese

Më poshtë kemi paraqitur një HTTP mesazh tipik kërkues :

GET /somedir/page.html HTTP/1.1

Host: www.aomeschool.edu

Connection: close

User-agent: Mozilla/4.0

Accept-language: fr

Ne mund të mësojmë shumë nga vështrimi i këtij mesazhi të thjeshtë kërkues.Së pari mund të

shohim që mesazhi është i shkruajtur me një tekst të zakonshëm ASCII ashtu që qenia njerëzore

që ka njohuri rreth kompjuterit mund ta lexojë atë.Së dyti,shohim që mesazhi përbëhet prej pesë

rreshtave,secili i shoqëruar nga një rresht pasues.Rreshti i fundit është i shoqëruar nga një

mbartje shtesë kthyese dhe një rresht pasues.Edhe pse ky mesazh i veçantë kërkues ka pesë

rreshta,një mesazh kërkues mund të ketë shumë më shumë rreshta ose më pak vetëm një

rresht.Rreshti i parë i HTTP mesazhit kërkues

http://www.aomeschool.edu/






Faqe 20

quhet rreshti kërkues;rreshtat pasues quhen rreshtat e header-it(kokës).Rreshti kërkues ka 3

fusha:fusha e metodës,fusha e URL-së dhe fusha e versionit të HTTP-së.Fusha e metodës mund

të marrë vlera të ndryshme,duke përfshirë GET,POST,HEAD,PUT dhe DELETE.Shumica e

mesazhave kërkuese të HTTP-së përdorin metodën GET.Metoda GET përdoret kur browser-i

(shfletuesi) kërkon një objekt,me objektin e kërkuar identifikohet në fushën e URL.Në këtë

shembull,browser-i kërkon objektin /somedir/page.html.Versioni është i dukshëm,në këtëshembull browser-i implementon versionin HTTP/1.1.

Tani le të shohim rreshtat e header-it në shembull.Rreshti i header-it Host:

www.someschool.edu specifikon host-in në të cilin objekti qëndron.Ju mund të mendoni që ky

rresht i header-it është i panevojshëm,meqë tashmë ka një TCP lidhje nga vendi në host.Por siç

do të shohim në pjesën 2.2.5,informacioni i dhënë nga rreshti i header-it host është i kërkuar nga

Web proxy cache-et.

Duke e përfshirë rreshtin e header-it Connection: close,browser-i i tregon serverit që nuk

dëshiron të ngacmohet me lidhjet e vazhdueshme;ai dëshiron që serveri të mbyll lidhjen pasi të

jetë dërguar objekti i këkuar.Rreshti i header-it User-agent: specifikon mjetin përdorues(agjentin

përdorues),që është ,tip i browser-it i cili bën kërkesën në server.Këtu mjeti përdorues është

Mozilla/4.0,browser i Netscape-it.Ky rresht i header-it është i dobishëm,pasi që serveri mund të

dërgojë versione të ndryshme të të njejtit objekt në tipe të ndryshme të mjeteve

përdoruese.(Secili prej versioneve është i adresuar nga e njejta URL.)Rreshti i header-it Accept-

language: tregon që përdoruesi preferon të marr versionin Francez të objektit,nëse një objekt i

tillë ekziston në server;përndryshe,serveri e dërgon versionin e përgjithshëm(default).Headeri

Accept-language: është njëri prej header-ave me përmabjtje negociuese të përdorur në

HTTP.Tani le të shikojmë formatin gjeneral të një mesazhi kërkues të treguar në Figurën

2.8.Shohim që formati gjeneral i përafrohet shembullit të mëparshëm.Ju ndoshta keni

vërejtur,megjithatë, që pas rreshtave të header-it ka një “entitet të trupit”. Entiteti i trupit është i

zbrazët me metodën GET,por përodret me metodën POST.Një HTTP klient shpesh përdor

metodën POST kur përdoruesi zgjeron një formë- për shembull,kur përdoruesi kërkon fjalët në

një makinë kërkuese.Me një mesazh POST,përdoruesi ende kërkon një Web page prej

serverit,por përmabajtja specifike e Web page varet nga çka përodoruesi shkruan në fushat e

formës.




Faqe 21

Figura 2.8 Formati gjeneral i një HTTP mesazhi kërkues

Nëse vlera e fushës së metodës është POST,atëherë entiteti i trupit përmban çka përdoruesi

vendos në fushat e formës.Do të ishim të pakujdesshëm nëse nuk përmendim që kërkesa e

gjeneruar me një form nuk është e nevojshme të përdor metodën POST.Në vend të kësaj,HTML

format shpesh përdorin metodën GET dhe përfshijnë të dhënat hyrëse(në fushat e formës)në

URL-në e kërkuar.Për shembull,nëse në një formë përdorë metoën GET,ka dy fusha,dhe fyrjet

në të dy fushat janë monkeys &bananas,atëherë URL do ta ketë strukturëns sikur që është

paraqitur më poshtë: www.somesite.com/animalsearch?monkeys&bananas.

Në shërbimet e sotme të Web-it, është e mundur të keni vërejtur URL-të të këtij lloji.

Metoda HEAD është e ngjajshme me metodën GET.Kur serveri pranon një kërkese me

HEAD,përgjigjet me një FTTP mesazh dhe e menjanon objektin e kërkuar.Zhvilluesit e

aplikacioneve shpesh përdorin metodën HEAD për rregullime të gabimeve.Metoda PUT shpesh

është e përdorur në lidhje me veglat publike të Web-it.Ai i lejon përdoruesit të ngarkoj(upload)

një objekt te një shteg specifik në një server të një Web-i specifik.Metoda PUT është përdorur

nga aplikacionet që nevoiten të ngarkojnë objektet në Web servera.Metoda DELETE i lejon

përdoruesit,ose një aplikacioni,të fshijë një objekt në Web server.

HTTP mesazhet përgjigjëse

Më poshtë kemi paraqitur një HTTP mesazh tipik përgjigjës.Ky mesazh përgjigjës mund të ishte

përgjigjja e shembullit të mesazhit kërkues të sapo diskutuar.

HTTP/1.1 200 OK

Connection: close

Date: Set, 07 Jul 2007 12:00:15 GMT

Server: Apache/1.3.0 (Unix)

Last-Modified: Sun,6 May 2007 09:23:24 GMT

Content-Length: 6821

Content-Type: text/html




Faqe 22

(data data data data data ...)

Le ta shikojmë me kujdes këtë nesazh përgjigjës.Ka tri pjesë:një rresht fillestar të

pozitës,gjashtë rreshta të header-it dhe pastaj entiteti i trupit.Entiteti i trupit është mesi i

mesazhit – përmban në vete objektin e kërkuar( i paraqitur me data data data data data

...).Rreshti i pozitës ka tri fusha: fushën e versionit të protokollit,kodin e pozitës dhe pozitën

korresponduese të mesazhit.Në këtë shembull,rreshti i pozitës tregon që serveri përdor HTTP/1.1 dhe që qdo gjë është në rregull OK(kjo do të thotë,serveri e ka gjetur dhe e ka

dërguar objektin e kërkuar).

Tani le ti shqyrtojmë rreshtat e header-it.Serveri përdor rreshtin e header-it Connection: close

për t’i treguar treguar klientit që është duke e mbyllur TCP lidhjen pas dërgimit të

mesazhit.Rreshti i header-it Date: tregon kohën dhe datën kur HTTP përgjigjja është krijuar dhe

dërguar nga serveri.Vëreni që kjo nuk është koha kur objekti është krijuar dhe së fundi është

modifikuar; është koha kur serveri rigjen objektin prej file-it të sistemit të tij,vendos objektin

brenda mesazhit përgjigjës dhe e dërgon mesazhin përgjigjës.Rreshti i header-it Server: tregon

që mesazhi ishte gjeneruar nga Apache Web server; është e ngjajshme me User-agent:rresht i

header-it në HTTP mesazhin kërkues.Rreshti i header-it Last-Modufied:tregon kohën dhe datën

kur objekti ishte krijuar ose së fundi modifikuar.Header-i Last-Modified:të cilin do ta

shqyrtojmë më detajisht, është kritik për keshimin e objektit,për të dy ,klientin lokal dhe rrjetën

e kesh serverave(të njohur si proxy server).Rreshti I header-it Content-Length:tregon numrin e

byte-ve në objektin që është dërguar.Rreshti i header-it Content-Type:tregon që objekti në

entitetin e trupit është HTML tekst.(Tipi i objektit zakonisht është treguar nga header-i Content-

Type dhe jo nga ekstensioni i file-it.)Tani le të saktësojmë formatin gjeneral të një mesazhi

përgjigjës,i cili është treguar në Figurën 2.9.Ky format gjeneral i përshtatet shembullit të

mëparshëm të mesazhit përgjigjës.Le të themi disa fjalë rreth kodit të pozitës dhe shprehjet e

tij.Kodi i statusit dhe shprehja plotësuese tregojnë përfundimin e kërkesës.Disa kode të

zakonshme të pozitës dhe shprehje përfshijnë:

200 OK: Kërkesa dhe informacioni me sukses janë kthyer në përgjigje.

301 Moved Permanently: Objekti i kërkuar ka qenë i bartur për një kohë të gjatë;URL e

re ështëe specifikuar në header-in Location të mesazhit përgjigjës.Klienti i software-it

automatikisht do ta pranojë UTL-në e re.




Faqe 23

Figura 2.9 Formati gjeneral i një HTTP mesazhi përgjigjës

400 Bad Request: Ky ështv një gabim i gjeneruar i kodit duke treguar që kërkesa nuk ka

mundur të kuptohet nga serveri.

404 Not Found: Dokumenti i kërkuar nuk ekziston në këtë server.

505 HTTP Version Not Supported: Versioni i protokollit të kërkuar nuk është i

mbështetur nga serveri.Si do të kuptonit një HTTP mesazh përgjigjës?Ky është një rekomandim i lartë dhe i lehtë për ta

bërë.Së pari Telnet në Web serverin tuaj të preferuar.Pastaj tipi i një rreshti të mesazhit kërkues

për disa objekte që vendosen në server.Për shembull,nëse jeni qasur në command prompt ,tipi:

telnet cis.poly.edu 80

GET/~ross/HTTP/1.1

Host: cis.poly.edu

Kjo paraqet një TCP lidhje në portin 80 të host-it cis.poly.edu dhe pastaj dërgon HTTPmesazhin kërkues.Ju do ta shihni një mesazh

përgjigjës që përfshin HTTP file-in bazë të homepage-it të profesor Ross.Nëse ju vetëm i shihni

rreshtat e HTTP mesazhit dhe nuk pranoni objektin,zëvendësoni GET me HEAD.Në

fund,zëvendësoni /~ross/ with /~banana/ dhe shikoni çfarë lloji të mesazhit përgjigjës merrni.

Në këtë pjesë ne diskutuam një numër të rreshtave të header-it që mund të përdoren në HTTP

mesazhet kërkuese dhe përgjigjëse.HTTP specifikacioni definon shumë më shumë rreshta që

mund të vendosen nga browser-ët,Web serverat dhe serverat e rrjetës cache.Ne kemi shqyrtur

vetëm një numër të vogel të rreshtave të header-it.Do ti shqyrtojmë disa më poshtë dhe një

numër tjetër i tyre do të shqyrtohen në Paragrafin 2.2.5.Diskutimi më gjithpërfshirës dhe më i

lartë,duke përfshirë header-at dhe kodet e pozitës, është dhënë në [Krishnamurty 2001];gjithashtu edhe [Loutonen 1998].

Si vendos browser-i cilët rreshta të header-it të përfshihen në njëmesazh përgjigjës?

Si vendos Web browser-i cilët rreshta të header-it të përfshihen në një mesazh përgjigjës?

Browser-i do të gjenerojë rreshtat e header-it si një funksion i një tipi dhe versioni të browser-it

(për shembull,një HTTP/1.0 browser do të gjenerojë ndonjë rresht të 1.1 header-it),konfigurimi I

përdoruesit të browser-it(për shembull,gjuha e preferuar),dhe nëse browser-i aktualisht ka një

cache-im,por mundet të jetë i vjetruar,versioni i objketit.

Web serverat veprojnë ngjajshëm: Ka prodhime,versione dhe konfigurime të ndryshme,secila

prej tyre ka ndikim cilët rreshta të header-it janë përfshirë në mesazhin përgjigjës.

2.2.4 Interaksioni Përdorues-Server : Cookie-it




Faqe 24

Kemi përmendur më lart se HTTP serveri është pa strukturë.Kjo e thjeshtëson dizajnin e serverit

dhe ka lejuar inxhinierët të zhvillojnë Web server të performansave të larta të cilët mund të

bartin mijëra TCP lidhje në të njejtën kohë.Megjithatë, është e dëshirueshme për një Web site të

identifikojë përdoruesit,pasi që serveri dëshiron të kufizojë çasjen e përdoruesit ose të paraqesë

përmbajtjen si një funksion të identitetit të përdoruesit.Për këto qëllime,HTTP-ja përdor cookie-

it.Cookie-it janë definuar në RFC 2965,i lejojnë site-ve të ruajnë gjurmët e përdoruesve.Shumicae Web site-ve komercial sot përdorin cookie-it.Siq është treguar në Figurën 2.10,teknologjia e

cookie-ve ka 4 komponente: (1) rreshti i një header-i të cookie-it në HTTP mesazhin përgjigjës;

(2) rreshti i një header-i të cookie-it në HTTP mesazhin kërkues; (3) një cookie file i ruajtur në

end system-in e përdoruesit dhe i udhëhequr nga një browser i përdoruesit; (4) një databazë e

fundme në Web site.Duke përdorur Figurën 2.10,le të shqyrtojmë një shembull se si punojnë

cookie-it.Supozoni Suzan,e cila gjithmonë çaset në Web duke përdorur Internet Explorer prej

PC së saj,lidhet në Amazon.com për të parën herë.Le të supozojmë që ajo në të kaluarën ka

vizituar eBay site.Kur kërkesa arrin në Web serverin e Amazon-it,serveri krijon një numër unik

identifikues dhe krijon një hyrje në databazen e tij të fundme që është e indeksuar sipas numrit

identifikues.Web serveri i Amazon-it pastaj i përgjigjet browser-it të Suzan-ës,duke përfshirë në

HTTP përgjigjën header-it Set-cookie: i cili përmban numrin identifikues.Për shembull,rreshti i

header-it mund të jetë:

Set-cookie: 1678

Kur browser-i i Suzanës pranon HTTP mesazhin përgjigjës,e vëren header-in Set-

cookie.Browseri pastaj i bashkangjit një rresht të veçantë file-it të cookie-it që e udhëheq.Ky

rresht përfshin hostname-in e serverit dhe numrin identifikues në header-in Set-cookie.Vërehet

që file i cookie-it tanimë ka një hyrje në eBay,që kur Suzan e kishte vizituar atë site në të

kaluarën.




Faqe 25

Figura 2.10 Ruajtja e gjendjes së përdoruesit me cookie-it

Aq sa Suzan vazhdon të shfletojë Amazon site,çdo herë kur ajo kërkon një Web page,browser-i isaj e konsulton file-in e saj,ekstrakton numrin e saj identifikues për këtë site dhe e vendos një

rresht të header-it të cookie-it që përfshin numrin identifikues në HTTP kërkesën.Më

saktësisht,secila prej HTTP kërkesave të saj në serverin e Amazon-it përfshin rreshtin e header-

it:

Cookie: 1678

Në këtë mënyrë serveri i Amazon-it është në gjendje të gjurmojë aktivitetin e Suzan-vs në

Amazon site.Megjithëse Web site-i Amazon nuk e di domosdo emrin e Suzan-ës,ai e di

saktësisht cilat faqe që përdorin 1678 janë vizituar,në cilën radhë dhe në çfarë kohe! Amazon përdor cookie-it për të pajisur shërbimin e tij të kartelës së blerjes – Amazon mund të ruajë

listën e të gjitha blerjeve të caktuara të Suzanës,ashtu që ajo të mund të paguaj për to

kolektivisht në fund të një sesioni.

Nëse Suzana viziton site-in e Amazon-it,të të themi,një javë më vonëbrowser-i i saj do të

vazhdojë të vendos rreshtin e header-it Cookie: 1678 në mesazhin kërkues.Amazon gjithashtu i

rekomandon Suzanës produktet duke u bazuar në Web faqet që ajo i ka vizituar në të

kaluarën.Nëse Suzan gjithashtu regjistrohet në Amazon-duke dhënë emrin




Faqe 26

e plotë,e-mail,adresën,adresën postale dhe informacionin e kredit kartelës- atëherë Amazoni

mund ta përfshijë këtë informatë në databazën e tij,në lidhje me emrin e Suzan-ës dhe me

numrin identifikues të saj(dhe të gjitha faqet që ajo ka vizituar në të kaluarën!).Kjo është se si

Amazon-i dhe site-at tjerë e-commerce paraqesin “one-click shoping”-kur Suzan zgjedh të blejë

ndonjë artikull gjatë vizitës pasuese,ajo nuk ka nevojë të rishkruaj emrin e sa,numrin e kreditkartelës ose adresën.

Prej këti diskutimi shohim që cookie-it mund të përdoren për të identifikuar përdoruesin.

Për të parën herë që përdoruesi viziton një site,përdoruesi mund të ketë një identifikues(mund të

jetë emri i tij).Gjatë sesioneve të ardhshme,browser-i e vendos header-in e cookie-it në

server,duke e identifikuar përdoruesin në server. Kështu cookie-it mund të përdoren për të

krijuar një shtresë të sesionit të përdoruesit sipër HTTP-së.Për shembull,kur përdoruesi kyçet në

një Web aplikacion të bazuar në(siq është Hotmail),dërgon informacionin e cookie-it në

server,duke i lejuar serverit të identifikojë përdoruesin përgjatë sesionit të përdoruesit me

aplikacionin.

Megjithëse cookie-it shpesh i thjeshtësojnë eksperiencën e Internet blerjes për përdoruesin,ato

janë të diskutueshme pasi që mund të konsiderohen si ndërhyrje e privatësisë.Siq pamë,duke

përdorur një kombinim të cookie-ive dhe informacionit mbi llogarinë(account) e

përdoruesit,Web site mund të marr informacione të shumta rreth përdoruesit dhe e reklamon

këtë informacion.Cookie Central [Cookie Central 2008] përfshin informacion gjithpërfshirës në

diskutimin e cookie-it.

2.2.5 Web Caching

Një Web cache – gjithashtu e njohur si server proksi – ështe një njësi rrjeti që plotëson kërkesat

e HTTP si përfaqsues e nje Web serveri origjinues. Web cache ka hapësirën e vet të ruajtjes dhe

mban kopje të objekteve më të vonshme të kërkuara në këtë hapësirë ruajtjeje. Siç shihet në

figurën 2.11, shfletuesi (browser) i përdoruesit mund të konfigurohet në mënyrë që të gjitha

kërkesat HTTP të përdoruesit së pari ti drejtohen Web cache-it. Për shembull, supozojmë se

shfletuesi kërkon objektin http://www.someschool.edu/campus.gif. Ja çfarë ndodh:

1. Shfletuesi i vendos Web cache-it një lidhje TCP dhe i dërgon Web cache-it një kërkesë

HTTP për objektin.




Faqe 27

Figura 2.11 Klienti kërkon objektet përmes Web cache

2. Web cache-i kontrollon nëse ka ndonjë kopje të objektit të ruajtur lokalisht. Nëse e ka,

Web cache-i i kthen shfletuesit te klientit objektin brenda një mesazhi përgjegjës HTTP.3. Nëse Web cache-i nuk e ka objektin, Web cache-i e hap një lidhje TCP me serverin

origjinues, që ështe, ëëë.someschool.edu. Më pas Web cache-i dërgon një kërkesë HTTP për

objektin kundrejt lidhjes TCP cache-to-server. Pas marrjes së kërkesës, serveri origjinues i

dërgon Web cache-it objektin brenda një përgjigjeje HTTP.

4. Kur Web cache-i e merr objektin, e ruan një kopje në hapësirën e vet lokale të ruajtjes

dhe ia dërgon një kopje, brenda një mesazhi përgjegjës HTTP, klientit shfletues (në lidhjen

ekzistuese TCP ndërmjet klientit shfletues dhe Web cache-it).

Duhet pasur parasysh që Web cache-i është server dhe klient në të njejtën kohë. Kur merr

kërkesë nga shfletuesi dhe kur i dërgon përgjigje shfetuesit, është server. Kur i dërgon kërkesë

serverit origjinues dhe kur merr përgjigje nga serveri origjinues, ështe klient.Në mënyrë tipike

Web cache-i merret dhe instalohet nga një ISP. Për shembull, një universitet mund të instalojë

një cache në rrjetin e vet të kompjuterave të kampusit dhe ti konfigurojë të gjithë shfletuesit që ti

drejtohen një cache-i. Ose një ISP kryesor rezidencial (siç është AOL) mund ti instalojë një apo

më shumë cache-a rrjetit të vet, dhe ti parakonfigurojë shfletuesit e vet të dërguar që ti drejtohen

cache-ve të instaluar.Web caching është pozicionuar mirë në Internet për dy arsye. E para, një

Web cache mund ta zvogëlojë substancialisht kohën e përgjigjes ndaj një kërkese klienti,

veçanërisht nëse ngadalësimi i bandwidthit mes klientit dhe serverit origjinues është shumë më i

vogël se ngadalësimi i bandwidthit mes klientit dhe cache-it, siç është shpesh, dhe nëse cache-i e

ka objektin e kërkuar, atëherë cache-i do të mund t’ia dorëzojë shumë shpejtë objektin klientit. E

dyta, siç do ta ilustrojmë me një shembull, Web cache-at mund ta ulin substancialisht trafikun në

kyqjen e një institucioni në Internet.




Faqe 28

Figura 2.12 Bottleneck në mes rrejte institucionale dhe Interneti

Me uljen e trafikut, institucioni (për shembull, një kompani apo universitet) nuk do ta ketë të

nevojshme ta modernizojë bandwidthin aq shpejtë, kështuqë ulen harxhimet. Për më shumë,

Web cache-at mund ta ulin substancialisht trafikun e Rrjetit në Internet si të tërë, duke

përmirësuar performancën për të gjitha aplikacionet.Për të përfituar njohuri edhe më të thella

mbi përfitimet nga cache-t, ta marrim në konsideratë një shembull në kontekstin e Figurës 2.12.

Kjo figurë tregon dy rrjeta kompjuterësh - rrjetin institucional dhe pjesën tjetër të Internetit publik. Rrjeti institucional është një LAN me shpejtësi të lartë. Një router në rrjetin institucional

dhe një router në Internet janë të lidhur me një lidhje 15 Mbps. Serverat origjinues janë të kyqur

në Internet por janë të lokalizuar në gjithë globin. Supozojmë që mesatarja e madhësisë së

objektit është 1 Mbits dhe që mesatarja e raportit të kërkesës nga shfletuesit e institucioneve

ndaj serverave origjinues është 15 kërkesa për sekond. Supozojmë që mesazhet kërkues HTTP

janë shumë të vegjël për tu marrë parasyshë dhe nuk krijojnë trafik në rrjete apo në lidhje hyrëse

(nga routeri institucional tek routeri Internetit). Gjithashtu supozojmë që sasia e kohës që merret

prej kur routeri në anën e Internetit të lidhjes hyrëse në Figurën 2.12 shtyen para një kërkesë

HTTP (brenda datagramit të IP) deri kur ai merr përgjigje (tipikisht brenda shumë datagramësh

të IP) është mesatarisht dy sekonda. Jo formalisht, në i referohemi kësaj vonesës së fundit si“vonesë Interneti.”

Koha e përgjithshme e përgjigjes – që është, koha prej parashtrimit të kërkesës nga shfletuesi

për një objekt deri kur ai pranon objektin – është shuma e vonesës së LAN-it, vonesës së hyrjes

(që është, vonesa në mes dy routerave), dhe vonesës së Internetit. Tani ta bëjmë një kalkulim të

papërpunuar për ta llogaritur këtë vonesë. Intensiteti i trafikut në LAN (shif Seksionin 1.4.2)

është




Faqe 29

(15 kërkesa/sekond)*(1 Mbits/kërkesë)/(100 Mbps)=0.15

ndërsa intensiteti i trafikut në lidhjen hyrëse (nga routeri Internetit deri te routeri institucionit)

është

(15 kërkesa/sekond)*(1 Mbits/kërkesë)/(15 Mbps)=1

Një intensitet trafiku prej 0.15 në LAN zakonisht rezulton në, më së shumti, dhjetra milisekondavonesë; kështu që, mund ta neglizhojmë vonesën e LAN-it. Megjithatë, siç është diskutuar në

Seksionin 1.4.2, përderisa intensiteti i trafikut i afrohet 1-shit (si në rastin e lidhjes hyrëse në

figurën 2.12), vonesa në lidhje bëhet shumë e madhe dhe rritet pa kufi. Pra, mesatarja e kohës së

përgjigjes që kënaq kërkesat do të jetë në përmasa minutash, nëse jo më shumë, gjë që është e

papranueshme për përdoruesin e institucionit. Duket qartë që diçka duhet të ndërmirret.

Një zgjidhje e mundshme është që të rritet niveli i kyqjes nga 15 Mbps në, për shembull, 100

Mbps. Kjo do ta ulte intensitetin e trafikut në lidhjen hyrëse në 0.15, që rezulton në vonesa të

neglizhueshme në mes dy routerave. Në këtë rast, koha e përgjithshme e përgjigjes do të jetë

përafërsisht dy sekonda, që ëshë, vonesa e Internetit.Por kjo zgjedhje gjithashtu do të thotë që

institucioni duhet ta rrisë lidhjen hyrëse nga 15 Mbps në 100 Mbps, që është një propozim ikushtueshëm.

Tani marrim parasysh zgjedhjen alternative të mos rritjes së lidhjes hyrëse por në vend të saj

instalimin e një Web cache-i në rrjetin e institucionit. Kjo zgjedhje është e ilustruar në Figurën

2.13. Shkalla e goditjes – fraksioni i kërkesave që janë të plotësuara nga cache-i – tipikisht

shtrihet nga 0.2 deri në 0.7 në praktikë. Për qëllime ilustrative, të supozojmë që cache-i furnizon

një shkallë goditjeje prej 0.4 për këtë institucion. Meqë klientet dhe cache-i janë të kyqur në të

njejtin LAN me shpejtësi të lartë, 40 përqind të kërkesave do të plotësohen gati menjëherë, të

themi, brenda 10 milisekondash, nga cache-i. Prapëseprapë, 60 përqind e kërkesave të mbetura

duhet të plotësohen nga serverat origjinues. Por me vetëm 60 përqind të objekteve të kërkuar që

kalojnë nëpër lidhjen hyrëse, intensiteti i trafikut në lidhjen hyrëse zvogëlohet nga 1.0 në 0.6.

Tipikisht, një intensitet trafiku më i vogël se 0.8 i përkon një vonese të vogël, të themi, dhjetra

milisekonda, në një lidhje 15 Mbps. Kjo vonesë është e neglizhueshme në krahasim me vonesën

dy-sekondëshe te vonesës së Internetit. Duke marrur këto në parasysh, mesatarja e vonesës është

0.4*(0.01 sekonda) + 0.6 * (2.01 sekonda)

që është shumë pak më e vogël se 1.2 sekonda.




Faqe 30

Figura.2.13 Vendosja e cache-it në rrjetën institucionale

Kështuqë, zgjidhja e dytë paraqet një kohë përgjigjeje edhe më të vogël se zgjidhja e parë, dhe

nuk ia imponon institucionit ta rrisë lidhjen në Internet. Kjo zgjidhje duhet, normalisht, të blej

dhe të instalojë një Web cache. Por kjo kosto është e ulët – shumë cache përdorin softvere me

domaine publike që funksionojnë në kompjutera të lirë.

2.2.6 The Conditional GET (Kushti MERR)

Megjithëse caching mund të zvogloj user-perceived (shfletuesin e përceptuar ) në përgjigjje në

kohë,kjo paraqet një problem të ri-kopje e një objekti që jeton në cache të ndenjur.Me fjalë të

tjera,objekt të vendosur në Web server mund të ket qenë ndrryshuar që nga kopja që është kopje

e ruajtur në të klientit.Për fat të mirë,HTTP ka një mekanizëm që lejon cache për të verifikuar

objektet e saj që janë deri më tani.Ky mekanizëm është quajtur kushti GET.Një mesazh kërkesë

HTTP është një mesazh i ashtu-quajtur kushti MERR në qoftë se (1) mesazh kërkesa përdor

metoda GET dhe (2) mesazh kërkesa përmban një rast të ndrryshuar që nga :header line (linja në

krye).Për ta ilustruar se si kushti GET vepron,le të marrim një shembull.Së pari në emër të një

browser (shfletues kërkues),një proxy(përfaqësues)dërgon një mesazh kërkes në një server në

Web:

GET /fruit/kiwi.gif HTTP/1.1

Host: www.exotiquecuisine.com

Së dyti,Web server dërgon një mesazh përgjigje me objekt të kërkuar në cache:

http://www.exotiquecuisine.com/






Faqe 31

HTTP/1.1 200 OK

Date: Sat, 7 Jul 2007 15:39:29


Last-Modified: Wed, 4 Jul 2007 09:23:24

Content-Type: image/gif

(data data data data data ...)

Cache e përciell objektin te shfletues kërkuesi por gjithashtu edhe në arkën e objektit në

nivelin lokal.E rëndësishmja ,cache në datën e fundit të ndryshuar vjen së bashku me objekt në

dyqane.E treta,një javë më vonë,një tjetër browser kërkon të njëjtin objekt me anë të cache,dhe

objekti është ende në cache.Që nga atëhetë ky objekt mund të ket qenë ndryshuar në Web server

në javën e fundit, cache kryen nje up-to-date kontrollë duke lëshuar një kusht GET. Në mënyrë

të veçantë, cache dërgon:

GET /fruit/kiwi.gif HTTP/1.1

Host: www.exotiquecuisine.com

If-modified-since: Wed, 4 Jul 2007 09:23:24

Vini re se vlera nëse ka ndryshuar që nga:header line është saktësisht e barabartë me vlerën e

fundit të ndryshuar:header line që është dërguar nga serveri një javë më pare.Ky kusht GET

është thënë në server për të dërguar objektin vetëm nëse objekti është ndryshuar që nga data e

cekur . Supozoni se objekti nuk ka qenë ndryshuar që nga 4 korrik, 2007 09:23:24.Atëherë, i

katërti, Web serveri dërgon një përgjigje mesazh cache:

HTTP/1.1 304 Not Modified

Date: Sat, 14 Jul 2007 15:39:29


(empty entity body)

Ne shohim që në përgjigje të kushtit GET ,Web serveri dërgon edhe një mesazh përgjigje,por

nuk përfshin ne kërkim objektin në mesazh përgjigje.Duke përfshir objektin e kërkuar vetem

gjërsin e humbur dhe e rrite përgjigjen në kohë të user-perceived, veçanërisht nëse objekti

është i madh. Vini re se kjo përgjigje e fundit e mesazhit ka 304 jo ndryshime ne statusin e

linës, e cila i tregon cache-it se ajo mund të shkojë përpara dhe para saj kopje (cache proxy-së) e

objektit të browser-it.Kjo përfundon diskutimin ton të HTTP,protokolli i parë Internet(një

kërkes-protokoll shtesë) që ne i kemi studiuar në detaje. Ne kemi parë format të mesazheve

HTTP dhe veprimet e marra nga klienti Web dhe server si këto mesazhe janë dërguar dhe

pranuar. Ne kemi studiuar edhe pak nga infrastruktura Web-it aplikimit, duke përfshirë edhe

sasi, cookies, dhe prap në fund bazat e të dhënave, të gjitha të cilat janë të lidhura në një farë

mënyre për protokollin HTTP.




Faqe 32

2.3 File Transfer: FTP

Në një seancë tipike FTP, shfrytëzuesi është i ulur para nje host (host lokale) dhe dëshiron të

transferoj file për të ose nga një host në distancë. Me qëllim për përdoruesin për të hyrë në

llogari të largët, përdoruesi duhet të sigurojë një identifikim të përdoruesit dhe njëfjalëkalim(user identification and a password).Pas sigurimit të autorizimit të

informacionit,perdoruesi mund te transferoj file nga file të sistemit vendor në sistemin e file-ve

në distancë dhe anasjelltas.Siç shihet në figura 2.14, përdoruesi ndërvepron me FTP përmes një

agjent përdorues FTP. Përdoruesit të parë i ofron hostname-in e host-it ne distanc,duke bërë që

procesi FTP klient në host lokal për të vendosur një TCP lidhje me procesin e serverit FTP ne

host ne distanc.Përdoruesi më pas ofron identifikimin e përdoruesit dhe fjalëkalimin,të cilat janë

dërguar në lidhje me lidhje TCP si pjesë e komandave FTP. Pasi serveri ka autorizuar

përdoruesin, kopjet e perdoruesit një ose më shumë file të ruhet në sistemin file lokal në sistem

file në distanc (ose anasjelltas). HTTP dhe FTP janë dy protokoll file transfer dhe kanë shumë

karakteristika të përbashkëta;për shembull, ata të dy të kandidojë në krye të TCP. Megjithatë, të

dy-aplikojnë shtresa protokolle që kanë dallime të rëndësishme.

Figura 2.14 FTP lëviz file-të në mes të sistemeve file lokal dhe në distancë

Figura 2.15 Kontrolli dhe lidhjet e të dhënave

Dallimi më i spikatur është që FTP përdor dy lidhje paralele TCP për të transferuar një file, një

lidhje e kontrollit dhe një lidhje të dhënave. Lidhja e kontrollit është përdorur për të dërguar

informacion të kontrollit midis dy host-informacionit të tillë si identifikimi user, password,

urdhëron për ndryshim directory në distancë, dhe urdhëron për "të vënë" dhe të "marrë" files.

Lidhja e të dhënave është përdorur në fakt dërgoni një file. Sepse FTP përdor një lidhje të




Faqe 33

veçantë të kontrollit,FTP është e thënë që të dërgojë informacionin e saj të kontrollit nga-e-band.

Në kapitullin 7 ne do të shohim se protokolli RTSP,e cila është përdorur për kontrollin

transferimin e mediave të vazhdueshme të tilla si audio dhe video, gjithashtu dërgon

informacion të saj të kontrollit nga-e-band.HTTP, siç ju kujtohet, dërgon kërkesën dhe linjat

header përgjigje në të njëjtën lidhje TCP që mbart transfer file në vetvete. Për këtë arsye, HTTP

është e thënë që të dërgojë informacionin e saj të kontrollit në grup.Në seksionin e ardhshëm ne

do të shohim se SMTP, protokoll kryesore për postën elektronike, gjithashtu dërgon informacionnë kontroll-band. lidhjet e kontrollit FTP dhe të dhënat janë ilustruar në figurën 2.15.

Kur një user fillon një seancë FTP me një mori distancë, në anën e klientit e FTP(user) fillon të

parë një lidhje TCP kontroll me anën e serverit (host në distancë) në port server numër 21. Ana e

klientit të FTP dërgon identifikimi e përdoruesit dhe fjalëkalimi mbi këtë lidhje të kontrollit.

Ana e klientit e FTP gjithashtu dërgon, mbi lidhje të kontrollit, komanda për të ndryshuar dosjen

në distancë. Kur ana e serverit merr një urdhër për një transferim file mbi lidhjen e kontrollit

(ose për të, ose nga, host në distancë), ana server fillon një lidhje të dhënave TCP në anën e

klientit. FTP dërgon një file pikërisht mbi lidhjen e të dhënave dhe pastaj mbyllet lidhjen e të

dhënave. Nëse, gjatë seancës së njëjtë, user dëshiron të transferojë një tjetër file, FTP hap një

tjetër lidhje të dhënave. Kështu, me FTP, lidhja e kontrollit të mbetet e hapur gjatë gjithëkohëzgjatjes së seancës së user, por një lidhje e re të dhënave është krijuar për çdo file

transferohet brenda një seancë (që është, lidhjet e të dhënave janë jo-të vazhdueshme).

Gjatë një seancë, serveri FTP duhet të mbajë shtetin ne lidhje me user. Në

veçanti, serveri duhet të shoqëroj lidhje të kontrollit me një llogari user të veçantë,

dhe serveri duhet të vazhdojë rrugën e dosjes aktuale të përdoruesit si endet user

në lidhje me pemët në distancë dosjen. Mbajtja të këtij informacioni të shtetit për çdo

seancë të vazhdueshme të konsiderueshme user kufizon numrin e përgjithshëm të seancave që

FTP mund të mbajë në të njëjtën kohë. Kujtojnë se HTTP, në anën tjetër, është pa shtetësi-it nuk

duhet të mbajnë gjurmët e ndonjë user-i të shtetit.

2.3.1 FTP Komandat dhe Përgjigjet

Ne fund këtë seksion me një diskutim të shkurtër të disa nga komandat FTP më të zakonshme

dhe përgjigjet.Komanda, nga klienti në serveri, dhe pergjigjet, nga serveri të klientit,janë

dërguar në të gjithë lidhje e kontrollit në formatin 7-bit ASCII.Kështu, si komanda HTTP,FTP

komanda janë të lexueshëm nga njerëzit.

Në mënyrë që të përcaktojë komanda të njëpasnjëshme e një kthim transporti dhe të ushqyerit e

linjës në fund të çdo komande. Çdo komandë përbëhet nga katër karaktere ASCII kapitale, disa

me argumente fakultative. Disa të komanda më të zakonshme janë dhënë më poshtë:

• USER username: Përdoret për të dërguar identifikimin e përdoruesit në server.

• PASS password: Përdoret për të dërguar fjalkalimin e përdoruesit në server.

• LIST: Përdoret për të pyetur serverin për të dërguar të të gjithë file-ve në dosjen aktuale në

distancë.Listën e disjeve të dërguara më shumë se një (të ri dhe jo të vazhdueshëm) lidhjen e të

dhënave më tepër se sa TCP lidhjen e kontrrollit.




Faqe 34

• RETR filename: Përdoret për të marrë (që është,marrë)një file nga lis ta aktuale e host-it në

distancë.Kjo komand shkakton host në distancë për të nisur një lidhje të dhënave dhe për të

dërguar file-in e kërkuar pë lidhjen e të dhënave.

• STOR filename: Përdoret për të ruajtur (që është,vendosë) një file në dosjen aktuale të host-it

në distancë.

Ekziston zakonisht nje një-për-një korrespondencë mes komandës që çështjet e user dhe tëkomande FTP ta dërgoi në të gjithë lidhjen e kontrollit. Çdo komande është pasuar nga një

përgjigje, ta dërgoi nga serveri te klienti. përgjigjet janë numra me tre shifra, me një mesazh të

mundshëm pas numrit. Kjo është e ngjashme në strukturë me kodin e statusit dhe shprehjen në

linjë statusin e mesazhit përgjigje HTTP. Disa përgjigjet tipike, së bashku me mesazhet e tyre të

mundshme, janë si vijon:

• 331 Username OK, password required(Emri i përdoruesit OK, fjalekalimin kërkohet)

• 125 Data connection already open; transfer starting(Lidhjen Data tashmë të hapur, duke filluar

transferimi)

• 425 Can't open data connection(Nuk mund të hapen te dhënat në lidhje)

• 452 Error writing file(Gabim gjatë shkrimit të file)

Lexuesit që janë të interesuar për të mësuar në lidhje me komanda tjera FTP dhe përgjigjet janë

të inkurajuar për të lexuar RFC 959.

2.4 Posta elektronike në interent

Posta elektronike ka fillu të përdoret që nga fillimi i internetit. Ishte aplikacioni më i përhapur

kur interneti ishte në fillimet e tij [Segaller 1998], dhe vazhdonte të bëhej gjithnjë e më i

përpunuar dhe më i fuqishëm. Mbetet një nga aplikacionet më të rëndësishme dhe më të

përdorura të internetit.Ashtu si me postë të zakonshme postare, e-mail është një medium i

komunikimit asinkron - ku njerëzit dërgojn dhe lexojn mesazhet kur janë të përshtatshme për ta,

pa pasur nevojë ti koordinojnë me modelet e njerëzve të tjerë. Ndryshe nga adresat postare,

posta elektronike është e shpejtë, e lehtë për tu shpërndarë dhe e lirë. E-mail-at kohor kanë

shumë veҫori të fuqishme. Duke përdorur listat e kontakteve , e-mail dhe spam mund të

dërgohenë te mijëra marrës përnjëherë. E-mail-at kohor shpesh përfshijnë të bashkëngjitur

hyperlinqe, tekste HTML të formatuar, dhe fotografi.

Në këtë seksion ne do të shqyrtojmë aplikacionet-protokollet që janë pjesët kryesore të e-mail-

ev. Para se të hyme në diskutim të thellë për këto protokolle le të marrim një pikëpamje të

nivelit të lartë, të përgjithësuar, për sistemin e adresave në internet që është një komponentë

kryesore. Figura 2.16 paraqet një pamje të nivelit të lartë të sistemit të adresave. Nga ky diagram

ne shohim se ai ka tre komponente kryesore:agjent përdoruesin(user agents), mail serverin (mail

servers) dhe çelësin:




Faqe 35

çelësin:

Figura 2.16 një pamje e nivelit të lartë e sistemit të e-mail të internetit

Simple Mail Transfer Protocol (SMTP). Ne tani do të përshkruajmë secilën nga këto

komponentë në kontekstin e një dërguesi, Alice, që dërgon një mesazh e-mail për pranuesin

Bob. Agjentët përdorues ju lejojnë përdoruesve të lexojnë, të përgjigjen për të, të ruajnë, dhe

të krijojnë mesazhe. (Agjentët përdorues për postë elektronike nganjëherë quhen lexues të

maileve (mail readers ), edhe pse ne në përgjithësi në këtë libër i jemi shmangur këti termi.) Kur Alice ka mbaruar kompozimin e mesazhit të saj, agjent përdoruesi i saj dërgoi mesazhe te mail

serveri i saj, ku mesazhi është vendos në mail serverin e mesazheve tw ruajtura. Kur Bob

dëshiron të lexojë një mesazh, agjent përdoruesi i i tij rinxjerr mesazhin nga kutia postare në

mail serverin e tij. Në fund të 1990-ës, “Graphical User Interface “(GUI) agjentët përdoruesë

bëhenë të famshëm, duke i lejuar përdoruesit të shiqojnë dhe kompozojnë mesazhe

multimediale . Aktualisht, Microsoft Outlook, Apple Mail dhe Mozilla Thunderbird janë ndër

agjentët përdorues GUI më të popullarizuarë për e-mail.

Rast historik

Web e-mail Në dhjetor 1995, vetëm disa vjet pas Web-i është "shpikur", Sabeer Bhatia dhe Jack Smith

vizituanë një ndërmarrje kapitaliste interneti Draper Fisher Jurvetson dhe propozuanë

zhvillimin e një Ëeb sistemi të lirë për e-mail. ideja ishte për të dhënë e-mail adresë të lirë për

të gjithë ata që dëshironin një, dhe për të bërë këto e-mail adresa të arritshme nga ëeb-i. Në

ndryshim për 15 përqind të kompanisë, Draper Fisher Jurvetson financoi Bahtia dhe Smith, të

cilët formuan një kompani të quajtur Hotmail. Me 3 njerëz




Faqe 36

që punonin me orar të plotë dhe 14 njerëz me orar të pjesshëm, të cilët punuanë për mundësitë

e aksioneve. Ata ishin në gjendje të zhvillojnë dhe të nisin shërbimin në korrik 1996. Një muaj

pas nisjes, ata kishin 100.000 abonentë. Në dhjetor 1997, më pak se 18 muaj pas fillimit të

shërbimit, hotmail kishte mbi 12 milionë abonentë, që ishin siguruar nga Microsoft, përfolet

për rreth 400 million $. Suksesi i hotmail-it i atribuohet shpesh "Avantazhi të parë- lëvizës"

dhe të brendshëm "marketing viral" e-mail. (Ndoshta disa prej studentëve duke lexuar këtë libër do të jetë në mesin ndërrmarrësve të rinj të cilët krijojnë dhe zhvillojnëe shërbime të internetit

me “ internet marketing viral”.)

Web e-mail vazhdojn të lulëzojë, duke u bërë më i sofistikuar dhe më i fuqishëm për cdo vitë.

Një prej shërbimeve më të popullarizuara sot është Gmail , e cila ofron gigabajt të ruajtjes të

lirë dhe zbulimin e virusit, enkriptimin e e-mail të zgjedhur (duke përdorur SSL), mail tërheqës

nga pala e tretë e serverit të e-mail, dhe një kërkim – orientuar interface.

Mail serverët nga thelbi i infrastrukturës të e-mail. Çdo pranues, si është Bob, ka një kuti

postare që është e vendosurë në një nga mail serverët. Kutia postare(mailbox) e Bobit e

menaxhon dhe ruan mesazhet që janë dërguar për të. Mesazhi tipik fillon udhëtimin te agjent

përdoruesi i dërguesit , udhëton për në mail server të dërguesit , dhe pastaj në mail server të

marrësit, ku është ruajtur në kutinë postara(mailbox). Kur Bobi dëshiron të përdor mesazhet në

kutinë e tij, mail serveri që përmban kutinë e tij identifikon Bobin (me username dhe passëord).

Mail server i Alice duhet të merret me dështimet në mail serverin e Bobit. Në ҫoftë se ser veri i

Alice nuk mund të dorëzojë mail tek serveri i Bobit, serveri Alice mban mesazhin në një radhë

të mesazheve( Drafts) dhe përpiҫet të dërgojë mesazhin më vonë. Reattempts shpesh kryhen

çdo 30 minuta apo më shumë: nëse nuk ka sukses pas disa ditësh, serveri heq mesazhin dhe

njofton dërguesin (Alice) me një e-mail.SMTP është një aplikacion parësor , protokoll për postë

elektronike. Përdorë shërbim të besueshëm për transferim të të dhënave TCP nga mail serveri

i dërguesit tek mail serveri i pranuesit. Si shumë aplikacione-layer Protokolli SMTP ka dy anë:

ana e klientit, e cila ekzekuton mail serverin e dërguesit, dhe ana e serverit, që ekzekuton mail

serverin e marrësit. Edhe ana e klientit edhe e serverit të SMTP kandidojë në çdo mail server.

Kur një server dërgon mail në serverat e tjerë, ai vepron si një SMTP klient. Kur mail serveri

pranon një mail nga serverat e tjerë, ai vepron si një SMTP.

2.4.1 SMTP

SMTP, definuar në RFC 5321, është pjesa kryesore e adresave elektronike. Siҫ e përmendëm më

lartë SMTP transferon mesazhet nga serveri i dërguesit tek mail serveri i pranuesit. SMTP është

shumë më i vjetër se HTTP (Përkatsishtë SMTP RFC daton në 1982) Edhe pse SMTP ka cilësi

të shumta, shumë të mira, siç dëshmohet nga gjithëpranimi i tij në internet, ai është megjithatë

një teknologji trashëgimi që posedon karakteristika të sigurta .Për shembull, kjo e e kufizon

pjesën kryesore (jo vetëm headerin) e të gjitha mesazheve të thjeshtë ASCII 7-bit. Kjo pengesë

la përshtypje në fillim të viteve 1980, kur kapaciteti i transmetimit u “trembë” dhe askush në

email nuk bashkangjite skedarë , imazhe të mëdha, audio, apo video file. Por tani në epokën e

multimedias , 7-bit ASCII përpara se të dërgohet përmes SMTP kërkon që mesazhi

korrespondues ASCII të deshifrohet ,kthehet në binar pas transportimit SMTP. Theksojmë nga




Faqe 37

neni 2.2 se HTTP nuk kërkon që të dhënat multimediale të kodohen në ASCII para

transferimit.Për të ilustruar funksionet bazë të SMTP, le të shohim nëpër një skenar të

përbashkët. Supozojmë se Alice dëshiron ti dërgojë Bob një mesazh të thjeshtë ASCII.

1.Alice i kërkon agjent përdoruesit të saj për e-mail, i ofron Bobit e-mail adresën (për shembull,

bob-someschool.edu), shkruan një mesazh, dhe udhëzon agjent përdoruesin për ta dërguar

mesazhin.

2.Agjent përdoruesi i Alices dërgon mesazh te mail serveri i saj, ku është vendosur në një radhëmesazhesh.

3. Ana e klientit të SMTP kandidon në mail server të Alices, ku sheh mesazhin në radhë

mesazhesh. Hap një lidhje TCP për një SMTP server, kandidon në mail server të Bob-it.

Figura 2.17 Alisa i dërgon mesazh Bob-it

4. Pas disa ritualeve fillestare SMTP, ana e klientit SMTP dërgon Alises mesazhin brenda

lidhjes TCP.

5. Te mail serveri i Bobit, ana e serverit SMTP e merr mesazhin. Pastaj mail serveri I Bobit

vendos mesazhin ne kutinë postare.

6. Bob i kërkon agjentit përdorues të tij të lexon mesazhin në lehtësi.

Skenari është përshkruar në Figurën 2.17. Është me rëndësi që të vëzhgojmë se SMTP

normalisht nuk përdorë mail server të ndërmjetëm për dërgimin e mailave, madje edhe atëherë

kur dy mail serverë janë të pozicionuar në dy skajet e kundërta të botës. Nëse serveri i Alices

gjendet në Hong Kong dhe serveri i Bobit gjendet në St.Louis, lidhja TCP është lidhje e

drejtpërdrejt midis serverëve të Hong Kongut dhe St.Louis-it. Veçanërisht, nëse mail serveri i

Bobit është jashtë pune, atëherë mesazhi mbetet tek mail serveri i Alices dhe pret për tentimin

tjetër për dërgim – mesazhi nuk zë vend në ndonjë mail server të ndërmjetëm.Le të hedhim njëshikim më të ngushtë se si SMTP transferon mesazhin prej mail serverit dërgues deri tek mail

server pranues. Ne do të shohim se protokolli SMTP ka shumë ngjashmëri me protokolet që

përdoren për ndërveprimin

njerëzor sy-më-sy. E para, klienti SMTP (i kyçur në host mail serverin dërgues) vendosë lidhjen

TCP në portin 25 me serverin SMTP (i kyçur në host mail serverin pranues). Nëse serveri është

jashtë pune, klienti provon përsëri më vonë. Atëherë kur kjo lidhje vendoset, serveri dhe klienti




Faqe 38

kryejnë disa shkëmbime të shtresës së aplikacionit – ashtu siç njerëzit shpesh e prezantojnë

vetvehten para se të transferojnë informacione prej njërit tek tjetri, klientët dhe serverët SMTP

prezantojnë vetvehten para se të fillojnë me transformimin e informacioneve. Gjatë kësaj faze të

këmbimit SMTP, klienti SMTP tregon e-mail adresën e dërguesit (personi i cili gjeneron

mesazhin) dhe e-mail adresën e marrësit. Atëherë kur klienti dhe serveri SMTP të kenë

prezantuar vetvehten me njëri-tjetrin, klienti e dërgon mesazhin. SMTP mund të llogarisë në besueshmërinë e transferit të të dhënave me shërbimin TCP për dërgimin e mesazhit në server

pa gabime. Klienti pastaj përsëritë këtë proces përmes lidhjes së njejtë TCP nëse ka mesazhe të

tjera për dërgim në server; përndryshe, ai jep instruksione TCP-së për mbylljen e lidhjes.Le të

hedhim një shikim tjetër në një shembull transkripti të mesazheve të shkëmbyera midis një

klienti SMTP (C) dhe një serveri SMTP (S). Emri host (angl . hostname) i klientit është crepes.fr

dhe emri qëndror i serverit është hamburger.edu. Linjat e tekstit ASCII që fillojnë me C: janë

saktësisht linjat nëpër të cilat klienti dërgon nëpër prizat e TCP-së së tij, ndërsa linjat e tekstit

ASCII që fillojnë me S: janë saktësisht linjat që serveri dërgon nëpër prizat e TCP-së së tij.

Transkripti në vijim fillon menjëherë sapo të vendoset lidhja TCP.

S: 220 hamburger.edu

C:HELO crepes.fr

S:250 HELLO crepes.fr , pleased to meet you

C:MAIL FROM:<alice&crepes.fr>

S:250 alice&crepes.fr …sender ok

C:RCTP TO: < bob&hamburger.edu>

S: 250 bob&hamburger.edu…Recipient ok

C:DATA

S:354 Enter mail ,end with “.” On a line by itself

C:Do you like ketchup?

C:How about pickles?

C: .

S:250 message accepted for delivery

C:QUIT

S: 221 hamburger.edu closing connection

Në shembullin e mësipërm, klienti dërgon mesazhin (“Do you like ketchup? How about

pickles?”) prej mail serverit crepes.fr në mail serverin hamburger.edu. Si pjesë e dialogut,

klienti lëshon pesë komanda: HELO (një shkurtesë për HELLO), MAIL FROM, RCPT TO,

DATA, and QUIT. Këto komanda janë vetë-sqaruese. Klienti gjithashtu dërgon një linjë që

përbëhet nga një periodë e vetme, e cila paraqet fundin e mesazhit në server. (Në zhargonin

ASCII, secili mesazh përfundon me CRLF.CRLF, ku CR dhe LF janë

shkurtesa për transportin kthyes (angl . carriage return) dhe daljen e linjës (angl . line feed),

respektivisht). Serveri lëshon përgjigje për secilën komandë, me secilën përgjigje që ka

përgjigjen kodike dhe disa (opcionale) shpjegime të gjuhës angleze. Ne përmendim këtu se

SMTP përdorë lidhje të qëndrushme: Nëse mail serveri dërgues ka disa mesazhe për të dërguar

në mail serverin pranues, ai mund të dërgojë të gjitha mesazhet nëpër lidhjen e njejtë TCP. Për

secilin mesazh, klienti nisë procesin me një MAIL FROM:crepes.fr të ri, dizajnon fundin e




Faqe 39

mesazhit me një periodë të izoluar, dhe lëshon komandën QUIT vetëm pasi të dërgohen të gjitha

mesazhet. Rekomandohet shumë që të përdorni Telnet për bartjen e një dialogu direkt me

serverin SMTP. Për të bërë këtë, lëshohet

telnet serverName 25

ku serverName është emri i mail serverit lokal. Kur ta bëni këtë, ju thjeshtë jeni duke vendosur lidhjen TCP midis hostit lokal dhe mail serverit. Pasi të shtypet kjo linjë, do duhej që ju

menjëherë të pranonit përgjigjen 220 nga server. Pastaj lëshon komandat SMTP: HELO, MAIL

FROM, RCPT TO, DATA, CRLF.CRLF, dhe QUIT në kohët e përshtatshme. Gjithashtu

rekomandohet shumë që të përdorni Programimin e Caktuar 2 në fund të këtij kapitulli. Në atë

Caktim, do të ndërtoni një agjent-përdorues të thjeshtë që implementon anën e klientit të SMTP-

së. Ai ju mundëson juve që të dërgoni një e-mail mesazh tek ndonjë marrës i çfarëdoshëm

përmes mail serverit lokal.

2.4.2 Krahasimi me HTTP

Le ta krahasojmë tash me fjalë të shkurtëra SMTP me HTTP.Të dyja protokolet përdoren pë të

transferuar fajlla nga njëri host në tjetrin.HTTP transferimi I fajllave(gjithashtu i quajtur i

objekteve)nga një Web server në Web klient(tipike ështe një browser);SMTP transferimi i

fajllave(kjo ëhtë e-mail mesazhet)nga një mail server në mail serverin tjetër.Kur transferohen

fajllat të dyjat HTTP dhe SMTP përdorin lidhje të qëndrueshme.Kështu që të dyja protokolet

kanë karakteristika të përbashkëta.Sidoqoftë kanë edhe ndryshime të rëndësishme.Së pari,HTTP

është kryesisht pull protokoll- dikush ngarkon informacione ne Web server dhe përdoruesit

përdorin HTTP për të marr informacione nga server me lehtësi.Në vecanti,konektimi TCP është

inicuar nga makina e cila to të pranojë fajlla.Në anën tjetër,SMTP është kryesisht push – dergimi

i mail serverit i shtyn fajllat në mail serverin pranues.Në vecanti,TCP lidhjet janë të inicuara nga

makina e cila to të dërgojë fajlla.Ndryshimi i dytë,te cilën e permendëm terthorazi më

hërët,është se SMTP kërkon cdo mesazh,duke përfshirë trupin e cdo mesazhi të jetë ne formatin

7-bit ASCII.Nëse mesazhi përmban karaktere të cilat nuk janë te 7-bit ASCII(psh.karakteret në

gjuhën frenge me theks)ose përmban të dhëna binare (sikur një fajll me fotografi),atëherë

mesazhi duhet të enkodohet ne 7-bit ASCII.Të dhënat në HTTP nuk ta imponojnë këtë kufizim.

Ndryshimi i tretë i rëndësishëm përmban si është trajtuar një dokument i perbërë nga teksti dhe

fotografitë(së bashku me mundesinë e tipeve tjera të mediave).Sic e mësuam ne Seksionin

2.2,HTTP enkapsulon secilin object në mesazhin që i pergjigjet HTTP.Internet mail vendet nga

të gjitha objektet e mesazheve në një mesazh.

2.4.3 Formatet e Mail Mesazheve

Kur Alice i shkruan një leter me email te zakonshëm Bobit,ajo mund të perfshije të gjitha llojet e

hederit anësorë në informat në fillim të letrës,edhe atë adresen e Bobit,adresën e saj kthyese,dhe




Faqe 40

datën.Ngjajshëm,kur një e-mail mesazh dërgohet nga një person në tjetrin,hederi paraprin me

përmbajtjen periferike dhe të trupit të mesazhit të vet.Kjo informatë periferike ka përmbajtje një

seri të rreshtave të hederit,të cilat janë të definuara në RFC 5322.Rreshti i hederit dhe trupi i

mesazhit janë të ndara me një rresht të bardhë(kjo është,nga CRLF).RCF 5322 specifikon

formatin e sakt për rreshtin e hederit sikur interpretimin kuptimor të tyre.Sikur me HTTP ,cdo

rresht i hederit përmban tekst të lexueshem,duke përfshirë cdo fjalë të shoqëruar nga një kolonëte shoqëruar me një vlere.Disa nga fjalet janë të nevojshme dhe të tjerat jo të detyrueshme.Cdo

heder duhet të kete një FROM: dhe një rresht heder me TO:; një heder mund të perfshije një

rresht SUBJECT : dikur edhe rreshtat tjerë jo të detyrueshëm.është e rëndesishme te cekim kto

rreshta të hederit janeë të ndryshme nga komandat SMTP të cilat i kemi studiuar në seksionin

2.4.1(edhe pse ato përmbajnë fjalë të përbashkëta sic janë “from” dhe “to”).Komandat në atë

seksion ishin të ndara në protokolin SMTP ;rreshtat e hederit që janë kontrolluar në këtë seksion

janë pjesë e vet mesazhit.

Hederi i një mesazhi tipik duket kështu:

From: [email protected]

To : [email protected]

Subject:Duke kërkuar kuptimin e jetës.

Pas hederit të mesazhit,e shoqëron një rresht i bardhe;atëherë e shoqeron trupi i

mesazhit ( në ASCII).Ju duhet ta përdorni Telnet’in të dergoni mesazh në një mail

server e cila permban disa rreshta të hederit,duke përfshire rreshtin Subject:.Per ta bërë

këtë,përdor telnet serverName 25,sic është diskutuar në seksionin 2.4.1.

2.4.4.Mail Protokolet me Hyrje

Nganjehëre pranon mesazh të SMTP nga mail server i Alice në mail serverin e Bob’it,mesazhi

është vendosur në mailbox’in e Bob’it.Gjatë gijthë ketij diskutimi në

heshturazi kemi supozuar që Bob i lexon mail’et e tij duke u kycur ne hostin e serverit dhe pastaj

duke egzekutuar një mail lexues e cila është aktive në atë host.Deri në vitet e hershme të 1990

kjo ishte mënyra standarde psr ti bërë gjërat.Por sot,qasja në mail e perdor një arkitekturë klient-

server shfrytzuesi tipik e lexon e-mail me një klient e cila egzekutohet në sistemin e fundit të

perdoruesit,psh,një kompjuter në zyre,një laptop ose nje PDA.Me egzekutimin e mail klientit në

kompjuter local,shfrytzuesit kënaqen me arritjen e karakteristikave,duke përfshire aftësitë për të

parë mesazhe të multimedias dhe attachmente’e. E dhëna e Bob’it(pranuesit)egzekuton agjentin

e tij local në kompjuterin e tij,është e natyrshme të konsiderosh zëvendsimin e mail serveri’t në

lokal hostin e kompjuterit të tij.Me këtë mbërrijme,mail server i Alice do të diagolojë direkt me

kompjuterin e Bob’it.Sidoqoftë,ka një problem me këtë qasje.Kujtoj që mail server menaxhon

mailbox’at dhe egzekuton klientin dhe anën e serverit të SMTP.Nëse mail serveri Bob’it është

vendosur që të qëndrojë në kompjuterin e tij local,atëherë kompjuteri I Bob’it do të mbetet

gjithmonë mbi,dhe I lidhur me internet,në urdhërin të pranojë mail’a të rinj,të cilat mund të

mbrrijnë në cdo kohë.Kjo është jopraktike për disa shfrytzues të internetit.Në vend të kësaj,një

shfrytzues I zakonshëm përdor hyrjet në kompjuterin lokal të tij dhe mailbox’at ruhen gjithmonë

në mail servera.Këta mail servera janë të shpërndarë shfrytzuesve tjerë dhe është tipike të ruhet

nga shfrytzuesit ISP(psh,universiteti ose kompania).

mailto:[email protected]











Faqe 41

Tash le të konsiderojmë rrugën që bën një e-mail kur i dërgohet nga Alice Bobit.Ne sapo

mësuam që në një pikë gjatë rrugës e-mail mesazhi duhet të depozitohet në mail serverin e

Bobit.Kjo mund të bëhet thjesht duke pasur agjentin e shfrytzuesin e Alice's që dergon mesazh

direkt në mail serverin e Bob'it.Dhe kjo mund të bëhet me SMTP,në të vërtetë,SMTP është

dizajnuar për shtyrje te e-mail nga një host në tjetrin.Sidoqoftë,agjenti i shfrytzuesit të fundit

nuk dialogon direkt me mail serverin e pranuesit.Në vend të kësaj,sic shihet në fig 2.18, agjenti i

shfrytzuesit të Alice's shfrytzon SMTP që të shtyje e-mail mesazhin në mail serverin e saj,pastajmail serveri i Alice shfrytzon SMTP(sikur një klient te SMTP) të transmetojë e-mail mesazhin

në mail serverin e Bob'it.Pse këto dy hapa procedurë?Së pari sepse pa tranmetimin në mail

serverin e Alice's,agjenti i shfrytzuesit të Alice nuk ka asnjë adresim te një destinacion i

paaritshëm të mail serverit.Duke pasur së pari depozitën e email'it të Alice në mail serverin e

vet,mail serveri i Alice mund vazhdimisht të provojë të dërgojë mesazhe në mail serverin e

Bob'it,të themi cdo 30minuta,derisa mail serveri i Bob'it të punojë..(dhe nëse mail serveri i

Alice's është jofunksional,atëherë ajo duhet të ankohet në sistemin administrativ të saj!) SMTP

RFC definon se si komandat SMTP mund të përdoren të transmetojnë mesazh përgjatë shumë

SMTP serverëve.

Por egziston ende një pjesë e humbur e puzzle!Si një pranues sikur Bob,e shfrytzon një agjentlokal në kompjuterin e tij, merr mesazhin e tij,të cilat janë të deponuara në mail serverin e Bobit

pa ISP e Bobit?Vërejmë se mjeti shfrytzues i Bob'it nuk mund të perdore SMTP që të marre

mesazhin sepse marrja e mesazhit është një punë që tërheq,ndërsa SMTP eshte një protokoll

shtytes.

Figura 2.18 E-mail protokollet dhe komunikimet e tyre

Puzzle kompletohet duke futur nje mail hyrje special për protokollin që transferon mesazhe nga

bob në mail serverin lokal te kompjuterit të tij.Jane aktualisht një numer i kerkuar i mail me

hyrje ne protokole,duke perfshirë Post Office Protocol-Version3(POP3),Internet Mail Access

Protocol(IMAP) dhe HTTP.Figura 2.18 jem një permbledhje e protokoleve te lilat shfrytzohen

për Internet mail:SMTP përdoret të transferojë mail nga një dërgues i mail servererit te mail

serveri i pranuesit;SMTP gjithashtu shfrytzohet të transferojë mail nga një mjet i shfrytzuesit të

dërguesit në mail serverin e dërguesit.Mail me hyrje në protokol,sikur është POP3,është

përdorur të

tranferojë mail nga mail serveri i pranuesit në mjetin e shfrytzuesit të pranuesit.

POP3

POP3 është ekstremisht një mail me hyrje në protokol i thjeshtë.është i definuar në [RFC

1939],e cila sshtë e shkurtë dhe plotësisht e lexueshme.Përshkak të thjeshtësisë është






Faqe 43

S: .......................

S: .........blah)

S: .

C: dele 1

C: retr 2

S: (blah blah ...

S: .......................S: .........blah)

S: .

C: dele 2

C: quit

S: + OK POP3 server signing off

Mjeti i shrytzuesit së pari e pyet mail serverin rëndësinë madhësinë e cdo mesazhi të

deponuar.Mjeti i shfrytzuesit pastaj korigjon dhe fshinë cdo mesazh nga serveri.Lajmron që pas

frazës së autorizimit,mjeti i shfrytzuesit punëson vetëm kater komanda: list,retr,dele dhe

quit.Sintaksa e këtyre komandave është definuar në RFC 1939.Pas procesimit komandaquit,serveri POP3 i fut azhurimet e frazave dhe i largon mesazhin 1 dhe 2 nga mailbox'i.

Problemi me këtë modul shkarko - dhe - fshijë është se marrësi,Bob, mund të jetë shtegtues dhe

mund të mos dojë të hyje në mail mesazhet nga një makine e shumfishtë.,psh,kompjuteri në

zyren e tij,kompjuteri në shtëpinë e tij,dhe kompjuterii bartshem i tij.Modi shkarko-dhe - fshijë e

ndan mail mesazhet e Bob'it mbi këto tri makina;në vecanti nëse Bob së pari e lexon mesazhin e

tij në kompjuterin e zyrës,ai nuk do të mund të rilexojë mesazhin në mbrëmje në shtëpine e

tij.Në modin shkarko-dhe-mbaj ,mjeti i shfrytzuesit le mesazh në mail serverin pas shkarkimit të

tyre.Në këtë rast,Bob mund të rilexojë nga makina të ndryshme;ai mund të ketë hyrje në mesazh

nga puna dhe pastaj prap një javë me vonë nga shtëpia.Gjatë sesionit POP3,mes makines së

përdoruesit dhe mail serverit,POP3 serveri mban disa informata të gjendjes;në vecanti,i mban

gjurmet se cili shfrytzues ka etiketu dhe fshijë.Sidoqoftë, serveri POP3 nuk mban informata të

gjendjes pergjatë sesionit POP3.Kjo mungesë e gjendjes së informacionit përgjatë sesionit e

thjeshtëson shumë implementimin e POP3 serverit.

IMAP

Me hyrje në POP3,një herë Bob duhet të shkarkoje mesazhin e tij në makinen lokale,ai mund te

krijojë nje mail folder dhe të lëvize mesazhet e shkarkuara ne atë folder.Bob pastaj mund të

fshije mesazhet,të levizë mesazhet pergjat folderit,dhe të kërkoje

mesazhe(me emer të derguesit ose subjektit).Por kjo paradigmë-me emër,folderet dhe mesazhet

në makinen lokale- parashtron një problem për perdoruesit shtegtues,i cili do të preferojë te

mbaj hierarkine e folderit nga një server i largët ajo mund të jetë hyrje nga cdo kompjuter.Kjo

nuk është e mundur me POP3-POP3 protokolli nuk siguron ndonjë domethënie për shfrytzuesin

të krijoj një folder në largësi dhe ti përcaktojë mesazhet në folder.Për ta zgjidhur, këtë dhe

problemet tjera, është zbuluar IMAP protokolli,i definuar në [RFC 3501].Sikur POP3,IMAP

është një mail protokol me hyrje.Ka me shumë tipare se sa POP3,kuptohet është edhe më




Faqe 44

kompleks.(Dhe kështu që klientet dhe implementimi nga ana e serverit është me

komplekse,)IMAP serveri do të lidh cdo mesazh me një folder;kur mesazhi së pari arrin në

server,është i lidhur me folderin e pranuesit INBOX.Pranuesi pastaj mund ti lëvize në një folder

të ri të sapokrijuar,të lexojë mesazhet të fshijë mesazhet dhe ti levizë nga një folder në

tjetrin.IMAP gjithashtu siguron komanda që lejon shfrytzuesit të kërkojnë në largesi për

mesazhet nëpër foldere duke ju pergjigjur kriteri i caktuar.Sheno këtë,i ndryshem nga POP3,njeserver IMAP mban informata të gjendjes se shfrytzuesit pergjatë sesionit IMAP-psh,emri i

foldereve dhe cili mesazh është i lidhur me cilin folder.

Një tipar tjetër i rëndesishë i IMAP është se ka komanda që lejojnë që mjetet e sfhrytzuesit

mund të marrin vetëm hederin e mesazhit nga mesazhi ose vetem një mesazh MIME.Ky tipar

është i shfrytzueshëm kur ka lidhje të ngadalshme-bandëith(psh,shpejtësi e vogël e lidhjes së

modemit)mes makinës së shfrytzuesit dhe mail serverit.Me lidhje të dobtë të

bandwidth,shfrytzuesi mund të mos e dojë të shkarkojë të gjitha mesazhet në mailbox'in e

tij,vecanërisht i shmanget mesazheve të gjata të cilat mund të përmbajnë,psh,një audio ose video

klip.Ju mund të lexoni të gjitha ne faqen zyrtare të IMAP .[IMAP 2009].

E-mail i bazuar ne Web

Shume e me shume shfrytëzues sot po dërgojnë dhe po ju casen e-maileve të tyre përmes Web

shfletuesve. Hotmail-i e prezantoi qasjen e bazuar ne Web nga mesi i viteve 1990; Tani e-maili i

bazuar në Web është gjithashtu i siguruar edhe nga Yahoo, Google si dhe nga pothuajse cdo

universitet dhe koorporate e madhe. Me këtë shërbim, agjenti shfrytëzuesi është një Web

shfletues i zakonshëm, dhe shfrytëzuesi komunikon me kutine e largët postare të tij pëmres

HTTP-se. Kur pranuesi, sikurse Bobi, dëshiron ti qaset mesazhit në kutinë postare të tij, e-mail

mesazhi është dërguar nga nga serveri postar i Bobit, tek shfletuesi që përdor HTTP protokolin

në vend të POP3 ose IMAP protokolit. Kur dërguesi, sikurse Alice, dëshiron të dërgojë nje

mesazh, ai mesazh dërgohet prej shfletuesit deri te serveri postar i saj permes HTTP ne vend te

SMTP. Serveri postar i Alicës, megjithatë, ende dërgon dhe pranon mesazhet prej serverëve tjere

postarë që përdorin SMTP.

2.5 DNS- Shërbyesi drejtues i Internetit

Ne qeniet njerëzore, mund të indentifikohemi në shumë mënyra. Për shembull, ne mund të

indentifikohemi me emrat që konfigurojnë në certifikatat tona të lindjes. Ne mund të

indentifikohemi nga Numrat Social të Sigurise. Mund të indentifikohemi nga numrat e lejës se

Vozitjes. Edhe pse secili nga këta indentifikues mund të përdoret për të indentifikuar njerëzit, në

një kontekst të caktuar, një identifikues mund të jetë më i përshtatshëm se një tjetër. Për

shembull, kompjuterët në IRS( Agjensi e panjohur e tawave ne SHBA ) preferon të përdorë

Numra Social te Sigurisë me një gjatësi fikse ne vend të certifikatave të lindjes. Në anën tjetër,

njerëzit e zakonshëm preferojnë më shumë emrat e certifikatave të lindjes sesa NSS. ( A mund

të paramendoni veten duke thënë, ‘Përshëndetje, une jam 132-67-9857. Ju lutem takohuni me

burrin tim 178-87-1146’).




Faqe 45

Sikurse që njerëzit mund të indentifikohen në shumë mënyra, ashtu munden edhe hostet në

internet. Një identifikues për host eshte emri i hostit(hostname). Emrat e

ato vështire se do të procesoheshin nga ruterat. Për këto arsye, hostet gjithashtu idnetifikohen

nga të ashtuquajturat IP adresa.Ne do ti diskutojmë IP adresat me më shumë detaje ne kapitullin

4, por është frytëdhënëse tit hemi disa fjalë për to tani. Një IP Adresë konsiston me 4 bita dhe ka

një hierarki strukturale të fortë. Një IP Adresë duket sikurse 127.7.106.83, ku secila pikë ndan

njërin nga bajtat të shprehur në formën decimale nga 0 deri në 255. Një IP Adresë ka strukturëhierarkike sepse sikurse ne mund ta skenojmë adresën nga e majta në të djathtë, në sigurojmë

shumë e më shumë informacion specific për atë se ku është i lokalizuar hosti në Internet ( kjo

dmth, përmes cilit rrjet, ne rrjetin e rrjetave ). Ngjashëm, kur ne skenojmë një adresë postare nga

poshtë-lartë, ne sigorjmë cdo herë e më shumë informacione specifike se ku është lokalizuar

adresa.

2.5.1 Shërbimet e siguruara nga DNS

Ne sapo pamë se ekzistojnë dy mënyra për të identifikuar një host-nga emri i tij dhe nga IP

Adresa. Njerëzit preferojnë idnetifikues që memorizohen më lehtë, përderisa ruterat preferojnëIP Adresa te strukturuara me gjatësi fikse. Në mënyrë që të koordinohen tëto kërkesa neve na

duhet nje shërbim drejtues i cili përkthen emrat e hosteve në IP Adresa. Kjo është detyra

kryesore e Sistemit për Domen të Emrit (DNS-Domain Name System ). DNS- është (1) një bazë

e shpërndarë e shënimeve e implemetuar në një hierarki të DNS serverëve dhe (2) një protocol

aplikacion-shtresor që lejon hostet të bëjnë kërkesa ne bazën e shpërndarë të shënimeve.

Zakonisht serverët DNS janë makinat UNIW që ekzekutojnë BIND-in (Berkley Internet Name

Domain ) softuerin ( BIND 2009 ). Protokoli DNS vepron përmes UDP-se dhe shfrytëzon portin

53. DNS në mënyrë të përbashkët sfhrytëzohet nga protokolet e aplikacioneve tjera shtresore-

duke përfshirë HTTP,SMTP, dhe FTP-për të përkthyer emrat e hosteve të shfrytëzuesve ne IP

Adresa. Sa për ilustrim, konsidero qfarë ndodh kur një shfletues( që është nje klient HTTP ), që

po vepron në hostin e ndonjë shfrytëzuesi, kërkon URL-në www.someschool.edu/indew.html.

Në mënyrë që host ii shfrytëzuesit të jetë në gjendje të dërgojë një mesazh kërkesë për Web

serverin www.someschool.edu . Kjo bëhet kështu siq vijon

1. Makina e njëjtë e sfhrytëzuesit ekzekuton pjesën e Klientit për nje server DNS.

2. Shfletuesi e zgjeron emrin e hostit, www.someschool.edu, nga URL dhe dhe e kalon emrin

e hostit në anën e klientit në aplikacionin DNS.

3. Klienti DNS e dërgon një kërkesë që përmban emrin e hostit për një server DNS.

4. Klienti DNS eventualisht pranon një përgjigje, e cila përfshinë IP Adresën për emrin e

dhënë të hostit.

5. Sapo shfletuesi të pranojë IP Adresën nga DNS-i, aim und të inicojë një lidhje TCP me

serverin e HTTP-së që është i okalizuar në portin ,80 me atë IP Adresë.

Ne nga ky shembull shohim se DNS-i i shton një vonesë-ndonjëherë substanciale- aplikacionit

që e shfrytëzon atë. Për fat të mirë, sic e diskutuam më parë IP Adresa e dëhiruar zakonisht ruhet

“afer” serverit DNS, i cili ndihmon te zvogelohet trafiku ne rrjetin e DNS njejte sikurse edhe

vonesën mesatare DNS. DNS-i permban edhe disa shërbime tjera me rëndësi me tendencën për

të përkthyer emrin e hostit në IP Adresë.




Faqe 46

PRINCIPE NË PRAKTIKË

DNS: FUNKSIONET KRITIKE TË RRJETAVE PËRMES MODELIT KLIENT-

SERVER

Sikurse HTTP,FTP, dhe SMTP, protokoli i DNS-it është aplikacion-shtresor përderisa (1)

ekzekuton në mes komunikimit të sistemeve të fundit duke përdorur modelin klient-server dhe (2)

bazohet në një transport protocol shfrytëzuesIfundit-tek-shfrytëzuesiIfundit për të trasferuar të mesazhet DNS në mes të sistemve të fundit komunikuese. Në një tjetëe kuptim, roli i DNS-it është

mjaft i ndryshëm nga a ii Web-it, transferuesi i fajlave, dhe aplikacioneve të e-mailit. Ndryshe

nga aplikacionet, DNS-i nuk është një aplikacion me të cilin shfrytëzuesi kontakton direct. Por,

DNS-i siguron një funksion bazik të internetit-i quajtur, përkthimi i emrave të hosteve ne IP

Adresat e tyre, për shfrytëzuesit e aplikacioneve dhe softwerëve tjerë në Internet. Ne theksuam

ne seksionin 1.2 që shumica e kompleksitetit ne arkitekturën e Internetit është e lokalizuar në

“siperfaqen” e rrjetit. DNS -i, i cili implementon përkthimin kritik emër-në-adresë duke

përdorur klientat dhe serverat e lokalizuar në sipërfaqen e rrjetit, është prap një tjetër shembull

i asaj filozofie të dizajnit.

DNS mund të përfshihet nga një aplikacion për të siguruar emrin e autorizuar të hostit për një

emer të ngjashëm hosti sikurse IP Adresa e hostit.

Pseudonimi postë server. Për arsye të qarta, është shumë e dëshirueshme që që e-mail

adresat të jenë të memorueshme. shembull, nëse Bobi e ka një logari në Hotmail, adresa

elektronike e Bobit mundet të jetë aq e thjeshtë si [email protected]. Megjithatë, hosti i

serverit postar të Hotmail është më i komplikuar dhe shumë më pak mund të mbahet në

mend, jo vetëm si hotmail.com( për shembull emri i autorizuar mund të jetë dicka si

relay1west-coast.hotmail.com ). DNS-i mund të përfshihet nga një aplikacion postar për

të siguruar emrin e autorizuar të hostit për një emër të ngjashëm hosti njëjtë sikurse IP

Adresa hostit. Në fakt, shënimi MX ( shiko më poshtë ) lejon serverin postar dhe Webserverin e kompanisë të kene emra hostesh identike ( aliased ); për shembull, Ëeb server

i një kompanie dhe serveri postar munden të dy të quhen enterprise.com.

Shpërndarja e ngarkuar. DNS-i poashtu përdoret për të performuar shpërndarje të

ngarkuar përmes serverëve të kopjuar. Sajtet e ngarkuara, sikurse cnn.com, janë të

kopjuar nëpër shumë serverë, me secilin server që ekzekutohet në një end-sistem tjetër,

dhe ku secili ka një tjetëe IP Adresë. Pëe Xeb serverët e kopjuar, një bashkësi e IP

Adresave është e lidhur me një emër të autorizuar hosti. Baza e të dhenave të DNS-it

përmban këtë bashkësi të adresave. Kur klientët bëjnë një DNS kërkesë për një emër të

planifikuar për një bashkësi adresash, serveri përgjigjet përmes të gjithë bashkësisë së IPAdresave, por rrotullon rendin e adresave përmes secilës përgjigje. Meqenëse klienti e

dërgon kërkesën e tij HTTP tek IP Adresa që është e listuar e para në bashkësi, rotacioni

DNS e shpërndan trafikun përmes serverëve të kopjuar. Rotacioni DNS është gjithashtu

i përdorur për e-mail, kështu që serverë të shumtë postarë mund të kene emrin e njëjtë.

Së fundi, kompanitë shpërndarëse sikurse Akamai e kanë perdorur DNS-in në shumë

mënyra të sofistikuara për të siguruar shpërndarje të kënaqshme në Xeb.








Faqe 47

2.5.2 Mbikqyrje se si punon DNS-i

Ne tani prezentojme një mbikqyrje të nivelit të larte, në atë se si punon DNS-i. Diskutimi ynë do

të fokusohet në shërbimin e perkthimit emerHosti-në-IP-adresë. Supozoni se një aplikacion (

sikurse Web shfletuesi ose lewuesi i postës ) duke ekzekutuar në një host të shfrytëzuesit duhet

që të përkthejë një emër hosti në një IP adresë. Aplikacioni do të përfshijë anën e klientit të

DNS-it, duke specifikuar emrin e hostit që duhet të përkthehet. ( Në shumë makina Uniw-baze,gethostbyname() është funksioni thirrës që një aplikacion thërret në mënyrë që ta performojë

përkthimin. Në seksionin 2.7 ne do të tregojmë se si një aplikacion Java mund të përfshijë DNS-

in ). DNS-i është host ii shfrytëzuesit, që dërgon njëkërkesë mesazh në rrjet. Të gjitha kërkesat

dhe përgjigjet DNS dërgohen përmes datagrameve UDP të portit 53. Pas një vonese, që zgjat

nga disa milisekonda deri në disa sekonda, DNS-i ne hostin e sfhrytëzuesit pranon një përgjigje

DNS që siguron planifikim e dëshiruar. Ky planifikim pastaj kalon në aplikacionin e përfshirë.

Kështu që nga prespektiva e aplikacionit të përfshirë në hostin e shfrytëzuesit, DNS-i është një

kuti e zezë që siguron një shërbim përkthimi të thjeshtë dhe të drejtpërdrejtë. Por në fakt , kutia e

zezë që implementon shërbimin është e komplikuar, e mbushur me numra të mëdhenj të

seerverëve DNS të shpërndarë përreth Globit, sikurse një protocol in je aplikacioni-shtresor qëspecifikon se si serverët DNS dhe hostet kërkuese komunikojnë.Një dizajn i thjeshtë për DNS

do të kishtë një server DNS që e bën të gjithë planifikimin. Në këtë dizajn të centralizuar,

klientët thjeshtë i drejtojnë të gjitha kërkesat në serverin e vetëm DNS, dhe DNS i vetem u

përgjigjet direct kërkesave të klientëve. Edhe pse thjeshtësia e këtij dizajni është atraktiv, është e

papërshtatshme për Internetin e sotëm, me numrin e pafundëm( në rritje e sipër ) të hosteve.

Problemi me një dizajn të centralizuar përfshinë:

Një pikë e vetme dështimi. Neë server i DNS-it bjen, fat i njëjtë e prêt edhe tërë

Internetin!

Volumi në trafik. Një server i vetëm DNS do të duhej të përballonte të gjitha kërkesat e

DNS-it ( për të gjitha kërkesat HTTP dhe e-mail mesazhet të gjeneruara nga qindramijëra miliona hoste).

Baze e largët qëndrore e të dhenave. Një server i vetëm DNS nuk mund të “mbyllet

ndaj” të gjithë klientëve kërkues. Nëse ne e vendosim DNS serverin e vetëm në New

York, të gjitha kërkesat nga Australia duhet të udhetojnë në anën tjetër të globit, ndoshta

nëpër linja të ngadalshme e të mbushura. Kjo mund të dërgojë deri tek vonesa të

dukshme.

Mirëmbajtja. DNS server ii vetëm do të duhej të mbante shënime për të gjitha hostet e

Internetit. Jo vetëm që kjo Baze qëndrore e të dhënave do të ishte shumë e madhe, por

edhe do të duhej të azhurohej në mënyrë të vazhdueshme për të shënuar secilin host të

ri. Në përmbledhje, një Bazë qëndrore e të dhënave në një DNS të vetëm thjesht nuk funksionon. Si

pasojë, DNS-i është sipas dizajnit i shpërndare. Në fakt, DNS-i ështe një shembull fantastic se si

një Bazë e shpërndarë e shënimeve mund të implementohet në Internet.

Databazë e shpërndarë dhe e organizuar në mënyrë hierarkike






Faqe 49

paraqitur një hartë e këtyre serverev Fig.2.20; një list e tanishme e DNS serverave

rrënjë është në dispozicion në [Root-servers 2009]. Edhe pse jemi referuar për secilin

nga 13 DNS serverët rrënjë sikur të ishte një serveri i vetëm, çdo server është në fakt

një grup serverësh të replikuar , për dy qellime: siguri dhe besueshmëri.

Serverët e domeneve të nivelit të lartë (TLD). Këta server janë përgjegjës për domene

të nivelit të lartë si: com, org, net, edu, dhe gov si dhe për të gjitha top domenet e

shteteve si uk, fr, ca, jp. Kompania Network Solutions mirëmban TLD serveret për comtop domenin, kurse kompania Educause mirëmban TLD serveret për atë të edu.

Autoritativ DNS serverat. Çdo organizat me çasje publike (si Web serveret dhe mail

serveret) duhet të lejojn qasje publike në DNS të dhënat që lidhin emrin e hostave me

IP adresën.Organizatat e DNS servereve autoritativ i mbajnë këto DNS të dhena.

Organizatat mund të zgjedhin që të kenë DNS serverin autoritativ personal që t’i

mbajë këto të dhëna; apo ato mund të paguajnë që këto të dhëna të ruhen në një DNS

server autoritativ të një kompanie që ofron këtë shërbim. Shumica e universiteteve dhe

kompanive të mëdha kanë dhe ruajn backupin e tyre në DNS serverin autoritativ

personal.

Rrënjë, TLD dhe autoritativ DNS serveret i përkasin hierarkisë të DNS serverve, të treguar në

fig. 2.19. Një lloj tjetër i rëndesishëm i DNS servereve është edhe lokal DNS serveri. Lokal

DNS serveri jo rreptësisht i përket hierarkisë të servereve por megjithatë është qendra e DNS

arkitekturës. Çdo ISP – si universitetet, departamentet akademike, kompani punonjësve, apo një

residenciale ISP- ka një DNS server lokal. Kur një host

lidhet me një ISP, ISP i siguron hostiti IP adresa të marra nga një apo më shumë DNS serveret

lokal të saj (në mënyrë tipike me anë të DHCP, për të cilen është diskutuar në kapitullin 4).Ju

lehtë mund të përcaktoni IP adresën e DNS serverit tuaj lokal duke hyrë në dritaren e statusit të

rrjetit në Windows ose UNIX. Hosti i DNS serverit lokal zakonisht është “afër” hostit. Për njëISP institut, DNS serveri lokal mund të jetë në të njejtin LAN si dhe hosti; një ISP banesore

është e ndarë në mënyrë tipike nga hosti vetëm nga disa rutera. Kur një host benë një DNS

pyetje(query), pyetja dergohet tek një DNS server lokal, i cili sillet si përfaqësues, duke e

parashtruar këtë pyetje në DNS server hierarkin, e shpjeguar në detaje më poshtë.

Le ta shikojmë një shembull të thjeshtë. Supozojmë se hosti cis.poly.edu dëshiron IP

adresen e gaia.cs.umass.edu. Po ashtu supozojmë se Polytechnic’s DNS serveri lokal quhet

dns.poly.edu dhe se autoritativ DNS serveri për gaia.cs.umass.edu quhet dns.umass.edu. Siç

tregohet në fig.2.21, hosti cis.poly.edu se pari DNS mesazh pyetjen e dergon në DNS serverin

lokal të tij, dns.poly.edu. Mesazh pyetja përmban host emrin i cili duhet përkthyer,dmth,

gaia.cs.umass.edu. DNS serveri lokal përcjell mesazhin tek një rrenjë DNS server. Rrenjë DNSserveri e merr parasysh prapashtesën edu dhe kthen tek DNS serveri lokal një listë me IP adresa

për TLD serveret përgjegjës për edu. DNS serveri lokal atëherë ridërgon mesazh pyetjen tek një

nga këta TLD servera. TLD serveri merr parasysh prapashtesën umass.edu dhe përgjigjet me IP

adresën e DNS serverit autoritativ për Universitetin e Masaçusets, dmth, dns.umass.edu. Dhe në

fund, DNS serveri lokal ridërgon mesazh pyetjen direkt te dns.umass.edu, i cili përgjigjet me IP

adresën e gaia.cs.umass.edu. Duhet theksuar se në këtë shembull, në mënyrë që të marrim

planifikimin(mapping) për një host emër, janë dërguar tetë DNS mesazhe: katër mesazh pyetje




Faqe 50

dhe katër mesazh përgjigje. Së shpejti do të shohim se si DNS caching zvogëlon këtë trafik

pyetjesh.

Në shembllin tonë të mëprashëm është supozuar se TLD serveri e dinë autoritativ DNS

serverin për host emrin. Në përgjithësi kjo nuk është gjithmonë e vërtetë. Në vend të kësaj, TLD

serveri mund të dijë një DNS server të ndërmjetëm, i cili nga ana e vetë mund të di autoritativ

DNS serverin për host emrin. Për shembull, supozojmë se Universiteti i Masaçusets ka një DNSserver për vete të quajtur dns.umass.edu.

Fig.2.21 Ndërveprimi në mes DNS serverve të ndryshëm

Po ashtu supozojmë se,çdo departament në Universitetit të Masaçusets ka DNS serverin e vet,

dhe çdo DNS server i departamentit është autoritativ për çdo host në atë departament. Në këtë

rast, kur DNS serveri i ndërmjetëm, dns.umass.edu, pranon një pyetje me host emër qe mbaron

me cs.umass.edu, kthen IP adresen për dns.cs.umass.edu tek dns.poly.edu,e cila është

autoritative për të gjithë host emrat që mbarojnë me cs.umass.edu. DNS serveri lokaldns.poly.edu pastaj dërgon pyetjen tek autoritativ DNS serveri, i cili kthen hartën e kërkuar të

DNS serverit lokal, e cili më pas kthen hartën e hostit të kërkuar. Në këtë rast, 10 DNS mesazhe

janë derguar !Shembulli i treguar në Fig. 2.21 benë përdormin e pyetjeve

rekursive(ripërsëritëse) dhe atyre iterative(përsëritëse). Pyetja e dërguar nga cis.poly.edu te

dns.poly.edu është një pyetje rekursive, sepse ajo kërkon që dns.poly.edu të marrë hartën në

emër të saj. Por tri pyetjet pasuese janë iterative pasi që të gjitha përgjigjet janë kthyer direkt

tek dns.poly.edu. Në teori,çdo DNS pyetje mund të jetë iteraktive ose rekursive. Për shembull,




Faqe 51

në Fig.2.22 tregohet një zinxhir DNS pyetje për të cilat të gjithat përgjigjet janë rekursive. Në

praktikë pyetjet zakonisht ndjekin modelin si në Fig.2.21. Forma e pyetjeve të kërkuar nga hosti

për DNS serverin lokal është rekursive, kurse pjesa tjetër e mbetur e pyetjeve janë iterative.

Fig. 2.22 Pyetjet rekursive në DNS

DNS Caching

Në diskutimin tonë deri më tani kemi injoruar DNS caching (ruajtjen e kopjes), një tipar shumë i

rëndesishëm për DNS sistemin. Në të vërtetë DNS-i shfrytëzon gjerësisht DNS ruajtjen e kopjes,

në mënyrë që të përmirësoj vonesat dhe të zvogëloj numrin e DNS mesazheve ripërseritëse në

internet. Ideja prapa DNS ruajtjes së kopjes është shumë e thjeshtë. Në një zinxhir pyetje, kur

një DNS server merr një DNS përgjigje (që përmbanë, për shembull një hartë nga një hostname

për një IP adresë) ai mund të bejë kopje (cache) hartën në kujtesën lokale. Për shembull, në

figurën 2.21 çdo herë kur DNS serveri dns.poly.edu merr një përgjigje nga ndonjë DNS server

tjetër, mund të bejë kopje cilendo nga informatat që gjinden në atë përgjigje. Në qoftë se njëhostname / ip adresë është kopje e rujatur në DNS server dhe një pyetje tjetër arrin në atë DNS

server për të njejtin hostname,DNS serveri mund të sigurojë IP adresën e dëshiruar, edhe pse

nuk është autoritativ për atë hostname. Për shkak se hosti dhe hartat në mes të hostname dhe IP

adresave nuk janë të përhershme, DNS serverat i hedhin kopjet pas një periudhe kohe (zakonisht

pas dy ditëve). Për shembull, supozojmë që hosti apricot.poly.edu pyet dns.oply.edu për IP

adresën e hostname cnn.com. Më pas supozojmë se pas disa orëve , një tjetër Polytechnic

University host, psh, kiwi.poly.fr, pyet dns.poly.edu për të njëjtin hostname. Për shkak të




Faqe 52

ruajtjes së kopjes(caching), DNS serveri lokal është në gjendje që menjëherë të kthej IP adresën

e cnn.com për hostin e dytë kërkues pa patur nevojë që të pyes DNS serverat tjerë. DNS serveri

lokal mund të bejë kopje IP adressat e TLD serverëve, duke lejuar DNS serverin lokal të

anashkalojnë rrenjë DNS serverët në zinxhir pyetjet (gjë që ndodh shpesh).

2.5.3 DNS të dhënat dhe mesazhet

Serverat e DNS që përbëjnë bazen e shpërndarë e të dhënave DNS ,ruajnëresource

records(shq.të dhënat nga baza) ose RR s,duke përfshirëRR s tregojnë mënyrën se si janë

organizuar(ang.mapping) të dhënat si Emri_Hostit – IpAdresa.Secili mesazh kthyes DNS

përmban një ose më shumëresource records.Në këtë dhe pjesën e ardhshme do të spejgojmë

shkurt DNS dhe resource records , më shumë detaje mund të gjeni në[Abitz 1993] ose në DNS

RFCs [RFC 1034;RFC 1035].

Njëresource record përbëhet nga katër rreshta të cilët kanë këto fusha :

(Emri ,Vlera , Tipi ,TTL)

TTL ështëtime to live për resource record (të dhënave në bazë) pra përcakton kohën kur një e

dhënë duhet të largohet nga kesh memoria.Në shembujt e mëposhtëm ne injorojm fushën e TTL

.Kuptimi i Emrit dhe Vlera varet nga Tipi :

Nëse Tipi=A,atëherë Emri është emri i hostit(hostname) dhe vlera është IP adresa për

atë host.Kështu Tipi A i të dhënave jep informatat standarde emri i hostit – Ip adresa.Si

shembull (relay1.bar.foo.com,143.37.93.126,A) është një e dhënë e tipit A.

Nëse Tipi =NS ,atëherë emri është domeni(sikur foo.com) dhe vlera është emri i hostit

të një serveri autoritativ DNS i cili din si të merr IP adresat për hostat në domen.Kjo e

dhënë përdoret gjatë rrugëtimit të pyetësorëve DNS në zingjirin e këtyre të fundit.Si

shembull (foo.com,dns.foo.com,NS) është tip NS i të dhënave.

Nëse Tipi=CNAME ,atëherë Vlera emri i plotë i hostit ndërsa akronimi i këtij emri tëhostit ruhet në fushën Emri.Kjo formë pra jep emrin kanonik të hostit për pyetësorët.Si

në shembull ,(foo.com , relay1.bar.foo.com , CNAME) është një e dhënë CNAME.

Nëse Tipi=MX , atëherë Vlera është emri kanonik të mail serverit(angl.mail-postë) i cili

ka një shkurtesë të tij që vendoset në fushën Emri. Si shembull është (foo.com.

mail.bar.foo.com,MX) është një e dhënë e tipit MX.Të dhënat MX lejon që emrat e

hostave t’i shënojmë përmes shkurtesave të thjeshta.Kështu me anë të dhënave MX një

kompani mund të përdorë një shkurtesë të tillë për mail serverat dhe për një nga serverët

e saj të tjerë(sikur ëeb serverat).Për me marr emrin e plotë,kanonik të një mail serveri

një klient duhet të kërkojë për një të dhënë MX ndërsa për serverin tjetër duhet të

kërkojë për një të dhënë të tipit CNAME.

Nëse një server ka autoritetin për një emer të caktuar të hostit atëherë serveri tillë do të ketë një

Tip A të dhnëave për emrin e hostit.(Edhe nëse serveri nuk e ka autoritetin e duhur për një emër

të caktuar hosti ai prap mund të përmbajë të dhëna të Tipit A në kesh).Nëse server nuk është

autoritativ për atë emër të hostit,atëherë serveri do të përmbajë të dhëna të Tipit NS për domenin

që përfshin edhe emrin e hostit,gjithashtu do të përmbajë një të dhënë të Tipit A i cili tregon Ip

adresën e serverit DNS që ruhet në fushën për Vlerë në rekordin Tipit NS .Si shembull një




Faqe 53

server edu TLD nuk është përgjegjës për hostin gaia.cs.umass.edu.Atëherë ky server do të

përmbajë të dhënat për domenin i cili përfshinë hostin :

gaia.cs.umass.edu psh.(umass.edu,dns.umass.edu,NS).Serveri eduTLD gjithashtu një të dhënë

tipit A e cila i shoqëron serverit DNS server.dns.umass.edu një IP adrese

psh.(dns.umass.edu,128.119.40.111,A).

DNS Mesazhet

Në kapitujt e mëhershëm ne pamë DNS pyetësorët dhe mesazhet si përgjigje të këtyre

mesazheve.Këto janë dy llojet e vetme të DNS mesazheve gjithashtu këto janë në format të

njejët sikur tregohet në figurën 2.23.Semantika e fushave në një mesazh DNS është si në vijim:

12 bajtat e parë janë në pjesën e headerit që tregojnë numrin e fushave.Fusha e

parëështë një numër 16 bita që identifikon këtë pyetësor.Ky identifikues kopjohet në

mesazhet përgjigjëse për pyetësorët e ndryshëm , duke i lejuar klientit me i pranu

përgjigjet e kërkuara.Janë një numër i flamujve (angl.flags) në fushën për flamuj.Një

flamur një bit pytësor/përgjigje tregon nëse mesazhi është pyetësor(0) apo

përgjigje(1).Një flamur 1 bit i quajtur autoritativ tregon nëse serveri është autoritativ për

emrin e kërkuar në pyetësor.Një flamur 1 bit rekursiv vendoset nëse klienti (hosti apo

serveri DNS) dëshiron që serveri të kryej kërkim rekurziv nëse nuk ka ndonjë të

dhënë.Një bit rekursiv vendoset edhe në përgjigje dhe tregon se serveri përkrahë

rekursionin.Në header janë gjithashtu katër numra të fushave .Këto fusha tregojnë llojet

e katër tipeve të dhënave që mund të jenë në header .

Figura 2.23 Formati i DNS mesazhit

Pjesa e pyetjes përmbanë informata për pyetësorin i cili kërkohet.Ky sektorë përmban

(1)një fushë për emrin që përmbanë emrin i cili kërkohet nga pyetësori dhe (2) një fushë

të tipit që përmbanë tipin e pytjes që pyet për emrin – psh. një adresë të hostit që lidhet

me emrin (Tipi A) ose mail serverin për emrin (Tipi MX).

Pjesa e përgjigjes nga DSN serveri përmbanëresource records për emrin e kërkuar .Siç e

pamë në çdoresource record kemi Tipin(psh. A,NS,CNAME dhe MX),pastaj Vlerën




Faqe 54

dhe TTL.Mesazhi mund të kthejë shumë RRs në përgjigje pasi emri i hostit mund të

ketë shumë IP adresa(psh. për ëeb serverët e replikuar siç është përmendur më herët në

këtë kapitull)

Pjesa e autoritetit ruan të dhënat për serverët e tjerë autoritativ.

Pjesa shtesë ruan të dhëna tjera shtesë.Si shembull,fusha e përgjigjes në një pyetësorë

MX përmbanëresource records të cilët ruajnë emrin kanonik të hostit të një mailserveri.Pjesa shtesë përmbanë një të dhënë të Tipit A e cila ka IP adresën për emrin

kanonik të hostit të një mail serveri.

Si do të dëshironit ju të dërgonit një DNS mesazh direkt nga hosti që jeni duke punuar në një

DNS server? Kjo lehtë mund të realizohet me një nslookup program i cili gjendet në shumicën

e platformave Ëindoës apo UNIX.Psh. një host nëËindoës përmes Command Prompt mund të

qaset direkt nënslookup programin thjeshtë duke shënuar “nslookup”.Pasi të keni thirrur

nslookup mund të dërgoni DNS mesazhe secilit DNS server(rrënjë,TLD apo autoritativ).Pasi të

ketë pranuar mesazhin nga DNS serveri, nslookup do të shfaqë informatat e pranuara në një

formë të lexueshme për njeriun.Alternativa tjera përveq nslookup janë edhe shumëëeb faqe të

cilët lejojnë përdorimin nga largësia nslookup.(Vetëm shëno “nslookup” në makinën kërkuese

dhe do të drejtoheni për një nga këto faqe).

Insertimi i të dhënave në një bazë të dhënave DNS

Pjesa e mësipërme më shumëështë marrë me mënyrën se si të dhënat merren nga një bazë e të

dhënave DNS.Mund të pyesni se si janë vendosur të dhënat në një bazë të tillë të

dhënave.Shikojmë se si kjo realizohet me një shembull specifik.Supozoni se ju keni themeluar

një kompani të quajtur Network Utopia.Gjëja e parë që do të bënit do të ishte regjistrimi i emrit

të domenit networkutopia.com në njëregistrar i cili është një grup komercial i cili verifikon nëse

domeni është unik dhe e ruan këtë emër të domenit në një bazë të dhënave DNS(siç do tëdiskutohet më poshtë) dhe për këtë shërbim kërkon një shumë të vogël të parave.Prej vitit 1999

njëregistrar i quajtur Network Solutions ka pasur monopolin për regjistrimin e domenëve në

.com , .net , .org domenët.Por në ditët e sotit ka shumëregistrar të tillë të cilët akreditohen nga

Internet Corporation for Assigned Names and Numbers(ICANN).Një listëkomplete të e

registrar të akredituar mund të gjendet nëhttp://www.internic.net .Kur regjistroni emrin e

domenit netëorkutopia.com në njëregistrar duhet të njoftoni këta të fundit me emrat dhe IP

adresat e DNS serverët autoritativ primar dhe sekondar.Supozojmë se emrat dhe IP adresat janë

dns1.networkutopia.com,dns2.networkutopia.com, 212.212.212.1 dhe 212.212.212.2.Për secilin

nga këta DNS serverëregistrar do të përkujdeset se të dhënat Tipi NS dhe Tipi A të vendosen në

TLD com serverët.Më saktë për serverin autoritativ primar për netëorkutopia.com registrar do tëvendosë në DNS bazën e të dhënave këto informata:

(networkutopia.com, dns1.networkutopia.com, NS)

(dns1.networkutopia.com, 212.212.212.1, A)

Gjithashtu duhet që të sigurohemi të dhënat e Tipit A për web serverinwww.networkutopia.com

dhe Tipi MX pra të dhënat për mail serverin shënohen në DNS serverin e juaj.(Deri vonë

përmbajtja e secilit DNS server është ndryshuar në mënyrë statistikore psh. nga një fajll

http://www.internic.net/


http://www.networkutopia.com/








Faqe 55

konfigurimi i krijuar nga menaxheri i atij sistemi.Ndërsa në kohët e fundit është shtuar opsioni

UPDATE në DNS protokollin i cili mundëson shënimin dhe ndryshimin e të dhënave direkt

përmes mesazheve DNS.[RFC 2136J dhe IRFC 3007 J tregojnë për këto azhurime dinamike ).

Fokusi në siguri

Pikat e dobëta të DNS

Kemi parë se DNS është një komponentë shumë e rëndësishme e infrastrukturës së Internetit që ofron shumë shërbime të rëndësishme duke përfshirëËeb dhe email të cilat pra shkurt nuk mund

të funksionojnë pa të.Prandaj ne mund të pyesim veten si mund të “sulmohet” DNS?A është i

sigurtë DNS duke parë se në rast të ndonjë sulmi të gjitha aplikacionet në Internet nuk do të

mund të përdoreshin.Sulmi i parë te i cilin mund t’a mendojmëështëDDoS bandwidth flooding

(shiko pjesën 1.6) kundër serverave të DNS.Për shembull një sulmues mund të dërgojë një

numër shumë të madh të paketave një serveri DNS aq shumë sa shumica e tyre nuk do të mund

të marrin përgjigje nga serveri.Një sulm i tillë I përmasave të mëdha ndodhi më 21 tetor

2002.Në këtë sulm u përdorëbotnet për të dërguar numër shumë të madh të ICMP ping

mesazheve secilit prej 13 DNS serverave kryesor.(ICMP mesazhet spjegohen në kapitullin 4 për

tani mjafton të dijmë se ICPM paketat janë një lloj i veçantë i IP datagramëve.)Fatmirësisht një sulm i tillë nuk solli dëme të mëdha dhe pati shumë pak ndikim në shfrytëzuesit e

Internetit.Sulmuesit arritën të dërgojnë një numër shumë të madh të paketave në serverat

kryesor por ata ishin të mbrojtur mirë nga filterët për paketa të cilët ishin të modifikuar ashtu që

të bllokojnë gjithë ICPM ping mesazhet të cilat kishin si destinacion serverat kryesor.Kështu

këta servera ishin kursyer nga sulmi dhe mund të vazhdonin punën pa problem.Për më shumë

shumica e DNS serverave ruajtën IP adresat e serverave kryesor dukë mundësuar që procesi i

përgjigjes së pyetësorëve të bartet direkt në këta serverë kryesor.Një sulm më i dëmshëm DDoS

kundër serverave të DNS me siguri do të ishte dërgimi i një numri të madh të kërkesave DNS

serverëve kryesor psh të gjithë serverave kryesorë të cilët merren me domenin .com.Do të ishte

më i vështirë filtrimi i këtyre kërkesave të cilat janë drejtuar DNS serverëve por prapë në

serverët kryesor(top level) nuk mund të qasemi aq lehtë sikur nëroot serverët.Por një sulm i tillë

mund të mos jetë aq serioz për shkak tëcaching në serverët lokal.

Ka edhe metoda tjera për të sulmuar një DNS .Sikur sulmi man-in-the-middle ku sulmuesi merr

pyetësorët nga hosti dhe kthen përgjigje të zbrazëta.Në “helmimin e DNS” sulmuesi dërgon

përgjigje në formë të mesazhe të tilla të ndryshme DNS serverëve duke i mashtruar ata dhe

duke bërë që ata të mbushen me të dhëna të tilla , të panevojshme.Secili nga këto sulme mund të

përdoret për të drejtuar një shfrytëzues tëweb në një faqe të caktuar të cilën sulmuesi

dëshiron.Megjithatë këto sulme vështirë mund të realizohen sepse duhet të merren paketat ose

duhet përmes throttling [Skoudis 2006].

Një sulm tjetër DNS i cili sulmon infrastrukturën e DNS në vend të shërbimeve të tij për të

inicuar një sulm DDoS kundër hostëve të caktuar(psh. mail serverit të universitetit).Në këtë lloj

sulmi , dërgohen një numë i madh i kërkesave shumë serverëve autoritativ ku secila nga këto

kërkesa do të ketë një adresë të rreme nga hosti.Kështu DNS serverët i dërgojnë përgjigjet hostit

tësulmuar.Nëse pyetësorët krijohen në atë mënyrë ashtu që përgjigjia të jetë shumë më e madhe

(në bajta) se kërkesa(i ashtuquajturi amplifikim) atëher sulmuesi mund të “pushtoj” një host të

caktuar pa pasur nevoj që vetë të ngarkojë trafikun e rrjetit.Por edhe ky sulm nuk ka pasur edhe

aq sukses,deri sot [Mirkovic 2005] .




Faqe 56

Pra në përgjithësi DNS çuditërisht është treguar mjaftë e fuqishme ndaj sulmeve të ndryshme të

cilat janë kryer kundër saj.Deri sot nuk ka pasur një sulm i cili do të pengonte shërbimet e

sistemit DNS edhe pse ka pasur sulme të shumta por të gjitha këto janë evituar me sukses nga

konfigurimi mjaft i mirë i DNS serverëve.

Pasi këta hapa të jenë përfunduar vizitorët mund të shikojnë faqen tonë apo ju mund të dërgoniemail punëtorëve në kompanin tuaj.Të mbyllim diskutimin për DNS duke vërtetuar këtë fjali.Ky

vërtetim na përforcon atë që vetëm e kemi mësuar për DNS.Supozojmë se Alice e cila është në

Australi dëshiron të shohëëeb faqen www.networkutopia.com. Sikur është përmendur edhe më

herët hosti i saj fillimisht i dërgon mesazh DNS serverit lokal.Pastaj ky server lokal do të lidhet

me një TLD com server.(Serveri lokal do të duhej të kontaktonte DNS serverin root(kryesor)

nëse adresa e TLC com serverit nuk është e ruajtur në kesh).Ky TLD server ruan të dhënat e

Tipit NS dhe Tipit A pasi registrar i vendoste këto të dhëna në të gjithë TLD com serverët.TLD

com serveri i kthen përgjigjen DNS serverit lokal të Alice,përgjigje e cila përmbanë dy të dhëna

nga baza(resource records).Serveri lokal DNS pastaj dërgon një DNS pyetësor në 212.212.212.1

duke kërkuar Tipin A të dhënave që i përgjigjet www.networkutopia.com. Kjo e dhënë ka IP

adresën e ëeb serverit të dëshiruar psh. 212.212.71.4 të cilin serveri lokal DNS ia kthen prapa

hostit të Alice.Tani shfletuesi i Alice mund të realizojë një TCP lidhje në hostin 212.212.71.4

dhe të dërgojë një kërkesë HTTP përmes kësaj lidhje.Uhh Ka shumë gjëra që ndodhin në

prapaskenë gjatë shfletimit të njëweb faqeje.

2.6 Aplikacionet PEER-TO-PEER

Aplikacionet e përshkruara në këtë kapitull deri më tani – duke perfshirë web, e-mail dhe DNS –

të gjitha me arkitekturen klient-server me besim të madh në infrastrukturen e serverave

gjithmonë në shërbim. Rikthim nga seksioni 2.1.1 që me arkitekturën P2P, besimi nëinfrastrukturën e serverave gjithmonë në shërbim është minimal (apo fare). Përndryshe, palët që

lidhen, të quajtur peers (shokë), komunikojnë direkt me njëri tjetrin. Shokët (peers) nuk janë

pronësi e ndonjë servis provajderi, por janë kompjuterë dhe llaptopë të kontrolluar nga

shfrytëzuesit.

Në ketë seksion ne do të egzaminojmë tri aplikacione të ndryshme që janë veçanërishtë

të përshtatshme për dizajn P2P. E para është shpërndarja e fajllave, ku aplikacioni shpërndanë

ndonjë fajll nga një burim në një numër të madh të shokëve (peers). Shpërndarja e fajllave është

një vend i mirë të fillojmë investigimet e P2P, pasiqë ekspozohet qartë arkitektura e P2P. Si

shembull specifik për shpërndarjen e

fajllave, ne përshkruajmë sistemin e njohur BitTorrent. Aplikacioni i dytë në P2P që do të

egzaminojmë është një databazë e shpërndarë nëpër një komunitet të madhë të shokëve (peers).

Për këtë aplikacion ne do të eksplorojmë konceptin e “Distributed Hash Table (DHT)”.

Përfundimisht për aplikacionin tonë të tretë, ne do të egzaminojmë Skype, një aplikacion

fenomenalisht i suksesshëm në telefoninë në internet P2P.












Faqe 57

2.6.1 Shpërndarja i fajllave P2P

Ne fillojmë zhvillimin në P2P duke konsideruar si një aplikacion shum natyral, duke shpërndarë

një fajll të madhë nga një server në një numër të madhë të shokëve (peers).

Fajlli mund të jetë një version i ri i sistemit operativ Linux, një softver për ndonje sistem

operativ egzistues ose aplikacion, një fajll muzike MP3, ose nje video fajll MPEG. Në

shpërndarjen klient-server, serveri duhet të dërgoje një kopje të fajllit në setcilin prej shokëve

(peers) – duke ngarkuar shumë serverin dhe konsumuar një sasi të madhe të kapacitetit tëserverit. Në shpërndarjen e fajllave P2P, setcili nga shokët mund të rishpërndajë cilëndo pjesë të

fajllit që i ka arritur tek ndonjë shok tjeter, kështuqë ndihmojnë serverin në shpërndarje të

fajllave. Nga ky shkrim (Vjeshtë 2009), protokolli më i popullarizuar në shpërndarjen e fajllave

P2P është BitTorrent [BitTorrent 2009]. Zhvilluar origjinial nga Bram Cohen (shikoni

intervistën me Bram Cohen në fund të këtij kapitulli), tashmë janë shumë klientë të pavarur

BitTorrent në përputhje me protokollet e BitTorrent, sikurse janë një numer e klientëve me

shfletues të Web-it që janë në perputhje me protokollet HTTP. Në këtë nënseksion, ne fillimisht

egzaminojmë vetë-shkallëzimin e arkitekturës P2P në kontekstion e shpërndarjes së fajllave. Ne

pastaj përshkruajmë BitTorrent në detaje.

Shkallëzimi i arkitektures P2P

Për të krahasuar arkitekturën klient-server me arkitekturën peer-to-peer, dhe për të ilustruar

trashigiminë e vetë-shkallëzimit të P2P, ne tani marrim në konsideratë një model të thjeshtë

sasior për të shpërndarë një fajll në një set të caktuar shokësh (peers) për të dy llojet e

arkitekturave. Siq është paraqitur në figurën 2.24, serveri dhe shokët (peers) janë të lidhur në

internet. Është paraqitur shkalla e ngarkimit të serverit (U s), shkalla e ngarkimit të I-shokësh

(U), dhe shkalla e shkarkimit të I-shokësh (di). Gjithashtu është paraqitur madhësia e fajllit që

shpërndahet (në bit) – F, dhe numri i shokëve që duan të marrin një kopje të fajllit (N). Koha e

shpërndarjes është koha për të marrë një kopje të fajllit në të gjithë N-shokët. Në analizën tonë

mëposhtë të kohës së shpërndarjes, për të dy arkitekturat klient-server dhe P2P, ne bëjmë

supozim të thjeshtë që berthama e internetit ka mjaft kapacitet, duke lënë të kuptohet se të gjitha

pengesat janë në qasje të rrjetit.




Faqe 58

Figura 2.24 – Një ilustrim i problemit të shpërndarjes së fajllit

Ne poashtu supozojmë se serveri dhe klientët nuk bashkpunojnë në asnjë aplikacion tjetër të

rrjetave, për këtë arsye i gjith kapaciteti i ngarkimit dhe shkarkimit mund të shfrytëzohet për

shpërndarje të këtij fajlli.

Së pari të përcaktojmë kohën e shpërndarjes për arkitekturën klient-server, të cilën e

paraqesim me Dcs. Në arkitekturen klient-server, asnjë nga shokët nuk ndihmon në shpërndarje

të fajllit. Ne bëjmë këto vëzhgime:

Serveri duhet të dërgoj një kopje të fajllit në setcilin prej N-shokëve. Ashtuqë serveri

duhet të dërgoje NF bita. Prej që shkalla e ngarkimit të serverit është Us, koha për

shpërndarjen e fajllit duhet të jetë të paktën NF/Us.

Le të jetë dmin për shkallën minimale të shkarkimit të shokut (peer),

dmin = min{d1, d p, …, dn}. Shoku (peer) me shkallen e shkarkimit minimale nuk mund ti

përvetësoj të gjithë F-bitat të fajllit në më pak se F/dmin sekonda. Ashtuqë koha

minimale e shpërndarjes është të pakten F/dmin.

Duke bashkuar këto dy vëzhgime ne fitojmë

{ }




Faqe 59

Kjo të jep një kufi më të vogël në kohën minimale të shpërndarjes për arkitekturën klient-server.

Në problemet në detyrat e shtëpisë ju do të tregoni se serveri mundet organizoj dergimin ashtuqë

kufiri i vogël të arrihet. Pra le të marrim kufirin e vogël si kohën e shpërndarjes aktuale, ajo

është,

(2.1)

Ne shohim nga ekuacioni 2.1 se për N madhësi të caktuar, koha e shpërndarjes klient-server

është dhënë nga NF/us. Kështuqë, koha e shpërndarjes rritet linearisht me numrin e shokëve N.

Pra, për shembull, nëse numri i shokëve prej një jave në tjetrën rritet për mijëra-herë nga njëmije

në njëmilion, koha e duhur për shpërndarje të fajllit tek të gjithë shokët rritet për 1000.

Le të shohim tani analizën e ngjashme për arkitekturën P2P, ku qdo shok mund të

ndihmojë serverin ta shpërndajë fajllin. Në veçanti, kur një shok pranon disa të dhëna nga fajlli,

ai mund të përdorë kapacitetin e vetë të ngarkimit që të shpërndajë të dhënat tek të tjerët shokë.

Për të kalkuluar kohën e shpërndarjes për arkitekturën P2P është disi më e komplikuar se sa për

arkitekturën klient-server, pasiqë koha e shpërndarjes varet se si qdo shok shpërndanë pjesët e

fajllit tek shokët e tjerë. Megjithatë, një shprehje e thjeshtë për kohën minimale të shpërndarjesmund të përcaktohet. Për ta caktuar, fillimisht ne bëjmë këto vëzhgime:

Në fillim të shpërndarjes, vetëm serveri përmbanë fajllin. Për ta marre atë në

komunitetin e shokëve, serveri duhet të dërgojë qdo bit të fajllit të paktën njëherë në

lidhjen e tij. Ashtuqë koha minimale e shpërndarjes të jetë të paktën F/u s. (Përndryshe

nga skema klient-server, një bit i dërguar një herë nga serveri nuk mund të dergohet nga

serveri prap, ndërsa shokët mund të shpërndajnë këtë bit në mes vete.)

Sikurse në arkitekturën klient-server, shoku me shkallën më të vogël të shkarkimit nuk

mund të marr të gjith F bitat e fajllit në më pak se F/dmin sekonda. Ashtuqë kohaminimale e shpërndarjes ështe të paktën F/dmin.

Përfundimisht, kapaciteti total i ngarkimit të sistemit është i barabartë me shkallën e

ngarkimit të serverit plus shkallët e ngarkimit të setcilit shok në vete, kjo është, utotal = us

+ u1 + ... + un. Sistemi duhet të ngarkojë F bita të setcilit prej N-shokëve, ashtuqë të

dergoj total NF bita. Kjo mund të bëhet me një shkallë më të madhe se u total. Ashtuqë

koha minimale e shpërndarjes është gjithashtu të paktën NF/(us + u1 + ... + un).

Duke bashkuar këto dy vëzhgime, ne fitojmë kohën minimale të shpërndarjes për P2P

∑

} (2.2)

Ekuacioni 2.2 jep kufi më të vogël për kohen minimale të shpërndarjes për arkitekturën P2P. Del

se nëse ne imagjinojmë se setcili shok mund të shpërndajë një bit menjëherë pasi që e pranon një

bit, atëhere kemi skemen e shpërndarjes që aktualisht arrin këtë kufi të vogël. (Ne do të






Faqe 61

Figura 2.25 – Koha e shpërndarjes per arkitekturat P2P dhe klient-server

BitTorrent

BitTorrent-i është një P2P(Peer to Peer) protokol për shpërndarjen e fajllave[BitTorrent 2009].

Në gjuhën e BitTorrent-it, koleksioni i te gjithë peer-save që marrin pjesë në shpërndarjen e një

fajlli të caktuar quhet torrent . Peer-sat në torrent shkarkojnë pjesë(chunks) të barabarta nga fajlli

prej njëri-tjetrit, me një madhësi tipike të këtyre pjesëve prej 256 Kb. Kur një peer se pari kyqet

në një torrent, ai nuk ka pjesëza(chunks). Me kohë ai mbledh shumë pjesëza. Përderisa ai

shkarkon pjesë njëkohësisht transferon(uploads) pjesë tek peer-sat tjerë. Kur një peer arrin të

marr komplet fajllin, ai mund të shkëputet nga torrent-i(egoist) ose mund të qëndroj në torrent

dhe të vazhdoj të transferoj pjesë peer-save tjerë(altruist).Gjithashtu, çdo peer mund të largohet

nga torrent-i në çdo kohë me vetëm disa pjesë dhe më vonë mund të kthehet prapë në torrent tëvazhdoj të shkarkoj pjesën e mbetur.Të vështrojmë tani për së afërmi se si operon BitTorrent-i.

Pasiqë BitTorrent-i është një sistem dhe protokol i komplikuar, ne do të përshkruajmë

mekanizmat e tij kryesor,duke fshehur disa detaje, në këtë mënyrë do të koptojmë më qartë

operimin e Bittorrent-it.Çdo torrent ka një (infrastructure node) që quhet gjurmues(tracker). Kur

një peer i bashkangjitet një torrent-i, e regjistron vetveten me anë të gjurmuesit dhe periodikisht

e informon atë se ende ndodhet në torrent. Në këtë mënyrë, gjurmuesi mban gjurmë për peer-sat

që marrin pjesë në torrent. Në torrent mund të ketë më pak se dhjetë ose më shumë se mijëra

peer-sa që marrin pjesë në të njëjten kohë. Siq shihet në figurën 2.26, kur një peer-s i ri, Alice, i

bashkohet torrent-it, gjurmuesi kuturu(randomly) përzgjedh një nënbashkësi të peer-save(p.sh.

50) nga bashksia e peer-save pjesëmarrës dhe i dergon Ip adresat e këtyre 50 pjesëmarrësve tek

Alice. Duke poseduar listen e peer-save, Alice tenton të vendos konektime TCP konkuruese me

të gjithë peer-sat në këtë list. Le ti quajmë të gjithë peer-sat me të cilët Alice i a del që të vendos

lidhje peer-sat fqinj(“neighboring peers”) (Në figuren 2.26, Alice shihet të ketë vetëm tre peer -

sa fqinj. Normalisht do duhej tkishte shumë më shumë). Me kalimin e kohës disa nga ata peer-sa

mund të largohen dhe peer-sa të tjerë(jashtë atyre 50 të parëve) tentojnë të vendosin lidhje TCP

me Alice. Kështu peer-sat fqinj të peer-sit do të ndryshojnë me kohë. Në çdo kohë , secili peer

do të ketë një nënbashkësi nga fajlli, dhe peer-sa të ndryshëm që kanë nënbashkësi të ndryshme.




Faqe 62

Periodikisht, Alice do t’i pyes secilin nga peer -sat fqinj(përmes lidhjes me TCP) pë listën e

pjesëve që i kanë. Nëse Alice ka L peer-sa fqinj ajo do të përmbaj L lista të pjesëve. Me këtë

njohuri, Alice do të dergoj kërkesat për pjesët që nuk i ka. Kështu në çdo kohë, Alice do të ketë

një nënbashkësi të pjesëve dhe do të dijë se cilat pjesë i kanë fqinjët e saj.Me këto informata,

Alice do të marr dy vendime kryesore. Së pari, se cilat pjesë duhet ti kërkoj nga nga fqinjët e

saj? Dhe se dyti cilit nga fqinjët e tu duhet dergojë kerkesen për pjesëza? Që të vendos se cilën pjesë ta kërkoj, Alice përdor një teknik që quhet Rarest first(më e ralla e para).

Figura 2.26 Shpërndarja e file-it me BitTorrent

Ideja është të përcaktoj, prej pjesëve qe nuk i ka ato pjesë të cilat janë më të rrallat tek fqinjet e

saj(kjo dmth pjesët te cilat kanë më së paku kopje të perseritura në fqinjet e saj) dhe ti kërkoj

këto së pari. Në këtë mënyrë, pjesët e rralla rishpërndahen më shpejt dhe tentojnë të barazojnë

numrin e kopjeve të çdo pjese në torrent.Për të caktuar se cilëve kerkesa Alice duhet tu pergjigjet, BitTorrent-i përdor një algoritëm të

shkëmbimit. Ideja themelore është që Alice tu jep prioritet fqinjeve të cilët janë momentalisht

duke e furnizuar atë me të dhëna në shpejtësinë më të madhe.Kështu për secilin nga fqinjet e saj

Alice vazhdimisht e llogarit shpejtësinë me të

cilen ajo pranon bita dhe përcakton 4 peer-sat te cilët po e furnizojnë atë me bita në shpejtsinë

më të madhe. Pastaj ajo u dergon bita reciprokisht këtyre 4 peer-save. Çdo 10 sekonda, ajo e




Faqe 63

rillogarit shkallën me të cilën pranon të dhëna dhe mund të modifikoj bashkësinë prej 4 peer-

save. Në gjuhën e BitTorrent-it, këto 4 peer-sa thuhet të jenë të pangopura(unchoked). Është me

rëndësi të ceket se çdo 30 sekonda Alice spontanisht zgjedh një fqinj shtesë dhe i dergon pjesë.

Të supozojmë se fqinji I përzgjedhur spontanisht quhet Bob. Në gjuhën e BitTorrent-it, Bob-i

thuhet të jetë (optimistically unchoked). Pasi Alice po i dërgon të dhëna Bobit ajo mund të bëhet

njëra nga top katërshja e Bobit, ku në këtë rast Bobi do dergonte të dhëna tek Alice. Nëse

shkalla me të cilën Bobi dergon të dhëna Alicies është mjaft e lart, atëherë edhe Bobit mund të bëhet njëri nga top kater fqinjet e Alice. Me fjalë të tjera, çdo 30 sekonda Alice do të përzgjedh

spontanisht një partner për shkëmbim të të dhënave dhe do të filloj të shkëmbej të dhëna me të.

Nëse të dy peer-sat janë të kënaqur me shkëmbimin ata do të vendosin njëri tjetrin në listen e top

4 transferuesve(uploaders) dhe vazhdojnë shkëmbimin me njëri-tjetrin derisa njëri nga ta nuk

gjen një partner më të mirë. Efekti i kësaj është se peer-sat e aftë që transferojnë në shkallë të

njëjta tentojnë të gjejnë njëri-tjetrin. Selektimi spontan i një fqinji i lejon peer-sat e rinj të marrin

pjesë(chunks), në mënyrë që të kenë qka të transferojnë. Të gjithë fqinjët tjerë përveq këtyre 5

janë të ngopur(choked),pra ata nuk marrrin asnjë pjesëz(chunk) nga Alice. BitTorrent-i ka një

numër të mekanizmave interesant të cilët nuk diskutohet këtu, duke përfshir pjesët(mini-chunks),

piplining, zgjedhja e parë spontane, modi fundi i lojës, anti-snubbing[Cohen 2003].Mekanizmi stimulues për transport qe sapo e përshkruam zakonisht njihet edhe si tit-for-

tat[Cohen 2003]. Është vërejtur se kjo skemë stimuluese mund të evitohet[Liogkas 2006; Locher

2006; Paitek 2007].Megjithatë ekosistemi i BitTorrent-it është i suksesshëm, me miliona peer-sa

aktiv të cilët që shkëmbejnë fajlla në qindra mijëra Torrent-a. Nëse BitTorrent-i do të dizajnohej

pa tit-for-tat (ose një variant), ai edhe mund të mos ekzistonte pasiqë shumica e përdoruesve do

të ishin freeriders[Saroiu 2002].

Variante interesante te protokollit te BitTorrent-it janë propozuar[Guo 2005; Piatek 2007].

Poashtu, shumë nga aplikacionet live streaming P2P si psh PPLive dhe PPStream, janë inspiruar

nga BitTorrent-i[Hei 2007].

2.6.2 HASH TABELAT E DISTIRBUARA(DHTs)

Një komponent kritike e shumë P2P aplikacioneve dhe e aplikacioneve tjera të distribuara është

indeksi(kjo është, një bazë e të dhënave e thjeshtë) qe përmban operacione të kërkimit dhe

modifikimit. Kur kjo bazë e të dhënave është e shpërndarë, peer-sat do të fshehin përmbajtjen

dhe dërgimin e pyetsorëve mes tyre. Pasiqë indeksimi i informatave dhe kërkimi është një

komponent kaq kritike në këto sisteme, tani do të shqyrtojmë një teknik të njohur të indeksimit

dhe kërkimit, Hash tabelay e distribuara(DHT).

Të konsiderojmë ndërtimin e një baze të të dhënave të distribuar nëpër një numër të

madh(mundet ehde miliona) të peer-save të cilët mbështesin indeksimin dhe pyetsoret e thjeshtë.

Informatat e ruajtura në bazën tonë të të dhënave do të pëmbajnë qifte të qelsave dhe vlerave.

Për shembull, qelsat mund të jenë numrat e sigurisë dhe vlerat mund të korrespodojnë me emrat

e njerëzve; në këtë rast, një shembull i çiftit çelës-

vlerë do të ishte(156-45-7081,Johnny Wu).Ose çelësi mund të jetë emri i përmbajtjes(p.sh.

emrat e filmave, albumeve dhe softverit), dhe vlerat mund të jenë IP adresa në të cilat është

ruajtur përmbajtja; në këtë rast, një shembull i çiftit çelës-vlerë është(Led Zeppelin IV,




Faqe 64

203.17.123.38). Peer-sat e pyesin bazën e të dhënave duke siguruar çelësin: nëse në bazën e të

dhënave ka çifte(çelës,vlerë) që përputhen me çelësin atëherë baza e të dhënave i kthen peer-sit

qe pyet çiftin që përputhet me çelësin. Kështu, për shembull, nëse një bazë e të dhënave ruan

numrat social të sigurimit dhe emrat e tyre korrespondues, një peer mund të pyes për një numër

sigurimi të caktuar, baza e të dhënave do të kthej emrin përkatës pra emrin e personit qe ka at

numer të sigurimit. Peer-sat poashtu mund të fusin çifte (çelës,vlerë) në bazën tonë të të dhënave. Ndërtimi i duhur i një baze të të dhënave të tillë bëhet me arkitekturën klient-server për të cilën

të gjitha çiftet (çelës,vlerë) ruhen në një server qendror.Qasja e centralizuar e është përdorur

edhe me heret tek sistemet P2P si Napster-i. Por problemi është më sfidues dhe më interesant në

sistemet e distribuar të cilat përmbajnë miliona peer-sa të konektuara por pa autoritet qendror.

Në një sistem P2P, ne duam te distribuojmë çiftet(çelës,vlerë) nëpër të gjithë peer-sat ashtu qe

çdo peer të mbaj një nënbashkësi të të gjitha çifteve(çelës,vlerës,vlerë). Një qasje naive në

ndërtimin e P2P bazës së të dhënave është (1) shpërndarja random e çifteve(çelës,vlerë) nëpër

peer-sa dhe (2) të bëjmë që çdo peer të mbaj një listë të IP adresave të gjithë peer-save që marrin

pjesë. Në këtë mënyrë, peer-si që pyet mund të dergoj pyetjen të gjithë peer-save, dhe peer-sat të

cilët përmbjanë çifte(çelës,vlerë) që përputhen me çelësin mund t’i përgjig jen me këto çifte

peer-sit që pyet.Kjo qasje është plotësisht e pa shkallëzuar pasiqë do të kërkonte çdo peer të gjej

peer-sat tjerë(mund të jenë edhe milliona) dhe çka është edhe më keq tu dërgoj çdo pyetsor të

gjithë peer-save.

Tani do të prezantojmë një qasje më të sofistikuar për dizajnimin e P2P bazës së të dhënave. Së

pari ia bashkangjesim një identifikues çdo peer-si, ku çdo identifikues është një numër I rendit

[ ] Duhet pasur parasysh se Duhet pasur parasysh se çdo identifikues I tillë mund të

shprehet me një n-bit reprezantim.Poashtu të kërkojmë që çdo çelës të jetë një numër I shkallës

së njëjtë. Lexuesi mund të ketë vërejtur se shembujt e çelësave që u përshkruan më heret nuk

ishin numra. Për të krijuar numra nga këta çelësa do të përdorim hash funksionin qe mapon çdo

çelës(psh numri I sigurimit) në numër mes

[

]Hash funksioni është një funksion një

me shumë për të cilin çdo dy të hyra të ndryshme mund të kenë të njëjtën vlerë dalëse, por gjasa

qe te kenë vlerën dalëse të njëjtë është relativisht e vogël.(Përdoruesit që nuk dine shumë për

hash funksionet mund të shikojnë kapitullin 7 ku diskutohen në detaje hash funksionet). Hash

funksioni është publikisht I disponueshëm për të gjithë peer-sat në system. Andaj kur I

referohemi një çelësi në fakt I jemi referuar vlerës hash të çelësit original. Kështu për shembull

nëse çelësi original është “Led Zeppelin IV” çelësi do të jetë numri që është I barabart me

hashin e “Led Zeppelin IV”. Gjithashtu, pasi po I përdorim hash-at e çelësave në vend të

çelësave atëherë do ti referohemi bazës së të dhënave të distribuar si Hash tablela e distribuar

(HDT).

Të marrim parasysh tani ruajtjen e çiftit(çelësi,vlera) në DHT. Qështja kryesore është përcaktimi

I një rregulle për bashkëngjitjen e çelësave peer-save. Kemi thënë se çdo peer ka një numer

identifikues dhe se çdo çelës është gjithashtu një numër I të njëjtës shkallë, andaj një qasje e

natyrshme do të ishte t’I bashkangjesim çdo peer -si çiftin(çelës,vlerë) identifikuesi I të cilit

është më afër çelësit. Për implementimin e një skeme të tillë duhet të definojmë se çka po

nënkuptojmë me “më I afërt” për të cilën mund të marrim kuptime të ndryshme.

Le të definojmë peer-sin me të afërt si vlerën suksesive të çelësit. Që ta kuptojmë më mire ti

referohemi një shembulli. Supozojmë se n=4 ashtu që të gjithë peer-sat dhe identifikuesit e




Faqe 65

çelësit janë në mes [0,15]. Në vazhdim të supozojmë se janë 8 peer-sa në sistem me identifikues

1, 3, 4, 5, 8, 10, 12 dhe 15. Se fundi, të supozojmë se duam të ruajmë çiftin çelës-vlerë

(11,Johnny Wu) në njërin nga 8 peer-sat. Poe në cilin peer saktësisht? Pasiqë peer-si I 12 është

vlera suksesive për çelësin 11, ne do të ruajmë çifitn (11, Johnny Wu) në peer-sin 12. [Që ta

kompletojmë definicionin e “më afër” çelësit, nëse çelësi është I barabart me ndonjërin nga

identifikuesit e peer-save, e ruajmë çifitin(çelës, vlerë) në atë peer; dhe nëse çelësi është më I

madh se të gjithë identifikuesit e peer-save ne përdorim modulo e ruajmë çiftin (çelës,vlerë)në indentifikusin më të vogël.]

Tani të supozojmë se një peer, Alice, dëshiron të vendos një çift(çelës, vlerë) në DHT. Ajo së

pari e gjen peer-sin I cili ka numrin identifikues më afër çelësit, pastaj ajo ia dërgon mesazhin

peer-sit dhe jep instruksione që ai ta ruaj këtë çift. Por si do ta përcaktoj Alice se cili është peer-

si që ka identifikuesin më afër çelësit? Nëse Alice do të ruante ID dhe IP adresat e peer-save në

sistem ajo do të mund ta gjente peer-sin me të afërt. Por në këtë mënyrë çdo peer duhet të ruante

gjurmë të të gjithë peer-save tjerë në DHT – e kjo do të ishte shumë jo praktike për një sistem I

cili ka miliona peer-sa.

DHT-ja rrethore

Që të adresojmë këtë problem të shkallës, t’I organizojmë peer -sat në rreth. Atëherë çdo peer-s

do të mbante gjurmë të peer-sit pauses(modulo ). Një shembull I tillë është paraqitur në

figurën 2.27(a). në këtë shembull, n është prapë 4 dhe janë gjithsejt 8 peer-sa sikur në

shembullin paraprak.

Figura 2.27 (a) DHT rrethore. Peer-si 3 dëshiron te përcaktoj kush është përgjegjës për çelësin

11. (b) Një DHT rrethore me shkurtesa.

Çdo peer mban gjurmë të peer-sit pauses; për shembull peer-si 5 e dine ID-në, IP adresën dhe

identifikuesin e peer-sit 8 dhe jo doemos duhet të dijë për peer-sat e tjerë që gjenden në DHT.




Faqe 66

Kjo vendosje rrethore e peer-save është rast special I një rrjeti të mbishtresuar(overlay network).

Në një rrjet të mbishtresuar peer-sat nga një rrjet logjik abstrakt I cili gjendet mbi nënshtresën e

rrjetit kompjuterik pëmbajnë linqe fizike, ruter dhe hosta. Linqet në një rrjet të mbishtresuar nuk

janë linqe fizike por janë lidhje virtual në mes të çifteve të peer-save. Në rrjetin e mbishtresuar

në figuren 2.27 (a) janë 8 peer-sa dhe b linqe të mbishtresuara ndërsa në atë në figuren 2.27(b)

janë 8 peer-sa dhe 16 linqe te mbishtresuara. Një link I mbishtresuar përdor shumë linqe fizikedhe rutera fizik në rrjetin nënshtresor.

Duke përdorur rrjetin rrethor në figuren 2.27(a) të supozojmë se peer-si 3 dëshiron të caktoj cili

peer në DHT përmban çelësin 11[ose për të vendosur ose pyetur për një çift(çelës,vlerë)]. Duke

përdorur mbishtresat rrethore peer-si 3 krijon një mesazh që thotë: ”Kush është përgjegjës për

çelësin 11?” dhe e dërgon këtë mesazh tek peer -si pauses, peer-si 4. Kurdo që një peer pranon

një mesazh të tillë, pasiqë e di numrin identifikues të peer-sit pauses të tij e përcakton se a është

ai përgjegjës për çelësin në pyetje. Nëse e vëren se peer-si pauses nuk është përgjegjës për

çelësin ai thjesht ia dërgon atij mesazhin. Pra për shembull kur peer-si 4 merr mesazhin që pyet

për çelësin 11, e vëren nga numri identifikues se pasuesi I tij nuk është prgjegjës për atë se

pasuesi I tij çelës dhe thjeshtë Ia dërgon atij mesazhin, pra peer-sit 5.ky process vazhdon derisa

mesazhi të mbërrij tek peer-si 12, I cili e kupton se është peer-si më I afërt me çelësin 11. Në

këtë pike peer-si 12 I dërgon një mesazh peer-sit të origjinës, pra peer-sit 3 duke e njoftuar se

është përgjegjës për çelësin 11.

Kjo DHT rrethore është një zgjidhje mjaft e mire pasiqë e zvogëlon shumën e informatave të

mbishtresuara që çdo peer duhet të menagjoj.Në veçanti, çdo peer

është i njohur vetëm me dy peer-sa tjerë, me pasuesin e tij dhe parardhësin e tij.(Peer-si e njeh

paraardhsin e tij pasiqë ai I dërgon mesazhe). Por kjo zgjedhje sjell një problem të ri. Edhe pse

çdo peer është në dijeni të vetëm dy peer-save fqinj, që të gjej peer-sin përgjegjës për çelës(në

rastin më të keq), të gjithë peer-sat në DHT duhet të të përcjellin një mesazh nëpër rreth;

mesatarisht N/2 mesazhe duhet të dërgohen.

Andaj, në dizajnimin e një DHT-je, është një barazi në mes të numrit të fqinjëve çdo peer duhet

të gjej dhe numrit të mesazheve që DHT-ja duhet të dërgoj për të zgjidhur një pyetje të vetme.

Në njërën anë nëse çdo peer mban gjurmë të të të gjithë peer-save tjerë (mesh overlay), atëherë

vetëm një mesazh dërgohet për një pyetje por çdo peer duhet të mbajë gjurmë të N peer-save. Në

anën tjetër, me një DHT rrethore, çdo peer mban gjurmë të vetëm dy peer-savefqinj por duhet të

dërgoj mesatarisht N/2 mesazhe për të zgjedhur një pyetje(query). Por fatmirësisht ne mund të

dizajnojmë DHT-në ashtu që numri I fqinjëve për peer dhe numri I mesazheve për pyetje të

mbahet në një sasi të pranueshme. Ky dizajn bëhet duke përdorur rrjetin mbishtresor rrethor si

bazë dhe të shtojmë “shortcuts” ashtu që çdo peer të mbajë gjurmë jo vetëm të peer -sit pauses

por poashtu të një numri relativisht të vogël shortcut peer-save të shpërndar nëpër rreth. Një

shembull I një DHT-je të tillë është paraqitur në figurën 2.27(b). Shortcut-at përdoren për të

dërguar mesazhet e pyetsorëve. Kështu kur një peer merr një mesazh që pyet për çelës, ai e

përcjell atë tek fqinji(fqinji mund të jetë pasuesi ose shortcut fqinj) I cili është më afër çelësit.

Andaj në figurën 2.27 (b) kur peer-si 4 merr mesazhin që pyet për çelësin 11, e kupton se peer-

si më I afërt me çelësin nga fqinjët e tij është peer-si 10. Pra vërejmë se shortcut-at e zvogëlojnë

numrin e mesazheve që duhet dërguar për zgjedhjen e një pyetjeje.




Faqe 67

Pyejta e rradhës është: Sa shortcut duhet të ketë çdo peer dhe cilët peer-sa duhet të jenë shortcut

të peer-sit në fjalë? Kësaj pyetje ju kushtua rëndësi në komunitetin e hulumtimeve[Stoica 2001;

Rowstron 2001; Ratnasamy 2001; Zhao 2004; Maymounkov 2002; Garces-Erce 2003]. U

vërejtë se DHT-ja mund të dizajnohet në atë mënyrë që numri I fqinjëve për këtë peer dhe numri

I mesazheve për pyetje ështv O(logN), ku N është numri I peer-save. Ky dizajnim vendos

kompromis në mes të përdorimit të mesh overlay dhe circular overlay.

Peer Churn

Ne sistemet P2P, nje PEER mund te vije apo shkoje pa lajmerim. Tutje duke e dizajnuar nje

DHT, ne gjithashtu duhet te jemi te vemendshem per ruajtjen e DHT ne prezencen e llojit te tille

te peer churn. Per te pasur nje parafytyrim me te mire per te kuptuar se si mund te realizohet, le

ta konsiderojme edhe nje here rrethin e DHT ne fig 2.27 (a). Per ta trajtuar peer churn, ne do te

kerkojme secilen peer to track (qe eshte ta dije IP adresen)eshte i pari dhe i dyti pasues; per

shembull, peer 4 tani "le gjurme" te dyjat 5 dhe peer e 8. Ne gjithashtu kerkojme secilen peer qe

ne menyre periodike te verifikojne se eshte qe dy suksese jane gjalle (per shembull, ne menyre

periodike te dergojne mesazhe ping atyre dhe ti pres ti kthejne pergjigje). Le te konsiderojme qeDHT eshte mbajtur kur nje peer befas largohet. Per shembull, supozojme peer 5 ne fig. 2.27 (a)

abruptly largohet. Ne kete rast, te dy peers paraprak peer-in e kaluar (4 dhe 3) mesojme se 5 ka

qene e kaluar, perderisa me nuk jep pergjegje (nuk reagon) ne ping mesazhet. Peers 4 dhe 3 tutje

kane nevoje per update te pasuesit te informacionit. Le te shihim se si e ben update statusit te tij

peer 4:

1. Peer 4 zevendeson pasuesin e tij te pare (peer 5) me pasuesin e dyte (peer 8).

2. Peer 4 pastaj pyet pasues e tij te pare (peer 8) per identifikatorin dhe IP adress e pasuesin e tij

te menjehershem (peer 10). Peer 4 pastaj ben peer 10 pasuesin e tij te dyte.Ne problemet e

homeworkut, ju do te duhet te determinoni se si peer 3 e ben update informates mbulese te

tij.Pasi qe e shqyrtuam shkurtimisht se qfare ka per tu bere kur nje peer largohet, tani le te

shiqojme se qfare ndodh kur nje peer deshiron te bashkangjitet DHT. Le te themi se nje peer me

13 identifikatore deshiron te bashkangjitet tek DHT, dhe ne momentin e bashkangjitjes, ai din

vetem per peer e pare 1 ekziston ne DHT. Peer 13 deshirin se pari te dergoje peer 1 nje mesazh,

duke i thene: "Qka do te jete paraardhes dhe pasardhes (pasues)?" Ky mesazh forwardohet

(percillet) nepermjet DHT'se perderisa arrin peer 12, i cili realizon qe ai do te jete paraardhes

dhe qe eshte pasardhes i 13te. Pastaj, peer 12 dergon kete informate paraardhesit dhe pasuesit

tek peer 13. Peer 13 tani mund te ti bashkangjitet DHT-se duke e bere peer 15 pasues e tij dhe

duke e njoftuar peer 12 qe ai duhet te nderroje pasuesin e tij ne 13.

DHT ka gjetur perdorim te gjere ne praktike, Per shembull BitTorrent perdor Kademlia DHT per

te krijuar nje "traker te trazuar" Ne BitTorrent, qelesi eshte se identifikatori i torrentit dhe vlera

eshte IP adresa e te gjithe peer te tanishem duke marrur pjese ne torrent [Falkner 2007, Neglia

2007]. Ne kete menyre, duke e shpreh dyshimin e DHT me nje identifikaor torrenti, nje arritje e

re BitTorrent peer mund te determinoje peer qe eshte pergjegjes per identifikatore (qe eshte, per

ti shkuar pas gjurmeve peers ne torrent). Pasi qe eshte gjetur peer, peer qe vjen mund te pyes ate

per nje liste te peer tjeter ne torrent. DHTs gjithashtu perdoren ekskluzivisht ne eMule sistemin e

file-shperndarjes per permbajtjen e lokacionit ne peer [Liang 2006].




Faqe 68

2.6.3 Rast Studimi: P2P Telefonia e Internetit me Skype

Skype eshte nje aplikacion pafundesisht i popullarizuar P2P, shpesh me shtate ose tete milion

perdorues te konektuar (lidhur) ne te, ne te njejten kohe. Ne vend qe te ofroje PC-per-PC

sherbimi i telefonise nepermjet internetit, Skype ofron Pc-per-telefon sherbim i telefonise,

telefon-per-PC sherbim i telefonise, dhe PC-per-PC sherbimi i video konferencave. E gjetur ngate njejtat individe te cilet krijuan FastTrack dhe Kazaa, Skype u kerkua nga eBay in vitin 2005

per 2.6milione dollare $.Skype perdor P2P teknika ne nje numer te menyrave inovative, ne

menyre te mire duke ilustruar se si P2P mund te perdoret ne aplikacione qe shkojne pas

shperndarjes se permbajtjes dhe shperndarjes se fajllave. Siq eshte me mesazhe te shpejta, PC-

per-PC telefonia nepermjet internetit eshte e trasheguar P2P, ne berthame te aplikacionit, pjeset

e perdoruesve komunikojne me njeri tjetrin ne kohe reale. Por Skype gjithashtu puneson teknikat

P2P per dy funksione tjera te rendesishme, te emeruara, per vendndodhjen e perdoruesit dhe per

transverzalen NAT.Jo vetem protokollet e regjistruara te Skype, por te gjitha transmisionet e

paketave (paketat e zerit dhe kontrollit) jane te enkriptuara. Nevertheless, nga Website i Skype

dhe nje numer i studimeve, hulumtimeve kane mesuar sesi Skype ne menyre gjenerale punon

[Baset 2006; Guha 2996; Chen 2006; Suh 2006; REn 2006]. Sikur me FastTrack, nyjet ne Skype

jane te organizuara ne rrjet

hirearkike overlay, me secilen peer te klasifikuar si nje super peer apo nje peer te zakonshme

Skype perfshin nje index qe paraqet perdoruesit e Skype ne IP adrese te tanishme (dhe numrat e

portit).

Ky indeks eshte i distribuuara nepermjet super peers. Kur Alice deshiron ta therras Bob-in,

kerkimet e klientit ne Skype indeksin e distriboura per te determinuar Ip adresen e tanisme te

Bob-it.Pasiqe protokolli i Skype eshte i regjistruar, nuk eshte e qarte tani se si planifikimet e

indeksit jane te organizuara rreth super peers, edhepse disa nga organizimi i DHT eshte shume e

mundshme..P2P teknikat jane gjithashtu te perdorshme ne "transmetimet" e Skype, te cilat jane

te perdorshme per krijimin e thirrjeve nepermjet hostave ne rrjetin e shtepise. Shume

konfiguracione te rrjetit shtepiak ofrojne akses ne internet nepermjet ruterit (ne menyre tipike

nje ruter i wirelessit). Keta rutera aktualisht jane me shume se rutera, dhe ne menyre tipike

perfshijne te ashtuquajturen perkthyes i rrjetit te adresave (NAT). Ne do ta shtjelojme NATs ne

kapitullin 4. Per tani, e tere ajo qe na nevoitet te dijm eshte se NAT parandalon nje host nga

jashte rrjetit shtepiak nga inicimi i lidhjes per nje host perbrenda. Nese te dyjte thirresit e Skype

kane NAT, atehere ekziston nje problem-asnjeri smund te pranoje nje thirrje iniciuar nga tjetri,

duke e bere nje thirrje me sa duket e pamundur. Perdorimi i menqur i super peers dhe

transmeton ne menyre te mire zgjedh kete problem. Supozojme se Alice hin ne linje, ajo eshte

caktuar nje jo NATuar super peer. Alice mund te filloje nje sesion per super peer qekur NAT i

saj vetem e ndalon sesionin e filluar nga jashte rrjetit te shtepise. Kjo lejon Alice dhe super peer

te shkembejne mesazhet e kontrolluara nepermjet ketij sesioni. E njejta ndodh me Bobin, kur ai

hyn ne linje. Tani, kur Alice deshirin ta therrase Bob, ajo informon super peer e saj, i cili

informon super peer e Bob's, i cili informon Bobin per ardhjen e thirrjes nga Alice. Nese Bob e

pranon thirrjen, te dy super peers selektojne nje NAT-e te trete super peer-the transmeton nyje-

puna e te cilit do te jete te tranmetoje te dhenat ne mes Alice dhe Bob. Super peers e Alice dhe




Faqe 69

Bob-it pastaj udhezon Alice dhe Bob respektivisht per te iniciuar nje sesion me transmetim.

Alice pastaj e dergon paketen e zerit per ne transmeton nepermjet te lidhjes Alice-to-relay (e cila

u inicua nga Alice), dhe transmetimi pastaj forwardon (shperndan) keto paketa nepermes

transmetimit-ne lidhjen e Bobit (e cila u iniciua nga Bob); paketat nga Bob dhe Alice rrjedhje

nepermjet te njejtave transmetime idhjes ne te kunderten. Dhe voila!-- Bob dhe Alice kane ne

demand end-to-end lidhjen edhepse asnjeri smund te pranoje nje sesion me origjine nga jashte

LAN-it te tij. Perdorimi i "transmetimit" ilustro rritjen e dizajnit te sofistikuar te sistemit P2P, ku peers performojne sherbimin sistem themelor (berthame) per tjerat (sherbimin e indekseve dhe

duke qene transmetuar dy shembuj) perderisa ne te njejten kohe ata vete perdorin nje servis end-

user (per shembull downloadimi i fajllave), telefonija IP) duke qene te siguroje nga nje sistem

P2P.

Skype ka qene nje aplikacion i gjere i internetit, duke shperndare "fjale per fjale" dhjetera e

miliona perdoruesve. Befasimi i shpejte dhe eshte perhapur adoptimi i Skype, nje P2P

shperndarje e fajllave, Webi, dhe mesazhimi i shpejte para tyre, eshte nje testim tregues per

menquri te dizajnit arkitektonik te pergjithshem te internetit, nje dizajn qe nuk mund te shihet

perpara zgjerimin e pasur e setin e aplikacioneve te internetit qe do te zhvillohet ne 30 vjetet e

tjera. Sherbimet e ofruara te networkut (rrjetit) ne aplikacionet e internetit--connectless datagramtransport (UDP), connected-oriented i besueshem datagram transfer (TCP), interfejsi prize,

adresimi, emerimi (DNS), rreth tjerave-kane deshmuar mjaft per te lejuar qindra aplikacione per

tu zhvilluar. Qekur keto aplikacione kane qene te gjitha "shtrirjet" ne maje te kater "shtrirjet"

ekzistues te internet protokolit te grumbulluar, ata perfshijne vetem zhvillimin e serverit te

klientit te ri si te softweri peer-to-peer per perdorim ne sistemin e fundem. Ky ka lejuar keto

aplikacione te jene ne menyre rapide vendosen dhe te adaptohen.

2.7 Programimi I Socket-it me TCP

Tani qe kemi shikuar nje numer te aplikacioneve te rrjetit, le te eksplorojme (hulumtojme)

programet e aplikacionit te rrjetit jane te shkruara. Ne kete sesion ne do te shkruajme programe

te aplikacionit qe perdorin TCP; ne sesionin percjelles ne do te shkruajme programe qe perdorin

UDS.Te kujtojme Sesionin 2.1 ku shume aplikacione te rrjetit perbehet nga nje pale

programesh- nje program i klientit dhe nje program serveri-rri ne dy sisteme te ndryshme. Kur

keto dy programe ekzekutohen, krijohet procesi i serverit dhe klientit, dhe keto procese

komunikojne me njera tjetren duke lexuar nga ajo dhe duke shkruar ne "prize". Kur krijohet nje

aplikacion i rrjetit, qellimi kryesor i zhvillimit eshte te shkruaje kodin per te dy: klientin dhe

programin e serverit.

Keto jane dy lloje te te aplikacionit te rrjetit. Njeri lloj eshte nje implementim i standardit te

protokolit te definuar, per shembull, nje RFC, Per kete lloj implementimi, klienti dhe

programet e serverit duhet te pershtaten rregullave diktoje nga RFC. Per shembull, programi i

klientit mund te ishte nje implementim i anes se klientit nga FTP protokolli, i cili eshte i

pershkruar ne Sesionin 2.3 dhe ne menyre eksplicite (te caktuar) te definuar ne RFC 959; ne

menyre te njejte programi i serverit mund te jete nje implementim i FTP server protokollit,

gjithashtu ne menyre eksplicite te definuar ne RFC 959. Nese nje zhvillues shkruan kod per

programin e klientit dhe nje developer individual shkruan kod per programin e serverit, pastaj te

dy programet do te jene ne gjendje interoperojne. Ne te vertete, ne aplikacionet e sotme te rrjetit




Faqe 70

duke e perfshire komunikim ne mes klientit dhe program serverit qe kane qene te krijuara nga

zhvillues individuale--per shembull, nje komunikim i browserit Firefox me nje Web server

Apache, ose nje FTP klient ne nje fajll te uploaduar ne PC, ne nje server Linux FTP. Kur nje

klient ose program server implementon nje protokoll te definuar ne nje RFC, ai duhet te perdor

numrin e portit ne asociim me protokollin. (Numrat e portit kane qene shkurter te permbledhur

ne Sesionin 2.1. Ata jane te mbuluar apo permbledhur detajisht ne kapitullin 3)Lloji tjeter i aplikacionit te rrjetit eshte nje aplikacion i rrjetit te duhur. Ne kete rast protokolli i

aplikacionit shtrese i perdorur nga klienti dhe programet e serverit nuk kane nevoje te

konfirmojne ne asnje RFC ekzistuese. Ne zhvillues i vetem (ose grup zhvilluesish) krijojne te dy

klientin dhe program serverin, dhe zhvilluesi ka kompletuar kontrollen se qfare shkron

(shkruhet) ne kod. Por pasiqe kodi nuk e implementon nje protokoll domen, tjere developer

ndipendent nuk do te jene ne gjendje te zhvilloje kodin qeinteroperon me aplikacionin. Kur

zhvillon nje aplikacion te caktuar, zhvilluesi duhet te jete i kujdesshem qe te mos perdor njerin

nga numrat e portit te njohur te definuar te RFC.Ne kete dhe sesionin e ardhshem, ne

egzaminojme qeshtjet kyqe zhvillimin e aplikacionit te server-klientit. Gjate fazes se zhvillimit,

njeri nga vendimet e para eshte qe zhvilluesi duhet te beje eshte qe nese aplikacioni te kaloje

mbi TCP ose

UDP. Kujtojme se TCP eshte lidhje e orientuar dhe siguron nje kanal bajt-stream te besueshem

nepermjet te cilit te dhenat rrjedhin nepermjet dy end sistemeve. UDP eshte i pa lidhur dhe

dergon paketa te pavarura te te dhenave nga nje sistem i fundem tek tjetri pa asnje garancion per

dorezimin (shperndarjen).

Ne kete sision ne zhvillojme nje aplikacion te thjeshte te klientit i cili drejtohet me TCP;nne

sesionin tjeter, ne zhvillojme nje aplikacion te thjeshte te klientit i cili drejtohet me UDP. Ne

prezentojme keto apliakacione te thjeshta TCP dhe UDPne Java. Ne do mund ta shkruanim

kodin ne C ose C++, por ne zgjedhem Java-n me shume sepse aplikacionet jane me te qarta dhe

teresisht te shkruara ne Java. Me Java jane me pak rreshta kodi, dhe secili rresht (linje) mund te

shpjegohet per programeret fillestar pa shume veshtersi. Por nuk ka nevoje per frikesim nese ju

nuk jeni familjar (te njohur) me Java. Ju duhet te percillni kodin nese keni pervoje me

programim ne ndonje gjuhe tjeter programuese.Per lexuesit te cilet jane te interesuar ne

programimin e klient serverit ne C, keto jane disa referenca te mira ne dispozicion [Donahoo

2001; Stevens 1997; Frost 1994; Kurose 1996].

2.7.1 Socket Programming with TCP

Perkujto nga kapitulli 2.1 qe proceset që punonë në makina të ndryshme komunikojnë me njeri

tjetrin duke dërguar mesazhe në “socket”. Ne thamë që qdo process ishte I ngjashëm me shtëpi

dhe socket I procesit ishte I ngjashëm me deren. Siq shihet ne figurën 2.28, socket është dera në

mes të procesit të aplikacionit dhe TCp. Zhvilluesi I aplikacionit ka kontroll në qdo gjë të socket

në shtresen aplikative; sidoqoftë, ka shum pak kontroll në shtresen transportuese. ( Më e shumta

që mund të bëjë zhvilluesi i aplikacionit është që rregullojë disa parametra të TCP, siq është

madhësia makismale e buffer dhe madhësia maksimale e segmenteve).








Faqe 73

Figura 2.30 Aplikacioni klent – server,duke përdorur shërbimet e transportit të lidhjes orientuese

Në mënyrë që të theksojmë çështjet kyçe, ne qëllimisht sigurojmë që kodi të jetë me vend."Good

code" ("Kodi i mirë") padyshim do të kishte edhe disa rreshta ndihmës më shumë. Kur dy programet janë përpiluar në host-at e tyre përkatës, programi i server-it së pari është ekzekutuar

në host-in e server-it., i cili krijon një proces të server-it në host-in e server-it. Siq e diskutuam

më sipër, procesi i server-it pret që të kontaktohet nga procesi i klientit.

Në këtë shembull të aplikacionit, kur programi i klientit është ekzekutuar, krijohet një proces te

klienti, dhe ky proces menjëherë kontakton server-in dhe krijon një lidhje TCP me të. Përdoruesi

tek klienti pastaj mund të përdorë aplikacionin për të dërguar një rresht dhe për të marrë një

version të kapitalizuar të rreshtit.

TCPClient.java

Këtu është kodi i aplikacionit për anën e klientit:

import java.io.*;

import java.net.*;

class TCPClient {

public static void main (String argv [] ) throws Exception

{






Faqe 75

Figure 2.31.TCPKlienti ka tre stream-a me karakter flow

Le të shohim tani rreshta nga më të ndryshëm në kod.

import java.io.*;

import java.net.*;

java.io dhe java.net janë paketa të Java. Paketa java.io përmban klasa për stream-a hyrës dhe

dalës. Në veqanti paketa java.io përmban klasat BufferedReader dhe DataOutputStream, klasat

të cilat programi i përdor për të krijuar 3 stream-at që ilustruam më heret. Paketa java.net

siguron klasa për mbështetje të rrjetës. Në veqanti, përmban klasat Socket dhe ServerSocket.

Objekti clientSocket i këtij programi është i nxjerrur(përfituar) nga klasa Socket.

class TCPClient {

public static void main ( String argv [] ) throws Exception

{.......}

}

Deri këtu, çka ne kemi parë janë gjëra të standardit (standard stuff) që ju i shihni në fillimin e

shumicës së kodeve të Java-s. Rreshti i tretë është fillimi i bllokut të definimit të klasës. Fjala

class e fillon definimin e klasës për klasën e emëruar TCPClient. Klasa përmban variabla dhe

metoda. Variablat dhe metodat e klasës janë të futura në kllapat gjarpërore të cilat fillojnë dhe

përfundojnë bllokun e definimit të klasës. Klasa TCPClient




Faqe 76

nuk ka variabla të klasës por ka saktësisht një metodë,metodën main( ). Metodat janë të

ngjajshme me funksionet ose procedurat në gjuhët si C; metoda main( ) gjuhën Java është e

ngjajshme me funksionin main ( ) në C dhe C++. Kur Java interpretuesi ekzekuton aplikacionin

(duke u thirrur në klasën e kontrolluar të aplikacionit ), fillon duke e thirrur metodën main( ) të

klasës. Metoda main ( ) pastaj i thërret të gjitha metodat tjera të nevojshme për të drejtuar

aplikacionin. Për këtë hyrje të programimit socket në Java, ju mund të injoroni fjalët kyçe si public,static,void,main, and throws Exceptions(ndonëse ju duhet t'i përfshini ato në kod).

String sentence;

String modifiedSentence;

Këta dy rreshtat e mësipërm deklarojnë objektet të tipit String. Objekti sentence është i tipiëzuar

string nga përdoruesi, dhe dërgohet tek serveri. Objekti modifiedSentence është string i marrë

nga server-i dhe dërgohet tek standard output-i(monitori) i perdoruesit.

BufferedReader inFromUser = new BufferedReader (

new InputStreamReader(System.in));

Rreshti i mësipërm krijon objektin e stream-it inFromUser të tipit BufferedReader. Stream-i

hyrës është inicializuar me System.in, e cila e lidh stream-in me standard input(hyrjen

standarde). Komanda lejon klientin të lexojë tekstin nga tastiera e tij.

Socket clientSocket = new Socket("hostname",6789);

Rreshti i mësipërm krijon objektin clientSocket të tipit Socket. Gjithashtu starton konektimin

TCP nëpërmes klientit dhe server-it. Stringu "hostname" duhet të zëvendësohet me hostname-in

e server-it (për shembull,"apple.poly.edu"). Para se konektimi TCP të jetë aktualisht i startuar,

klienti kryen DNS lookup-in në hostname që të marrë IP-adresesën e hostit. Numri 6789 është

numri i portit. Ju mund të përdorni numër të ndryshëm të portit, por ju duhet të siguroheni që të

përdorni po të njejtin numër të portit në anën e severit të aplikacionit. Siq u diskutua më heret,

IP-adresa e hostit së bashku me numrin e portit të aplikacionit identifikojnë procesin e serverit.

DataOutputStream outToServer =

new DataOutputStream(clientSocket.getOutputStream( ));

BufferedReader inFromServer =

new BufferedReader( new inputStreamReader(

clientSocket.getInputStream( )));

Dy rreshtat e mësipërm krijojnë objekte stream të cilat janë të lidhura në socket. Streami-i

outToServer siguron process output në socket. Streami-i inFromServer siguron process input

nga socket-a(shiko Figure 2.31).

sentence = inFromUser.readLine( );








Faqe 79

2.8 Programimi i soketeve me UDP

Ne mesuam paraprakisht se kur dy prcese komunikojne nepermjet Tcp ,eshte per arsye se

ekziston nje tub ndermje dy proceseve.Ky tub nenkupton nje vend deri sa dy proceset ta mbyllin

ate.Kur njeri nga proceset deshiron te dergon disa bita ne procesin tjeter thjesht I dergon bitat ne

tub..Procesi I derimit nuk eshte envojshme te oermbaj nje adres derguese per bajtat sepse tubilogjikisht eshte I lidher me cakun.Permeteper tub deshmon nje rrjedhje te bitave ne program

duke marrurr bitat qe derguesi I fut ne tub.Udp poashtu lejon dy e me shum procese te cilat

punojne ne perdorues te ndryshem.Megjithate Udp eshte e ndryshme nga tcp ne menyra te

ndryshme.Mesepari,Udp eshte nje lidhje qe nuk ka te beje me takim te duarve kur tubi eshte I

aktivizuar ne dy proceset.Meqense UDP nuk ka nje tub kur procesi deshiron tju dergoje bita ne

procesin tjeter,procesi I dergimit duhet ti tregohet caku ne procesin e adresave me shum

bita.Dhe jo duhet te behet per secilin grumbull te bitave ne prcesin e dergimit.Nje analogji me

jeten e perditshme eshte nese 20 persona marrim 5 taksi ne vendin e njejt perderisa njerzit hipin

ne taksi qdo taksist duhet te informohet per ccakun e arritjes.Prandaj Udp eshte e ngjashme me

sherbimine e taksive.Destinacioni I adresave ka te beje me pershtatje e ip adrses se cakut dhenumrin e portit qe qe caku proceson.Ne I referohemi nje grumbulli te bitave te informit se

bashku me destinacionin e adresave ip dhe numrin e portit si ‘’paket’’.Udp deshmon nje

mesazh te orentuar jo real qe ben perpjekje te shperndaj nje grumbull bitave ne nje destinacion

te caktuar.Eshte nje mesazh I orentuar se ne grumbull te bitave jan derguar ne nje zero te vetem

ne anen e dergimit,do te dergohet si grumbull ne anen e marrjes;per dallim ne tcp rrjedhja e

bitave shkon ne menyr semantike.Sherbimi I Udp eshte perpjekja me e mir qe e ben UDP qe nje

numer I grumbulluar I bitave te shperndahen.Sherbimi I udp nepermjet formave te ndyrhsme

me tcp bejne rrjedhjen e bitave ne shebim modeli.Pas krijimit te paketave procesi I dergimit e

fut paketen ne rrjet neper soketit.Duke vazhduar me lidheshmerin me taksit ne anen tjeter te

dergimit te soketit eshte dikush duke pritur paketen.Me pas taksi vozit paketen ne cakun e

caktuar.Megjithate taksi nuk garanton qe do te marr pakten dh eta dergoj ne vedin e deshiruar

sepse aim und te ket problem te pa parashikuara.Prandaj Udp deshmon nje sherbim transporti jo

real perderisa udhtimi vazhdon dhe paketa permab jo siguri ne arritjen ne cak.Ne kete tregim ne

e ilustruam programimin me soket duke rizhvilluar aplikacionin e njejt me ate paraprak mirpo

ksaj rradhe ne perfundim te udp.Ne do te shikojme se kodi per udp eshte shum me ndryshe se tc

p ne forma te rendeshishme.Ne veqanti ska takim duarsh ndejmjet dy proceseve dhe ska nevoj

per soket mirseardhesh,ska rjedhje te lidhura per soket ,dergusit krijojne pakta duke perfshir ip

adresen dhe numrin e portit per qdo bite qe dergon dhe procesi I marrjes duhet te permbaj qdo

paket me informacione te bitave.Perserisim dhe nje her nje aplikacion te thjesht:

1.Nje klient lexon nje rresht nga nje linje satndarde(tastatur) dhe nje linje te dyt qe eshte soketi

ne server.

2.Serveri lexon nga nje rresht prej sokteti.

3.Serveri e konverton linjen ne qeshtje me te madhe

4.Serveri dergon linjen e modifikuar jasht nga soketi te klienti.

5.Klienti lexon linjen e modifkuar nga soketi dhe e paraqet ate ne monitor.






Faqe 81

DatagramPacket(receiveData,receiveData.length);

clinetSocket.receive(ReceivePacket);

String modifiedSentence =new String(receivePacket.getData());

System.out.println(“FROM SERVER:”+modifiedSentence);

clientSocket.close();

}

}

Programi UDPClient.java ndërton një rrjedhoj dhe një soket, siq është e treguar në Fig.2.33.

Soketi është emruar si clientSocket, dhe është tip i DatagramSocket. Kujtojmë se UDP përdor

lloje të ndryshme të soketave se sa TCP te klienti. Në veqanti , me UDP klienti perdor

DatagramSocket,ndërsa me TCP klienti perdot Socket. inFromUser është rrjedh e të dhënave

në program; është I bashkangjitur të dhënave standarte, kjo ështe,te dhena nga tastiera.Ne kemi

një rrjedhje ekujvalente n@ versionin e TCP – s të progtamit. Kur përdoruesi shenon karakteret

nga tastieran, karakteret rrjedhin në nivelin e inFromUser.Por në krahasim me TCP , këtu nuk

ka nivele(te hyra apo te dalura)të bashkngjitura ne soket.Në vend të furnizimit të bajtave të

nivelit të bashkangjitur në objektin e Soketit, UDP mund të vendos paketa individuale neobjektin e DatagramSocket.

Ti shohim disa pjesë te kodit që ndryshojn konsiderushem nga TCPClient.java.

DatagramSocket clientSocket = new DatagramSocket () ;

Kjo pjesë krijon objektin clientSocket e tipit DatagramSocket.Në contrast më TCPClient.java,

kjo pjesë nuk do të filloj TCP lidhjen.Në veqanti, pjesa e klientit nuk kontakton me serverin

përderisa ekzekutohet kjo linjë. Për këtë arsye, konstruktori DatagramSocket () nuk e merr

emrin e serverit apo numrin e portit si argument. Duke përdorur nje tub hyrje analogjike,

ekzekutimi I linjes paraprake krijon një hyrje per procesin e klientit po nuk krijon nje

transmetim në mes të dy proceseve .

InetAddress IPAddress = InetAddress .getBYName(“hostname”);




Faqe 82

Figura 2.33 UDPklienti ka një stream;socket-i pranon paketat prej procesit dhe shpërndan

paketat në proces.

Që të dergojm bajta në destinacionin e procesit, ne na duhet adresa e procesit.Pjesë e kësaj

adrese edhe IP adresa e destinacionit bartës. Linja paraprake përfshin DNS qe transmeton

hostname-in(në këtë shembull, furnizuar në kod nga zhvillimet) në një IP adres. DNS ishtegjithashtu I përfshir nga verzioni TCP te klientit, ndonëse ishte zgjethur në menyr implicite

me teper se sa në atë eksplicite.Metoda getByName () merr si argument hostname e serverit

dhe e kthen IP adresen e serverit të njejt.E vendos këtë adres ne objektin e IPAdress e tipit

InetAdress.

Byte [ ] sendData =new byte[1024];

Byte[ ] reciveData=new byte[1024];

Bajtat e vargjeve sendData dhe reciveData mund të mbajn daten , të hyrat dhe dalurat e

klientit,përkatësisht.

sendData = sentence.getBytes ();

Linja paraprake në thelb interpreton tipin e konvertimit.Merr vargun e fjalis dhe e riemron at

si sendData,që është një grup i bajtave.

DatagramPacket sendPacket =new DatagramPacket

(sendData,sendData.length,IPAddress,9876);




Faqe 83

Kjo linjë ndërton paketën, sendPacket, më të cilen klienti mund të futet ne rrjet përmes

soketit. Kjo paketë perfshin at datë që përfshin në paket,sendData,kohëzgjatje e kësaj date, IP

adresen e serverit, dhe port numërin e aplikacionit(cila është 9876).Kujtojm se sendPacket

është tip i DatagramPacket.

clientSocket.send(sendPacket);

Në linjën paraprake , metoda send() e objektit clientSocket. Merr paket e vetem që ta ndërtojdhe ta fus atëne rrjet përmescilent Socket.Edhe një herë kujtojm se UDP dërgon linjat e

karaktev ne mënyrëa shumë të ndryshme nga TCP. TCP thjesht inserton stringet e karaktereve

në nivel,e cila ka një lidhje logjike direkte me serverin.;UDP krijon paketa qe perfshin adresen e

serverit. Pasi te dergohet paketa, klienti prêt që të pranoj paketen nga server.

DatagramPacket receivedPacket =new

DatagramPacket(receiveData,receiveData.length);

Në linjën paraprake ,përderisa klienti prêt për pranimi e paketes nga serveti ,ai krijon një

vendëpranim për paketm, receivePacket,një object I tipit DatagramPacket.clinetSocket.receive(ReceivePacket)

Kur e merr paketen, e vendos atë në receivePacket.

String modifiedSentence =

new String(receivePacket.getData());

Linja paraprake nxjerr daten nga receivePacket dhe ekzekuton tipin e konvertimit,konvertimin

e nje grup bajtave ne string modifiedSentence.

System.out.println(“FROM SERVER:”+modifiedSentence);

Kjo linjë, që është gjithëashtu prezente ne TCPClient, shtyp jasht stringut modifiedSentence ne

monotorin e klientit.

clientSocket.close();

Kjo linjë e fundit e mbyll soketin.Sepse UDP është e konektushme , kjo linjë nuk e detyron

klientin te dërgoj mesazhe transporuse te server(ne kundershtim me TCPClient).

UDPServer.java

Le te shohim pjesën e serverit te aplikacionit:

Import java.oi.*;

Import java.net.*;

Class UDPServer {

Public stasic void main(String arg []) throws Exception

{






Faqe 85

Linja paraprake nderton DatagramSocket serverSocket ne portin 9876.Të gjitha datat e derguara

dhe të pranuara kalojnë perms soketit.Sepse UDP me pak I konektushem, nuk kemi te krijom

një soket të ri e te kerkojm një rrjet të ri , siq bëm te TCPServer.java.

String sentence =new String(receivePacket.getData());

InetAddress IPAddress =receivePacket.getAddress();

int port = receivePacket.getPort();

E para linjë heq daten nga paketa dhe e vendos daten ne Stringsentence; ka nje lidhje analoge

me UDPClient.|E dyta linjë heq IP adresen , e treat linjë heq port numërin e klientit , I cili është

zgjedh nga klienti dhe është ndyshe nga port numëri 9876 I serverit.(Do ta diskutojm port

numërin e klientit në disa detaje në kapitullin tjetër).ështe e nevojshme per serverin të siguroj

adresen (IP adresen dhe port numërin) e klientit.Kjo e kompleton analizen tone të UDP

programit.Që të testosh aplikacionin ju duhet të instaloni dhe hartoje UDPClient.java në një

host dhe UDPServer në një tjeter host.Pastaj ekzekuto të dy programet n@ hostat e tyre

përkatës.Ndryshe nga me TCP, ju mund të ekzekutoni së pari pjesen e kilentit pastaj atë të

serverit.Kjo ndodhë sepse procesi I klientitn nuk përpiqet që të filloj lidhjen me server kur ju eekzekutoni klient programin.Njëherë ju ekzekutoni klient dhe server programin, ju ndoshta

mund të perdorni aplikacionin duke zgjedhur linjat të klienti.




Documents

2_Kapitulli 2.pdf