nivelul aplica ie - digital.ubm.rodigital.ubm.ro/?download=computer networks cap 7.pdf · anume,...

52

7 NIVELUL APLICA IE

Dup ce am epuizat toate preliminariile putem aborda nivelul unde pot fi g site toate aplica!iile. Nivelurile de sub nivelul aplica!ie servesc la asigurarea unui transport sigur, dar nu îndeplinesc nici o func!ie concret pentru utilizatori. În acest capitol vom studia câteva aplica!ii reale.

Totu"i, chiar "i la nivelul aplica!ie, apare necesitatea unor protocoale-suport care s permit func!ionarea aplica!iilor reale. Înainte de a începe studiul aplica!iilor, ne vom ocupa de unul dintre acestea. Subiectul în discu!ie este DNS, care se ocup de conven!iile de nume în Internet. Dup ace-ea vom examina trei aplica!ii reale: po"ta electronic , World Wide Web (rom.: re!ea de întindere planetar ) "i, în final, multimedia.

7. DNS - SISTEMUL NUMELOR DE DOMENII

Cu toate c teoretic programele ar putea s se refere la sistemele gazd , la cutiile po"tale "i la alte resurse prin adresa lor de re!ea (de exemplu prin adresa IP), aceste adrese sunt greu de memorat de c tre oameni. De asemenea, în trimiterea de po"t electronic la tana@ 28. .24.4 ar însemna c dac furnizorul de servicii Internet sau organiza!ia Tanei mut serverul de po"t pe o ma"in diferi-t , cu o adres IP diferit , adresa ei de e-mail se va schimba. De aceea au fost introduse nume ASCII pentru a separa numele ma"inilor de adresele ma"inilor. În acest fel, adresa Tanei ar putea fi ceva de genul tana@art.ucsb.edu. Cu toate acestea, re!eaua în!elege numai adrese numerice, deci este nece-sar un mecanism care s converteasc "irurile ASCII în adrese de re!ea. În sec!iunile urm toare se va studia cum este realizat aceast conversie în Internet.

522 NIVELUL APLICA!IE CAP. 7

Înc de la ARPANET exista un fi"ier host.txt care cuprindea toate sistemele gazd "i adresele lor IP. În fiecare noapte, toate gazdele îl preluau de la situl unde era p strat. Pentru o re!ea format din câteva sute de ma"ini mari, cu divizarea timpului, aceast abordare era destul de rezonabil .

Totu"i, atunci când la re!ea au fost conectate mii de sta!ii de lucru, to!i "i-au dat seama c aceast abordare nu putea s func!ioneze la nesfâr"it. În primul rând dimensiunea fi"ierului ar deveni prea mare. Cu toate acestea "i chiar mai important, conflictele de nume de sisteme gazd ar ap rea în permanen! dac nu ar fi administrate centralizat, ceva de negândit într-o re!ea interna!ional de dimensiuni uria"e din cauza înc rc rii "i a laten!ei. Pentru a rezolva aceste probleme, a fost inventat DNS (Domain Name System - Sistemul numelor de domenii).

Esen!a DNS-ului const într-o schem ierarhic de nume de domenii "i a unui sistem de baze de date distribuite pentru implementarea acestei scheme de nume. În principal este utilizat pentru a pune în coresponden! numele sistemelor gazd "i adresele destina!iilor de e-mail cu adresele IP, dar poate fi utilizat "i pentru alte scopuri. DNS este definit în RFC-urile #034 "i #035.

Foarte pe scurt, DNS este utilizat dup cum urmeaz . Pentru a stabili coresponden!a dintre un nume "i o adres IP, programul de aplica!ie apeleaz o procedur de bibliotec numit resolver, transferându-i numele ca parametru. Putem vedea un exemplu de resolver, gethostbyname, în fig. 6-6. Resolver-ul trimite un pachet UDP la serverul DNS local, care caut numele "i returneaz adresa IP c tre resolver, care o returneaz apelantului. Înarmat cu adresa IP, programul poate stabili o co-nexiune TCP cu destina!ia sau îi poate trimite pachete UDP.

7. . Spa"iul de nume DNS

Administrarea unui volum mare de nume în permanent schimbare nu este o problem prea u"oar . În sistemul po"tal, administrarea numelor este realizat impunând ca pe o scrisoare s se specifice (implicit sau explicit) !ara, statul sau provincia, ora"ul, strada "i restul adresei destinatarului. Utilizând o astfel de adresare ierarhic , nu exist nici o confuzie între Marvin Anderson de pe Main St. din White Plains, N.Y. "i Marvin Anderson de pe Main St. din Austin, Texas. DNS lucreaz în acela"i mod.

Conceptual, Internetul este divizat în peste 200 domenii de nivel superior, fiecare domeniu cu-prinzând mai multe sisteme gazd . Fiecare domeniu este parti!ionat în subdomenii "i acestea sunt, la rândul lor, parti!ionate ".a.m.d. Toate aceste domenii pot fi reprezentate ca un arbore, a"a cum se arat în fig. 7-#. Frunzele arborelui reprezint domenii care nu au subdomenii (dar, bineîn!eles, con-!in sisteme). Un domeniu frunz poate con!ine un singur sistem gazd sau poate reprezenta o firm , deci s con!in mii de sisteme gazd .

Domeniile de pe primul nivel se împart în dou categorii: generice "i de ! ri. Domeniile generice sunt com (comercial), edu (institu!ii educa!ionale), gov (guvernul federal al SUA), int (organiza!ii interna!ionale), mil (for!ele armate ale SUA), net (furnizori Internet) "i org (organiza!ii nonprofit). Domeniile de ! ri includ o intrare pentru fiecare !ar , cum se define"te în ISO 3#66.

În noiembrie 2000, ICANN a aprobat patru domenii de nivel superior noi, de interes general, "i anume, biz (afaceri), info (informa!ii), name (nume de persoane), "i pro (profesii, ca de exemplu doc-tori sau avoca!i). În plus, au fost introduse trei domenii de nivel superior cu caracter specializat, ce-rute de c tre anumite industrii. Acestea sunt aero (industria aerospa!ial ), coop (cooperative), "i museum (muzee). În viitor vor fi ad ugate alte domenii superioare.

SEC. 7.# DNS - SISTEMUL NUMELOR DE DOMENII 523

Fig. 7- . O por!iune a spa!iului numelor de domenii din Internet.

Pe de alt parte, pe m sur ce Internetul devine mai comercial, el devine "i mai discutabil. S lu-

m domeniul pro, de exemplu, care a fost proiectat pentru profesioni"tii atesta!i. Dar cine este un profesionist? $i de cine este atestat? Dar cum r mâne cu fotografii, profesorii de pian, magicienii, instalatorii, frizerii, exterminatorii, arti"tii de tatuaje, mercenarii "i prostituatele? Sunt acestea mese-rii "i sunt acceptabile pentru domeniile pro? $i daca da, cine atest diver"i practicieni?

În general, ob!inerea unui domeniu de nivel secundar, ca de exemplu nume-al-companiei.com, este u"oar . Pur "i simplu este necesar doar consultarea serviciului de înregistrare al nivelului su-perior corespunz tor (com în acest caz) pentru a vedea dac numele dorit este disponibil "i nu apar-!ine altcuiva. Dac nu sunt probleme, solicitantul pl te"te o mic tax anual "i prime"te numele. Pân acum, cam toate cuvintele comune (din englez ) au fost luate în domeniul com. Încerca!i nu-me de articole casnice, animale, plante, p r!i ale corpului etc. Aproape toate sunt luate.

Fiecare domeniu este identificat prin calea în arbore de la el la domeniul (f r nume) r d cin . Componentele sunt separate prin puncte (pronun!at „dot”). Astfel, departamentul tehnic de la Sun Microsystems ar putea fi eng.sun.com, în loc de numele în stil UNIX /com/sun/eng. De notat c aceast numire ierarhic face ca eng.sun.com s nu intre în conflict cu posibila utilizare a lui eng din eng.yale.edu, care ar putea fi folosit pentru departamentul de limba englez de la Yale.

Numele de domenii pot fi absolute sau relative. Un nume absolut de domeniu se termin cu un punct (de exemplu, eng.sun.com.), în timp ce unul relativ nu. Numele relative trebuie interpretate în context pentru a le determina în!elesul adev rat. În ambele cazuri, un nume de domeniu se refer la un anumit nod din arbore "i la toate nodurile de sub el.

Numele de domenii nu fac distinc!ie între litere mici "i litere mari, astfel edu, Edu, sau EDU în-seamn acela"i lucru. Componentele numelor pot avea o lungime de cel mult 63 caractere, iar în-treaga cale de nume nu trebuie s dep "easc 255 de caractere.

În principiu, domeniile pot fi inserate în arbore în dou moduri diferite. De exemplu, cs.yale.edu ar putea la fel de bine s fie inclus în domeniul ! rii us ca cs.yale.ct.us. În practic , totu"i, aproape toate organiza!iile din Statele Unite sunt repartizate dup criteriul generic, iar aproape toate din afara Statelor Unite fac parte din domeniul ! rii lor. Nu exist nici o regul împotriva înregistr rii sub dou domenii de nivel superior, îns pu!ine organiza!ii în afar de cele multina!ionale o fac (de exemplu, sony.com "i sony.nl).

Fiecare domeniu controleaz cum sunt alocate domeniile de sub el. De exemplu, Japonia are domeniile ac.jp "i co.jp echivalente cu edu "i com. Olanda nu face nici o distinc!ie "i pune toate orga-

524 NIVELUL APLICA!IE CAP. 7

niza!iile direct sub nl. Astfel urm toarele trei nume sunt toate departamente de calculatoare (com-puter science) din universit !i:

#. cs.yale.edu (Universitatea Yale din Statele Unite). 2. cs.vn.nl (Vrije Universiteit în Olanda). 3. cs.keio.ac.jp (Universitatea Keio din Japonia).

Pentru a crea un nou domeniu, se cere permisiunea domeniului în care va fi inclus. De exemplu, dac un grup VLSI de la Yale dore"te s fie cunoscut ca vlsi.cs.yale.edu, acesta are nevoie de permisiu-nea celui care administreaz cs.yale.edu. Similar, dac este acreditat o nou universitate, s zicem Uni-versitatea din Northern South Dakota, ea trebuie s cear administratorului domeniului edu s -i atri-buie unsd.edu. În acest mod sunt evitate conflictele de nume "i fiecare domeniu poate !ine eviden!a tuturor subdomeniilor sale. Odat ce un nou domeniu a fost creat "i înregistrat, el poate crea sub-domenii, cum ar fi cs.unsd.edu, f r a cere permisiunea de la cineva din partea superioar a arborelui.

Atribuirea de nume respect grani!ele organiza!ionale, nu pe cele ale re!elelor fizice. De exem-plu, dac departamentele de "tiin!a calculatoarelor "i de inginerie electric sunt localizate în aceea"i cl dire "i folosesc aceea"i re!ea local , ele pot avea totu"i domenii distincte. Similar, dac departa-mentul de "tiin!a calculatoarelor este împ r!it în dou cl diri (Babbage Hall "i Turing Hall), toate sistemele gazd din ambele cl diri apar!in aceluia"i domeniu.

7. .2 Înregistr#ri de resurse

Fiec rui domeniu, fie c este un singur calculator gazd , fie un domeniu de nivel superior, îi poa-te fi asociat o mul!ime de înregistr ri de resurse (resource records). Pentru un singur sistem gazd , cea mai obi"nuit înregistrare de resurs este chiar adresa IP, dar exist multe alte tipuri de înregis-tr ri de resurse. Atunci când un resolver trimite un nume de domeniu c tre un DNS, ceea ce va primi ca r spuns sunt înregistr rile de resurse asociate acelui nume. Astfel, adev rata func!ie a DNS este s realizeze coresponden!a dintre numele de domenii "i înregistr rile de resurse.

O înregistrare de resurs este un 5-tuplu. Cu toate c , din ra!iuni de eficien! , înregistr rile de re-surse sunt codificate binar, în majoritatea expunerilor ele sunt prezentate ca text ASCII, câte o înre-gistrare de resurs pe linie. Formatul pe care îl vom utiliza este urm torul:

Nume_domeniu Timp_de_via ! Clas! Tip Valoare

Nume_domeniu (domain_name) precizeaz domeniul c ruia i se aplic aceast înregistrare. În mod normal exist mai multe înregistr ri pentru fiecare domeniu "i fiecare copie a bazei de date p streaz informa!ii despre mai multe domenii. Acest câmp este utilizat ca cheie de c utare primar pentru a satisface cererile. Ordinea înregistr rilor în baza de date nu este semnificativ .

Câmpul Timp_de_via!" (time_to_live) d o indica!ie despre cât de stabil este înregistrarea. In-forma!ia care este foarte stabil are asigurat o valoare mare, cum ar fi 86400 (num rul de secunde dintr-o zi). Informa!iei instabile îi este atribuit o valoare mic , cum ar fi 60 (# minut). Vom reveni la acest punct mai târziu, când vom discuta despre utilizarea memoriei ascunse.

Al treilea câmp dintr-o înregistrare de resurs este Clasa (class). Pentru informa!iile legate de In-ternet este tot timpul IN. Pentru alte informa!ii pot fi folosite alte coduri, îns în practic acestea se întâlnesc rar.

Câmpul Tip (type) precizeaz tipul înregistr rii. Cele mai importante tipuri sunt prezentate în fig. 7-2.

SEC. 7.# DNS - SISTEMUL NUMELOR DE DOMENII 525

Tip Semnifica!ie Valoare SOA Start autoritate Parametrii pentru aceast! zon! A Adresa IP a unui sistem gazd! Întreg pe 32 de bi i MX Schimb de po"t! Prioritate, domeniu dispus s! accepte po"t! electronic! NS Server de Nume Numele serverului pentru acest domeniu CNAME Nume canonic Numele domeniului PTR Pointer Pseudonim pentru adresa IP HINFO Descriere sistem gazd! Unitate central! "i sistem de operare în ASCII TXT Text Text ASCII neinterpretat

Fig. 7-2. Principalele tipuri de înregistr ri de resurse DNS.

O înregistrare SOA furnizeaz numele sursei primare de informa!ii despre zona serverului de nume (descris mai jos), adresa de e-mail a administratorului, un identificator unic "i diver"i indica-tori "i contoare de timp.

Cel mai important tip de înregistrare este înregistrarea A (adres ). Ea p streaz adresa IP de 32 de bi!i a unui sistem gazd . Fiecare sistem gazd Internet trebuie s aib cel pu!in o adres IP, astfel încât alte ma"ini s poat comunica cu el. Unele sisteme gazd au dou sau mai multe conexiuni în re!ea, caz în care vor avea câte o înregistrare de tip A pentru fiecare conexiune ("i astfel pentru fieca-re adres IP).

Urm toarea ca importan! este înregistrarea MX. Aceasta precizeaz numele sistemului gazd preg tit s accepte po"ta electronic pentru domeniul specificat. El este folosit deoarece nu toate ma-"inile sunt preg tite s accepte po"ta electronic pentru domeniul specificat. Dac cineva vrea s -i tri-mit un e-mail, de exemplu, lui bill@microsoft.com, sistemul care trimite trebuie s g seasc un server la microsoft.com dispus s accepte e-mail. Înregistrarea MX poate s furnizeze aceast informa!ie.

Înregistr rile NS specific serverele de nume. De exemplu, fiecare baz de date DNS are în mod normal o înregistrare NS pentru fiecare domeniu de pe primul nivel, astfel încât, de exemplu, po"ta electronic s poat fi trimis în zone îndep rtate ale arborelui de nume. Vom reveni la acest aspect mai târziu.

Înregistr rile CNAME permit crearea pseudonimelor. De exemplu, o persoan familiarizat cu atribuirea numelor în Internet, care dore"te s trimit un mesaj unei persoane al c rei nume de co-nectare la un sistem de calcul din departamentul de calculatoare de la M.I.T. este paul poate presu-pune c adresa paul@cs.mit.edu este corect . De fapt aceast adres nu este corect , deoarece do-meniul departamentului de calculatoare de la M.I.T. este lcs.mit.edu. Totu"i, ca un serviciu pentru cei care nu "tiu acest lucru, M.I.T. poate crea o intrare CNAME, pentru a dirija persoanele "i pro-gramele în direc!ia corect . O astfel de intrare poate fi:

cs.mit.edu 86400 IN CNAME lcs.mit.edu

Ca "i CNAME, PTR se refer la un alt nume. Totu"i, spre deosebire de CNAME, care este în rea-litate numai o macro-defini!ie, PTR este un tip de date DNS a c rui interpretare depinde de contex-tul în care este utilizat. În practic este aproape întotdeauna utilizat pentru asocierea unui nume cu o adres IP, pentru a permite c utarea adresei IP "i ob!inerea numelui ma"inii corespunz toare. Aces-tea se numesc c#ut#ri inverse (reverse lookups).

Înregistr rile HINFO permit aflarea tipului de ma"in "i de sistem de operare c rora le cores-punde domeniul. În sfâr"it, înregistr rile TXT permit domeniilor s se autoidentifice într-un mod arbitrar. Aceste dou tipuri de înregistr ri sunt introduse pentru u"urin!a utilizatorului. Nici una

526 NIVELUL APLICA!IE CAP. 7

dintre ele nu este necesar , astfel încât programele nu pot conta pe ob!inerea lor ("i probabil c dac le ob!in nu le pot trata).

În final ajungem la câmpul Valoare. Acest câmp poate fi un num r, un nume de domeniu sau un "ir ASCII. Semantica depinde de tipul de înregistrare. O scurt descriere a câmpurilor Valoare pen-tru fiecare dintre principalele tipuri de înregistr ri este dat în fig. 7-2.

Un exemplu de informa!ie ce se poate g si în baza de date DNS a unui domeniu este prezentat în fig. 7-3. Aceast figur prezint o parte (semi-ipotetic ) a bazei de date pentru domeniul cs.vu.nl prezentat în fig. 7-#. Baza de date con!ine "apte tipuri de înregistr ri de resurse.

;Baza de date pentru cs.vu.nl cs.vu.nl. 86400 IN SOA star boss (9527, 7200, 7200, 24#920, 86400) cs.vu.nl. 86400 IN TXT „Divisie Wiskunde en Informatica.” cs.vu.nl. 86400 IN TXT „Vrije Universiteit Amsterdam.” cs.vu.nl. 86400 IN MX # zephyr.cs.vu.nl. cs.vu.nl. 86400 IN MX 2 top.cs.vu.nl. flits.cs.vu.nl. 86400 IN HINFO Sun Unix flits.cs.vu.nl. 86400 IN A #30.37.#6.##2 flits.cs.vu.nl. 86400 IN A #92.3#.23#.#65 flits.cs.vu.nl. 86400 IN MX # flits.cs.vu.nl. flits.cs.vu.nl. 86400 IN MX 2 zephyr.cs.vu.nl. flits.cs.vu.nl. 86400 IN MX 3 top.cs.vu.nl. www.cs.vu.nl. 86400 IN CNAME star.cs.vu.nl. ftp.cs.vu.nl. 86400 IN CNAME zephyr.cs.vu.nl. rowboat IN A #30.37.56.20# IN MX # rowboat IN MX 2 zephyr IN HINFO Sun Unix

little-sister IN A #30.37.62.23 IN HINFO Mac MacOS

laserjet IN A #92.3#.23#.2#6 IN HINFO „HP Laserjet IIISi” Proprietary

Fig. 7-3. O parte dintr-o posibil baz de date DNS pentru cs.vu.nl. Prima linie necomentat din fig. 7-3 d câteva informa!ii de baz despre domeniu, de care nu ne

vom ocupa. Urm toarele dou linii furnizeaz informa!ii textuale despre amplasarea domeniului. Urmeaz dou intr ri care specific primul "i al doilea loc unde se încearc s se livreze po"ta elec-tronic trimis pentru persoana@cs.vu.nl. Mai întâi se încearc trimiterea la ma"ina zephyr. Dac aceasta e"ueaz , atunci trebuie s se încerce la top.

Dup o linie liber , ad ugat numai pentru claritate, urmeaz linii care spun c flits este o sta!ie de lucru Sun care lucreaz sub UNIX "i se specific ambele sale adrese IP. Urmeaz trei variante de tratare a po"tei electronice trimise la flits.cs.vu.nl. Prima alegere este, în mod natural, chiar flits, iar dac nu se reu"e"te, se încearc la zephyr "i apoi la top. Urmeaz un pseudonim, www.cs.vu.nl, astfel ca aceast adres s poat fi utilizat f r a specifica o anumit ma"in . Crearea acestui pseudonim permite ca cs.vu.nl s schimbe serverul www f r invalidarea adresei folosite în mod curent pentru adresarea lui. Un argument similar este valabil pentru ftp.cs.vu.nl.

Urm toarele patru linii con!in o înregistrare tipic pentru o sta!ie de lucru, în acest caz rowboat. cs.vu.nl. Informa!ia furnizeaz adresa IP, destina!ia primar "i secundar pentru po"ta electronic "i

SEC. 7.# DNS - SISTEMUL NUMELOR DE DOMENII 527

informa!ii despre ma"in . Urmeaz o intrare pentru un sistem non-UNIX care nu este capabil s primeasc po"ta el însu"i, urmat de o intrare pentru o imprimant laser conectat la Internet.

Ceea ce nu este ar tat ("i nu exist în acest fi"ier) sunt adresele IP utilizate pentru a c uta adrese-le domeniilor de pe primul nivel. Acestea sunt necesare pentru a c uta sistemele gazd aflate la dis-tan! , dar, deoarece ele nu fac parte din domeniul cs.vu.nl, nu se g sesc în acest fi"ier. Ele sunt furni-zate de serverele r d cin ale c ror adrese IP sunt prezentate în fi"ierul de configurare a sistemului "i sunt înc rcate în memoria ascuns DNS atunci când este pornit serverul DNS. Exist cam o duzi-n de servere r d cin în lume "i fiecare "tie adresele IP ale tuturor celorlalte servere de domenii de nivel superior. Astfel, dac o ma"in "tie adresa IP a cel pu!in unuia din serverele r d cin , el poate c uta orice nume DNS.

7. .3 Servere de nume

Teoretic, un singur server de nume poate con!ine întreaga baz de date DNS "i poate s r spun-d tuturor cererilor. În practic , acest server poate fi atât de înc rcat, încât s devin de neutilizat. În afar de aceasta, dac se defecteaz , va fi afectat întregul Internet.

Fig. 7-4. O parte din spa!iul numelor DNS prezentând împ r!irea în zone.

Pentru a evita problemele asociate cu existen!a unei singure surse de informa!ie, spa!iul de nume

DNS este împ r!it în zone care nu se suprapun. O posibil cale de împ r!ire a spa!iului de nume din fig. 7-# este ar tat în fig. 7-4. Fiecare zon con!ine câte o parte a arborelui precum "i numele serve-re-lor care p streaz informa!ia autorizat despre acea zon . În mod normal, o zon va avea un ser-ver de nume primar, care preia informa!ia dintr-un fi"ier de pe discul propriu "i unul sau mai multe servere de nume secundare, care iau informa!iile de pe serverul primar. Pentru a îmbun t !i fiabili-tatea, unele servere pentru o zon pot fi plasate în afara zonei.

Plasarea limitelor unei zone este la latitudinea administratorului ei. Aceast decizie este luat în mare parte bazându-se pe câte servere de nume sunt dorite "i unde s fie plasate. De exemplu, în fig. 7-4, Yale are un server pentru yale.edu care administreaz eng.yale.edu, dar nu "i cs.yale.edu, care este o zon separat cu propriile servere de nume. O astfel de decizie poate fi luat atunci când un de-partament ca cel de englez nu dore"te s aib propriul server de nume, în schimb departamentul de calculatoare dore"te. În consecin! cs.yale.edu este o zon separat , în timp ce zona eng. yale.edu nu este separat .

528 NIVELUL APLICA!IE CAP. 7

Atunci când un resolver are o cerere referitoare la un nume de domeniu, el transfer cererea unuia din serverele locale de nume. Dac domeniul c utat este sub jurisdic!ia serverului de nume, cum ar fi ai.cs.yale.edu, care este sub cs.yale.edu, el reîntoarce înregistr ri de resurse autorizate. O înregistrare autorizat# (authoritative record) este cea care vine de la autoritatea care adminis-treaz înregistrarea "i astfel este întotdeauna corect . Înregistr rile autorizate se deosebesc de înre-gistr rile din memoria ascuns , care pot fi expirate.

Dac , totu"i, domeniul se afl la distan! , iar local nu este disponibil nici o informa!ie despre domeniul cerut, atunci serverul de nume trimite un mesaj de cerere la serverul de nume de pe pri-mul nivel al domeniului solicitat. Pentru a clarifica acest proces s consider m exemplul din fig. 7-5. Aici resolverul de pe flits.cs.vu.nl dore"te s "tie adresa IP a sistemului gazd linda.cs.yale.edu. În pa-sul # trimite o cerere la serverul de nume local cs.vu.nl. Aceast cerere con!ine numele de domeniu c utat, tipul (A) "i clasa (IN).

Fig. 7-5. Modul în care un resolver caut un nume aflat la distan! , în opt pa"i.

S presupunem c serverul local de nume nu a avut niciodat o cerere pentru acest domeniu "i

nu "tie nimic despre el. Poate solicita informa!ii de la câteva servere de nume din apropriere, dar dac nici unul dintre ele nu "tie, va trimite un pachet UDP la serverul pentru edu specificat în baza de date (vezi fig. 7-5), edu-server.net. Este pu!in probabil ca acest server s cunoasc adresa linda.cs.yale.edu "i probabil nu cunoa"te nici adresa cs.yale.edu, dar trebuie s cunoasc adresele fiilor din subarbore, astfel c va transmite cererea la serverul de nume yale.edu (pas 3). Acesta va transmi-te cererea mai departe c tre cs.yale.edu (pas 4), care trebuie s aib înregistr rile autorizate de resur-se. Deoarece fiecare cerere este de la un client la un server, înregistrarea de resurs cerut parcurge pa"ii 5 pân la 8.

Odat ce aceste înregistr ri de resurse ajung înapoi la serverul de nume cs.vu.nl, ele vor fi depuse în memoria ascuns , pentru a fi folosite ulterior. Totu"i, aceast informa!ie nu este autorizat , deoa-rece orice schimbare f cut la cs.yale.edu nu se va propaga spre toate serverele care au folosit-o. Din acest motiv intr rile în memoria ascuns nu ar trebui s aib via! prea lung . Acesta este motivul pentru care câmpul Timp_de_via!" este inclus în fiecare înregistrare de resurs . El informeaz serverele de nume aflate la distan! cât timp s men!in înregistr rile în memoria ascuns . Dac o anumit ma"in are de ani de zile aceea"i adres IP, aceast informa!ie ar putea fi p strat timp de o zi. Pentru informa!ii mai volatile este mai sigur ca înregistr rile s fie eliminate dup câteva secunde sau un minut.

De men!ionat c metoda de interogare descris aici este cunoscut ca metoda de interogare re-cursiv# (recursive query), deoarece fiecare server care nu are informa!ia cerut o caut în alt parte "i raporteaz . Este posibil "i o alt variant . În acest caz, atunci când o cerere nu poate fi rezolvat local, cererea e"ueaz , dar este întors numele urm torului server de pe calea ce trebuie încercat . Unele servere nu implementeaz interogarea recursiv "i întorc întotdeauna numele urm torului server la care s se încerce.

SEC. 7.2 PO$TA ELECTRONIC% 529

De asemenea merit men!ionat faptul c atunci când un client DNS nu reu"e"te s primeasc un r spuns înainte de expirarea timpului de c utare, data viitoare va încerca un alt server. Se presupune c serverul este probabil nefunc!ional, nu c cererea sau r spunsul s-au pierdut.

De"i DNS este foarte important pentru func!ionarea corect a Internetului, el nu face decât s pun în coresponden! nume simbolice de ma"ini cu adresele lor IP. El nu ajut la localizarea oame-nilor, resurselor, serviciilor sau obiectelor în general. Pentru localizarea acestora a fost definit un alt serviciu director, numit LDAP (Lightweight Directory Access Protocol, rom.: Protocol de acces la cataloage simplificate). El este o versiune simplificat a serviciului de cataloage OSI X.500, descris în RFC 225#. El organizeaz informa!ia sub form de arbore "i permite c ut ri pe diferite componente. Poate fi privit ca o carte de telefon obi"nuit (de tipul „pagini albe”). Nu o s intr m în am nunte referitoare la el în aceast carte, îns pute!i g si mai multe informa!ii în (Weltman "i Dahbura, 2000).

7.2 PO$TA ELECTRONIC%

Po"ta electronic , sau e-mail, cum este cunoscut de c tre numero"ii s i admiratori, exist de peste dou decenii. Înainte de #990, era folosit în special în mediul academic. În timpul anilor #990, a devenit cunoscut publicului larg "i a crescut exponen!ial pân la punctul în care num rul de mesaje electronice trimise pe zi este acum mult mai mare decât num rul de scrisori tradi!ionale (adic pe hârtie).

E-mail-ul, ca majoritatea celorlalte forme de comunicare, are conven!iile "i stilurile sale proprii. În particular, el este foarte neprotocolar "i are un prag de folosire foarte sc zut. Oamenii care n-ar visa niciodat s sune la telefon sau chiar s scrie o scrisoare unei Persoane Foarte Importante nu ezit o secund s trimit un e-mail neglijent.

E-mail-ul este plin de jargoane precum BTW (By The Way - apropo), ROTFL (Rolling On The Floor Laughing – a se t v li pe jos de râs) "i IMHO (In My Humble Opinion - dup umila mea p -rere). Mul!i oameni folosesc în e-mail-urile lor câteva caractere ASCII numite smileys sau emoti-cons (fa!a zâmbitoare "i fa!a trist ). Câteva din cele mai interesante sunt reproduse în fig. 7-6. Pentru cei mai mul!i, rotirea c r!ii cu 90 de grade în sensul acelor de ceasornic, le va face mai clare. Pentru o c rticic cu peste 650 smileys, vede!i (Sanderson "i Dougherty, #993).

Smiley Semnifica!ie Smiley Semnifica!ie Smiley Semnifica!ie :-) Sunt fericit =|:-) Abe Lincoln :+) Nas mare :-( Sunt trist, sup!rat =):-) Unchiul Sam :-)) Gu"! :-| Sunt apatic *<:-) Mo" Cr!ciun :-{) Musta ! ;-) Fac cu ochiul <:-( Dunce #:-) P!r încurcat :-(0) $ip (-: Australian 8-) Poart! ochelari :-(*) Vomit :-)X Om cu papion C:-) Cap mare

Fig. 7-6. Câteva smileys. Nu vor fi în examenul final :-) Primele sisteme de po"t electronic constau pur "i simplu din protocoale de transfer de fi"iere,

cu conven!ia ca prima linie a fiec rui mesaj (adic fi"ier) s con!in adresa receptorului. Cu timpul, limit rile acestei abord ri au devenit din ce în ce mai evidente. O parte dintre neajunsuri erau:

530 NIVELUL APLICA!IE CAP. 7

#. Trimiterea unui mesaj c tre un grup de persoane era incomod . Managerii au nevoie adesea de aceast facilitate pentru a trimite note "i rapoarte tuturor subordona!ilor.

2. Mesajele nu aveau structur intern , f când astfel dificil prelucrarea lor cu ajutorul calcula-torului. De exemplu, dac un mesaj trimis mai departe era inclus în corpul altui mesaj, ex-tragerea p r!ii incluse din mesajul primit era dificil .

3. Ini!iatorul (transmi! torul) nu "tia niciodat dac mesajul a ajuns sau nu. 4. Dac cineva avea în plan s plece în c l torie de afaceri pentru mai multe s pt mâni "i do-

rea ca toat po"ta primit în acest timp s fie preluat de c tre secretar , acest lucru nu era u"or de realizat.

5. Interfa!a cu utilizatorul era slab integrat cu sistemul de transmisie, cerând utilizatori-lor ca întâi s editeze un fi"ier, apoi s p r seasc editorul "i s apeleze programul de transfer de fi"iere.

6. Nu era posibil transmiterea de mesaje care s con!in o combina!ie de text, desene, facsimil "i voce.

Pe m sur ce s-a câ"tigat experien! , au fost propuse sisteme de po"t electronic mai complica-te. În #982 au fost publicate propunerile cu privire la e-mail ale ARPANET, sub numele de RFC 82# (protocolul de transmisie) "i RFC 822 (formatul mesajelor). Revizii minore, RFC 282# "i RFC 2822, au devenit standarde Internet, totu"i toat lumea se refer la e-mail gândindu-se la RFC 822.

În #984, CCITT a emis recomandarea X.400. Dup dou decenii de competi!ie, sistemele de po"t electronic bazate pe RFC 822 sunt larg r spândite, în timp ce acelea bazate pe X.400 au dis-p rut. Modul în care un sistem încropit de o mân de absolven!i de "tiin!a calculatoarelor a învins un standard interna!ional oficial, puternic sus!inut de c tre toate PTT-urile din lumea întreag , de mul-te guverne "i de o parte substan!ial a industriei calculatoarelor, ne aduce în minte povestea biblic a lui David "i Goliat.

Motivul succesului lui RFC822 nu este dat de faptul c ar fi atât de bun, ci acela c X.400 a fost atât de slab proiectat "i atât de complex, încât nimeni nu l-ar putea implementa bine. Având de ales între un sistem nesofisticat, dar care func!ioneaz , cum este cel bazat pe RFC822 "i sistemul de e-mail X.400, presupus cu adev rat minunat, dar nefunc!ional, majoritatea organiza!iilor l-au ales pe primul. Poate c este "i o lec!ie în spatele acestei pove"ti. De acea discu!ia noastr referitoare la e-mail se va concentra asupra sistemului de e-mail din Internet.

7.2. Arhitectur# &i servicii

În aceast sec!iune vom furniza o prezentare de ansamblu a ceea ce pot face sistemele de po"t electronic "i cum sunt ele organizate. Aceste sisteme constau de obicei din dou subsisteme: agen-"ii-utilizator, care permit utilizatorilor s citeasc "i s trimit scrisori prin po"ta electronic "i agen"ii de transfer de mesaje, care transport mesajele de la surs la destina!ie. Agen!ii-utilizator sunt pro-grame locale, care furnizeaz o metod de a interac!iona cu sistemul de e-mail bazat pe comenzi, meniuri sau grafic . Agen!ii de transfer de mesaje sunt, de regul , demoni de sistem, adic procese care se execut în fundal. Sarcina lor este s transfere mesajele prin sistem.

În general, sistemele de po"t electronic pun la dispozi!ie cinci func!ii de baz . S arunc m o privire asupra lor.

Compunerea se refer la procesul de creare a mesajelor "i a r spunsurilor. De"i pentru corpul mesajului poate fi folosit orice editor de texte, sistemul însu"i poate acorda asisten! la adresare "i la

SEC. 7.2 PO$TA ELECTRONIC% 53

completarea numeroaselor câmpuri antet ata"ate fiec rui mesaj. De exemplu, când se r spunde la un mesaj, sistemul poate extrage adresa ini!iatorului din mesajul primit "i o poate insera automat în locul potrivit din cadrul r spunsului.

Transferul se refer la deplasarea mesajului de la autor la receptor. În mare, aceasta necesit stabilirea unei conexiuni la destina!ie, sau la o ma"in intermediar , emiterea mesajului "i eliberarea conexiunii. Sistemul de po"t ar trebui s fac acest lucru singur, f r a deranja utilizatorul.

Raportarea se refer la informarea ini!iatorului despre ce s-a întâmplat cu mesajul. A fost livrat? A fost respins? A fost pierdut? Exist numeroase aplica!ii în care confirmarea livr rii este importan-t "i poate avea chiar semnifica!ie juridic . („$ti!i, domnule judec tor, sistemul meu de po"t elec-tronic nu e foarte de încredere, a"a c presupun c cita!ia electronic s-a pierdut pe undeva.”)

Afi&area mesajelor primite este necesar pentru ca utilizatorii s -"i poat citi po"ta. Uneori sunt necesare conversii sau trebuie apelat un program de vizualizare special; de exemplu, dac mesajul este un fi"ier PostScript, sau voce digitizat . Se mai încearc uneori "i conversii simple "i format ri.

Dispozi"ia este pasul final "i se refer la ceea ce face receptorul cu mesajul, dup ce l-a primit. Posibilit !ile includ eliminarea sa înainte de a-l citi, aruncarea sa dup citire, salvarea sa ".a.m.d. Ar trebui de asemenea s fie posibil reg sirea "i recitirea de mesaje deja salvate, trimiterea lor mai departe, sau procesarea lor în alte moduri.

În plus fa! de aceste servicii de baz , unele sisteme de e-mail, în special cele interne companii-lor, dispun de o gam variat de facilit !i avansate. S men!ion m pe scurt câteva dintre ele. Când utilizatorii se deplaseaz sau când sunt pleca!i pentru o perioad de timp, pot dori ca po"ta lor s fie trimis acolo unde se g sesc, a"a c sistemul ar trebui s fie capabil s fac acest lucru automat.

Majoritatea sistemelor permit utilizatorilor s -"i creeze cutii po&tale (mailboxes) pentru a p stra mesajele sosite. Sunt necesare comenzi de creare "i distrugere a cutiilor po"tale, de inspectare a con-!inutului acestora, de inserare "i de "tergere de mesaje din cutii po"tale ".a.m.d.

Managerii de companii au adesea nevoie s trimit un acela"i mesaj fiec rui subordonat, client sau furnizor. Acest lucru d na"tere ideii de list# de po&t# (mailing list), care este o list de adrese de po"t electronic . Când un mesaj este trimis la lista de po"t , copii identice ale sale sunt expediate fiec ruia dintre cei de pe list .

Alte caracteristici evoluate sunt copii la indigo, po"t de prioritate mare, po"t secret (criptat ), receptori alternativi, dac cel primar nu este disponibil, "i posibilitatea de a permite secretarelor s se ocupe de po"ta primit de "efii lor.

Po"ta electronic este în prezent folosit pe scar larg în industrie, pentru comunica!ie în cadrul companiilor. Aceasta permite unor angaja!i, r spândi!i la distan!e mari unii de ceilal!i, chiar "i peste mai multe fusuri orare, s coopereze la proiecte complexe. Eliminând majoritatea indiciilor cu privire la func!ie, vârst "i gen, dezbaterile prin po"ta electronic tind s se concentreze asupra ideilor "i nu a statutului din cadrul organiza!iei. Prin po"ta electronic , o idee sclipitoare a unui student la cursurile de var poate avea un impact mai mare decât una stupid , venit de la un vicepre"edinte executiv.

O idee fundamental în toate sistemele moderne de e-mail este distinc!ia dintre plic "i con!inutul s u. Plicul încapsuleaz mesajul. Con!ine toat informa!ia necesar pentru transportul mesajului, cum ar fi destina!ia, adresa, prioritatea, nivelul de securitate, toate acestea fiind distincte de mesajul în sine. Agen!ii de transfer de mesaje folosesc plicul pentru rutare (dirijare), a"a cum face "i oficiul po"tal.

Mesajul din interiorul plicului con!ine dou p r!i: antetul "i corpul. Antetul con!ine informa!ie de control pentru agen!ii utilizator. Corpul mesajului se adreseaz în întregime utilizatorului uman. Plicurile "i mesajele sunt ilustrate în fig. 7-7.

532 NIVELUL APLICA!IE CAP. 7

Fig. 7-7. Plicuri "i mesaje. (a) po"t clasic (b) po"t electronic .

7.2.2 Agentul utilizator

Sistemele de po"t electronic au, a"a cum am v zut, dou p r!i esen!iale: agen!ii-utilizator "i agen!ii de transfer de mesaje. În aceast sec!iune ne vom uita la agen!ii utilizator. Un agent utilizator este de obicei un program (uneori numit cititor de po"t ) care accept o varietate de comenzi pentru compunerea, primirea "i r spunsul la mesaje, cât "i pentru manipularea cutiilor po"tale. Unii agen!i-utilizator au o interfa! sofisticat , dirijat prin meniuri sau icoane, care necesit un maus, în timp ce altele accept comenzi de câte un caracter, date de la tastatur . Func!ional îns , to!i ace"tia sunt iden-tici. Unele sisteme sunt dirijate prin meniuri sau icoane dau au "i alternative mai „scurte” pe tastatur .

Trimiterea po&tei electronice Pentru a trimite un mesaj prin po"ta electronic , un utilizator trebuie s furnizeze mesajul, adre-

sa destina!ie, "i eventual al!i câ!iva parametri. Mesajul poate fi produs cu un editor de texte de sine-st t tor, cu un program de procesare de text sau, eventual, cu un editor de texte specializat, construit în interiorul agentului utilizator. Adresa de destina!ie trebuie s fie într-un format cu care agentul utilizator s poat lucra. Mul!i agen!i-utilizator solicit adrese de forma utilizator@adres"-dns. Deoa-rece aceste lucruri au fost studiate anterior în acest capitol, nu vom relua materialul respectiv aici.

SEC. 7.2 PO$TA ELECTRONIC% 533

Oricum, merit notat c exist "i alte forme de adresare. În particular, adresele X.400 arat radi-cal diferit de cele DNS. Ele sunt compuse din perechi de forma atribut = valoare, separate de bare oblice. De exemplu:

/C=US/SP=MASSACHUSETTS/L=CAMBRIDGE/PA=360 MEMORIAL DR./CN=KEN SMITH/

Aceast adres specific o !ar , un stat, o localitate, o adres personal "i un nume obi"nuit (Ken Smith). Sunt posibile multe alte atribute, astfel încât po!i trimite mesaje cuiva al c rui nume nu-l "tii, atâta timp cât "tii suficiente alte atribute (de exemplu, compania "i func!ia). Cu toate c adresele X.400 sunt mult mai pu!in convenabile decât cele DNS, cele mai multe sisteme de po"t electronic permit folosirea de pseudonime (aliases, uneori numite "i porecle) pentru ob!inerea numelor sau adreselor de e-mail corecte ale unei persoane. În consecin! , chiar "i cu adresele de tip X.400, de obicei nu este necesar scrierea în întregime a acelor "iruri ciudate.

Majoritatea sistemelor de e-mail accept liste de po"t , astfel c un utilizator poate trimite, cu o singur comand , un acela"i mesaj tuturor persoanelor dintr-o list . Dac lista de po"t este p strat local, agentul-utilizator poate pur "i simplu s trimit câte un mesaj separat fiec ruia dintre recepto-rii dori!i. Dac lista este p strat la distan! , atunci mesajele vor fi expandate acolo. De exemplu, dac un grup de admiratori de p s ri au o list de po"t numit birders, instalat la meadowlark. arizona.edu, atunci orice mesaj trimis la birders@meadowlark.arizona.edu va fi dirijat c tre Universi-tatea din Arizona "i expandat acolo în mesaje individuale pentru to!i membrii listei de po"t , oriunde ar fi ei în lume. Utilizatorii acestei liste de po"t nu pot determina c aceasta este o list de adrese. Ar putea fi la fel de bine cutia po"tal personal a Prof. Gabriel O. Birders.

Citirea po&tei electronice În mod obi"nuit, când este lansat un agent-utilizator, înainte de a afi"a ceva pe ecran, el se va ui-

ta în cutia po"tal a utilizatorului dup mesajele care sosesc. Apoi poate anun!a num rul de mesaje din cutie, sau poate afi"a pentru fiecare mesaj câte un rezumat de o linie, pentru ca apoi s a"tepte o comand .

Ca exemplu despre cum lucreaz un agent-utilizator, s arunc m o privire asupra unui scenariu tipic pentru po"ta electronic . Dup lansarea agentului-utilizator, utilizatorul cere un rezumat al mesajelor sale. O imagine ca aceea din fig. 7-8 apare în acest caz pe ecran. Fiecare linie se refer la câte un mesaj. În acest exemplu, cutia po"tal con!ine opt mesaje.

# Marcaje Octe!i Transmi!"tor Subiect # K #030 Asw Changes to MINIX 2 KA 6348 Trudy Not all Trudys are nasty 3 K F 45#9 Amy N. Wong Request for information 4 #236 Bal Bioinformatics 5 #036#0 Kaashoek Material on peer-to-peer 6 #223 Frank Re: Will you review a grant proposal 7 3##0 Guido Our paper has been accepted 8 #204 Dmr Re: My student’s visit

Fig. 7-8. Un exemplu de afi"are a con!inutului unei cutii po"tale.

Fiecare linie de afi"aj con!ine câteva câmpuri extrase de pe plicul sau din antetul mesajului co-respunz tor. Într-un sistem simplu de po"t electronic , alegerea câmpurilor afi"ate este f cut în cadrul programului. Într-un sistem mai sofisticat, utilizatorul poate specifica ce câmpuri s fie afi"a-te, furnizând un profil al utilizatorului, adic un fi"ier care descrie formatul de afi"are. În exemplul

534 NIVELUL APLICA!IE CAP. 7

considerat, primul câmp reprezint num rul mesajului. Al doilea câmp, Marcaje, poate con!ine un K, însemnând c mesajul nu este nou, dar a fost citit anterior "i p strat în cutia po"tal ; un A, însem-nând c deja s-a r spuns la acest mesaj; "i/sau un F, însemnând c mesajul a fost trimis mai departe altcuiva. Sunt de asemenea posibile "i alte marcaje.

Al treilea câmp specific lungimea mesajului "i al patrulea spune cine a trimis mesajul. Din mo-ment ce el este pur "i simplu extras din mesaj, acest câmp poate con!ine prenume, nume complete, ini!iale, nume de cont, sau orice altceva "i-a ales transmi! torul s pun . În sfâr"it, câmpul Subiect specific despre ce este mesajul, într-un scurt rezumat. Persoanele care omit s includ un câmp Subiect adesea descoper c r spunsurile la scrisorile lor tind s nu ob!in prioritate maxim .

Dup ce au fost afi"ate antetele, utilizatorul poate executa oricare dintre comenzile disponibile, ca de exemplu afi"area unui mesaj, "tergerea unui mesaj "i a"a mai departe. Sistemele mai vechi lu-crau în mod text "i de obicei foloseau comenzi de un caracter pentru diversele opera!ii, ca de exem-plu T (scrie mesaj), A (r spunde la mesaj), D ("terge mesaj) "i F (trimite mai departe). Un argument specifica mesajul corespunz tor. Sistemele mai recente folosesc interfe!e grafice. De obicei, utiliza-torul selecteaz un mesaj cu mouse-ul "i apoi apas pe o iconi! pentru a scrie, r spunde la mesaj, sau pentru a-l trimite mai departe.

Po"ta electronic a parcurs un drum lung de pe vremea când era doar transfer de fi"iere. Agen!i-utilizator sofistica!i fac posibil manevrarea unui volum mare de scrisori. Pentru persoane care pri-mesc "i trimit mii de mesaje pe an, asemenea instrumente sunt nepre!uite.

7.2.3 Formatele mesajelor

S ne întoarcem acum de la interfa!a utilizator la formatul mesajelor de po"t electronic în sine. Mai întâi ne vom uita la e-mailul ASCII de baz , care utilizeaz RFC 822. Dup aceea ne vom con-centra asupra extensiilor multimedia ale RFC 822.

RFC 822 Mesajele constau dintr-un plic simplu (descris în RFC 82#), un num r de câmpuri antet, o linie

goal "i apoi corpul mesajului. Fiecare câmp antet se compune (din punct de vedere logic) dintr-o singur linie de text ASCII, con!inând numele câmpului, dou puncte, "i, pentru majoritatea câmpu-rilor, o valoare. RFC 822 a fost creat acum dou decenii "i nu distinge clar plicul de câmpurile antet, cum ar face un standard nou. Cu toate c a fost corectat în RFC 2822, o refacere complet n-a fost posibil datorit r spândirii sale largi. La o utilizare normal , agentul-utilizator construie"te un me-saj "i îl transmite agentului de transfer de mesaje, care apoi folose"te unele dintre câmpurile antet pentru a construi plicul efectiv, o combina!ie oarecum demodat de mesaj "i plic.

Principalele câmpuri antet, legate de transportul de mesaje, sunt înf !i"ate în fig. 7-9. Câmpul To: ofer adresa DNS a receptorului primar. Este permis de asemenea existen!a de receptori multipli. Câmpul Cc: d adresa oric rui receptor secundar. În termenii livr rii, nu este nici o diferen! între un receptor primar "i unul secundar. Este în întregime o deosebire psihologic , ce poate fi importan-t pentru persoanele implicate, dar este neimportant pentru sistemul de po"t . Termenul Cc: (Car-bon copy - copie la indigo) este pu!in dep "it, din moment ce calculatoarele nu folosesc indigo, dar este bine înr d cinat. Câmpul Bcc: (Blind carbon copy - copie confiden!ial la indigo) este la fel ca Cc:, cu excep!ia c aceast linie este "tears din toate copiile trimise la receptorii primari "i secun-dari. Acest element permite utilizatorilor s trimit copii unei a treia categorii de receptori, f r ca cei primari "i secundari s "tie acest lucru.

SEC. 7.2 PO$TA ELECTRONIC% 535

Antet Con!inut To: Adresa(ele) de e-mail a(le) receptorului(ilor) primar(i) Cc: Adresa(ele) de e-mail a(le) receptorului(ilor) secundar(i) Bcc: Adresa(ele) de e-mail pentru „blind carbon copy” From: Persoana sau persoanele care au creat mesajul Sender: Adresa de e-mail a transmi !torului curent Received: Linie ad!ugat! de fiecare agent de transfer de-a lungul traseului Return-Path: Poate fi folosit! pentru a identifica o cale de întoarcere la transmi !tor

Fig. 7-9. Câmpurile antet ale lui RFC 822, legate de transportul de mesaje.

Urm toarele dou câmpuri, From: "i Sender:, precizeaz cine a scris "i respectiv cine a trimis me-sajul. Acestea pot s nu fie identice. De exemplu, se poate ca o directoare executiv s scrie un me-saj, dar ca secretara ei s fie cea care îl trimite efectiv. În acest caz, directoarea executiv va fi afi"at în câmpul From: "i secretara în câmpul Sender:. Câmpul From: este obligatoriu, dar câmpul Sender: poate fi omis dac este identic cu From:. Aceste câmpuri sunt necesare în cazul în care mesajul nu poate fi livrat "i trebuie returnat transmi! torului.

O linie con!inând Received: este ad ugat de fiecare agent de transfer de mesaje de pe traseu. Linia con!ine identitatea agentului, data "i momentul de timp la care a fost primit mesajul "i alte informa!ii care pot fi utilizate pentru g sirea defec!iunilor în sistemul de dirijare.

Câmpul Return-Path: este ad ugat de agentul final de transfer de mesaje "i are în inten!ie s indi-ce cum se ajunge înapoi la transmi! tor. În teorie, aceast informa!ie poate fi adunat din toate antetele Received: (cu excep!ia numelui cutiei po"tale a transmi! torului), dar rareori este completa-t a"a "i de obicei con!ine chiar adresa transmi! torului.

Antet Con!inut Date: Data "i momentul de timp la care a fost trimis mesajul Reply-To: Adresa de e-mail la care ar trebui trimise r!spunsurile Message-Id: Num!r unic, utilizat ulterior ca referin ! pentru acest mesaj (identificator) In-Reply-To: Identificatorul mesajului al c!rui r!spuns este mesajul curent References: Al i identificatori de mesaje relevan i Keywords: Cuvinte cheie alese de utilizator Subject: Scurt cuprins al mesajului, afi"abil pe o singur! linie

Fig. 7- 0. Câteva câmpuri utilizate în antetul lui RFC 822. În plus fa! de câmpurile din fig. 7-9, mesajele RFC 822 pot con!ine de asemenea o varietate de

câmpuri antet, folosite de agen!ii-utilizator sau de receptorii umani. Cele mai des întâlnite dintre ele sunt prezentate în fig. 7-#0. Majoritatea lor se explic de la sine, deci nu vom intra în detaliu la toate.

Câmpul Reply-To: este uneori utilizat când nici persoana care a compus mesajul, nici cea care l-a trimis nu vrea s vad r spunsul. De exemplu, un director de marketing scrie un mesaj prin e-mail pentru a spune clien!ilor despre un nou produs. Mesajul este trimis de o secretar , dar câmpul Reply-To: con!ine "eful departamentului de vânz ri, care poate r spunde la întreb ri "i primi comenzi. Acest câmp este foarte folositor când transmi! torul are dou conturi de e-mail "i vrea ca r spunsul s ajung în cel lalt.

Documentul RFC 822 afirm explicit c utilizatorilor le este permis s inventeze noi antete, atâta timp cât acestea încep cu "irul de caractere X-. Se garanteaz c nici o extindere ulterioar nu va folosi nume ce încep cu X-, pentru a evita conflictele (suprapunerile) dintre antetele oficiale "i cele

536 NIVELUL APLICA!IE CAP. 7

personale. Uneori studen!ii care fac pe de"tep!ii includ câmpuri de tipul X-Fruit-of-the-Day: sau X-Disease-of-the-Week:, care sunt legale, de"i nu întotdeauna clarificatoare.

Dup antete urmeaz corpul mesajului. Aici utilizatorii pot pune orice vor. Unii oameni î"i în-cheie mesajele cu semn turi elaborate, incluzând caricaturi ASCII simple, citate din personalit !i mai mari sau mai mici, declara!ii politice "i declin ri de tot felul (de exemplu: Corpora!ia XYZ nu este r spunz toare pentru p rerile mele; de fapt nu poate nici m car s le în!eleag ).

MIME - Multipurpose Internet Mail Extensions (extensii de po&t# cu scop multiplu) La începuturile ARPANET, po"ta electronic consta exclusiv din mesaje de tip text, scrise în en-

glez "i exprimate în ASCII. Pentru acest context, RFC 822 realiza sarcina complet: specific antetele, dar l sa con!inutul în întregime în seama utilizatorilor. În zilele noastre, aceast abordare nu mai este adecvat pentru Internetul care se întinde în lumea întreag . Problemele includ transmi-sia "i recep!ia de:

#. Mesaje în limbi cu accente (de exemplu franceza "i germana). 2. Mesaje în alfabete ne-latine (de exemplu ebraic "i rus ). 3. Mesaje în limbi f r alfabet (de exemplu chinez "i japonez ). 4. Mesaje care nu con!in text deloc (de exemplu audio "i video).

O solu!ie posibil a fost propus în RFC #34# "i actualizat în RFC-urile 2045-2049. Aceast so-lu!ie, numit MIME (Multipurpose Internet Mail Extensions), este în prezent larg utilizat . O vom descrie în continuare. Pentru informa!ii suplimentare în leg tur cu MIME, vede!i RFC-urile.

Ideea fundamental a MIME este s continue s foloseasc formatul RFC 822, dar s adauge structur corpului mesajului "i s defineasc reguli de codificare pentru mesajele non-ASCII. Deoa-rece respect RFC 822, mesajele MIME pot fi trimise utilizând programele "i protocoalele de po"t existente. Tot ceea ce trebuie modificat sunt programele de transmitere "i recep!ie, pe care utilizato-rii le pot face ei în"i"i.

Antet Con!inut MIME-Version: Identific! versiunea de MIME Content-Description: %ir adresat utilizatorului care spune ce este în mesaj Content-Id: Identificator unic Content-Transfer-Encoding: Cum este împachetat corpul pentru transmisie Content-Type: Natura mesajului

Fig. 7- . Antetele RFC 822 ad ugate de c tre MIME. MIME define"te cinci noi antete de mesaje, a"a cum se arat în fig. 7-##. Primul dintre acestea

specific pur "i simplu agentului-utilizator care prime"te mesajul c este vorba de un mesaj MIME "i ce versiune de MIME utilizeaz . Orice mesaj care nu con!ine un antet MIME-Version: este presupus ca fiind un mesaj în text pur, în englez , "i este procesat ca atare.

Antetul Content-Description: este un "ir de caractere ASCII specificând ce este în mesaj. Acest antet este necesar pentru ca receptorul s "tie dac merit s decodifice "i s citeasc mesajul. Dac "irul de caractere spune: “ Fotografia hamsterului Barbarei” "i persoana care prime"te mesajul nu este un mare iubitor de hamsteri, mesajul va fi probabil mai curând aruncat, decât decodificat într-o fotografie color de înalt rezolu!ie.

Antetul Content-Id: identific con!inutul. Utilizeaz acela"i format ca antetul standard Message-Id:.

SEC. 7.2 PO$TA ELECTRONIC% 537

Antetul Content-Transfer-Encoding: arat cum este împachetat pentru transmisie corpul mesaju-lui, într-o re!ea care poate ridica obiec!ii la majoritatea caracterelor diferite de litere, cifre "i semne de punctua!ie. Sunt furnizate cinci scheme (plus o evadare c tre noi scheme). Cea mai simpl sche-m se refer chiar la text ASCII. Caracterele ASCII utilizeaz 7 bi!i "i pot fi transportate direct prin protocolul de e-mail, atâta timp cât nici o linie nu are mai mult de #000 de caractere.

Urm toarea schem ca simplitate este cam acela"i lucru, dar utilizeaz caractere de câte 8 bi!i, re-prezentând toate valorile de la 0 la 255 inclusiv. Aceast schem de codificare încalc protocolul (origi-nal) de e-mail utilizat în Internet, dar este folosit de unele p r!i ale Internetului, care implementeaz ni"te extensii ale protocolului original. În timp ce declararea codific rii nu o face s devin legal , faptul c o avem explicit poate cel pu!in s l mureasc lucrurile atunci când ceva merge prost. Mesajele utili-zând codificarea de 8 bi!i trebuie înc s respecte lungimea maxim a liniei, care este standard.

Este chiar mai r u în cazul mesajelor care utilizeaz codificare binar . Aceste mesaje sunt fi"iere binare arbitrare, care nu numai c utilizeaz to!i cei 8 bi!i, dar nu respect nici limita de linie de #000 de caractere. Programele executabile intr în aceast categorie. Nu se acord nici o garan!ie c me-saje binare vor ajunge corect, dar mul!i le trimit oricum.

Modalitatea corect de a codifica mesaje binare este de a utiliza codificarea în baz 64, numit uneori armur ASCII. În aceast schem , grupuri de câte 24 de bi!i sunt împ r!ite în patru unit !i de câte 6 bi!i, fiecare dintre aceste unit !i fiind transmis ca un caracter ASCII legal. Codificarea este „A” pentru 0, „B” pentru #, ".a.m.d., urmate de cele 26 de litere mici, cele #0 cifre, "i în cele din ur-m + "i / pentru 62 "i respectiv 63. Secven!ele == "i = sunt utilizate pentru a ar ta c ultimul grup a con!inut doar 8 sau respectiv #6 bi!i. Se ignor secven!ele carriage return "i line feed, astfel c ele pot fi inserate dup dorin! , pentru a p stra liniile suficient de scurte. Utilizând aceast schem pot fi trimise sigur texte binare arbitrare.

Pentru mesajele care sunt aproape în întregime ASCII "i con!in pu!ine caractere ne-ASCII, codi-ficarea în baz 64 este oarecum ineficient . În locul acesteia se utilizeaz o codificare numit quoted-printable-encoding (codificare afi"abil marcat ). Aceasta este o codificare de tip ASCII pe 7 bi!i, având toate caracterele cu cod mai mare de #27 codificate sub forma unui semn egal urmat de va-loarea caracterului reprezentat prin dou cifre hexazecimale.

Rezumând, datele binare ar trebui trimise codificate în baz 64 sau sub form quoted-printable. Când exist motive întemeiate pentru a nu utiliza una dintre aceste scheme, este posibil s se specifi-ce în antetul Content-Transfer-Encoding: o codificare definit de c tre utilizator.

Ultimul antet înf !i"at în fig. 7-## este cu adev rat cel mai interesant. El specific natura corpului mesajului. În RFC 2045 sunt definite "apte tipuri, fiecare având unul sau mai multe subtipuri. Tipul "i subtipul sunt separate printr-o bar oblic (slash), ca în:

Content-Type: video/mpeg

Subtipul trebuie precizat explicit în antet; nu sunt furnizate valori implicite. Lista ini!ial de tipuri "i subtipuri specificate în RFC 2045 este prezentat în fig. 7-#2. De atunci au fost ad ugate multe altele, introducându-se intr ri adi!ionale de fiecare dat când a devenit necesar.

S parcurgem acum lista tipurilor. Tipul text este utilizat pentru text simplu. Combina!ia text/plain este folosit pentru mesaje obi"nuite care pot fi afi"ate de îndat ce sunt primite, f r codificare sau procesare ulterioar . Aceast op!iune permite ca mesajele obi"nuite s fie transportate în MIME ad ugând doar câteva antete suplimentare.

538 NIVELUL APLICA!IE CAP. 7

Tip Subtip Descriere Plain Text neformatat

Text Enriched Text incluzând comenzi simple de formatare Gif Imagini fixe în format GIF

Image Jpeg Imagini fixe în format JPEG

Audio Basic Sunet Video Mpeg Film în format MPEG

Octet-stream Secven ! neinterpretat! de octe i Application

Postscript Un document afi"abil în PostScript Rfc822 Un mesaj MIME RFC 822 Partial Mesajul a fost fragmentat pentru transmisie Message External-body Mesajul în sine trebuie adus din re ea Mixed P!r i independente în ordine specificat! Alternative Acela"i mesaj în formate diferite Parallel P!r ile trebuie vizualizate simultan

Multipart

Digest Fiecare parte este un mesaj RFC 822 complet

Fig. 7-"2. Tipurile "i subtipurile apar!inând MIME definite în RFC 2045.

Subtipul text/enriched permite includerea în text a unui limbaj simplu de marcare. Acest limbaj furnizeaz o modalitate independent de sistem pentru a exprima scrierea cu caractere aldine sau cursive, dimensiunile, alinierea, distan!ele dintre rânduri, folosirea de indici superiori sau inferiori "i paginarea simpl . Limbajul de marcare se bazeaz pe SGML, Standard Generalized Markup Language (limbajul standard generalizat de marcare), folosit de asemenea ca baz pentru HTML, utilizat în World Wide Web. De exemplu mesajul

The <bold> time </bold> has come the <italic> walrus </italic> said ...

ar fi afi"at sub forma:

The time has come the walrus said...

Depinde de sistemul receptor s aleag interpretarea potrivit . Dac sunt disponibile caractere aldine "i cursive, acestea vor putea fi folosite; altfel, pentru a scoate în eviden! se pot utiliza culori, scriere cu clipire sau video-invers etc. Sisteme diferite pot face alegeri diferite.

Când Web-ul a devenit popular, a fost ad ugat un nou subtip, text/html (în RFC 2854) pentru a permite paginilor Web s fie trimise într-un e-mail de tip RFC 822. Un subtip pentru sistemul extins de marcare, text/xml, este definit in RFC 3023. Vom studia HTML "i XML mai târziu în acest capitol.

Urm torul tip MIME este image, utilizat pentru trimiterea de imagini fixe. În zilele noastre sunt utilizate multe formate, atât cu, cât "i f r compresie, pentru a p stra "i transmite imagini. Dou dintre acestea, GIF "i JPEG, sunt recunoscute de aproape toate programele de navigare, dar exist "i altele care au fost ad ugate la lista original .

Tipurile video "i audio sunt pentru imagini în mi"care "i respectiv pentru imagini c rora li se asoci-az "i sunet. Trebuie notat c video include doar informa!ia video, nu "i coloana sonor . Dac trebuie transmis un film cu sunet, s-ar putea ca por!iunile audio "i video s trebuiasc s fie transmise separat, depinzând de sistemul de codificare utilizat. Primul format video definit a fost cel inventat de cei ce se intituleaz modest Moving Picture Experts Group (MPEG - Grupul de exper!i în imagini în mi"care), dar de atunci au fost ad ugate "i altele. În plus fa! de audio/basic, un nou tip audio, audio/mpeg a fost ad ugat în RFC 3003 pentru a permite oamenilor s trimit fi"iere MP3 prin e-mail.

Tipul application este utilizat ca un colector pentru formatele care necesit prelucrare extern , neidentificate de nici unul dintre celelalte tipuri. Un octet-stream este doar o secven! de octe!i nein-

SEC. 7.2 PO$TA ELECTRONIC% 539

terpreta!i. La primirea unui asemenea flux, un agent-utilizator ar trebui probabil s -l afi"eze, suge-rându-i utilizatorului s -l copieze într-un fi"ier "i cerându-i un nume pentru acesta. Procesarea ulte-rioar este apoi la latitudinea utilizatorului.

Cel lalt subtip definit este postscript, care se refer la limbajul PostScript, produs de Adobe Systems "i larg utilizat pentru descrierea paginilor imprimate. Multe imprimante au înglobate interpretoare PostScript. De"i un agent-utilizator poate pur "i simplu s apeleze un interpretor PostScript extern pentru a interpreta fi"ierele PostScript primite, acest lucru nu este lipsit de perico-le. PostScript este un întreg limbaj de programare. Dându-i-se destul timp, o persoan suficient de masochist ar putea scrie în PostScript un compilator de C, sau un sistem de management de baze de date. Afi"area unui mesaj primit în format PostScript se face executând programul PostScript con!inut de acesta. Pe lâng afi"area unui text, acest program poate citi, modifica, sau "terge fi"ierele utilizatorului "i poate avea "i alte efecte laterale nepl cute.

Tipul message permite încapsularea în întregime a unui mesaj în altul. Aceast schem este util , de exemplu pentru trimiterea mai departe a e-mailului, cu forward. Când un mesaj RFC 822 complet este încapsulat într-un mesaj exterior, ar trebui utilizat subtipul rfc822.

Subtipul partial face posibil împ r!irea unui mesaj încapsulat în buc !i de mesaj "i trimiterea se-parat a acestora (de exemplu, dac mesajul încapsulat este prea lung). Parametrii fac posibil re-asamblarea în ordinea corect a tuturor p r!ilor, la destina!ie.

$i în sfâr"it, subtipul external-body pate fi utilizat pentru mesaje foarte lungi (de exemplu, filme video). În loc de a include fi"ierul MPEG în mesaj, se d o adres FTP "i agentul utilizator al recep-torului o poate aduce din re!ea în momentul în care este necesar. Aceast facilitate este în special util când se trimite un film la o întreag list de po"t "i se presupune c doar câ!iva dintre membrii acesteia îl vor vedea (gândi!i-v la e-mailurile inutile, con!inând reclame video).

From: elinor@abcd.com To: carolyn@xyz.com MIME-Version: #.0 Message-Id: <070476094#.AA00747@abcd.com> Content-Type: multipart/alternative; boundary=qwertyuiopasdfghjklzxcvbnm Subject: P!mântul înconjoar! soarele de un num!r întreg de ori

Acesta este preambulul. Agentul utilizator îl ignor!. O zi bun!.

--qwertyuiopasdfghjklzxcvbnm Content-Type: text/richtext

Happy birthday to you Happy birthday to you Happy birthday dear <bold> Carolyn </bold> Happy birthday to you

--qwertyuiopasdfghjklzxcvbnm Content-Type: message/external-body; access-type=„anon-ftp”; site=„bicycle.abcd.com”; directory=„pub”; name=„birthday.snd;

content-type: audio/basic content-transfer-encoding: base64 --qwertyuiopasdfghjklzxcvbnm

Fig. 7-"3. Un mesaj multipart con!inând alternative de tip text formatat "i audio.

540 NIVELUL APLICA!IE CAP. 7

Ultimul tip este multipart, care permite unui mesaj s con!in mai multe p r!i, începutul "i sfâr"i-tul fiec rei p r!i fiind clar delimitat. Subtipul mixed permite fiec rei p r!i s fie diferit de celelalte, f r a avea o structur adi!ional impus . Multe programe de e-mail permit utilizatorului s aib una sau mai multe p r!i ata"ate la un mesaj text. Acestea sunt trimise folosind tipul multipart.

În contrast cu tipul multipart, subtipul alternative permite ca fiecare parte s con!in acela"i me-saj, dar exprimat într-un alt mediu sau într-o codificare diferit . De exemplu, un mesaj ar putea fi trimis ca ASCII simplu, ca text formatat "i ca PostScript. Un agent-utilizator proiectat corespunz -tor, la primirea unui asemenea mesaj, îl va afi"a, dac va fi posibil, în PostScript. A doua alegere va fi textul formatat. Dac nici una dintre aceste alternative nu ar fi posibil , s-ar afi"a text ASCII obi"nu-it. P r!ile ar trebui ordonate de la cea mai simpl , la cea mai complex , pentru a ajuta receptorii care folosesc agen!i-utilizator pre-MIME s în!eleag mesajul (chiar "i un utilizator pre-MIME poate citi text ASCII simplu). Subtipul alternative poate fi folosit de asemenea pentru limbaje multiple. În acest context, Rosetta Stone poate fi privit ca precursor al mesajului de tip multipart/alternative.

Un exemplu multimedia este prezentat în fig. 7-#3. Aici, o felicitare este transmis atât sub form de text cât "i sub form de cântec. Dac receptorul are facilit !i audio, agentul utilizator va aduce fi"ierul de sunet, birthday.snd "i îl va interpreta. Dac nu, versurile vor fi afi"ate pe ecran într-o lini"te de mormânt. P r!ile sunt delimitate de dou cratime urmate de "irul (definit de utilizator) specificat în parametrul boundary.

Observa!i c antetul Content-Type apare în trei pozi!ii în acest exemplu. La primul nivel indic faptul c mesajul are mai multe p r!i. În cadrul fiec rei p r!i specific tipul "i subtipul acesteia. În sfâr"it, în corpul celei de-a doua p r!i, este necesar pentru a indica agentului utilizator ce fel de fi"ier extern trebuie s aduc . Pentru a exprima u"oara diferen! de utilizare, s-au folosit litere mici, de"i toate antetele sunt case insensitive (nu fac diferen! între literele mari "i cele mici). Antetul content-transfer-encoding este în mod similar necesar pentru orice corp extern care nu este codificat ca AS-CII pe 7 bi!i.

Întorcându-ne la subtipurile corespunz toare mesajelor multipart, vom spune c mai exist dou posibilit !i. Subtipul parallel este utilizat când toate p r!ile trebuie s fie interpretate simultan. De exemplu, adesea filmele au un canal audio "i unul video. Ele sunt mai de efect dac aceste dou ca-nale sunt interpretate în paralel "i nu consecutiv.

În sfâr"it, subtipul digest este utilizat când multe mesaje sunt împachetate împreun , într-unul compus. De exemplu, ni"te grupuri de dialog de pe Internet pot aduna mesaje de la abona!ii lor "i apoi s le trimit în afar ca un singur mesaj de tip multipart/digest.

7.2.4 Transferul mesajelor

Sistemul de transfer de mesaje se ocup cu transmiterea mesajelor de la expeditor la receptor. Cea mai simpl cale de a realiza acest lucru const în stabilirea unei conexiuni de transport de la ma"ina surs la cea de destina!ie "i apoi, pur "i simplu în trimiterea mesajului. Dup ce examin m cum se face acest lucru în mod normal, vom studia câteva situa!ii în care metoda nu func!ioneaz "i vom vedea ce trebuie f cut în aceste cazuri.

SMTP – Simple Mail Transfer Protocol (Protocol simplu de transfer de po#t ) În cadrul Internetului po"ta electronic este livrat prin stabilirea de c tre ma"ina surs a unei

conexiuni TCP la portul 25 al ma"inii de destina!ie. La acest port se afl un demon de e-mail care "tie SMTP (Simple Mail Transfer Protocol). Acest demon accept conexiunile "i copiaz mesajele

SEC. 7.2 PO$TA ELECTRONIC% 54"

de la ele în cutiile po"tale corespunz toare. Dac mesajul nu poate fi livrat, se returneaz transmi! -torului un raport de eroare con!inând prima parte a mesajului nelivrat.

SMTP este un protocol simplu de tip ASCII. Dup stabilirea conexiunii TCP la portul 25, ma"ina transmi! toare, operând în calitate de client, a"teapt ca ma"ina receptoare, operând ca server, s vorbeasc prima. Serverul începe prin a trimite o linie de text, declarându-"i identitatea "i spunând dac este preg tit sau nu s primeasc mesaje. Dac nu este, clien!ii elibereaz conexiunea "i încear-c din nou mai târziu.

S: 220 xyz.com SMTP service ready

C: HELO abcd.com S: 250 xyz.com says hello to abcd.com

C: MAIL FROM: <elinor@abcd.com> S: 250 sender ok

C: RCPT TO: <carolyn@xyz.com> S: 250 recipient ok

C: DATA S: 354 Trimite mail; terminat cu ”.” pe linie nou! C: From: elinor@abcd.com C: To: carolyn@xyz.com C: MIME-Version: #.0 C: Message-Id: <070476094#.AA00747@abcd.com> C: Content-Type: multipart/alternative; boundary=qwertyuiopasdfghjklzxcvbnm C: Subject: P!mântul înconjoar! soarele de un num!r întreg de ori C: C: Acesta este preambulul. Agentul utilizator îl ignor!. O zi bun!. C: C: --qwertyuiopasdfghjklzxcvbnm C: Content-Type: text/enriched C: C: Happy birthday to you C: Happy birthday to you C: Happy birthday dear <bold> Carolyn </bold> C: Happy birthday to you C: C: --qwertyuiopasdfghjklzxcvbnm C: Content-Type: message/external-body; C: access-type=”anon-ftp”; C: site=”bicycle.abcd.com”; C: directory=”pub”; C: name=”birthday.snd”; C: C: content-type: audio/basic C: content-transfer-encoding: base64 C: --qwertyuiopasdfghjklzxcvbnm C: .

S: 250 message accepted C:QUIT

S: 22# xyz.com closing connection

Fig. 7-"4. Transferul unui mesaj de la elinor@abcd.com la carolyn@zxy.com.

542 NIVELUL APLICA!IE CAP. 7

Dac serverul este dispus s primeasc e-mail, clientul anun! de la cine vine scrisoarea "i cui îi

este adresat . Dac un asemenea receptor exist la destina!ie, serverul îi acord clientului permisiu-nea s trimit mesajul. Apoi clientul trimite mesajul "i serverul îl confirm . În general nu este nece-sar ata"area unei sume de control deoarece TCP furnizeaz un flux sigur de octe!i. Dac mai exist "i alte mesaje, acestea sunt trimise tot acum. Când schimbul de mesaje, în ambele direc!ii, s-a înche-iat, conexiunea este eliberat . În fig. 7-#4 este prezentat o mostr de dialog referitoare la trimiterea mesajului din fig. 7-#3, incluzând codurile numerice utilizate de SMTP. Liniile trimise de client sunt marcate cu C:, iar cele trimise de server cu S:.

Câteva comentarii în leg tur cu fig. 7-#4 ar putea fi utile. Prima comand a clientului este într-adev r HELO. Din posibilele abrevieri de patru caractere ale cuvântului HELLO, aceasta are nu-meroase avantaje fa! de concurenta sa cea mai mare. Motivul pentru care toate comenzile trebuiau s aib patru caractere s-a pierdut în negura vremii.

În Fig.7-#4, mesajul este trimis la un singur receptor "i de aceea este utilizat o singur comand RCPT. Mai multe asemenea comenzi sunt permise pentru a trimite un singur mesaj mai multor re-ceptori. Fiecare dintre ele este confirmat sau rejectat individual. Chiar dac unii dintre receptori sunt rejecta!i (deoarece ei nu exist la destina!ie), mesajul poate fi trimis celor r ma"i.

În sfâr"it, de"i sintaxa comenzilor de patru caractere de la client este rigid specificat , sintaxa re-plicilor este mai pu!in rigid . Doar codul numeric conteaz cu adev rat. Fiecare implementare poate pune dup cod ce "iruri de caractere vrea.

Pentru a în!elege mai bine cum func!ioneaz SMTP "i câteva din celelalte protocoale descrise în acest capitol, încerca!i-le! În orice caz, mai întâi merge!i la o ma"in conectat la Internet. Într-un sistem UNIX introduce!i comanda:

telnet mail.isp.com 25

înlocuind numele DNS cu numele serverului de mail al ISP-ului dvs. Pe un sistem Windows, face!i clic pe Start, apoi Run, apoi tasta!i comanda în c su!a de dialog. Aceast comand va stabili o cone-xiune Telnet (adic TCP) pe portul 25 pe ma"ina respectiv . Portul 25 este portul SMTP (vezi Fig. 6-27 pentru câteva porturi uzuale). Probabil o sa primi!i un r spuns de genul:

Trying #92.30.200.66... Connected to mail.isp.com Escape character is ’^]’. 220 mail.isp.com Smail #74 ready at Thu, 25 Sept 2002 #3:26 +0200

Primele trei linii spun ce face telnet-ul. Ultima linie este de la serverul SMTP de pe ma"ina de la distan! , anun!ând disponibilitatea acesteia de a vorbi cu dvs. "i de a accepta e-mail. Pentru a vedea ce comenzi accept , tasta!i:

HELP

De aici înainte, este posibil o secven! de comenzi ca cea din fig. 7-#4, începând cu comanda HELO dat de client.

E bine de notat faptul c folosirea liniilor de text ASCII pentru comenzi nu e un accident. Cele mai multe protocoale Internet func!ioneaz a"a. Folosirea textului ASCII face ca protocoalele foarte u"or de testat "i depanat. Ele pot fi testate trimi!ând manual comenzi, cum am v zut mai sus, pentru care copiile mesajelor (eng.: dumps) sunt u"or de citit.

SEC. 7.2 PO$TA ELECTRONIC% 543

Chiar dac protocolul SMTP este bine definit, mai pot ap rea câteva probleme. O proble-m este legat de lungimea mesajelor. Unele implement ri mai vechi nu pot s lucreze cu me-saje mai mari de 64KB. O alt problem se refer la expir ri de timp (timeout). Dac acestea difer pentru server "i client, unul din ei poate renun!a, în timp ce cel lalt este înc ocupat, întrerupând conexiunea în mod nea"teptat. În sfâr"it, în unele situa!ii, pot fi lansate schimburi infinite de mesaje. De exemplu, dac ma"ina # p streaz lista de po"t A "i ma"ina 2 lista de po"t B "i fiecare list con!ine o intrare pentru cealalt , atunci orice mesaj trimis oric reia din-tre cele dou liste va genera o cantitate nesfâr"it de trafic de e-mail.

Pentru a atinge câteva dintre aceste probleme, în RFC 282# s-a definit protocolul SMTP extins (ESMTP). Clien!ii care doresc s -l utilizeze trebuie s trimit ini!ial un mesaj EHLO în loc de HELO. Dac acesta este rejectat, atunci serverul este unul standard de tip SMTP "i clientul va trebui s se comporte în modul obi"nuit. Dac EHLO este acceptat, înseamn ca sunt permise noile co-menzi "i noii parametri.

7.2.5 Livrarea final

Pân acum, am presupus c to!i utilizatorii lucreaz pe ma"ini capabile s trimit "i s primeasc e-mail. Dup cum am v zut, e-mail-ul este livrat prin stabilirea unei conexiuni TCP între expeditor "i destinatar "i apoi prin trimiterea e-mail-ului prin ea. Acest model a func!ionat bine zeci de ani, atât timp cât toate calculatoarele din ARPANET ("i mai târziu din Internet) erau, de fapt, conectate la re!ea "i gata s accepte conexiuni TCP.

Totu"i, odat cu apari!ia celor care acceseaz Internet-ul folosind un modem cu care se conec-teaz la ISP-ul lor, acest lucru nu mai !ine. Problema este urm toarea: Ce se întâmpl când Elinor vrea s -i trimit Carolynei un e-mail "i Carolyn nu este conectat la re!ea în acel moment? Elinor nu va putea s stabileasc o conexiune TCP cu Carolyn "i astfel, nu va putea utiliza protocolul SMTP.

O solu!ie este ca agentul de transfer de mesaje de pe o ma"in ISP s accepte e-mail-ul pentru clien!ii s i "i s -l stocheze în cutiile lor po"tale pe o ma"in a ISP-ului. Din moment ce acest agent poate fi conectat la re!ea tot timpul, se poate trimite e-mail 24 de ore pe zi.

POP3 Din nefericire, aceast solu!ie d na"tere altei probleme: cum î"i ia utilizatorul e-mail-ul de la

agentul de transfer de mesaje al ISP-ului? Solu!ia acestei probleme este crearea unui alt protocol care s permit agen!ilor de transfer mesaje (afla!i pe calculatoarele clien!ilor) s contacteze agentul de transfer mesaje (de pe o ma"in ISP) "i s fac posibil copierea e-mail-ului de la ISP la utilizator. Un astfel de protocol este POP3 (Post Office Protocol Version 3- Protocol de po"t , versiunea 3), definit în RFC #939.

Situa!ia anterioar (când atât expeditorul cât "i destinatarul aveau conexiune permanent la In-ternet) este ilustrat în fig. 7-#5(a). O situa!ie în care expeditorul este efectiv conectat la re!ea (on-line) dar destinatarul nu, este ilustrat în fig. 7-#5(b).

POP3 începe când utilizatorul porne"te programul cititor de po"t (mail reader). Acesta sun la ISP (în caz c nu exist deja o conexiune) "i stabile"te o conexiune TCP cu agentul de transfer de mesaje, prin portul ##0. Odat ce conexiunea a fost stabilit , protocolul POP3 trece succesiv prin urm toarele trei st ri:

#. Autorizare.

544 NIVELUL APLICA!IE CAP. 7

(a)Sistemulexpeditor

SMTP Internet

Agentulde transfer

mesaje

Agentulutilizator

Agentulutilizator

Conexiunepermanentã

Conexiunetemporarã

Cutiepostalã

Sistemuldest inatar

Sistemulexpeditor

SMTP POP3Internet

Agentulde transfer

mesaje

ServerPOP3

Cutiepostalã

MasinaISP-ului

(b)

Fig. 7-"5. (a) Trimiterea "i citirea po"tei când destinatarul are o conexiune permanent la Internet, iar agentul utilizator ruleaz pe aceea"i ma"in ca "i agentul de transfer de mesaje.

(b) Citirea e-mail-ului când destinatarul are o conexiune comutat (dial-up) la un ISP. 2. Tranzac!ionare. 3. Actualizare.

Starea de autorizare se refer la admiterea utilizatorului în sistem (login). Starea de tranzac!ionare trateaz colectarea e-mail-urilor "i marcarea lor pentru "tergere din cutia po"tal . Starea de actuali-zare se ocup cu "tergerea efectiv a mesajelor.

Aceast comportare poate fi observat tastând ceva de genul:

telnet mail.isp.com ##0

unde mail.isp.com reprezint numele DNS al serverului de mail de la ISP. Telnet stabile"te o cone-xiune TCP prin portul ##0, pe care ascult serverul POP3. Dup acceptarea conexiunii TCP, serve-rul trimite un mesaj ASCII anun!ându-"i prezen!a. De obicei, el începe cu +OK urmat de un co-mentariu. Un exemplu de scenariu este ar tat în fig. 7-#6 începând dup ce conexiunea TCP a fost stabilit . Ca "i mai înainte, liniile marcate cu C: sunt ale clientului (utilizatorului) iar cele cu S: sunt ale serverului (agentul de transfer de mesaje de la ISP).

În timpul st rii de autorizare, clientul trimite numele s u de utilizator "i parola. Dup conectarea cu succes, clientul poate s trimit comanda LIST, care determin serverul s listeze con!inutul cuti-ei po"tale. Lista este terminat cu un punct.

Apoi, clientul poate reg si mesajele folosind comanda RETR "i le poate marca pentru "tergere cu DELE. Când toate mesajele au fost primite ("i eventual marcate pentru "tergere), clientul trimite comanda QUIT pentru terminarea st rii de tranzac!ionare "i intrarea în starea de actualizare. Când serverul a "ters toate mesajele, el trimite un r spuns "i desfiin!eaz conexiunea TCP.

SEC. 7.2 PO$TA ELECTRONIC% 545

S: +OK Serverul POP3 este preg!tit C: USER carolyn

S: +OK C: PASS vegetables

S: +OK autentificare cu succes C: LIST

S: # 2505 S: 2 #4302 S: 3 8#22 S: .

C: RETR # S: (trimite mesajul #)

C: DELE # C: RETR 2

S: (trimite mesajul 2) C: DELE 2 C: RETR 3

S: (trimite mesajul 3) C: DELE 3 C: QUIT

S: +OK Serverul POP3 întrerupe leg!tura

Fig. 7-"6. Folosirea protocolului POP3 pentru a aduce trei mesaje. De"i este adev rat c protocolul POP3 are abilitatea de a desc rca un anumit mesaj sau un anu-

mit grup de mesaje p strându-le pe server, cele mai multe programe de e-mail descarc tot "i golesc cutia po"tal . Ca urmare, practic singura copie r mâne înregistrat pe discul utilizatorului. Dac acesta se stric , toate e-mail-urile pot fi pierdute definitiv.

S recapitul m pe scurt cum lucreaz e-mail-ul pentru clien!ii unui ISP. Elinor creeaz un mesaj pentru Carolyn folosind un program de e-mail (adic , agentul utilizator) "i face clic pe o icoan pen-tru a-l trimite. Programul de e-mail trimite mesajul agentului de transfer de mesaje de pe calculato-rul Elinorei. Agentul de transfer de mesaje vede c mail-ul este pentru carolyn@xyz.com "i folose"te DNS pentru a c uta înregistrarea MX pentru xyz.com (unde xyz.com este ISP-ul Carolynei). Aceast cerere întoarce numele DNS al serverului de mail xyz.com. Agentul de transfer de mesaje caut acum adresa IP a acestei ma"ini folosind din nou DNS, de exemplu gethostbyname. Apoi, el stabile"-te o conexiune TCP cu serverul SMTP pe portul 25 de pe aceast ma"in . Folosind o secven! de comenzi SMTP, asem n toare celei din fig. 7-#4, el transfer mesajul în cutia po"tal a Carolynei "i întrerupe conexiunea TCP.

Dup un timp, Carolyn î"i porne"te PC-ul s u, se conecteaz la ISP "i porne"te programul de e-mail. Programul de e-mail stabile"te o conexiune TCP cu serverul POP3 pe portul ##0 al serverului de po"t al ISP-ului. Numele DNS sau adresa IP a acestei ma"ini este configurat în mod normal atunci când programul de e-mail este instalat sau când este f cut contractul cu ISP-ul. Dup ce co-nexiunea TCP a fost stabilit , programul de e-mail al Carolynei lanseaz protocolul POP3 pentru a aduce con!inutul cutiei sale po"tale pe discul fix folosind comenzi ca cele din fig. 7-#6. Odat ce a fost transferat tot e-mail-ul, conexiunea TCP este eliberat . De fapt, conexiunea cu ISP-ul poate fi desfiin!at acum, din moment ce tot e-mailul este pe discul fix al Carolynei. Desigur, pentru a trimite un r spuns, va fi nevoie din nou de conexiunea cu ISP-ul, care, în general, nu este întrerupt imediat dup aducerea po"tei.

546 NIVELUL APLICA!IE CAP. 7

IMAP Pentru un utilizator cu un singur cont de e-mail, la un singur ISP, care este tot timpul accesat de

la un singur PC, POP3 este bun "i larg folosit datorit simplit !ii "i robuste!ii sale. Totu"i, exist în industria calculatoarelor un adev r bine înr d cinat, acela c imediat ce un lucru func!ioneaz bine, cineva va începe s cear mai multe facilit !i ("i s aib mai multe probleme). Asta s-a întâmplat "i cu e-mail-ul. De exemplu, mult lume are un singur cont de e-mail la serviciu sau la "coal "i vrea s -l acceseze de pe PC-ul de acas , de pe calculatorul portabil în c l toriile de afaceri "i din Internet café-uri în vacan!e. Cu toate c POP3 permite asta, din moment ce în mod normal el descarc toate mesajele la fiecare conectare, rezultatul const în r spândirea e-mail-ului utilizatorului pe mai multe ma"ini, mai mult sau mai pu!in la întâmplare, unele dintre ele nefiind ale utilizatorului.

Acest dezavantaj a dat na"tere unei alternative a protocolului de livrare final , IMAP (Internet Message Access Protocol – Protocol pentru accesul mesajelor în Internet), care este definit în RFC 2060. Spre deosebire de POP3, care în mod normal presupune c utilizatorul î"i va goli c su!a po"tal la fiecare conectare "i va lucra deconectat de la re!ea (off-line) dup aceea, IMAP presupune c tot e-mail-ul va r mâne pe server oricât de mult, în mai multe c su!e po"tale. IMAP prevede mecanisme extinse pentru citirea mesajelor sau chiar a p r!ilor de mesaje, o facilitate folositoare când se utilizea-z un modem încet pentru citirea p r!ii textuale a unui mesaj cu mai multe p r!i audio "i video de mari dimensiuni. Întrucât premisa de folosire este c mesajele nu vor fi transferate pe calculatorul utilizatorului în vederea stoc rii permanente, IMAP asigur mecanisme pentru crearea, distrugerea "i manipularea mai multor cutii po"tale pe server. Astfel, un utilizator poate p stra o cutie po"tal pen-tru fiecare corespondent "i poate muta aici mesajele din inbox dup ce acestea au fost citite.

IMAP are multe facilit !i, ca de exemplu posibilitatea de a se referi la un mesaj nu prin num rul de sosire, ca în fig. 7-8, ci utilizând atribute (de exemplu, d -mi primul mesaj de la Bobbie). Spre deosebire de POP3, IMAP poate de asemenea s accepte atât expedierea mesajelor spre destina!ie cât "i livrarea mesajelor venite.

Stilul general al protocolului IMAP este similar cu cel al POP3-ului, dup cum se arat în fig. 7-#6, cu excep!ia faptului c exist zeci de comenzi. Serverul IMAP ascult pe portul #43. În fig. 7-#7 este prezentat o compara!ie între POP3 "i IMAP. E bine de notat, totu"i, c nu toate ISP-urile ofe-r ambele protocoale "i c nu toate programele de e-mail le suport pe amândou . A"adar, atunci când alege!i un program de e-mail, este important s afla!i ce protocoale suport "i s v asigura!i c ISP-ul ofer cel pu!in unul din ele.

Caracteristica POP3 IMAP Unde este definit protocolul RFC #939 RFC 2060 Portul TCP folosit ##0 #43 Unde este stocat e-mail-ul PC-ul utilizatorului Server Unde este citit e-mail-ul Off-line On-line Timpul necesar conect!rii Mic Mare Folosirea resurselor serverului Minim! Intens! Mai multe cutii po"tale Nu Da Cine face copii de siguran ! la cutiile po"tale Utilizatorul ISP-ul Bun pentru utilizatorii mobili Nu Da Controlul utilizatorului asupra scrisorilor preluate Mic Mare Desc!rcare par ial! a mesajelor Nu Da Volumul discului alocat (disk quota) este o problem! Nu Ar putea fi în timp Simplu de implementat Da Nu Suport r!spândit Da În cre"tere

Fig. 7-"7. O compara!ie între POP3 "i IMAP.

SEC. 7.2 PO$TA ELECTRONIC% 547

Facilit $i de livrare Indiferent dac este folosit POP3 sau IMAP, multe sisteme ofer leg turi pentru procesarea adi-

!ional a mesajelor e-mail sosite. Un instrument deosebit de valoros pentru mul!i utilizatori de e-mail este reprezentat de capacitatea de a construi filtre. Acestea sunt reguli care se verific la sosirea mesajelor sau la pornirea agentului utilizator. Fiecare regul specific o condi!ie "i o ac!iune. De exemplu, o regul ar putea spune c orice mesaj venit de la "ef trebuie pus în cutia po"tal num rul #, orice mesaj de la un anumit grup de prieteni se duce în cutia po"tal num rul 2 "i orice alt mesaj con!inând anumite cuvinte în Subiect este aruncat f r comentarii.

Unii ISP ofer filtre care clasific automat mesajele sosite ca fiind importante sau nerelevante (spam) "i memoreaz fiecare mesaj în cutia po"tal corespunz toare. Asemenea filtre func!ioneaz verificând mai întâi dac sursa este un autor cunoscut de mesaje „spam”. Apoi examineaz subiectul. Dac sute de utilizatori au primit un mesaj cu acela"i subiect, probabil c el este nerelevant. Exist "i alte tehnici folosite pentru detec!ia mesajelor lipsite de importan! .

O alt caracteristic a livr rii, pus la dispozi!ie adesea, este posibilitatea de a retrimite (temporar) po"ta la o adres diferit . Aceast adres poate fi "i un calculator utilizat de un serviciu comercial de comunica!ii, care va contacta utilizatorul prin radio sau satelit, afi"ând Subject: linie pe pagerul s u.

O alt tr s tur comun a livr rii finale este abilitatea de a instala un demon de vacan$ . Acesta este un program care examineaz fiecare mesaj sosit "i trimite o replic insipid cum ar fi:

Salut. Sunt în vacan !. M! întorc pe 24 august. O zi bun!.

Asemenea r spunsuri pot s specifice, de asemenea, cum s fie tratate problemele urgente, al-te persoane care pot fi contactate pentru probleme specifice etc. Majoritatea demonilor de vacan-! p streaz urma celor c rora le-au trimis replici "i se ab!in de la a trimite unei aceleia"i persoane o a doua asemenea replic . Demonii buni verific "i dac mesajul sosit a fost trimis de la o list de mail "i în acest caz, nu mai r spund deloc. (Cei care trimit mesaje în timpul verii la liste mari de e-mail, probabil c nu doresc s primeasc sute de replici în care s le fie detaliate planurile de va-can! ale fiec ruia.)

Autorul s-a lovit recent de o form extrem de prelucrare a livr rii când a trimis o scrisoare unei persoane care pretinde c prime"te 600 de mesaje pe zi. Identitatea sa nu va fi deconspirat aici, ca nu cumva jum tate dintre cititorii acestei c r!i s -i trimit "i ei scrisori. S -l numim în con-tinuare John.

John "i-a instalat un robot de e-mail care verific fiecare mesaj sosit, ca s vad dac este de la un nou corespondent. Dac este a"a, trimite înapoi o replic standard în care explic faptul c nu mai poate s citeasc personal toate mesajele. În schimb a produs un document FAQ (Frequently Asked Questions) personal, unde r spunde la multe întreb ri care i se pun de obicei. În mod normal, gru-purile de "tiri "i nu persoanele au documente FAQ.

Documentul FAQ al lui John d adresa acestuia, num rul de fax "i numerele de telefon "i spune cum poate fi contactat firma sa. Arat cum poate fi chemat ca vorbitor "i explic cum pot fi ob!inute lucr rile sale "i alte documente. Furnizeaz de asemenea referin!e la programele scrise de el, o confe-rin! pe care o organizeaz , un standard al c rui editor este "i a"a mai departe. E posibil ca aceast abordare s fie necesar , dar poate c un FAQ personal reprezint simbolul final al statutului.

Po#ta electronic pe Web (Webmail) Un subiect care merit men!ionat este po"ta electronic pe Web. Anumite situri de Web, cum ar

fi Hotmail sau Yahoo ofer servicii de po"t electronic oricui dore"te. Ele func!ioneaz dup cum

548 NIVELUL APLICA!IE CAP. 7

urmeaz . Au agen!i normali de transfer de mesaje, care a"teapt la portul 25 conexiuni noi de SMTP. Pentru a contacta, s spunem Hotmail, trebuie s ob!ine!i înregistrarea sa DNS MX, de exemplu tastând

host –a –v hotmail.com

pe un sistem UNIX. S presupunem c serverul de po"t electronic se nume"te mx 0.hotmail.com; atunci tastând

telnet mx#0.hotmail.com 25

se poate stabili o conexiune TCP prin care se pot trimite comenzi SMTP în modul obi"nuit. Deo-camdat , nimic special, cu excep!ia faptului c aceste servere mari sunt adeseori ocupate, ca atare se poate s dureze ceva mai mult pân v este acceptat o cerere de conexiune TCP.

Partea interesant este cum se transmite po"ta electronic . În principiu, atunci când utilizatorul se duce la pagina de Web a po"tei electronice, îi este prezentat un formular în care i se cere un nume de cont "i o parol . Când utilizatorul face clic pe Sign In, numele de cont "i parola sunt trimise serve-rului, care le valideaz . Dac autentificarea s-a f cut cu succes, serverul g se"te cutia po"tal a utili-zatorului "i construie"te o list similar cu cea din fig. 7-8, cu diferen!a c are formatul unei pagini de Web în HTML. Pagina Web este transmis apoi programului de navigare pentru a fi afi"at . Pe mul-te din elementele paginii se pot executa clic-uri, astfel c mesajele pot fi citite, "terse, ".a.m.d.

7.3 WORLD WIDE WEB

Web-ul este un context arhitectural pentru accesul la documente, r spândite pe mii de ma"ini din Internet, între care exist leg turi. În #0 ani a evoluat de la o aplica!ie pentru transmiterea de date utile pentru fizica energiilor înalte la o aplica!ie despre care milioane de oameni cred c este Inter-netul. Popularitatea sa enorm se datoreaz faptului c are o interfa! grafic plin de culoare, u"or de utilizat de c tre încep tori "i în acela"i timp ofer o cantitate imens de informa!ie - de la animale mitologice la tribul Zulu, pe aproape orice subiect posibil.

Web-ul (cunoscut "i ca WWW) a ap rut în #989 la CERN, Centrul European de Cercet ri Nuclea-re. CERN are câteva acceleratoare utilizate de echipe mari de cercet tori din ! rile europene pentru cercet ri în fizica particulelor. Deseori aceste echipe au membri din peste zece ! ri. Majoritatea experi-en!elor sunt foarte complicate "i necesit ani de preg tire "i construire de echipamente. Web-ul a ap -rut din necesitatea de a permite cercet torilor r spândi!i în lume s colaboreze utilizând colec!ii de rapoarte, planuri, desene, fotografii "i alte tipuri de documente aflate într-o continu modificare.

Propunerea ini!ial pentru crearea unei colec!ii de documente având leg turi între ele (Web) a fost f cut de fizicianul Tim Berners-Lee, fizician la CERN, în martie #989. Primul prototip (bazat pe text) era opera!ional #8 luni mai târziu. În decembrie #99#, s-a f cut o demonstra!ie public la conferin!a Hypertex'9# în San Antonio, Texas.

Aceasta demonstra!ie "i publicitatea aferent au atras aten!ia altor cercet tori, fapt care l-a de-terminat pe Marc Andreessen de la University of Ilinois s înceap s dezvolte primul program de navigare grafic, Mosaic. Acesta a fost lansat în februarie #993. Mosaic a fost atât de popular încât un an mai târziu Marc Andreessen a plecat pentru a forma o nou companie, Netscape Communica-tions Corp., care se ocupa cu dezvoltarea de software pentru Web. Când Netscape a devenit o com-

SEC. 7.3 WORLD WIDE WEB 549

panie public în #995, investitorii, care probabil c au crezut c este vorba de un fenomen de tip Mi-crosoft, au pl tit #,5 miliarde de dolari pentru ac!iunile companiei. Acest record a fost cu atât mai nea"teptat cu cât compania avea un singur produs, opera în deficit "i anun!ase probabilii investitori c nu se a"teapt la beneficii în viitorul apropiat. În urm torii trei ani, Netscape Navigator "i produ-sul Internet Explorer al companiei Microsoft au intrat într-un „r zboi al programelor de navigare”, fiecare din produse încercând cu frenezie ad ugarea de noi op!iuni ("i astfel a mai multor erori) de-cât cel lalt. În #998, America Online a cump rat Netscape Communications Corp. pentru suma de 4.2 miliarde $, încheind astfel durata scurt în care Netscape a fost o companie independent .

În #994, CERN "i M.I.T. au semnat o în!elegere pentru a forma Consor$iul World Wide Web (câteodat abreviat ca W3C), o organiza!ie care are ca obiectiv dezvoltarea Web-ului, standardizarea protocoalelor, "i încurajarea interoperabilit !ii între situri. Berners-Lee a devenit director. De atunci, sute de universit !i "i companii au intrat în consor!iu. M.I.T. coordoneaz partea american a con-sor!iului în timp ce centrul de cercet ri francez, INRIA, coordoneaz partea european . De"i exist foarte multe c r!i despre Web, cel mai bun loc pentru g sirea unor informa!ii la zi despre el este (în mod natural) chiar Web-ul. Pagina consor!iului are adresa www.w3.org . Cititorii interesa!i vor g si acolo leg turi la pagini care acoper toate documentele "i activit !ile consor!iului.

7.3." Aspecte arhitecturale

Din punctul de vedere al utilizatorului, Web-ul const dintr-o colec!ie imens de documente sau pagini de Web (Web pages), adesea numite prescurtat pagini, r spândite în toat lumea. Fiecare pagin poate s con!in leg turi (indicatori) la alte pagini, aflate oriunde în lume. Utilizatorii pot s aleag o leg tur prin execu!ia unui clic care îi va aduce la pagina indicat de leg tur . Acest proces se poate repeta la nesfâr"it. Ideea ca o pagin s con!in leg turi c tre altele a fost inventat în #945, cu mult înainte de a se fi inventat Internet-ul, de c tre Vannevar Bush, un profesor vizionar de la departamentul de inginerie electric al M.I.T.

Paginile pot s fie v zute cu ajutorul unui program de navigare (browser). Internet Explorer "i Netscape Navigator sunt cele mai cunoscute programe de navigare. Programul de navigare aduce pagina cerut , interpreteaz textul "i comenzile de formatare con!inute în text "i afi"eaz pagina, formatat corespunz tor, pe ecran. Un exemplu este prezentat în fig. 7-#8(a). Ca majoritatea pagi-nilor de Web, începe cu un titlu, con!ine informa!ii "i se termin cu adresa de po"t electronic a celui care men!ine pagina. $irurile de caractere care reprezint leg turi la alte pagini, se numesc hiper-leg turi, sunt afi"ate în mod diferit, fiind subliniate "i/sau colorate cu o culoare special . Pen-tru a selecta o leg tur , utilizatorul va plasa cursorul pe zona respectiv , ceea ce va determina schimbarea formei cursorului "i va executa un clic. De"i exist programe de navigare f r interfa! grafic , ca de exemplu Lynx, ele nu sunt atât de utilizate ca programele de navigare grafice, astfel încât în continuare ne vom referi numai la ultimele. Au fost dezvoltate "i programe de navigare bazate pe voce.

Utilizatorii care sunt interesa!i s afle mai multe despre „Department of Animal Psichology” vor selecta numele respectiv (apare subliniat). Programul de navigare va aduce pagina la care este legat numele respectiv "i o va afi"a, a"a cum se vede în fig. 7-#8(b). $irurile subliniate aici pot s fie selecta-te la rândul lor pentru a aduce alte pagini "i a"a mai departe. Noua pagin se poate afla pe aceea"i ma"in ca "i prima sau pe o ma"in aflat undeva pe glob la polul opus. Utilizatorul nu va "ti. Aduce-rea paginilor este realizat de c tre programul de navigare, f r nici un ajutor din partea utilizatoru-lui. Dac utilizatorul se va întoarce la prima pagin , leg turile care au fost deja utilizate vor fi afi"ate

550 NIVELUL APLICA!IE CAP. 7

Fig. 7-"8. (a) O pagin de Web. (b) pagina la care se ajunge dac se selecteaz

Department of Animal Psychology

altfel decât celelalte (subliniate cu linie punctat sau utilizând o alt culoare) pentru a fi deosebite de cele care nu au fost înc selectate. De notat c selec!ia liniei Campus Information din prima pagin nu are nici un efect. Nu este subliniat , ceea ce înseamn c este pur "i simplu un text care nu este legat de o alt pagin .

Modelul de baz al func!ion rii Web-ului este ar tat in fig. 7-#9. Aici un program de navigare afi-"eaz o pagin de Web pe ma"ina clientului. Atunci când utilizatorul face clic pe linia de text ce indic spre o pagin de pe serverul abcd.com, programul de navigare urmeaz hiper-leg tura trimi-!ând un mesaj serverului abcd.com în care se cere pagina respectiv . Atunci când pagina sose"te, ea este afi"at . Dac aceast pagin con!ine o hiper-leg tur c tre o pagin de pe serverul xyz.com pe care utilizatorul face clic, programul de navigare trimite o cerere ma"inii respective pentru acea pa-gin , "i a"a mai departe la nesfâr"it.

SEC. 7.3 WORLD WIDE WEB 55"

Fig. 7-"9. P r!ile componente ale modelului Web-ului

Aspecte privind clientul S examin m acum în detaliu aspectele ce privesc clientul din fig. 7-#9. În esen! , un program de

navigare este o aplica!ie capabil s afi"eze o pagin de Web "i s capteze clicurile mouse-ului pe elemente ale paginii afi"ate. Când un element este selectat, programul de navigare urmeaz hiper-leg tura "i ob!ine pagina selectat . Ca atare, hiper-leg tura con!inut în pagin necesit o modalitate de a adresa prin nume orice alt pagin de pe Web. Paginile sunt adresate prin nume folosind URL-uri (Uniform Resource Locators, rom.: Localizatoare Uniforme de Resurse). Un URL tipic este

http://www.abcd.com/products.html Vom explica ce înseamn URL mai târziu, în cadrul capitolului curent. Deocamdat , este sufici-

ent s "tim c un URL are trei p r!i: numele protocolului (http), numele calculatorului pe care se g se"te pagina (www.abcd.com) "i numele fi"ierului care con!ine pagina (products.html).

Când un utilizator execut un clic pe o hiper-leg tur , programul de navigare urmeaz o serie de etape pentru a ob!ine pagina indicat de hiper-leg tur . S presupunem ca utilizatorul navigheaz pe Web "i g se"te o leg tura despre telefonia pe Internet care indic spre pagina principal a ITU, http://www.itu.org/home/index.html. S urm m etapele parcurse când aceast leg tur este selectat .

#. Programul de navigare determin URL (pe baza selec!iei). 2. Programul de navigare întreab DNS care este adresa IP pentru www.itu.org. 3. DNS r spunde cu #56.#06.#92.32. 4. Programul de navigare realizeaz conexiunea TCP cu portul 80 al #56.#06.#92.32. 5. Trimite o cerere pentru fi"ierul /home/index.html. 6. Serverul www.itu.org transmite fi"ierul /home/index.html. 7. Conexiunea TCP este eliberat . 8. Programul de navigare afi"eaz textul din /home/index.html. 9. Programul de navigare aduce "i afi"eaz toate imaginile din acest fi"ier.

552 NIVELUL APLICA!IE CAP. 7

Multe programe de navigare informeaz despre etapa care se execut într-o fereastr de stare, în partea de jos a paginii. În acest mod, dac performan!ele sunt slabe, utilizatorul poate s "tie dac este vorba de faptul c DNS nu r spunde, c serverul nu r spunde, sau pur "i simplu de congestia re!elei în timpul transmisiei paginii.

Pentru a afi"a noua pagin (sau orice pagin ), programul de navigare trebuie s în!eleag forma în care este scris . Pentru a permite tuturor programelor de navigare s în!eleag orice pagin de Web, paginile de Web sunt scrise într-un limbaj standardizat numit HTML, care descrie paginile de Web. Vom discuta acest limbaj mai târziu în acest capitol.

De"i un program de navigare este în principiu un interpretor de HTML, majoritatea programe-lor de navigare au numeroase butoane "i op!iuni care ajut navigarea prin Web. Multe au un buton pentru revenirea la pagina anterioar , un buton pentru a merge la pagina urm toare (acest buton este opera!ional numai dup ce utilizatorul s-a întors înapoi dintr-o pagin ) "i un buton pentru selec-!ia paginii personale (home page). Majoritatea programelor de navigare au un buton sau un meniu pentru înregistrarea unei adrese de pagin (bookmark) "i un altul care permite afi"area unor adrese înregistrate, f când astfel posibil revenirea la o pagin cu ajutorul câtorva selec!ii simple realizate cu mausul. Paginile pot s fie salvate pe disc sau tip rite. Sunt disponibile numeroase op!iuni pentru controlul ecranului "i configurarea programului de navigare conform dorin!elor utilizatorului.

În afar de text obi"nuit (nesubliniat) "i hipertext (subliniat), paginile de Web pot s con!in iconi-!e, desene, h r!i, fotografii. Fiecare dintre acestea poate s fie, în mod op!ional, legat la alt pagin . Dac se selecteaz unul dintre aceste elemente, programul de navigare va aduce pagina respectiv "i o va afi"a, a"a cum se întâmpl în cazul select rii unui text. Pentru imaginile care sunt fotografii sau h r!i, alegerea paginii care se aduce poate s depind de regiunea din imagine pe care se face selec!ia.

Nu toate paginile con!in HTML. O pagin poate fi format dintr-un document în format PDF, o iconi! în format GIF, o fotografie în format JPEG, o melodie în format MP3, o înregistrare video în format MPEG sau oricare din cele alte câteva sute de tipuri de fi"iere. Deoarece paginile în forma standard HTML pot avea leg turi c tre oricare din acestea, programul de navigare are o problem atunci când întâlne"te o pagin pe care nu o poate interpreta.

În loc sa fac programele de navigare din ce în ce mai mari, înglobând interpretoare pentru o co-lec!ie de tipuri de fi"iere în cre"tere rapid , majoritatea programelor de navigare au ales o solu!ie mai general . Atunci când un server întoarce o pagin , el întoarce de asemenea informa!ii adi!ionale despre acea pagin . Aceast informa!ie include tipul MIME al paginii (fig. 7-#2). Paginile de tipul text/html sunt afi"ate direct, ca "i paginile de alte câteva tipuri interpretate implicit. Dac tipul MIME nu este unul dintre acestea, programul de navigare î"i consult tabela de tipuri MIME pentru a afla cum s afi"eze pagina. Aceast tabel asociaz un tip MIME cu o aplica!ie de vizualizare.

Fig. 7-20. (a) Un plug-in al programului de navigare. (b) O aplica!ie auxiliar

SEC. 7.3 WORLD WIDE WEB 553

Exist dou posibilit !i: plug-in-uri "i programe auxiliare (helper applications). Un plug-in este un modul pe care programul de navigare îl ob!ine dintr-un director special de pe disc "i îl instaleaz ca o extensie al însu"i programului de navigare, a"a cum se arat în fig. 7-20(a). Deoarece plug-in-urile se execut în interiorul programului de navigare, acestea au acces la pagina curent "i pot s modifice modul în care aceasta este afi"at . Dup ce plug-in-ul a terminat ceea ce avea de f cut (de obicei dup ce utilizatorul s-a deplasat la alt pagin de Web), acesta este scos din memoria programului de navigare.

Fiecare program de navigare are o colec!ie de proceduri pe care toate plug-in-urile trebuie s le implementeze pentru ca programul de navigare s poat executa plug-in-ul. De exemplu, exist de obicei o procedur pe care modulul principal al programului de navigare o apeleaz pentru a oferi plug-in-ului date ce trebuie afi"ate. Aceast colec!ie de proceduri constituie interfa!a unui plug-in "i este particular fiec rui program de navigare.

În plus, programul de navigare pune la dispozi!ia plug-in-ului propria sa colec!ie de proceduri. Pro-cedurile tipice din interfa!a programului de navigare se refer la alocarea "i eliberarea memoriei, afi"a-rea de mesaje în fereastra de stare a programului de navigare sau ob!inerea parametrilor acestuia.

Înainte ca un plug-in s poat fi folosit, acesta trebuie instalat. Procedura uzual de instalare este ca utilizatorul s navigheze la situl de Web al plug-in-ului "i s copieze un fi"ier de instalare. Pe sis-temele Windows, acesta este de obicei o arhiv zip cu decompresie automat cu extensia .exe. Când pe acest fi"ier se execut un dublu clic, se execut un program de mici dimensiuni ata"at p r!ii de început a fi"ierului. Acest program decomprim plug-in-ul "i îl copiaz în directorul de plug-in-uri al programului de navigare. Apoi execut apelurile necesare pentru înregistrarea tipului MIME cores-punz tor "i asocierea acestuia cu plug-in-ul. Pe sistemele UNIX, fi"ierul de instalare este in mod frecvent un fi"ier de comenzi care se ocup de copiere "i înregistrare.

Cea de-a doua modalitate de extindere a unui program de navigare este utilizarea aplica$iilor auxiliare (helper applications). Acestea sunt programe complete ce se execut ca procese separate. Acest fapt este ilustrat în fig. 7-20(b). Deoarece acestea sunt programe separate, nu ofer nici o interfa! programului de navigare "i nu utilizeaz serviciile acestuia. De obicei îns accept doar numele unui fi"ier temporar unde a fost stocat con!inutul paginii, deschide acest fi"ier "i îi afi"eaz con!inutul. De obicei, aplica!iile auxiliare sunt programe de dimensiuni mari care exist indepen-dent de programul de navigare, cum ar fi Adobe Acrobat Reader pentru afi"area fi"ierelor PDF, sau Microsoft Word. Unele programe (cum ar fi Acrobat) dispun de un plug-in care execut aplica-!ia auxiliar .

Multe aplica!ii auxiliare folosesc tipul MIME application. A fost definit un num r considerabil de subtipuri, de exemplu application/pdf pentru fi"iere PDF "i application/msword pentru fi"iere Word. În acest mod, un URL poate s indice direct c tre un fi"ier PDF sau Word "i atunci când utilizatorul execut un clic asupra sa aplica!iile Acrobat sau Word sunt pornite automat "i li se transmite numele fi"ierului temporar ce con!ine datele ce trebuie afi"ate. Ca atare, programele de navigare pot fi con-figurate s trateze un num r teoretic nelimitat de tipuri de documente, f r schimb ri aduse pro-gramului de navigare. Serverele de Web moderne sunt adesea configurate cu sute de combina!ii de tipuri/subtipuri "i combina!ii noi sunt ad ugate de fiecare dat când este instalat un program nou.

Aplica!iile auxiliare nu sunt restric!ionate la utilizarea tipului MIME application. Adobe Photo-shop folose"te image/x-photoshop "i RealOne Player poate trata de exemplu audio/mp3.

Pe sistemele Windows, atunci când un program este instalat pe un calculator, el înregistreaz ti-purile MIME pe care dore"te s le trateze. Acest mecanism conduce la conflicte atunci când mai multe aplica!ii sunt disponibile pentru vizualizarea unui subtip, cum ar fi video/mpg. Ceea ce se în-

554 NIVELUL APLICA!IE CAP. 7

tâmpl este c ultimul program ce se înregistreaz supraînscrie asocia!iile existente (tip MIME, apli-ca!ie auxiliar ), captând tipul pentru sine. Ca o consecin! , instalarea unui nou program poate schimba modul în care un program de navigare trateaz tipurile existente.

Pe sistemele UNIX, acest proces de înregistrare nu se face în general automat. Utilizatorul tre-buie s schimbe anumite fi"iere de configurare. Aceast abordare conduce la un volum mai mare de munc dar la surprize mai pu!ine.

Programele de navigare pot de asemenea deschide fi"iere locale în loc de a le ob!ine de pe serve-re de Web de la distan! . Deoarece fi"ierele locale nu au tipuri MIME, programul de navigare nece-sit o metod pentru a determina ce plug-in sau aplica!ie auxiliar trebuie folosit pentru alte tipuri decât cele tratate implicit ca text/html sau image/jpeg. Pentru tratarea fi"ierelor locale, aplica!iile auxi-liare pot fi asociate "i cu o extensie de fi"ier, ca "i cu un tip MIME. Considerând configura!ia stan-dard, deschiderea fi"ierului foo.pdf îl va înc rca în Acrobat "i deschiderea fi"ierului bar.doc îl va în-c rca în Word. Anumite programe de navigare folosesc tipul MIME, extensia fi"ierului "i chiar in-forma!ii din interiorul fi"ierului pentru a ghici tipul MIME. În special Internet Explorer se bazeaz în primul rând pe extensia fi"ierului decât pe tipul MIME atunci când acest lucru este posibil.

$i aici pot apare conflicte deoarece multe programe sunt dispuse, de fapt dornice s trateze mpg, de exemplu. În timpul instal rii, programele create pentru profesioni"ti afi"eaz frecvent c su!e de selec!ie pentru tipurile MIME "i extensiile pe care sunt preg tite s le trateze pentru a permite utili-zatorului selec!ia celor dorite pentru a preveni astfel supraînscrierea accidental a asocia!iilor exis-tente. Programele ce au ca !int marea mas a consumatorilor presupun c utilizatorul nu "tie ce este un tip MIME "i pur "i simplu acapareaz tot ce pot f r s !in seama de ceea ce au f cut pro-gramele instalate anterior.

Capacitatea de a extinde programul de navigare cu un num r mare de tipuri noi este util , dar poate duce "i la probleme. Atunci când Internet Explorer ob!ine un fi"ier cu extensia exe î"i da seama c acest fi"ier este un program executabil "i ca atare nu are o aplica!ie adi!ional asociat . Ac!iunea evident este execu!ia fi"ierului. Însa aceast ac!iune poate fi o problem de securitate enorm . Tot ceea ce trebuie s fac un site de Web r u inten!ionat este s ofere o pagin de Web, de exemplu cu fotografii de staruri de cinema sau sportive, toate imaginile indicând c tre un virus. Un singur clic pe o imagine determin ca un program executabil necunoscut "i posibil ostil s fie copiat "i executat pe ma"ina utilizatorului. Pentru a preveni astfel de vizitatori nedori!i, Internet Explorer poate fi confi-gurat s fie selectiv în a executa programe necunoscute în mod automat, dar nu to!i utilizatorii în!e-leg cum s foloseasc aceast configurare.

Pe sistemele UNIX pot exista probleme similare cu fi"ierele de comenzi pentru consola sistemu-lui, dar aceasta necesit ca utilizatorul s instaleze în mod con"tient consola sistemului ca aplica!ie auxiliar . Din fericire, acest proces este suficient de complicat pentru ca nimeni s nu poat s îl efectueze accidental ("i pu!ine persoane pot s îl efectueze chiar inten!ionat).

Aspecte privind serverul Cam atât despre aspectele privind clientul. S ne referim acum la aspectele privind serverul. A"a

cum am v zut mai sus, atunci când utilizatorul tasteaz un URL sau execut un clic asupra unei linii de hipertext, programul de navigare analizeaz URL-ul "i interpreteaz partea între http:// "i urm -torul caracter / ca un nume DNS ce trebuie c utat. Înarmat cu adresa IP a serverului, programul de navigare stabile"te o conexiune TCP la portul 80 de pe acel server. Apoi se transmite o comand ce con!ine restul URL-ului, care este de fapt numele fi"ierului de pe acel server. Serverul întoarce apoi fi"ierul pentru a fi afi"at de c tre programul de navigare.

SEC. 7.3 WORLD WIDE WEB 555

Într-o prim aproximare, un server de Web este similar cu serverul din fig. 6-6. Acel server, ca "i un server de Web real, prime"te numele fi"ierului ce trebuie c utat "i transmis programului de navi-gare. În ambele cazuri, etapele pe care le parcurge serverul în bucla sa principal sunt:

#. Accept o conexiune TCP de la un client (program de navigare). 2. Ob!ine numele fi"ierului cerut. 3. Ob!ine fi"ierul (de pe disc). 4. Întoarce fi"ierul clientului. 5. Elibereaz conexiunea TCP.

Serverele de Web moderne au mai multe caracteristici, dar în esen! acestea sunt func!iile unui server de Web. O problem cu aceast arhitectur este c fiecare cerere necesit acces la disc pentru ob!inerea fi"ierului. Rezultatul este c serverul de Web nu poate servi mai multe cereri pe secund decât num rul de accese la disc ce se pot executa pe secund . Un disc SCSI are un timp de acces mediu de circa 5 ms, ceea ce limiteaz serverul la cel mult 200 de cereri/sec, chiar mai pu!in dac trebuie citite des fi"iere mari. Pentru un sit de Web de importan! mare, acest num r este prea mic.

O îmbun t !ire evident (utilizat de toate serverele de Web) este folosirea unui sistem de me-morie ascuns , temporar pentru cele mai recente n fi"iere utilizate. Înainte de ob!inerea unui fi"ier de pe disc, serverul verific memoria ascuns (cache). Dac fi"ierul exist acolo, el poate fi servit direct din memorie, eliminând astfel accesul la disc. De"i pentru o memorie ascuns eficient sunt necesare o cantitate mare de memorie principal "i timp de procesare suplimentar pentru a analiza memoria ascuns "i pentru a-i administra con!inutul, economia de timp este aproape întotdeauna superioar timpului suplimentar de procesare "i costului memoriei.

Fig. 7-2". Un server de Web cu mai multe fire de execu!ie cu un modul frontal "i module de procesare

Urm torul pas pentru construc!ia unui server mai rapid este de a face serverul s admit mai

multe fire de execu!ie (multithreaded). Într-una din arhitecturi, serverul este format dintr-un modul frontal (front-end module), care accept conexiunile nou venite, "i k module de procesare, a"a cum arata fig. 7-2#. Cele k + # fire de execu!ie apar!in toate aceluia"i proces, astfel c modulele de proce-

556 NIVELUL APLICA!IE CAP. 7

sare au toate acces la memoria ascuns din interiorul spa!iului de adrese al procesului. La sosirea unei cereri, modulul frontal o accept "i construie"te o scurt înregistrare ce descrie cererea. Aceasta este transmis apoi unuia dintre modulele de procesare. În alt arhitectur posibil , modulul frontal este eliminat "i fiecare modul de procesare încearc s î"i ob!in propriile cereri, dar în acest caz este necesar un protocol de sincronizare pentru prevenirea conflictelor.

Modulul de procesare verific mai întâi memoria ascuns pentru a determina dac fi"ierul nece-sar se afl acolo. Dac da, modific înregistrarea pentru a include "i un indicator c tre fi"ierul din înregistrare. Dac fi"ierul nu se afl acolo, modulul de procesare începe opera!iile cu discul pentru a citi fi"ierul în memoria ascuns (renun!ând eventual la alte fi"iere pentru a face loc acestuia). Când fi"ierul este citit de pe disc, el este pus în cache "i de asemenea transmis clientului.

Avantajul acestei scheme este c în timp ce unul sau mai multe module de procesare sunt blocate a"teptând terminarea opera!iilor cu discul ("i deci nu consum din timpul procesorului), alte module pot fi active lucrând la satisfacerea altor cereri. Desigur, pentru a ob!ine o îmbun t !ire real asupra modelului cu un singur fir de execu!ie este necesar existen!a mai multor unit !i de disc, astfel încât mai multe discuri s poat fi ocupate în acela"i timp. Cu ajutorul a k module de procesare "i k unit !i de disc, eficien!a poate cre"te pân la de k ori fa! de modelul serverului cu un singur fir de execu!ie "i o singur unitate de disc.

Teoretic, un server cu un singur fir de execu!ie "i k unit !i de disc poate de asemenea câ"tiga un factor k în ceea ce prive"te eficien!a, dar implementarea "i administrarea sunt mult mai complicate deoarece apelurile de sistem READ normale, blocante nu pot fi folosite pentru accesul la disc. În cazul unui server cu mai multe fire de execu!ie, acestea pot fi folosite deoarece o opera!ie READ blocheaz doar firul de execu!ie care a executat opera!ia "i nu întregul proces.

Serverele de Web moderne efectueaz mai multe opera!ii decât acceptarea numelor de fi"iere "i transmiterea con!inutului acestora. De fapt, procesarea fiec rei cereri poate deveni destul de com-plicat . Din acest motiv, într-un num r mare de servere fiecare modul de procesare efectueaz o serie de etape. Modulul frontal transmite fiecare cerere sosit c tre primul modul de procesare dis-ponibil, care apoi execut cererea, utilizând o submul!ime a urm torilor pa"i, în func!ie de ce pa"i sunt necesari pentru respectiva cerere.

#. Rezolvarea numelui paginii de Web cerute. 2. Autentificarea clientului. 3. Verificarea drepturilor de acces ale clientului. 4. Verificarea drepturilor de acces asupra paginii de Web. 5. Verificarea memoriei ascunse. 6. Ob!inerea paginii cerute, de pe disc. 7. Determinarea tipului MIME ce va fi inclus în r spuns. 8. Rezolvarea altor probleme minore. 9. Transmiterea r spunsului c tre client. #0. Ad ugarea unei înregistr ri în jurnalul serverului.

Pasul # este necesar deoarece cererea sosit poate s nu con!in numele propriu-zis al fi"ierului, ca "ir de caractere. De exemplu, putem considera URL-ul http://www.cs.vu.nl, care are un nume de fi"ier vid. Acesta trebuie extins la un nume de fi"ier implicit. De asemenea, programele de navigare moderne pot specifica limba implicit a utilizatorului (de ex.: italian sau englez ), ceea ce deschide posibilitatea ca serverul s selecteze o pagin de Web în acea limb , dac aceasta este disponibil . În

SEC. 7.3 WORLD WIDE WEB 557

general, extinderea numelor nu este un proces atât de banal cum ar putea p rea la prima vedere, datorit unei variet !i de conven!ii existente privind numirea fi"ierelor.

Pasul 2 const în verificarea identit !ii clientului. Acest pas este necesar pentru paginile care nu sunt disponibile publicului larg. Vom discuta o modalitate de a realiza acest lucru mai târziu, în acest capitol.

Pasul 3 verific dac exist restric!ii referitoare la satisfacerea cererii, având în vedere identitatea "i localizarea clientului. Pasul 4 verific dac exist restric!ii de acces asociate cu pagina îns "i. Dac un anumit fi"ier (de ex.: .htaccess) este prezent în directorul unde se afl "i pagina dorit , accesul la acel fi"ier poate fi restrâns la anumite domenii, de exemplu numai la utilizatorii din interiorul companiei.

Pa"ii 5 "i 6 presupun ob!inerea paginii. Pasul 6 necesit capacitatea de tratare simultan a mai multor citiri de pe disc.

Pasul 7 se refer la determinarea tipului MIME din extensia fi"ierului, primele câteva cuvinte din fi"ier, un fi"ier de configurare sau alte surse posibile. Pasul 8 este destinat unei diversit !i de opera!ii, cum ar fi construc!ia unui profil al utilizatorului sau adunarea unor statistici.

Pasul 9 este cel în care rezultatul este transmis clientului "i pasul #0 adaug o înregistrare în jur-nalul sistemului, în scopuri administrative. Asemenea fi"iere de jurnalizare pot fi analizate ulterior pentru ob!inerea de informa!ii importante despre comportamentul utilizatorului, spre exemplu or-dinea în care vizitatorii acceseaz paginile.

Dac sosesc prea multe cereri în fiecare secund , procesorul nu va fi capabil sa suporte înc rca-rea, oricâte unit !i de disc ar fi utilizate în paralel. Solu!ia este ad ugarea mai multor noduri (calcu-latoare), posibil cu unit !i de disc replicate pentru a evita ca discurile s devin urm torul punct de gâtuire. Acest fapt conduce la modelul fermei de servere (server farm) din fig. 7-22. Un modul fron-tal accept în continuare cererile dar le împarte mai multor procesoare, nu mai multor fire de execu-!ie, pentru a reduce înc rcarea pe fiecare calculator. Ma"inile individuale pot fi cu mai multe fire de execu!ie "i în band de asamblare ca mai sus.

Fig. 7-22. O ferm de servere

O problem cu fermele de servere este c nu mai exist o memorie ascuns partajat deoarece

fiecare nod are propria sa memorie – decât dac se folose"te un sistem multiprocesor cu memorie partajat de cost mic. O modalitate de a contracara aceast pierdere de performan! este un modul frontal care re!ine unde direc!ioneaz fiecare cerere "i trimite cererile ulterioare pentru aceea"i pa-gin aceluia"i nod. Aceast abordare specializeaz fiecare nod în tratarea anumitor pagini astfel în-cât spa!iul destinat pentru cache nu se pierde re!inând fiecare fi"ier în fiecare cache.

O alt problem cu fermele de servere este aceea c fiecare conexiune TCP a clientului se termi-n la modulul de intrare, astfel c r spunsul trebuie transmis prin acest modul. Aceast situa!ie este

558 NIVELUL APLICA!IE CAP. 7

eviden!iat în fig. 7-23(a), unde cererea sosit (#) "i r spunsul transmis (4) trec ambele prin modulul frontal. Câteodat se poate folosi o solu!ie ingenioas numit parsare TCP (eng.: TCP handoff) pentru a evita aceast problem . Cu acest truc, cap tul comunica!iei TCP este „pasat” nodului de procesare astfel c acesta poate replica direct clientului, lucru eviden!iat ca (3) în fig. 7-23(b). Aceas-t pasare este f cut într-un mod transparent pentru client.

Fig. 7-23. (a) Secven! normal de mesaje cerere – r spuns. (b) Secven! în care se folose"te pasarea TCP.

URL- Uniform Resource Locators Am spus de mai multe ori c o pagin de Web poate s con!in referin!e la alte pagini. S expli-

c m cum sunt implementate aceste referin!e. Înc de la crearea Web-ului, a fost clar c pentru a avea o pagin care s indice spre alt pagin este necesar un mecanism care s permit numirea "i reg sirea paginilor. În particular, sunt trei întreb ri la care trebuie s se r spund înainte de a se putea afi"a o pagin :

#. Cum se nume"te pagina? 2. Cum este localizat pagina? 3. Cum se face accesul la pagin ?

Dac fiecare pagin ar avea un nume unic, atunci nu ar exista nici o ambiguitate în identificarea paginilor. Totu"i, problema nu este înc rezolvat . S consider m de exemplu o paralel între oa-meni "i pagini. În SUA aproape fiecare persoan are un num r de asigurare social , care este un identificator unic, astfel încât nu exist dou persoane cu acela"i num r. Totu"i, cunoscând numai num rul respectiv, nu exist nici o posibilitate de a g si adresa persoanei respective "i sigur nu se poate afla dac persoanei respective trebuie s i se scrie în Englez , Spaniol sau Chinez . Web-ul are practic acela"i fel de probleme.

Solu!ia aleas identific paginile într-un mod care rezolv toate trei problemele în acela"i timp. Fiecare pagin are un URL (Uniform Resource Locator - adresa uniform pentru localizarea resurse-lor) care func!ioneaz ca nume al paginii general valabil. Un URL are trei componente: protocolul (cunoscut "i sub numele de schem ), numele DNS al ma"inii pe care este memorat fi"ierul "i un nume local, care indic în mod unic pagina (de obicei numele fi"ierului care con!ine pagina). De exemplu, situl de Web al departamentului din care face parte autorul con!ine un num r de înregistr ri video despre universitate si despre ora"ul Amsterdam. URL-ul paginii cu înregistr rile video este:

SEC. 7.3 WORLD WIDE WEB 559

http://www.cs.vu.nl/video/index-en.html

Acest URL este format din trei componente: protocolul (http), numele DNS al serverului (www. cs.vu.nl) "i numele fi"ierului (video/index-en.html), cu semnele de punctua!ie corespunz toare. Nu-mele fi"ierului este o cale relativ la directorul de Web implicit de la cs.vu.nl.

Se utilizeaz nota!ii care reprezint prescurt ri standard. În cazul multor situri, un nume de fi"ier nul înseamn implicit pagina principal a organiza!iei. În mod obi"nuit, atunci când numele fi"ierului denot un director, aceasta implic un fi"ier numit index.html. În sfâr"it, ~user/ poate s fie pus în coresponden! cu directorul WWW al utilizatorului user, "i apoi cu fi"ierul index.html în acest direc-tor. De exemplu, pagina autorului poate s fie referit ca:

http://www.cs.vu.nl/~ast/

chiar dac de fapt numele propriu-zis al fi"ierului este index.html, implicit în acest director. Acum ar trebui s fie clar cum func!ioneaz hipertextul. Pentru a face o por!iune de text selecta-

bil , cel care scrie pagina trebuie s furnizeze dou elemente: textul prin care se face selec!ia "i URL-ul paginii care trebuie adus , dac textul este selectat. Vom explica sintaxa comenzii mai târziu în acest capitol.

Când se face selec!ia, programul de navigare caut numele serverului utilizând DNS-ul. Pe baza adresei IP a serverului, programul de navigare stabile"te o conexiune TCP spre server. Utilizând aceast conexiune, se transmite numele fi"ierului utilizând protocolul specificat. Bingo. Acum so-se"te pagina.

Aceast schem URL este deschis în sensul c este simplu s se utilizeze alte protocoale pentru a se ob!ine diferite tipuri de resurse. De fapt au fost definite URL-uri pentru protocoalele obi"nuite, "i multe programe de navigare în!eleg aceste protocoale. Forme simplificate ale celor mai obi"nuite sunt prezentate în fig. 7-24.

Nume Utilizat pentru Exemple http Hipertext (HTML) http://www.cs.vu.nl/~ast ftp FTP ftp://ftp.cs.vu.nl/pub/minix/README File Fi"ier local file:///usr/suzanne/prog.c news Grup de "tiri news:AA0#34223##2@cs.utah.edu news Articol de "tiri news:AA0#34223##2@cs.utah.edu gopher Gopher gopher://gopher.tc.umn.edu/##/libraries mailto Trimitere de po"ta electronic! mailto:JohnUser@acm.org telnet Conectare la distan ! telnet://www.w3.org:80

Fig. 7-24. Câteva URL-uri obi"nuite. S parcurgem lista rapid. Protocolul http este protocolul nativ pentru Web, el este utilizat de c -

tre serverele de Web. HTTP este o prescurtare pentru HyperText Transfer Protocol. Vom examina mai detaliat acest protocol mai târziu în acest capitol.

Protocolul ftp este utilizat pentru accesul la fi"iere prin FTP (File Transfer Protocol - protocol pentru transferul de fi"iere), protocolul Internet de transfer de fi"iere. FTP este utilizat de peste do-u zeci de ani "i este foarte r spândit. Numeroase servere de FTP din toat lumea permit ca de ori-unde din Internet s se fac o conectare "i s se aduc orice fi"ier plasat pe un server FTP. Web-ul nu aduce schimb ri aici, face doar ca ob!inerea fi"ierelor s se fac mai u"or, pentru c FTP are o interfa! mai pu!in prietenoas (dar este mai puternic decât HTTP, deoarece permite de exemplu ca un utilizator de pe ma"ina A s transfere un fi"ier de pe ma"ina B pe ma"ina C).

560 NIVELUL APLICA!IE CAP. 7

Este posibil s se fac acces la un fi"ier local ca la o pagin de Web, fie utilizând protocolul file (fi"ier), fie pur "i simplu utilizând numele fi"ierului. Aceast abordare este similar utiliz rii proto-colului FTP, dar nu implic existen!a unui server. Desigur func!ioneaz numai pentru fi"iere locale, nu "i pentru cele aflate la distan! .

Cu mult înainte de apari!ia Internet-ului exista sistemul de "tiri USENET. Acesta este format din aproximativ 30000 de grupuri de "tiri în care milioane de persoane discut despre o mare varietate de subiecte, ad ugând "i citind articole legate de subiectul grupului de "tiri. Protocolul news permite citirea un articol din "tiri ca "i cum ar fi o pagin de Web. Aceasta înseamn c un program de navigare este în acela"i timp "i un cititor de "tiri. De fapt, multe programe de navigare au butoane sau elemente de me-niu care permit citirea "tirilor USENET mai u"or decât dac se utilizeaz cititoare standard de "tiri.

Protocolul news admite dou formate. Primul format specific un grup de "tiri "i poate s fie uti-lizat pentru a ob!ine o list de articole de la un server de "tiri preconfigurat. Al doilea format cere identificatorul unui articol, de exemplu AA0 34223 2@cs.utah.edu. Programul de navigare aduce articolul de la serverul corespunz tor utilizând protocolul NNTP (Network News Transfer Protocol – Protocol de transfer al tirilor prin re!ea). Nu vom studia NNTP în aceast carte, dar este în mare bazat pe SMTP !i are un stil similar.

Protocolul gopher era utilizat de sistemul Gopher, care a fost proiectat la universitatea Minneso-ta. Numele este cel al echipei atletice a universit "ii, the Golden Gopher (de asemenea acest nume este utilizat în argou pentru „go for” adic o comand de aducere). Gopher-ul a precedat Web-ul cu câ"iva ani. Era o metod de reg sire a informa"iei, similar conceptual cu cea utilizat de Web, dar acceptând numai text !i imagini. Este considerat dep !it !i nu se mai folose!te în prezent.

Ultimele dou protocoale nu sunt de fapt protocoale pentru aducerea unor pagini de Web, dar sunt utile. Protocolul mailto permite transmiterea de po!t dintr-un program de navigare. Pentru a face aceast opera"ie, se selecteaz butonul OPEN !i se specific un URL constând din mailto: ur-mat de adresa destinatarului. Majoritatea programelor de navigare vor r spunde prin pornirea unei aplica"ii de po!t electronic cu adresa !i câteva alte câmpuri din antet deja completate.

Protocolul telnet este utilizat pentru stabilirea unei conexiuni cu o ma!in aflat la distan" . Se utilizeaz în acela!i fel ca !i programul telnet, ceea ce nu constituie o surpriz , deoarece majoritatea programelor de navigare utilizeaz programul telnet ca aplica"ie auxiliar .

Pe scurt URL-urile au fost proiectate nu numai pentru a permite utilizatorilor s navigheze prin Web, dar !i pentru a utiliza FTP, news, Gopher, e-mail !i telnet, ceea ce face inutile interfe"ele spe-cializate pentru aceste protocoale integrând astfel într-un singur program, navigatorul în Web, aproape toate tipurile de acces în Internet. Dac metoda nu ar fi fost proiectat de un fizician, ar fi putut s par produsul departamentului de publicitate al unei companii de software.

În ciuda tuturor acestor propriet "i, cre!terea Web-ului scoate în eviden" !i o sl biciune a meto-dei utiliz rii URL-urilor. Pentru o pagin care este foarte des referit , ar fi de preferat s existe mai multe copii pe servere diferite, pentru a reduce traficul în re"ea. Problema este c URL-rile nu ofer nici o posibilitate de indicare a unei pagini f r s se specifice unde este localizat pagina respectiv . Nu exist nici o metod pentru a spune ceva de genul: „Vreau pagina xyz, dar nu m intereseaz de unde o aduci”. Pentru a rezolva aceast problem !i a permite multiplicarea paginilor, IETF lucrea-z la un sistem de URN (Universal Resource Names - nume universale de resurse). Un URN poate s fie privit ca un URL generalizat. Acest subiect este în curs de cercetare, de!i o propunere de sin-tax este dat în RFC 2#4#.

SEC. 7.3 WORLD WIDE WEB 56"

Lipsa st#rii i utilizarea cookies A!a cum am v zut în mod repetat, Web-ul este, în principiu, lipsit de stare. Nu exist conceptul

unei sesiuni de conectare. Programul de navigare transmite o cerere c tre server !i prime!te un fi!i-er. Apoi serverul uit c a discutat vreodat cu acel client.

La început, când Web-ul a fost folosit doar pentru ob"inerea de documente accesibile publicului larg, acest model era perfect adaptat cerin"elor. Dar, pe m sur ce Web-ul a început s capete !i alte func"ii, acest model a dat na!tere unor probleme. De exemplu, anumite situri de Web impun clien"ilor s se înregistreze (!i chiar s pl teasc bani) spre a le utiliza. Ca atare, se pune întrebarea cum pot serverele s disting între cereri din partea utilizatorilor înregistra"i !i a celorlal"i. Un al doilea exemplu este comer"ul electronic. Dac un utilizator se plimb printr-un magazin electronic, aruncând din când în când produse în co!ul de cump r turi, cum poate serverul s re"in con"inutul co!ului? Un al treilea exemplu sunt portalurile de Web configurabile cum este Yahoo. Utilizatorii pot configura o pagin ini"ial detaliat , doar cu informa"ia pe care o doresc (de ex.: valorile ac"iunilor la burs !i echipele lor sportive favorite), dar cum poate serverul sa afi!eze pagina corect dac nu !tie cine este utilizatorul?

La o prim vedere, se poate crede c serverele pot s urm reasc utilizatorii uitându-se la adresele lor IP. Aceast idee nu func"ioneaz îns . În primul rând, mul"i utilizatori lucreaz pe calculatoare par-tajate cu al"i utilizatori, în special în cadrul companiilor, iar adresa IP identific doar calculatorul nu !i utilizatorul. În al doilea rând, mult mai grav, mul"i dintre cei ce ofer servicii de Internet (ISP) utilizea-z NAT, astfel încât toate pachetele ce pleac de la orice utilizator folosesc aceea!i adres IP. Din punctul de vedere al serverului, cele câteva de mii de clien"i ai unui ISP folosesc aceea!i adres IP.

Pentru a rezolva aceast problem , Netscape a proiectat o tehnic mult criticat numit cookies (rom. fursecuri). Numele deriv dintr-un argou foarte vechi al programatorilor în care un program apeleaz o procedur !i ob"ine rezultate ce ar putea fi mai târziu pentru a executa ceva. În acest sens, o înregistrare de descriere a unui fi!ier UNIX sau un identificator al unui obiect Windows reprezint un cookie. Mecanismul a fost formalizat mai târziu în RFC 2#09.

Când un client cere o pagin de Web, serverul poate oferi informa"ii adi"ionale odat cu pagina cerut . Aceste informa"ii pot include un cookie, care este un fi!ier (sau !ir de caractere) de dimensi-une mic (cel mult 4 KB). Programele de navigare stocheaz cookie-urile oferite într-un director special pentru acestea pe discul clientului, cu excep"ia cazurilor când utilizatorul a oprit utilizarea cookie-urilor. Cookie-urile sunt doar fi!iere sau !iruri de caractere, nu programe executabile. În principiu, un cookie ar putea con"ine un virus, dar deoarece cookie-urile sunt tratate ca date, nu exis-t nici o posibilitate oficial ca virusul s fie executat !i s cauzeze probleme. Este îns posibil ca un hacker s exploateze o eroare a programului de navigare !i s cauzeze activarea virusului.

Un cookie poate con"ine pân la cinci câmpuri, a!a cum se arat în fig. 7-25. Câmpul Domeniu spune de unde a sosit cookie-ul. Programele de navigare trebuie s verifice c serverele nu mint în leg tur cu domeniul lor. Fiecare domeniu poate stoca cel mult 20 de cookie-uri pentru fiecare cli-ent. Câmpul Cale reprezint o cale în structura de directoare a serverului care identific ce parte a arborelui de fi!iere de pe server poate utiliza cookie-ul respectiv. Adesea, acest câmp este /, ceea ce înseamn întregul arbore.

Domeniu Cale Con inut Expir! Sigur toms-casino.com / CustomerID=49779352" "5-"0-02 "7:00 Da joes-store.com / Cart"="-0050";"-0703";2-"372" ""-"0-02 "4:22 Nu aportal.com / Prefs=Stk:SUNW+ORCL;Spt:Jets 3"-"2-"0 23:59 Nu sneaky.com / UserID=3627239"0" 3"-"2-"2 23:59 Nu

Fig. 7-25. Câteva exemple de cookie-uri

562 NIVELUL APLICA$IE CAP. 7

Câmpul Con inut are forma nume = valoare. Atât nume cât !i valoare pot fi orice dore!te serve-rul. Acesta este câmpul în care se stocheaz con"inutul unui cookie.

Câmpul Expir! arat când expir un cookie. Dac acest câmp este absent, programul de navigare !terge cookie-ul la terminarea execu"iei. Un astfel de cookie se nume!te cookie ne-persistent (non-persistent cookie). Dac se ofer o dat !i o or , cookie-ul se nume!te persistent !i este p strat pân la expirare. Timpul de expirare se d pentru ora Greenwich (Greenwich Mean Time). Pentru a !ter-ge un cookie de pe discul unui client, un server retransmite cookie-ul cu timpul de expirare în trecut.

În sfâr!it, câmpul Sigur poate indica dac programul de navigare poate transmite cookie-ul nu-mai unui server sigur. Acest element este utilizat pentru comer"ul electronic, aplica"ii bancare !i alte aplica"ii sigure.

Am v zut cum se ob"in cookie-urile, dar cum sunt ele utilizate? Chiar înainte ca un program de navigare s transmit cererea pentru o pagin c tre un sit Web, el verific directorul de cookie-uri pentru a vedea dac exist vreun cookie care a fost stocat de c tre domeniul la care se duce cererea. În caz afirmativ, toate cookie-urile stocate de c tre acel domeniu sunt incluse în mesajul ce con"ine cererea. Atunci când serverul le ob"ine, le poate interpreta în orice mod dore!te.

S examin m acum câteva utiliz ri posibile pentru cookie-uri. În fig. 7-25, primul cookie a fost stocat de c tre toms-casino.com !i este utilizat pentru a identifica utilizatorul. Când clientul se conec-teaz s pt mâna urm toare pentru a arunca ni!te bani pe fereastr , programul de navigare transmi-te cookie-ul, astfel c serverul !tie cine este clientul. Odat ce de"ine num rul de identificare al clien-tului, serverul poate c uta datele sale într-o baz de date !i utiliza aceste informa"ii pentru a construi o pagin de Web potrivit . Depinzând de obiceiurile clientului, aceast pagin poate reprezenta o mas de poker, o list a curselor de cai din ziua respectiv sau o ma!in de jocuri.

Cel de-al doilea cookie a venit de la joes-store.com. Scenariul în acest caz este c utilizatorul se plimb prin magazin, c utând lucruri de cump rat. Atunci când g se!te un pre" bun !i execut un clic pe produsul respectiv, serverul construie!te un cookie ce con"ine num rul de buc "i !i codul pro-dusului !i îl transmite clientului. Pe m sur ce clientul continu s se plimbe prin magazin, cookie-ul este întors la fiecare nou pagin cerut . Pe m sur ce cump r turile se acumuleaz , serverul le adaug la cookie. În figur , co!ul de cump r turi con"ine trei produse, ultimul dintre ele în dublu exemplar. În cele din urm , când clientul selecteaz MERGI LA CAS", cookie-ul, care acum con"i-ne lista complet de cump r turi este trimis odat cu cererea. În acest mod, serverul !tie exact ce produse au fost cump rate.

Cel de-al treilea cookie este pentru un portal de Web. Atunci când utilizatorul selecteaz o leg tu-r c tre portal, programul de navigare transmite cookie-ul. Acesta spune portalului s construiasc o pagin ce con"ine valorile ac"iunilor pentru Sun Microsystems !i Oracle !i rezultatele echipei de fotbal New York Jets. Deoarece un cookie poate avea pân la 4 KB, exist suficient spa"iu pentru preferin"e mai detaliate în ceea ce prive!te titluri de articole din ziar, starea vremii, oferte speciale, !.a.m.d.

Cookie-urile pot fi utilizate !i în beneficiul serverului. De exemplu, s presupunem c un server dore!te s !tie în fiecare moment câ"i vizitatori a avut !i câte pagini au fost vizitate de fiecare dintre ace!tia înainte de a p r si situl. Prima cerere nu va fi înso"it de nici un cookie, astfel c serverul va transmite înapoi un cookie ce con"ine Counter=#. Selec"ii ulterioare ale paginilor acestui site vor transmite acest cookie înapoi la server. De fiecare dat , contorul este incrementat !i transmis înapoi clientului. Urm rind aceste contoare, serverul poate s vad câte persoane renun" dup vizitarea primei pagini, câte au vizitat dou pagini, !.a.m.d.

Cookie-urile au avut !i utiliz ri gre!ite. Teoretic, cookie-urile ar trebui s ajung doar la situl lor de origine, dar sp rg torii au exploatat numeroase erori în programele de navigare pentru a captura

SEC. 7.3 WORLD WIDE WEB 563

cookie-uri care nu le erau destinate. Deoarece numeroase situri de comer" electronic pun numerele de c r"i de credit în cookie-uri, poten"ialul pentru abuzuri este evident.

Un mod de utilizare controversat al cookie-urilor este colectarea, în secret, de informa"ii privind obiceiurile de navigare pe Web ale utilizatorilor. Mecanismul func"ioneaz în modul urm tor. O companie de publicitate, s spunem Sneaky Ads. (rom. sneaky = viclean) contacteaz un num r de situri de Web importante !i pune anun"uri publicitare ale clien"ilor s i pe paginile respectivelor si-turi, pentru care pl te!te celor ce de"in siturile o anumit sum . În loc s ofere sitului un fi!ier GIF sau JPEG pentru a fi amplasat pe fiecare pagin , le ofer un URL ce trebuie ad ugat la fiecare pa-gin . Fiecare din aceste URL-uri con"ine un num r unic în partea rezervat fi!ierului, cum ar fi

http://www.sneaky.com/382674902342.gif

Atunci când un utilizator viziteaz o pagin P ce con"ine un asemenea anun" publicitar, programul de navigare ob"ine fi!ierul HTML !i vede leg tura c tre imaginea de la www.sneaky.com, a!a c trans-mite cererea pentru imagine acestui server. Serverul întoarce un fi!ier GIF con"inând anun"ul publici-tar, împreun cu un cookie ce con"ine un num r unic de identificare pentru utilizator, 3627#239#0# în fig. 7-25. Compania Sneaky înregistreaz faptul c utilizatorul cu acest num r de înregistrare a vizitat pagina P. Aceasta este u!or de realizat având în vedere faptul c fi!ierul cerut (382674902342.gif) este men"ionat doar în pagina P. Desigur c anun"ul în sine poate apare pe o mie de alte pagini, dar de fie-care dat cu un nume de fi!ier diferit. Compania Sneaky colecteaz probabil doar câ"iva b nu"i de la compania ce a realizat produsul de fiecare dat când transmite anun"ul publicitar.

Mai târziu, când utilizatorul viziteaz o alt pagin de Web care con"ine unul din anun"urile pu-blicitare ale companiei Sneaky, dup ce programul de navigare a ob"inut fi!ierul HTML de la server, vede referin"a c tre, s spunem, http://www.sneaky.com/4936549#9923.gif !i cere acest fi!ier. Deoare-ce exist deja un cookie de la domeniul sneay.com, programul de navigare include cookie-ul compa-niei Sneaky ce con"ine !i num rul unic de identificare al utilizatorului. Compania Sneaky !tie acum o a doua pagin vizitat de utilizator.

Cu timpul, compania Sneaky poate construi un profil complet al obiceiurilor de navigare ale uti-lizatorului, de!i acesta nu a efectuat nici un clic pe vreun anun" publicitar. Desigur, acest profil nu include înc numele utilizatorului (de!i con"ine adresa IP a acestuia, informa"ie care poate fi sufici-ent pentru a deduce numele din alte baze de date). În cazul în care utilizatorul ofer vreodat nu-mele s u unui site care coopereaz cu Sneaky, un profil complet ce include !i numele este acum gata de vânzare pentru oricine dore!te s -l cumpere. Vânzarea acestor informa"ii poate fi suficient de profitabil pentru ca Sneaky sa poat plasa mai multe anun"uri publicitare pe mai multe situri Web !i astfel s colecteze !i mai multe informa"ii. Cea mai ascuns parte a acestei pove!ti este c majorita-tea utilizatorilor nu !tiu nimic despre aceast colectare de informa"ii !i chiar ar putea s se cread în siguran" , pentru c nu au selectat nici un anun" publicitar.

$i dac Sneaky vrea s fie !i mai viclean , anun"ul publicitar poate s nu fie unul clasic. Un „anun"” format dintr-un singur pixel de culoarea fondului (!i deci invizibil) are exact acela!i efect ca !i anun"ul propriu-zis: programul de navigare trebuie s ob"in imaginea gif de # x # pixeli !i s îi livreze toate cookie-urile care au fost transmise de domeniul de origine al pixelului.

Pentru a men"ine impresia de intimitate, o serie de utilizatori î!i configureaz programele de na-vigare pentru a refuza toate cookie-urile. Aceast ac"iune poate duce îns la probleme cu siturile de Web legitime ce folosesc cookie-uri. Pentru a rezolva aceast problem , utilizatorii instaleaz câteo-dat software care „m nânc cookie-uri” (cookie-eating software). Acestea sunt programe speciale care inspecteaz fiecare cookie la sosire !i îl accept sau refuz în func"ie de op"iunile utilizatorului

564 NIVELUL APLICA$IE CAP. 7

(de ex.: în ce situri Web se poate avea încredere). Aceast metod ofer utilizatorului un control fin asupra c ror cookie-uri sunt acceptate !i care sunt refuzate. Programele de navigare moderne cum ar fi Mozilla (www.mozilla.org) au un nivel de control complex asupra cookie-urilor.

7.3.2 Documente Web statice

Fundamentul Web-ului este transferul de pagini de Web de la server la client. În forma cea mai simpl , paginile de Web sunt statice, adic doar fi!iere existente pe un server, ce a!teapt s fie ceru-te. În acest sens, chiar !i o înregistrare video este o pagin de Web static , deoarece este doar un fi!ier. În aceast sec"iune vom privi paginile de Web statice în detaliu. În sec"iunea urm toare vom examina con"inutul dinamic.

HTML--HyperText Markup Language Paginile de Web sunt în prezent scrise într-un limbaj numit HTML (HyperText Markup Lan-

guage). HTML permite utilizatorilor s produc pagini de Web care con"in text, imagini !i referin"e la alte pagini de Web. HTML este un limbaj de marcare, un limbaj care descrie cum trebuie s fie formatate textele. Termenul de „marcare” provine din timpurile vechi, când editorii f ceau marcaje pe documente pentru a indica tipografului - în acele timpuri un om - ce font-uri s foloseasc !.a.m.d. Limbajele de marcare con"in comenzi explicite pentru formatare. De exemplu, în HTML, <b> înseamn# început de mod aldin, i </b> înseamn terminarea utiliz rii modului aldin. Avan-tajul utiliz rii unui limbaj de marcare fa" de unul în care nu se utilizeaz marcarea explicit const din faptul c este simplu de scris un program de navigare care s interpreteze comenzile de marcare. TeX !i troff sunt dou exemple foarte cunoscute de limbaje de marcare.

Prin standardizarea !i includerea comenzilor de marcaj în fiecare fi!ier HTML, devine posibil ca orice program de navigare s poat s citeasc !i s formateze orice pagin Web. Posibilitatea format rii paginii recep"ionate este foarte important , deoarece o pagin poate s fie construit pe un ecran cu #600 x #200 pixeli utilizând culori codificate cu 24 de bi"i, dar s-ar putea s fie necesar afi!area într-o mic fereastr de pe un ecran cu 640 x 320 pixeli !i utilizând culori codificate pe 8 bi"i.

În cele ce urmeaz se face o scurt introducere în limbajul HTML, doar pentru a oferi o idee de-spre subiect. Cu toate c este posibil s se construiasc documente HTML utilizând orice editor, !i mul"i fac asta, este posibil !i s se utilizeze editoare HTML speciale care pot s fac toat munca (desigur, în mod corespunz tor utilizatorul are mai pu"in control asupra detaliilor produsului final).

O pagin Web corect format con"ine o zon de cap !i o zon de corp, cuprinse între marcajele (tag-uri) <html> !i </html>, dar majoritatea programelor de navigare ignor absen"a acestor mar-caje. A!a cum se vede în fig. 7-26(a), capul este cuprins între marcajele <head> !i </head>, iar corpul între marcajele <body> !i </body>. Comenzile cuprinse între aceste marcaje se numesc di-rective. Majoritatea marcajelor HTML au acest format, adic , <ceva> pentru a indica începutul a ceva !i </ceva> pentru a marca sfâr!itul. Numeroase exemple de fi!iere HTML sunt disponibile. Majoritatea programelor de navigare au o op"iune VIEW SOURCE (afi!area sursei) sau ceva simi-lar. Selectarea acestei op"iuni afi!eaz pagina curent în format HTML în loc de forma interpretat .

Marcajele pot s fie scrise cu litere mici sau mari. Adic <head> !i <HEAD> înseamn acela!i lucru, dar versiuni mai noi ale standardului cer existen"a doar a primei forme. Cum este dispus textul în documentul HTML este nesemnificativ. Programele de navigare ignor spa"iile !i trecerile la rând nou, deoarece textul trebuie s fie formatat pentru a corespunde zonei de afi!are curente. Cores-

SEC. 7.3 WORLD WIDE WEB 565

punz tor, se pot utiliza spa"ii pentru a face documentele HTML mai u!or de citit, ceva ce ar fi nece-sar pentru majoritatea documentelor. Liniile albe nu pot s fie utilizate pentru separarea paragrafe-lor, deoarece sunt pur !i simplu ignorate. Este necesar utilizarea unor marcaje explicite.

<html> <head> <title> AMALGAMATED WIDGET, INC. </title></head> <body> <h"> Welcome to AWI’s Home Page </h"> <img SRC=”http://www.widget.com/images/logo.gif” ALT=”AWI Logo”> <br> We are so happy that you have chosen to visit <b> Amalgamated Widget’s</b> home page. We hope <i> you </i> will find all the information you need here. <p> Below we have links to information about our many fine products. You can order electronically (by WWW), by telephone, or by FAX. </p> <hr> <h2> Product Information </h2> <ul>

<li> <a href=”http://widget.com/products/big” > Big widgets </a> <li> <a href=”http://widget.com/products/little” > Little widgets </a> </ul> <h2> Telephone Numbers </h2> <ul>

<li> By telephone: "-800-WIDGETS, <li> By fax: "-4"5-765-432" </ul> </body> </hmtl>

(a)

(b)

Fig.7-26. (a) Un exemplu simplu de pagin de Web. (b) Pagina formatat .

566 NIVELUL APLICA$IE CAP. 7

Unele marcaje au parametri (care au nume), numi"i atribute. De exemplu:

<img src="abc" alt="foobar">

este un marcaj, <img>, având parametrul src cu valoarea abc !i parametrul alt cu valoarea foobar. Pentru fiecare marcaj, standardul HTML ofer o list a parametrilor care pot s fie utiliza"i, dac es-te cazul !i care este semnifica"ia lor. Deoarece parametrii au nume, ordinea în care se dau valorile parametrilor nu este semnificativ .

Din punct de vedere tehnic, documentele HTML sunt scrise utilizând setul de caractere ISO 8859-# Latin-#, dar pentru utilizatorii ale c ror tastaturi suport numai codul ASCII, se pot utiliza secven"e de caractere pentru reprezentarea caracterelor speciale cum ar fi è. Lista caracterelor spe-ciale este precizat în standard. Toate încep cu caracterul „&” !i se termin cu „;”. De exemplu &egrave; produce è iar &eacute; produce é. Deoarece <, > !i & au semnifica"ii speciale, pot s fie reprezentate numai utilizând secven"ele speciale de caractere corespunz toare, &lt; &gt; !i &amp;.

Principalul element din zona de cap este titlul care este cuprins între <title> !i </title>, dar aici pot s apar !i alte tipuri de informa"ii. Titlul nu este afi!at pe pagin . Unele programe de navigare îl utilizeaz pentru a eticheta fereastra în care se afi!eaz pagina respectiv .

S analiz m !i alte particularit "i prezente în exemplul din fig. 7-26. Toate marcajele utilizate în fig. 7-26 !i înc alte câteva sunt prezentate în fig. 7-27. Titlurile de capitole sunt generate de marca-jul <hn>, unde n este o cifr între # !i 6. <h#> este titlul cel mai important; <h6> este cel mai pu"in important.

Marcaj Descriere <html> ... </html> Delimiteaz! textul scris în HTML <head> ... </head> Delimiteaz! zona de cap <title> ... </title> Define#te titlul (nu este afi#at de programul de navigare) <body> ... </body> Delimiteaz! zona de corp <hn> ... </hn> Delimiteaz! un titlu de nivel n <b> ... </b> Textul ... o s! fie afi#at cu aldine <i> ...</i> Textul ... o s! fie afi#at cu cursive <center> ... </center> Centreaz! ... pe pagin! orizontal <ul> ... </ul> Delimiteaz! o list! neordonat! <ol> ... </ol> Delimiteaz! o list! ordonat! (numerotat!) <li> ... </li> Delimiteaz! un elemente într-o list! ordonat! sau neordona-

t! <br> Trecere la linie nou! <p> Început de paragraf <hr> Linie orizontal! <img src=„...”> Se încarc! o imagine <a href=„...”> ...</a> Se define#te o hiper-leg!tur!

Fig. 7-27. O selec"ie de marcaje uzuale. Unele mai au !i al"i parametri.

Depinde de programul de navigare s prezinte aceste titluri în mod diferit pe ecran. De obicei, ti-tlurile cu num r mai mic vor fi afi!ate utilizând caractere mai mari. Programul de navigare poate s utilizeze culori diferite pentru fiecare nivel de titlu. De obicei, pentru titlurile marcate cu <h#> se utilizeaz litere mari scrise cu aldine cu cel pu"in o linie liber înainte !i dup . Corespunz tor, pentru titlurile marcate cu <h2>, se utilizeaz caractere mai mici cu mai pu"in spa"iu l sat înainte !i dup .

Marcajele <b> !i <i> sunt utilizate pentru a indica modurile aldin !i respectiv cursiv. Dac pro-gramul de navigare nu poate s afi!eze aceste tipuri de caractere, va utiliza un alt mod de a le repre-zenta, de exemplu utilizând diferite culori sau video-invers.

SEC. 7.3 WORLD WIDE WEB 567

Limbajul HTML ofer diferite mecanisme pentru construirea de liste, inclusiv liste con"inute în alte liste. Listele încep cu <ul> sau <ol>, <li> fiind folosit pentru a marca începutul elementelor în ambele cazuri. Marcajul <ul> indic începutul unei liste neordonate. Elementele individuale, care sunt marcate în surs cu <li>, sunt reprezentate precedate de buline ( ). O variant a acestui mecanism este <ol>, care descrie o list ordonat . Când se utilizeaz acest marcaj, textele preceda-te de <li> sunt numerotate de c tre programul de navigare. Marcajele <ul> !i <ol> au aceea!i sintax !i efecte asem n toare.

Marcajele <br>, <p> !i <hr> indic o separare între diferitele p r"i ale textului. Formatul precis este descris în pagina de stil (vezi mai jos) asociat cu pagina curent . Marcajul <br> for"eaz trecerea la linie nou . De obicei programele de navigare nu insereaz o linie liber dup <br>. Marcajul <p> reprezint un început de paragraf, pentru care se va insera o linie nou !i eventual se va face o indentare. (În mod teoretic, exist !i </p> pentru a indica sfâr!itul de paragraf, dar este foarte rar utilizat; majoritatea celor care scriu în HTML nici nu !tiu c acest marcaj exist ). Ultimul marcaj, <hr>, for"eaz trecerea la linie nou !i deseneaz o linie orizontal .

HTML permite includerea de imagini în paginile de Web. Marcajul <img> arat c pe pozi"ia curent din pagin se va include o imagine. Marcajul poate s aib o serie de parametri. Parametrul src indic URL-ul imaginii. Standardul HTML nu specific ce formate grafice sunt permise. În prac-tic , toate programele de navigare accept fi!iere în format GIF, multe pot lucra !i cu fi!iere în for-mat JPEG. Programele de navigare pot s lucreze !i cu alte formate, dar o astfel de extensie este o sabie cu dou t i!uri. Dac , de exemplu un utilizator este obi!nuit cu un program de navigare care suport fi!iere în format BMP, este posibil ca el s includ astfel de fi!iere în pagina sa de Web !i s fie uimit c alte programe de navigare ignor imaginile sale minunate.

Al"i parametri pentru <img> sunt align, care controleaz modul în care se aliniaz imaginea fa" de limita de jos a textului (top, middle, bottom), alt, care furnizeaz textul afi!at în locul imaginii dac utilizatorul dezactiveaz op"iunea de afi!are a imaginilor !i ismap, un indicator care anun" c ima-ginea este o hart selectabil .

În sfâr!it, s consider m hiper-leg turile, care utilizeaz marcajele <a> (anchor) !i </a>. Ca !i <img>, <a> are diver!i parametrii, printre care href (URL-ul) !i name (numele hiper-leg turii). Textul cuprins între <a> !i </a> este afi!at. Dac este selectat, atunci se utilizeaz hiper-leg tura pentru a se aduce o nou pagin . În locul textului se poate pune !i un marcaj <img>, caz în care, cu un clic pe imagine, se va activa leg tura.

De exemplu, s consider m urm torul fragment HTML:

<a href=„http://www.nasa.gov”>NASA’s home page </a>

Când se afi!eaz acest fragment, pe ecran apare:

NASA’s home page

Dac utilizatorul execut un clic pe acest text, programul de navigare aduce !i afi!eaz pagina al c rei URL este http://www.nasa.gov.

Ca al doilea exemplu, s consider m

<a href=„http://www.nasa.gov”><img src=„shuttle.gif”alt=„NASA”></a>

Când se afi!eaz pagina va ap rea o imagine (o navet spa"ial ). Executând un clic pe imagine, se va aduce pagina NASA, la fel ca !i în cazul în care în exemplul anterior a fost selectat textul. Dac utili-zatorul a dezactivat op"iunea de afi!are a imaginilor, atunci în loc de imagine va fi afi!at textul NASA.

568 NIVELUL APLICA$IE CAP. 7

<html> <head><title> A sample page with a table </title></head> <body> <table border=" rules=all> <caption> Some differences between HTML Versions </caption> <col align=left> <col align=center> <col align= center > <col align= center > <col align= center > <tr> <th>Item <th>HTML ".0 <th>HTML 2.0 <th>HTML 3.0 <th> HTML 4.0 </tr> <tr> <th> Hyperlinks <td> x <td> x <td> x <td> x </tr> <tr> <th> Images <td> x <td> x <td> x <td> x </tr> <tr> <th> Lists <td> x <td> x <td> x <td> x </tr> <tr> <th> Active Maps and Images <td> &nbsp; <td> x <td> x <td> x </tr> <tr> <th> Forms <td> &nbsp; <td> x <td> x <td> x </tr> <tr> <th> Equations <td> &nbsp; <td> &nbsp; <td> x <td> x </tr> <tr> <th> Toolbars <td> &nbsp; <td> &nbsp; <td> x <td> x </tr> <tr> <th> Tables <td> &nbsp; <td> &nbsp; <td> x <td> x </tr> <tr> <th> Accesibility features <td> &nbsp; <td> &nbsp; <td> &nbsp; <td> x </tr> <tr> <th> Object embedding <td> &nbsp; <td> &nbsp; <td> &nbsp; <td> x </tr> <tr> <th> Scripting <td> &nbsp; <td> &nbsp; <td> &nbsp; <td> x </tr> </table> </body> </html>

(a)

Some diferences between HTML Versions

Item HTML .0 HTML 2.0 HTML 3.0 HTML 4.0 Hyperlinks x x x x Images x x x x Lists x x x x Active Maps and Images x x x Forms x x x Equations x x Toolbars x x Tables x x Accessibility features x Object embedding x Scripting x

(b)

Fig. 7-28. (a) O tabel HTML, (b) Un rezultat posibil. Pentru marcajul <a> se poate utiliza parametrul name pentru a fixa o hiper-leg tur , care s fie

referit din pagin . De exemplu, unele pagini de Web încep cu o tabel de con"inut selectabil . Prin execu"ia unui clic pe o intrare în tabela de con"inut, se va trece direct la sec"iunea corespunz toare din pagin .

SEC. 7.3 WORLD WIDE WEB 569

HTML evolueaz continuu. În versiunile HTML #.0 !i HTML 2.0 nu existau tabele, dar au fost ad ugate în HTML 3.0. O tabel HTML este format din una sau mai multe linii, fiecare fiind for-mat din una sau mai multe celule. Celulele pot s con"in diferite tipuri de informa"ii, inclusiv text, figuri, iconi"e, fotografii !i chiar tabele. Celulele pot s fie alipite, de exemplu un titlu poate s se întind peste mai multe coloane. Autorii paginilor au control asupra modului în care se face afi!area, inclusiv alinierea, stilul bordurii, marginile celulelor, dar programul de navigare este cel care hot r !-te de fapt cum se face afi!area.

O descriere în HTML a unei tabele este prezentat în fig. 7-28(a), iar efectul posibil este prezen-tat în fig. 7-28(b). Acest exemplu prezint câteva din facilit "ile de descriere a tabelelor în HTML. Tabelele încep cu marcajul <table>. Se pot specifica informa"ii suplimentare pentru a descrie pro-priet "ile generale ale tabelei.

Marcajul <caption> poate s fie utilizat pentru a furniza un titlu tabelei. Fiecare linie începe cu marcajul <tr> (Table Row - linie în tabel ). Celulele individuale sunt marcate cu <th> (Table Header - titlu de coloan ), <td> (Table Data - date în tabel ). Diferen"ierea este necesar pentru a permite programului de navigare s le afi!eze diferit, a!a cum se vede !i din exemplul considerat.

În tabele se pot utiliza alte marcaje. Acestea includ posibilitatea de a specifica alinieri orizontale sau verticale ale celulelor, alinierea în cadrul celulei, margini, gruparea de celule, unit "i !i multe altele.

În HTML 4.0 au fost ad ugate noi elemente. Acestea includ elemente ce fac paginile mai accesi-bile utilizatorilor cu handicap, înglobarea obiectelor (o generalizare a marcajului <img> astfel încât alte obiecte s poat fi înglobate în pagini), suport pentru limbaje de scripturi (pentru a permite con-"inut dinamic) !i multe altele.

Când un sit de Web este complex, fiind format din multe pagini produse de autori diferi"i ce lu-creaz pentru aceea!i companie, este adesea de dorit s existe o modalitate pentru a împiedica mo-duri de prezentare diferite în pagini diferite. Aceast problem poate fi rezolvat utilizând paginile de stil (style sheets). Atunci când se utilizeaz pagini de stil, paginile individuale nu mai folosesc sti-luri fizice, cum sunt modurile aldin !i cursiv. Autorii pot acum s utilizeze stiluri logice, cum sunt <dn> (defini"ie), <em> (eviden"iere), <strong> (eviden"iere accentuat ) !i <var> (variabile de program). Stilurile logice sunt definite în pagina de stil, pentru care exist o referin" la începutul fiec rei pagini. În acest fel, toate paginile au acela!i stil !i dac administratorul sitului (Webmaster) decide s schimbe stilul <strong> din stil cursiv de #4 puncte tipografice, culoare albastr în stil al-din, #8 puncte tipografice, culoare roz "ip tor, tot ceea ce trebuie s fac este s schimbe o singur defini"ie pentru a converti întregul sit Web. O pagin de stil poate fi comparat cu o directiv #in-clude într-un program C: schimbarea unei macrodefini"ii în fi!ierul inclus determin schimbarea în toate fi!ierele program ce includ respectivul header.

Formulare HTML #.0 func"iona într-o singur direc"ie. Utilizatorii puteau s aduc o pagin de la furnizorii

de informa"ie, dar era foarte dificil s se transmit informa"ie în sens invers. Pe m sur ce tot mai multe organiza"ii comerciale au început s utilizeze Web-ul, a ap rut o puternic cerere pentru co-munica"ia în dublu sens. De exemplu, multe companii vor s poat prelua comenzi pentru produse utilizând paginile lor de Web, furnizorii de software vor s distribuie programe prin intermediul Web-ului, clien"ii s î!i completeze fi!ele de înregistrare prin acela!i mijloc, iar companiile care ofer servicii de c utare în Web au nevoie ca utilizatorii de servicii s poat s introduc cuvintele pe baza c rora se face c utarea.

570 NIVELUL APLICA$IE CAP. 7

Acest gen de cereri a dus la includerea formularelor începând cu HTML 2.0. Formularele con"in casete !i butoane care permit utilizatorilor s completeze informa"ii sau s fac selec"ii !i apoi s transmit informa"iile la proprietarul paginii. În acest scop se utilizeaz marcajul <input>. Acesta are o varietate de parametri care determin m rimea, tipul, !i modul de afi-!are a casetei utilizate. Cele mai obi!nuite sunt câmpuri în care utilizatorul poate s introduc text, casete care pot s fie selectate, h r"i active, butoane submit. Exemplul din fig. 7-29 prezin-t câteva dintre aceste posibilit "i. <html> <head><title> AWI CUSTOMER ORDERING FORM </title></head> <body> <h"> Widget Order Form </h"> <form ACTION=”http://widget.com/cgi-bin/widgetorder” method=POST> <p> Name <input name=”customer” size=46> </p> <p> Street Address <input name=”address” size=40> </p> <p> City <input name=”city” size=20> State <input name=”state” size=4> Country <input name=”country” size="0> </p> <p> Credit card # <input name=”cardno” size="0> expires <input name=”expires” size=4> M/C <input name=”cc” type=radio value=”mastercard”> VISA <input name=”cc” type=radio value=”visacard”> </p> <p> Widget size Big <input name=”product” type=radio value=”expensive”> Little <input name=”product” type=radio value=”cheap”> Ship by express courier <input name=”express” type=checkbox> </p> <p> <input type=submit value=”submit order”> </p> Thank you for ordering an AWI widget, the best widget money can buy! </form> </body> </html>

(a)

(b)

Fig. 7-29. (a) Un formular de comand HTML. (b) Pagina formatat .

SEC. 7.3 WORLD WIDE WEB 57"

S începem discu"ia parcurgând exemplul. Ca orice formular, !i acesta este cuprins între marcaje-

le <form> !i </form>. Textele care nu sunt incluse între marcaje sunt afi!ate. Într-un formular poate s fie utilizat orice marcaj obi!nuit (de exemplu <b>) În acest formular sunt utilizate trei ti-puri de casete.

Prima caset din formular apare dup textul „Name”. Caseta are l "imea de 46 de caractere !i utilizatorul va introduce un !ir care va fi memorat în variabila customer pentru prelucr ri ulterioare. Marcajul <p> indic programului de navigare s afi!eze ceea ce urmeaz pe o linie nou , chiar dac mai este loc pe linia curent . Utilizând <p> !i alte marcaje care controleaz dispunerea textului, creatorul paginii poate s controleze cum arat formularul pe ecran.

Pe linia urm toare se solicit adresa utilizatorului, având cel mult 40 de caractere, pe o linie se-parat . Urmeaz o linie pe care se solicit ora!ul, statul !i "ara. Aici nu se utilizeaz marcajul <p>, deci programul de navigare o s le afi!eze pe toate pe aceea!i linie, dac încap. Din punctul de vede-re al programului de navigare, paragraful curent con"ine !ase elemente: trei !iruri alternând cu trei casete. El le afi!eaz pe aceea!i linie de la stânga la dreapta, trecând la o linie nou ori de câte ori pe linia curent nu mai încape urm torul element. Astfel, este posibil ca pe un ecran #600 x #200 s încap toate cele trei !iruri !i casetele corespunz toare, în timp ce pe un ecran #024 x 768 ele pot s fie distribuite în dou linii. În cazul cel mai defavorabil cuvântul „Country” este la cap tul liniei, iar caseta asociat este la începutul liniei urm toare. Nu exist nici o posibilitate de a for"a programul de navigare s afi!eze caseta lâng text.

Urm toarea linie solicit num rul c r"ii de credit !i data sa de expirare. Transmiterea numerelor c r"ilor de credit prin Internet trebuie s se fac numai dac s-au luat m surile de securitate adecva-te. Vom discuta despre aceste m suri în cap. 8.

Dup data de expirare, întâlnim un element nou: butoane radio. Acestea sunt utilizate atunci când trebuie s se fac o alegere între mai multe alternative. Modelul care se utilizeaz aici este cel al unui aparat de radio care are butoane pentru selec"ia scalelor. Programul de navigare afi!eaz aceste casete într-o form care permite utilizatorului s le selecteze sau s le deselecteze prin execu-"ia unui clic (sau utilizând tastatura). Selec"ia unuia dintre ele le deselecteaz pe toate celelalte care fac parte din acela!i grup. Modul de afi!are depinde de programul de navigare. „Widget size” utili-zeaz de asemenea dou butoane. Cele dou grupuri sunt diferen"iate prin câmpul name !i nu printr-un domeniu static de genul <radiobutton> ... </radiobutton>.

Parametrii value sunt utiliza"i pentru a ar ta care buton a fost ap sat. În func"ie de op"iunea alea-s pentru cartea de credit, variabila cc va avea ca valoare !irul „mastercard” sau „visacard”.

Dup cele dou seturi de butoane, urmeaz op"iunea referitoare la modul de transport, repre-zentat de o caset de tip checkbox. Aceasta poate s fie pe pozi"ia selectat sau nu. Spre deosebire de cazul butoanelor radio, unde poate s fie selectat un singur buton dintr-un set, fiecare caset de tip checkbox poate s fie selectat sau nu, independent de celelalte. De exemplu, când se comand o pi"a utilizând pagina de Web Electropizza, utilizatorul poate s aleag sardele $i ceap $i ananas (da-c le suport ), dar nu poate s aleag mic $i medie $i mare pentru aceea!i pi"a. Con"inutul cores-punz tor pi"ei va fi reprezentat de trei butoane diferite de tip checkbox, în timp ce dimensiunea va fi reprezentat de un set de butoane radio.

Pe de alt parte, în cazul în care lista din care se face alegerea este foarte lung , butoanele radio devin dificil de utilizat. Din acest motiv, marcajele <select> !i </select> sunt utilizate pentru a prezenta o list de alternative, utilizând semantica corespunz toare unor butoane radio (dac nu se utilizeaz parametrul multiple, caz în care semantica este cea de la casetele de tip

572 NIVELUL APLICA$IE CAP. 7

checkbox). Unele programe de navigare afi!eaz op"iunile cuprinse între <select> !i </select> ca un meniu derulant.

Am v zut jum tate din tipurile standard pentru marcajul <input>: radio !i checkbox. De fapt, am v zut !i un al treilea: text. Deoarece acesta este tipul implicit, nu am mai utilizat parametrul type = text, dar puteam s o facem. Alte dou tipuri sunt password !i textarea. O caset password func"io-neaz la fel ca o caset text, numai c nu se face afi!area caracterelor introduse. O caset textarea este similar unei casete text, numai c va con"ine mai multe linii.

Întorcându-ne la exemplul din fig. 7-29, urmeaz butonul submit. Când este selectat acest buton, informa"ia introdus de c tre utilizator este transmis la calculatorul de pe care provine formularul. Similar altor tipuri, submit este un cuvânt cheie pe care îl în"elege programul de navigare. $irul value reprezint în acest caz eticheta butonului !i se afi!eaz . Toate casetele pot s aib valori, dar am avut nevoie de aceast facilitate numai aici. Pentru casetele text, con"inutul câmpului value este afi!at o dat cu formularul, dar utilizatorul poate s îl modifice sau s îl !tearg . Casetele checkbox !i radio pot s fie ini"ializate, utilizând îns un parametru numit checked (deoarece parametrul value ofer un text, dar nu indic o selec"ie).

Atunci când utilizatorul selecteaz butonul „submit order”, programul de navigare împacheteaz informa"ia colectat într-o singur linie lung !i o transmite serverului pentru procesare. Pentru a separa câmpurile, se utilizeaz caracterul &; caracterul + reprezint spa"iu. De exemplu, r spunsul la formular poate s arate ca în fig. 7-30:

(împ!r it aici în trei linii din motive de aliniere pagin!)

customer=John+Doe&address="00+Main+St.&city=White+Plain& state=NY&country=USA&cardno="234567890&expires6/98&cc=mastercard& product=cheap&express=on

Fig. 7-30. Un r spuns posibil de la programul de navigare c tre server cu informa"iile completate de utilizator

$irul va fi transmis la server ca o singur linie, nu ca trei. Dac un checkbox nu este selectat, el es-

te omis din !ir. Este problema serverului s interpreteze !irul respectiv. Vom discuta cum se poate realiza acest lucru mai târziu în acest capitol.

XML i XSL Limbajul HTML, cu sau f r formulare, nu confer nici o structur paginilor de Web. De

asemenea, el amestec con"inutul cu informa"ii despre formatul paginii. Pe m sur ce comer"ul electronic !i alte aplica"ii devin din ce în ce mai r spândite, apare o cerere din ce în ce mai mare pentru structurarea paginilor de Web !i separarea con"inutului de informa"iile de format. De exemplu, un program care caut pe Web pre"ul cel mai bun al unei c r"i sau al unui CD trebuie s analizeze multe pagini de Web c utând numele produsului !i pre"ul s u. Cu paginile de Web în format HTML este foarte dificil ca un program s î!i dea seama unde se afl numele !i unde se afl pre"ul.

Din acest motiv, consor"iul W3C a dezvoltat îmbun t "iri ale limbajului HTML pentru a permite paginilor de Web s fie structurare în vederea proces rii automate. Dou limbaje noi au fost dezvol-tate în acest scop. Mai întâi, XML (eXtensible Markup Language) descrie con"inutul într-un mod

SEC. 7.3 WORLD WIDE WEB 573

structurat !i apoi, XSL (eXtensible Style Language) descrie formatul independent de con"inut. Am-bele limbaje reprezint subiecte mari !i complexe, ca atare scurta introducere care urmeaz atinge tangen"ial subiectul, de!i ar trebui s ofere o idee despre modul cum func"ioneaz .

S consider m documentul XML dat ca exemplu în fig. 7-3#. Acesta define!te o structur numit book_list, care reprezint o list de c r"i. Fiecare carte (book) are trei câmpuri, titlul, autorul !i anul public rii. Aceste structuri sunt extrem de simple. Sunt permise structurile ce con"in câmpuri repeti-tive (de ex.: mai mul"i autori), câmpuri op"ionale (de ex.: titlul CD-ROM-ului inclus) !i câmpuri la alegere (de ex.: URL-ul unei libr rii dac respectiva carte mai este disponibil sau URL-ul unui sit de licita"ii dac nu mai este disponibil pe pia" ).

În acest exemplu, fiecare din cele trei câmpuri este o entitate indivizibil , dar se permite subdivi-zarea ulterioar a unui câmp. De exemplu, câmpul autor putea fi alc tuit a!a cum urmeaz , spre a oferi un control mai fin la c utare !i formatare:

<author> <first_name>Andrew</first_name> <last_name>Tannenbaum</last_name> </author>

Fiecare câmp poate fi împ r"it în sub-câmpuri !i sub-sub-câmpuri pân la o adâncime arbitrar . Întregul fi!ier din fig. 7-3# define!te o list de c r"i ce con"ine trei c r"i. Nu spune nimic despre

modul cum se poate afi!a pagina de Web pe ecran. Pentru a oferi informa"ii de formatare avem ne-voie de un al doilea fi!ier, book_list.xsl, ce con"ine defini"ia XSL. Acest fi!ier este o pagin de stil care spune cum se poate afi!a pagina. (Exist alternative la paginile de stil, cum ar fi conversia XML în HTML, dar aceste alternative dep !esc subiectul acestei c r"i.)

<?xml version=”".0” ?> <?xml-stylesheet type=”text/xsl” href=”book_list.xsl”?>

<book_list>

<book> <title>Computer Networks, 4/e </title> <author> Andrew S. Tannenbaum </author> <year> 2003 </year> </book>

<book> <title> Modern Operating Systems, 2/e </title> <author> Andrew S. Tannenbaum </author> <year> 200" </year> </book>

<book> <title> Structured Computer Organization 4/e </title> <author> Andrew S. Tannenbaum </author> <year> "999 </year> </book>

</book_list> Fig. 7-3". O pagin de Web simpl în format XML

574 NIVELUL APLICA$IE CAP. 7

<?xml version=’".0’?> <xsl:stylesheet xmlns:xsl=”http://www.w3.org/"999/XSL/Transform” version=”".0”> <xsl:template match=”/”>

<html> <body>

<table border=”2”> <tr> <th> Title </th> <th> Author </th> <th> Year </th> </tr>

<xsl:for-each select=”book_list/book”> <tr> <td> <xsl: value-of select=”title”/> </td> <td> <xsl: value-of select=”author”/> </td> <td> <xsl: value-of select=”year”/> </td> </tr> </xsl:for-each> </table>

</body> </html> </xsl:template> </xsl:stylesheet>

Fig. 7-32. O pagin de stil în XSL Un exemplu de fi!ier XSL pentru formatarea con"inutului din fig. 7-3# este dat în fig. 7-32. Dup

câteva declara"ii necesare ce includ URL-ul standardului XSL, fi!ierul con"ine marcaje începând cu <html> !i <body>. Acestea definesc începutul unei pagini de Web, ca de obicei. Urmeaz apoi o defini"ie de tabel ce include titlurile celor trei coloane. S observ m c în plus fa" de marcajele <th> exist !i marcaje </th>, lucru care nu ne-a preocupat pân acum. Specifica"iile XML !i XSL sunt mult mai stricte decât specifica"ia HTML. Ele statueaz c rejectarea fi!ierelor incorecte din punct de vedere sintactic este obligatorie, chiar dac programul de navigare poate determina ce a inten"ionat proiectantul paginii Web. Un program de navigare care accept fi!iere XML sau XSL incorecte din punct de vedere sintactic !i repar eroarea el însu!i este neconform cu standardul !i va fi rejectat la un test de conforman" cu standardele. Programelor de navigare li se permite îns s identifice exact eroarea. Aceast m sur întrucâtva draconic este necesar pentru a rezolva pro-blema num rului imens de pagini de Web scrise neglijent, care exist în prezent.

Instruc"iunea

<xsl: for-each select=”book_list/book”>

este comparabil cu o instruc"iune for în C. Execu"ia ei determin programul de navigare s execute corpul buclei (terminat de <xsl:for-each>) câte o dat pentru fiecare carte. Fiecare itera"ie afi!ea-z cinci linii: <tr>, titlul, autorul !i anul !i </tr>. Dup aceast bucl , sunt transmise la ie!ire mar-cajele de închidere <body> !i </html>. Rezultatul opera"iei programului de navigare de a inter-preta aceast pagin de stil este acela!i ca !i în cazul când pagina de Web ar fi con"inut direct tabelul. Totu!i, în acest format, programele pot analiza fi!ierul XML !i g si cu u!urin" c r"ile publicate du-

SEC. 7.3 WORLD WIDE WEB 575

p 2000, de exemplu. Merit subliniat faptul c de!i fi!ierul nostru XSL con"inea un fel de bucl , paginile de Web în XML !i XSL sunt în continuare statice deoarece con"in pur !i simplu instruc"iuni pentru programul de navigare despre modul de afi!are a paginii, la fel ca !i paginile HTML. Desigur, pentru a folosi XML !i XSL, programul de navigare trebuie s fie capabil s interpreteze XML !i XSL, dar marea majoritate a acestora au deja aceast capacitate. Nu este înc foarte clar dac XSL va prelua paginile de stil tradi"ionale.

Nu am ar tat cum se poate face acest lucru, dar limbajul XML permite proiectantului de situri Web s creeze fi!iere de defini"ie în care structurile sunt definite în avans. Aceste fi!iere de defini"ii pot fi incluse unele în altele, f când posibil construc"ia de pagini Web complexe. Pentru informa"ii suplimentare despre aceasta !i multe alte caracteristici ale limbajelor XML !i XSL, consulta"i una din multele c r"i despre acest subiect. Dou exemple sunt (Livingston, 2002; !i Williamson, 200#).

Înainte de a încheia discu"ia despre XML !i XSL, merit s coment m pe marginea luptei ideo-logice din interiorul consor"iului WWW !i a comunit "ii dezvoltatorilor de pagini Web. Scopul ini"ial al limbajului HTML era s specifice structura documentului !i nu modul de afi$are. De exemplu,

<h"> Deborah’s Photos </h">

instruie!te programul de navigare s sublinieze titlul, dar nu spune nimic despre tipului font-ului, dimensiune sau culoare. Acestea sunt l sate pe seama programului de navigare, care cunoa!te pro-priet "ile ecranului (de ex.: câ"i pixeli are). Totu!i, mul"i dezvoltatori de pagini Web doreau controlul absolut asupra modalit "ii în care erau afi!ate paginile lor, astfel c au fost ad ugate noi marcaje la HTML pentru a controla modul de afi!are, cum ar fi

<font face=”helvetica” size=”24” color=”red”> Deborah’s Photos </font>

De asemenea, au fost ad ugate modalit "i de a controla pozi"ionarea precis pe ecran. Aceast abordare este c nu este portabil , ceea ce reprezint desigur o problem . De!i o pagin poate fi afi!at perfect de programul de navigare cu care este dezvoltat , un alt program de navigare, sau chiar alt versiune a aceluia!i program sau o alt rezolu"ie a ecranului poate fi un dezastru. XML este par"ial o încercare de întoarcere la scopul originar de a specifica doar structura nu modalitatea de afi!are a documentului. Totu!i, XSL este oferit în plus, pentru a controla modul de afi!are. Am-bele formate pot avea îns utiliz ri eronate. Pute"i conta pe asta.

XML poate fi utilizat !i în alte scopuri decât acela de a descrie pagini de Web. O utilizare din ce în ce mai frecvent este aceea de limbaj de comunicare între aplica"ii. În particular, SOAP (Simple Object Access Protocol – Protocol simplu pentru accesul la obiecte) este o modalitate de a executa apeluri de tip RPC între aplica"ii într-un mod independent de limbaj !i de sistem. Clientul constru-ie!te cererea ca mesaj XML !i o transmite serverului, utilizând protocolul HTTP (descris mai depar-te). Serverul trimite înapoi un r spuns sub form de mesaj XML. În acest mod pot comunica aplica-"ii de pe sisteme heterogene.

XHTML – eXtended HyperText Markup Language Limbajul HTML continu s evolueze pentru a se conforma noilor cereri. Multe persoane din

acest domeniu cred c în viitor majoritatea dispozitivelor cu acces la Web nu vor fi calculatoarele personale, ci dispozitive cu conexiuni f r fir, de tip PDA. Aceste dispozitive au memorie limitat pentru programe de navigare mari cu metode euristice ce încearc s trateze într-un anumit mod paginile de Web incorecte din punct de vedere sintactic. Astfel, urm torul pas dup HTML 4 este un limbaj care este Foarte Selectiv. Acest limbaj este numit XHTML (eXtended HyperText Markup Language, rom.: Limbaj extins de marcaje hipertext) mai degrab decât HTML 5, pentru c , de

576 NIVELUL APLICA$IE CAP. 7

fapt, este HTML 4 reformulat în XML. Prin aceasta vrem s spunem c marcaje precum <h#> nu au nici o însemn tate prin ele însele. Pentru a ob"ine efectul din HTML 4 este nevoie de o defini"ie în fi!ierul XSL. XHTML este noul standard pentru Web !i ar trebui folosit pentru toate paginile de Web noi pentru a asigura un maxim de portabilitate pe diverse platforme !i programe de navigare.

Exist !ase diferen"e majore !i mai multe diferen"e minore între XHTML !i HTML 4. S trecem acum în revist diferen"ele majore. Mai întâi, paginile XHTML !i programele de navigare trebuie s se supun în mod strict standardului. Gata cu paginile de Web de proast calitate. Aceast proprie-tate a fost mo!tenit din XML.

În al doilea rând, toate marcajele !i atributele trebuie s fie scrise cu litere mici. Marcaje ca <HTML> nu sunt valide în XHTML. Folosirea marcajelor precum <html> este acum obligatorie. Similar, <img SRC=”pic00#.jpg”> este interzis pentru c are în componen" un atribut scris cu lite-re mari.

În al treilea rând, sunt necesare marcaje de terminare, chiar !i pentru </p>. Pentru marcaje care nu au un marcaj natural de terminare, cum ar fi <br>, <hr> !i <img>, un caracter / trebuie s precead caracterul de terminare „>”, de exemplu

<img src=”pic00".jpg” />

În al patrulea rând, atributele trebuie s fie con"inute între ghilimele. De exemplu,

<img SRC=”pic00".jpg” height=500 />

nu mai este permis. Valoarea 500 trebuie pus între ghilimele, cum este numele fi!ierului JPEG, chiar dac 500 este doar un num r.

În al cincilea rând, marcajele trebuie s se con"in unul pe altul într-un mod corespunz tor. În trecut, acest lucru nu era necesar atât timp cât starea final atins era corect . De exemplu,

<center> <b> Vacation Pictures </center> </b>

era legal. În XHTML nu mai este. Marcajele trebuie închise în ordinea invers în care au fost des-chise.

În al !aselea rând, fiecare document trebuie s -!i specifice tipul documentului. De exemplu, am v zut acest lucru în fig. 7-32. Pentru o discu"ie asupra schimb rilor, fie ele majore sau minore, vezi www.w3.org.

7.3.3 Documente Web dinamice

Pân acum, modelul pe care l-am folosit este cel din Fig. 6-6: clientul transmite numele fi!ierului c tre server, care apoi întoarce fi!ierul. La începutul Web-ului, tot con"inutul era de fapt static în acest mod (doar fi!iere). Totu!i, în ultimii ani, din ce în ce mai mult con"inut a devenit dinamic, adic generat la cerere !i nu doar stocat pe disc. Generarea de con"inut poate avea loc fie la server, fie la client. S examin m acum pe rând fiecare din aceste cazuri.

Generare dinamic# de pagini de Web la server Pentru a vedea de ce este necesar generarea de con"inut la server, s lu m în considerare utiliza-

rea formularelor, a!a cum a fost descris mai devreme. Atunci când un utilizator completeaz un formular !i apas butonul submit, se transmite un mesaj c tre server, mesaj ce arat c are în interior con"inutul unui formular, împreun cu acele câmpuri completate de utilizator. Acest mesaj nu este numele unui fi!ier ce trebuie întors. În schimb, acest mesaj trebuie s fie oferit unui program, sau

SEC. 7.3 WORLD WIDE WEB 577

script, pentru a fi procesat. De obicei, procesarea implic folosirea informa"iilor oferite de utilizator pentru c utarea unei înregistr ri într-o baz de date de pe discul serverului !i generarea unei pagini HTML personalizate pentru a fi trimis înapoi clientului. De exemplu, într-o aplica"ie de comer" elec-tronic, atunci când utilizatorul face un clic pe MERGI LA CAS", programul de navigare întoarce cookie-ul ce con"ine produsele din co!ul de cump r turi, dar la server trebuie apelat un program, sau script, care proceseaz acest cookie !i genereaz o pagin HTML ca r spuns. Pagina HTML ar putea afi!a un formular ce con"ine lista de produse din co! !i ultima adres de expediere cunoscut a utiliza-torului, împreun cu o cerere de verificare a informa"iilor !i de specificare a modalit "ii de plat . Eta-pele necesare pentru procesarea informa"iei dintr-un formular HTML sunt ilustrate în fig. 7-33.

Fig. 7-33. Etapele de procesare a informa"iei dintr-un formular HTML Modalitatea tradi"ional de a trata formularele !i alte pagini de Web interactive este sistemul

numit CGI (Common Gateway Interface – Interfa" comun de conversie). Aceasta este o interfa" standardizat ce permite serverelor de Web s discute cu programele din fundal !i cu scripturile care accept o intrare (de ex.: formulare) !i s genereze pagini HTML ca r spuns. De obicei, aceste pro-grame de fundal sunt scripturi scrise în limbajul Perl deoarece scripturile Perl sunt mai u!or !i mai rapid de scris decât programele (cel pu"in dac !tii s programezi în Perl). În mod obi!nuit, ele sunt localizate într-un director numit cgi-bin, care este vizibil în URL. Câteodat un alt limbaj de scrip-turi, Python, este utilizat în loc de Perl.

Ca un exemplu de cât de frecvent lucreaz CGI, s consider m cazul unui produs al companiei Truly Great Products Company (rom. Compania Produselor cu Adev!rat Bune) care vine cu o fi! de înregistrare a produsului pentru garan"ie. În loc de a completa aceast fi! , clientului i se spune s mearg la www.tgpc.com pentru a se înregistra on-line. Pe acea pagin exist o hiper-leg tur care spune

Ap!sa i aici pentru a va înregistra produsul

Aceast leg tura indic spre un script Perl, s spunem www.tgpc.com/cgi-bin/reg.perl. Când acest script este executat f r parametri, transmite înapoi o pagin HTML con"inând formularul de înre-gistrare. Atunci când utilizatorul completeaz formularul !i face un clic pe submit se transmite un mesaj acestui script, mesaj ce con"ine valorile completate dup modelul din fig. 7-30. Scriptul Perl analizeaz parametrii, adaug o înregistrare în baza de date pentru noul client !i transmite înapoi o pagin HTML ce con"ine num rul de înregistrare !i un num r de telefon de la serviciul de asisten-" . Aceasta nu este singura modalitate de a trata formularele, dar este o modalitate des întâlnit . Exist un num r mare de c r"i despre scrierea scripturilor CGI !i programarea în Perl. Câteva exemple sunt: (Hanegan, 200#; Lash, 2002; !i Meltzer !i Michalski, 200#).

578 NIVELUL APLICA$IE CAP. 7

Scripturile CGI nu sunt singura modalitate de a genera con"inut dinamic la server. O alt moda-litate des întâlnit este de a îngloba mici scripturi în paginile HTML !i a l sa serverul s le execute pentru a genera pagina. Un limbaj popular pentru scrierea acestor scripturi este PHP (PHP: Hyper-text Procesor; rom.: Procesor Hipertext). Pentru a fi folosit, serverul trebuie s în"eleag PHP (exact cum programul de navigare trebuie s în"eleag XML pentru a interpreta paginile de Web scrise în XML). De obicei, serverele se a!teapt ca paginile de Web ce con"in PHP s aib extensia php mai degrab decât html sau htm.

Un mic script PHP este ilustrat în fig. 7-34; ar trebui s func"ioneze pe orice server care are PHP instalat. Con"ine HTML normal cu excep"ia scriptului PHP dintre marcajele <?php ... ?>. Ceea ce genereaz este o pagin de Web ce afi!eaz ceea ce !tie despre programul de navigare care o ape-leaz . Programele de navigare trimit de obicei o serie de informa"ii odat cu cererea lor (!i orice cookie aplicabil) !i aceast informa"ie este pus în variabila HTTP_USER_AGENT. Când acest pro-gram este pus în fi!ierul test.php în directorul de WWW al companiei ABCD, tastând URL-ul www.abcd.com/test.php se va afi!a o pagin de Web care spune utilizatorului ce program de navigare, ce limb !i ce sistem de operare folose!te.

<html> <body>

<h2> This is what I know about you </h2> <?php echo $HTTP_USER_AGENT ?>

</body> </html>

Fig. 7-34. O pagin HTML cu PHP înglobat PHP este folositor în special la tratarea formularelor !i este mai simplu de utilizat decât scrip-

turile CGI. Ca un exemplu al modului s u de func"ionare, s consider m exemplul din fig. 7-35(a). Aceast figur con"ine o pagin HTML normal cu un formular în interior. Singurul lucru neo-bi!nuit la aceast pagin este prima linie, care spune c fi!ierul action.php va fi invocat pentru a trata parametrii dup ce utilizatorul a completat !i transmis formularul. Pagina afi!eaz dou c -su"e de text, una cerând numele !i cealalt vârsta. Dup ce aceste c su"e au fost completate !i formularul transmis, serverul analizeaz !irul de caractere de forma celui din fig. 7-30, punând numele în variabila name !i vârsta în variabila age. Începe apoi s proceseze fi!ierul action.php, ar tat în fig. 7-35(b) pentru ob"inerea r spunsului. În timpul proces rii acestui fi!ier sunt executa-te comenzile PHP. Dac utilizatorul a completat valorile „Barbara” !i „24” în c su"ele formularu-lui, fi!ierul transmis înapoi este cel dat în fig. 7-35(c). Astfel, tratarea formularelor devine extrem de simpl în PHP.

De!i PHP este u!or de utilizat, este de fapt un limbaj de programare puternic, orientat pe interfa-"area dintre Web !i o baz de date a serverului. Suport variabile, !iruri de caractere, vectori !i majo-ritatea structurilor de control din C, dar un sistem de I/E mult mai puternic decât printf. PHP este un program public (open source) !i disponibil gratuit. A fost conceput special s lucreze bine cu Apache, care este de asemenea gratuit !i care este cel mai larg utilizat server de Web din lume. Pen-tru mai multe informa"ii despre PHP, vezi (Valade, 2002).

Am v zut pân acum dou moduri diferite de a genera pagini HTML dinamice: script-urile CGI !i PHP-ul înglobat. Exist !i o a treia tehnic , numit JSP (JavaServer Pages), care este similar cu PHP, cu excep"ia faptului c partea dinamic este scris în limbajul de programare Java în loc de

SEC. 7.3 WORLD WIDE WEB 579

PHP. Paginile ce folosesc aceast tehnic au în numele fi!ierului extensia jsp. O a patra tehnic , ASP (Active Server Pages), este versiunea de la Microsoft a PHP !i JavaServer Pages. Pentru generarea con"inutului dinamic folose!te limbajul de script proprietar al Microsoft-ului, Visual Basic Script. Paginile ce folosesc aceast tehnic au extensia asp. Alegerea dintre PHP, JSP, !i ASP are în general mai mult de-a face cu politici (open-souce vs. Sun vs. Microsoft) decât cu tehnologia, cele trei limba-je fiind comparabile. Colec"ia de tehnologii pentru generarea din zbor a con"inutului este uneori denumit HTML dinamic.

Generare dinamic# de pagini de Web la client Scripturile CGI, PHP, JSP !i ASP rezolv problema formularelor !i a interac"iunilor cu bazele de

date din server. Toate pot s accepte informa"ii care vin din formulare, s caute informa"ii într-una sau mai multe baze de date !i s genereze pagini HTML cu rezultate. Ceea ce nu poate face nici unul dintre scripturi este s r spund la mi!c rile mouse-ului sau s interac"ioneze direct cu utiliza-torii. În acest scop, este necesar ca scripturile s fie înglobate în paginile HTML care sunt executate mai degrab pe ma!ina clientului, decât pe ma!ina serverului. Începând cu HTML 4.0, astfel de scripturi erau permise folosind marcajul <script>. Cel mai popular limbaj de script la client este JavaScript, a!a c o s arunc m o scurt privire asupra lui.

<html> <body> <form action=”action.php” method=”post”> <p> Introduceti numele: <input type=”text” name=”name”> </p> <p> Introduceti varsta: <input type=”text” name=”age”> </p> <input type=”submit”> </form> </body> </html> (a)

<html> <body> <h"> Raspuns: </h"> Hello <?php echo $name; ?>. Prezicere: anul urmator veti avea <?php echo $age + "; ?> ani. </body> </html> (b)

<html> <body> <h"> Raspuns: </h"> Buna, Barbara. Prezicere: anul urmator veti avea 25 ani. </body> </html> (c)

Fig. 7-35. (a) O pagin Web ce con"ine un formular. (b) Un script PHP pentru afi!area dinamic a form-ului.

(c) Ie!irea scriptului PHP când datele de intrare sunt „Barbara” !i respectiv 24.

580 NIVELUL APLICA$IE CAP. 7

<html> <head> <script language=”javascript” type=”text/javascript”> function response(test_form) { var person = test_form.name.value; var years = eval(test_form.age.value) + "; document.open(); document.writeln(“<html> <body>”); document.writeln(“Hello “ + person + “.<br>”); document.writeln(“Prezicere: la anul vei avea “ + years + “.”); document.writeln(“</body> </html>”); document.close(); } </script> </head> <body> <form> Introduceti numele: <input type=”text” name=”name”> <p> Introduceti varsta: <input type=”text” name=”age”> <p> <input type=”button” value=”submit” onclick=”response(this.form)”> </form> </body> </html>

Fig. 7-36. Folosirea JavaScript Pentru procesarea unui formular. JavaScript este un limbaj de script, foarte inspirat din câteva idei ale limbajului de programare Ja-

va. Nu este cu siguran" Java. Ca alte limbaje de script, el este un limbaj de nivel foarte înalt. De exemplu, într-o singur linie din JavaScript este posibil s se creeze o fereastr de dialog, s se a!tep-te introducerea de text !i s se memoreze !irul rezultat într-o variabil . Astfel de caracteristici de nivel înalt fac din JavaScript un limbaj ideal pentru crearea de pagini Web interactive. Pe de alt parte, faptul c nu este standardizat !i c se modific mai repede ca o musc prins într-o ma!in cu raze X, fac extrem de dificil scrierea de programe JavaScript care s func"ioneze pe toate platfor-mele, dar poate într-o zi se va stabiliza.

Un exemplu de program în JavaScript, este cel din fig. 7-36. Ca !i în fig. 7-35(a), apare un formu-lar în care se cer numele !i vârsta !i care calculeaz vârsta persoanei în anul urm tor. Corpul este aproape la fel ca în exemplul PHP, principala diferen" fiind declararea butonului de trimitere a datelor !i asocierea unei func"ii cu acest buton. Aceast func"ie spune programului de navigare s invoce scriptul response la o ap sare de buton !i s -i trimit formularul ca parametru.

Complet nou aici este declararea func"iei JavaScript response în antetul fi!ierului HTML, o zon în mod normal rezervat titlurilor, culorilor de fundal !i a!a mai departe. Aceast func"ie extrage valoarea câmpului name din formular !i o p streaz ca !ir în variabila person. De asemenea extrage valoarea câmpului age, o converte!te la un întreg prin folosirea func"iei eval, o incrementeaz cu # !i re"ine rezultatul în years. Apoi deschide un document pentru ie!ire în care face trei scrieri, folosind metoda writeln, !i închide documentul. Documentul este un fi!ier HTML, dup cum se poate vedea din diversele marcaje HTML din el. Programul de navigare afi!eaz apoi documentul pe ecran.

SEC. 7.3 WORLD WIDE WEB 58"

Fig. 7-37. (a) Scripting la server cu PHP. (b) Scripting la client cu JavaScript.

Este foarte important de în"eles c în timp ce fig. 7-35 !i fig. 7-36 arat similar, ele sunt procesate total diferit. În fig. 7-35, dup ce utilizatorul a ap sat butonul submit, programul de navigare strânge informa"ia într-un !ir lung, în stilul celui din fig. 7-30 !i îl trimite serverului care a trimis pagina. Ser-verul vede numele fi!ierului PHP !i îl execut . Scriptul PHP produce o nou pagin HTML !i acea pagin este trimis înapoi programului de navigare pentru afi!are. Cu fig. 7-36, când butonul submit este ap sat, programul de navigare interpreteaz o func"ie JavaScript con"inut pe pagin . Totul este f cut local, în programul de navigare. Nu se face nici un contact cu serverul. Ca o consecin" , rezulta-tul este tip rit teoretic instantaneu, în timp ce cu PHP, poate exista o întârziere de câteva secunde înainte ca HTML-ul rezultat s ajung la client. Diferen"a între utilizarea scripturilor la server !i uti-lizarea acestora la client este ilustrat în fig. 7-37, inclusiv pa!ii implica"i. În ambele cazuri, pa!ii nu-merota"i încep dup afi!area formularului. Pasul # const din acceptarea datelor de intrare ale utili-zatorului. Apoi urmeaz procesarea acestora, care difer în cele dou cazuri.

<html> <head> <script language=”javascript” type=”text/javascript”>

function response(test_form) { function factorial(n) { if (n==0) return "; else return n * factorial(n-"); } var r = eval(test_form.number.value); // r = argument introdus de la tastatura document.myform.mytext.value = ”Aici sunt rezultatele.\n”; for (var i = "; i <= r; i++) // tipareste o linie de la " la r document.myform.mytext.value += (i + ”!= ” + factorial(i) + „\n”); } </script> </head>

<body> <form name=”myform”> Introduceti un numar: <input type=”text” name=”number”> <input type=”button” value=”calcul factorial” onclick=”response(this.form)”> <p> <textarea name=”mytext” rows=25 cols=50> </textarea> </form> </body> </html>

Fig. 7-38. Un program JavaScript pentru calculul !i afi!area factorialului.

582 NIVELUL APLICA$IE CAP. 7

Aceast diferen" nu înseamn c JavaScript este mai bun ca PHP. Utiliz rile lor sunt complet diferite. PHP (!i, prin implica"ie, JSP !i ASP) sunt utilizate când este necesar o interac"iune cu o baz de date aflat la distan" . JavaScript este utilizat când interac"iunea se face cu utilizatorul la calculatorul clientului. Este cu siguran" posibil (!i des întâlnit) s existe pagini HTML care folosesc atât PHP cât !i JavaScript, de!i evident nu pot face acela!i lucru pe acela!i buton, sau s de"in ace-la!i buton.

JavaScript este un limbaj de programare matur, cu toat puterea limbajelor C !i Java. Are varia-bile, !iruri, vectori, obiecte, func"ii, !i toate structurile de control obi!nuite. Are, de asemenea, un num r mare de facilit "i specifice paginilor Web, inclusiv abilitatea de a lucra cu ferestre !i cadre, setarea !i ob"inerea de cookie-uri, lucrul cu formulare, !i cu hiper-leg turi. Un exemplu de program JavaScript care utilizeaz o func"ie recursiv este dat în fig. 7-38.

JavaScript poate, de asemenea, s urm reasc mi!carea mouse-ului peste obiectele afi!ate. Mul-te pagini Web ce con"in JavaScript au proprietatea c atunci când mouse-ul se mi!c peste un text sau o imagine, se întâmpl ceva. Deseori, imaginea se schimb sau apare dintr-o dat un meniu. Acest tip de comportament este u!or de programat în JavaScript !i conduce la pagini de Web foarte dinamice. În fig. 7-39 este dat un exemplu.

<html> <head> <script language=”javascript” type=”text/javascript”> if (!document.myurl) document.myurl = new Array(); document.myurl[0] = “http://www.cs.vu.nl/ast/im/kitten.jpg”; document.myurl["] = “http://www.cs.vu.nl/ast/im/puppy.jpg”; document.myurl[2] = “http://www.cs.vu.nl/ast/im/bunny.jpg”; function pop(m) { var urx = “http://www.cs.vu.nl/ast/im/cat.jpg”; popupwin = window.open(document.myurl[m], “mywind”, “width=250,height=250”); } </script> </head>

<body> <p> <a href=”#” onMouseover=”pop(0); return false;”> Kitten </a> </p> <p> <a href=”#” onMouseover=”pop("); return false;”> Puppy </a> </p> <p> <a href=”#” onMouseover=”pop(2); return false;”> Bunny </a> </p> </body> </html>

Fig. 7-39. O pagin Web interactiv care r spunde la mi!carea mouse-ului. JavaScript nu este singura cale de a face paginile Web foarte interactive. Alt metod popular

este bazat pe folosirea applet-urilor. Acestea sunt mici programe Java care au fost compilate într-un cod ma!in pentru un calculator virtual numit JVM (Java Virtual Machine – Ma!ina Virtual Java). Applet-urile pot fi incluse în paginile HTML (între <applet> !i </applet>) !i sunt interpre-tate de programe de navigare care cunosc JVM. Deoarece applet-urile nu sunt executate, ci inter-pretate, interpretorul Java poate s le împiedice s fac Lucruri Rele. Cel pu"in în teorie. În practic , autorii de applet-uri au g sit !i exploatat un !ir aproape nesfâr!it de erori în bibliotecile Java de I/E.

R spunsul Microsoft la applet-urile Java de la Sun au fost paginile Web cu controale Active-X (Active-X controls), care sunt programe compilate pentru o ma!in Pentium !i sunt executate direct

SEC. 7.3 WORLD WIDE WEB 583

în hardware. Aceast proprietate le face mult mai rapide !i mai flexibile decât applet-urile interpre-tate, pentru c pot face orice poate face un program. Când Internet Explorer vede un control Acti-ve-X într-o pagin Web, îl descarc , îi verific identitatea !i îl execut . Totu!i, desc rcarea !i executa-rea de programe str ine ridic probleme de securitate, la care ne vom referi în cap. 8.

Din moment ce aproape toate programele de navigare pot s interpreteze atât programe Java cât !i JavaScript, un programator care vrea s fac o pagin Web foarte interactiv va putea s aleag între dou tehnici, iar dac nu se dore!te portabilitatea pe mai multe platforme, poate s aleag !i Active-X. Ca o regul general , programele JavaScript sunt mai u!or de scris, applet-urile Java se execut mai rapid iar controalele Active-X cel mai rapid dintre toate. De asemenea, din moment ce toate programele de navigare implementeaz exact aceea!i JVM, dar nu exist dou programe de navigare care s !tie aceea!i versiune de JavaScript, applet-urile Java sunt mai portabile decât pro-gramele JavaScript. Pentru mai multe detalii despre JavaScript, exist multe c r"i, fiecare cu multe (deseori peste #000) pagini. Câteva exemple sunt (Easttom, 200#; Harris 200#; !i McFerdries, 200#).

Înainte de a p r si subiectul con"inutului dinamic al Web-ului, s recapitul m pe scurt ce am atins pân acum. Pagini Web complete se pot genera din mers, folosind diverse script-uri pe ma!ina server. Odat ce sunt primite de programul de navigare, ele sunt tratate ca pagini HTML normale !i sunt doar afi!ate. Script-urile pot fi scrise în Perl, PHP, JSP sau ASP, dup cum este ar tat în fig. 7-40.

Fig. 7-40. Diverse moduri de a genera !i afi!a con"inut. Generarea con"inutului dinamic este posibil !i în partea clientului. Paginile Web pot fi scrise în

XML !i convertite la HTML conform unui fi!ier XSL. Programele JavaScript pot s efectueze diver-se calcule. În sfâr!it, plug-in-urile (plug-ins) !i aplica"iile ajut toare (helper applications) pot fi folosi-te pentru afi!area con"inutului într-o varietate de forme.

7.3.4 HTTP – HyperText Transfer Protocol

Protocolul de transfer utilizat pe Web este HTTP (HyperText Transfer Protocol, rom.:Protocol de Transfer al Hipertextului). Acesta specific ce mesaje pot trimite clien"ii c tre servere !i ce r s-punsuri primesc înapoi. Fiecare interac"iune const dintr-o cerere ASCII, urmat de un r spuns MIME conform RFC 822. To"i clien"ii !i toate serverele trebuie s se supun acestui protocol. Este definit în RFC 26#6. În aceast sec"iune vom trata câteva din propriet "ile sale cele mai importante.

584 NIVELUL APLICA$IE CAP. 7

Conexiuni Modul uzual prin care un program de navigare contacteaz un server este de a stabili o conexiu-

ne TCP pe portul 80 pe ma!ina serverului, de!i aceast procedur nu este cerut formal. Avantajul de a folosi TCP este c nici programele de navigare !i nici serverele nu trebuie sa se preocupe de mesajele pierdute, mesajele duplicate, mesajele lungi, sau mesajele de confirmare. Toate aceste as-pecte sunt tratate de implementarea TCP.

În HTTP #.0, dup ce conexiunea era stabilit , o singur cerere era transmis !i un singur r s-puns era primit înapoi. Apoi conexiunea TCP era eliberat . Într-o lume în care pagina tipic Web consta în întregime din text HTML, aceast metod era adecvat . În câ"iva ani îns , o pagin medie Web con"inea un num r mare de iconi"e, imagini !i alte lucruri pl cute vederii, astfel c stabilirea unei conexiuni TCP pentru a prelua o singur iconi" a devenit un mod foarte costisitor de a opera.

Aceast observa"ie a dus la apari"ia HTTP #.#, care suport conexiuni persistente. Cu ele, este posibil stabilirea unei conexiuni TCP, trimiterea unei cereri !i ob"inerea unui r spuns, apoi trimite-rea unor cereri adi"ionale !i ob"inerea de r spunsuri adi"ionale. Prin distribuirea pornirii !i eliber rii unei conexiuni TCP peste mai multe cereri, supraînc rcarea relativ datorat TCP-ului este mult mai mic pe fiecare cerere. Este de asemenea posibil trimiterea cererilor prin mecanismul pipeline, adic trimiterea cererii 2 înainte ca r spunsul la cererea # s fi sosit.

Metode Cu toate c HTTP a fost proiectat pentru utilizarea în Web, el a fost creat inten"ionat mai gene-

ral decât era necesar în perspectiva aplica"iilor orientate pe obiecte. Pentru aceasta sunt suportate opera"iile, denumite metode, care fac mai mult decât cele care doar cer o pagin Web. Aceast con-sidera"ie general a permis apari"ia SOAP. Fiecare cerere const din una sau mai multe linii de text ASCII, în care primul cuvânt din prima linie este numele metodei cerute. Metodele incorporate sunt listate în fig. 7-4#. Pentru accesarea unor obiecte generale, metode adi"ionale specifice obiectelor pot fi de asemenea disponibile. În numele metodelor este semnificativ utilizarea literelor mari/mici, de exemplu GET este o metod acceptat , dar nu !i get.

Metoda Descriere GET Cerere de citire a unei pagini Web HEAD Cerere de citire a antetului unei pagini de Web PUT Cerere de memorare a unei pagini de Web POST Ad!ugarea la o resurs! anume (de exemplu o pagin! de Web) DELETE $tergerea unei pagini de Web TRACE Tip!rirea cererii care a sosit CONNECT Rezervat pentru o utilizare în viitor OPTIONS Interogarea anumitor op iuni

Fig. 7-4". Metode de cerere standard pentru HTTP. Metoda GET cere serverului s trimit pagina (prin care noi în"elegem obiect, în cel mai general

caz, dar în practic de obicei doar un fi!ier). Pagina este codat corespunz tor în MIME. Marea majoritate a cererilor c tre servere Web sunt metode GET. Forma uzual a metodei GET este

GET fi#ier HTTP-"."

unde fi$ier denume!te resursa (fi!ierul) ce va fi adus , !i #.# este versiunea de protocol utilizat.

SEC. 7.3 WORLD WIDE WEB 585

Metoda HEAD cere doar antetul mesajului, f r s cear !i pagina propriu-zis . Aceast metod poate s fie utilizat pentru a afla când s-a f cut ultima modificare, pentru a ob"ine informa"ii pentru indexare, sau numai pentru a verifica corectitudinea unui URL.

Metoda PUT este inversa metodei GET: în loc s citeasc o pagin , o scrie. Aceast metod permite crearea unei colec"ii de pagini de Web pe un server la distan" . Corpul cererii con"ine pagi-na. Pagina poate s fie codificat utilizând MIME, caz în care liniile care urmeaz dup PUT pot include Content-Type !i antete de autentificare, pentru a demonstra c într-adev r cel care face cere-rea are dreptul de a realiza opera"ia cerut .

Similar metodei PUT este metoda POST. $i ea con"ine un URL, dar în loc s înlocuiasc date existente, noile date se vor ad uga într-un mod generalizat. De exemplu, se poate transmite un me-saj la un grup de !tiri sau ad uga un fi!ier la un sistem de informare în re"ea. În practic , nici PUT !i nici POST nu sunt utilizate prea mult.

DELETE realizeaz ce era de a!teptat: !tergerea unei pagini. Ca !i la PUT, autentificarea !i drepturile de acces joac aici un rol important. Nu exist nici o garan"ie asupra succesului opera"iei DELETE, deoarece chiar dac serverul dore!te s execute !tergerea, fi!ierul poate s aib atribute care s interzic serverului HTTP s îl modifice sau s îl !tearg .

Metoda TRACE este pentru verificarea corectitudinii. Ea cere serverului s trimit înapoi cere-rea. Aceast metod este util când cererile nu sunt procesate corect !i clientul vrea s !tie ce fel de cerere a ajuns de fapt la server.

Metoda CONNECT nu este utilizat în prezent. Este rezervat pentru utiliz ri ulterioare. Metoda OPTIONS asigur o modalitate pentru client de a interoga serverul despre propriet "ile

acestuia sau despre cele ale unui anumit fi!ier. Fiecare cerere ob"ine un r spuns ce const din linia de stare !i posibile informa"ii suplimentare

(de exemplu, o parte sau toat pagina Web). Linia de stare con"ine un cod de stare de trei cifre, indi-când dac cererea a fost satisf cut !i dac nu, cauza. Prima cifr este utilizat pentru împ r"irea r spunsurilor în cinci mari grupuri, ca în fig. 7-42. Codurile #xx sunt utilizate în practic foarte rar. Codurile 2xx indic tratarea cu succes a cererii !i con"inutul (dac exist ) este returnat. Codurile 3xx spun clientului s caute în alt parte, prin folosirea unui URL diferit, sau în propria memorie ascun-s (discutat mai târziu). Codurile 4xx indic insuccesul cererii din cauza unei erori la client, precum o cerere invalid sau o pagin inexistent . În fine, erorile 5xx indic o problem în server, datorat codului s u sau unei supraînc rc ri temporare.

Cod Semnifica ie Exemple xx Informa!ie 00 = serverul accept" tratarea cererii de la client 2xx Succes 200 = cerere reu#it"; 204 = nu exist" con!inut 3xx Redirectare 30 = pagin" mutat"; 304 = pagina din memoria ascuns" este

înc" valid" 4xx Eroare la client 403 = pagin" interzis"; 404 = pagina nu a fost g"sit" 5xx Eroare la server 500 = eroare intern" la server; 503 = încearc" mai târziu

Fig. 7-42. Grupuri de r spunsuri ale codurilor de stare.

Antete de mesaje Linia de cerere (de exemplu linia cu metoda GET) poate fi urmat de linii adi!ionale cu mai

multe informa!ii. Acestea poart numele de antete de cerere. Aceast informa!ie poate fi comparat cu parametrii unui apel de procedur . R spunsurile pot avea de asemenea antete de r spuns. Anu-mite antete pot fi folosite în orice sens. O selec!ie a celor mai importante este dat în fig. 7-43.

586 NIVELUL APLICA!IE CAP. 7

Antetul User-Agent permite clientului s informeze serverul asupra programului s u de navigare, sistemului de operare "i altor propriet !i. În fig. 7-34 am v zut c serverul avea în mod magic aceast informa!ie "i c o poate ob!ine la cerere într-un script PHP. Antetul este utilizat de client pentru a-i asigura serverului aceast informa!ie.

Antet Tip Descriere User-Agent Cerere Informa!ie asupra programului de navigare #i a platformei Accept Cerere Tipul de pagini pe care clientul le poate trata Accept-Charset Cerere Seturile de caractere care sunt acceptabile la client Accept-Encoding Cerere Codific"rile de pagini pe care clientul le poate trata Accept-Language Cerere Limbajele naturale pe care clientul le poate trata Host Cerere Numele DNS al serverului Authorization Cerere O list" a drepturilor clientului Cookie Cerere Trimite un cookie setat anterior înapoi la server Date Ambele Data #i ora la care mesajul a fost trimis Upgrade Ambele Protocolul la care transmi!"torul vrea s" comute Server R"spuns Informa!ie despre server Content-Encoding R"spuns Cum este codat con!inutului (de exemplu, gzip) Content-Language R"spuns Limbajul natural utilizat în pagin" Content-Length R"spuns Lungimea paginii în octe!i Content-Tzpe R"spuns Tipul MIME al paginii Last-Modified R"spuns Ora #i data la care pagina a fost ultima dat" modificat" Location R"spuns O comand" pentru client pentru a trimite cererea în alt" parte Accept-Ranges R"spuns Serverul va accepta cereri în anumite limite de octe!i Set-Cookie R"spuns Serverul vrea s" salveze un cookie la client

Fig. 7-43. Câteva antete de mesaje HTTP.

Cele patru antete Accept spun serverului ce este dispus clientul s accepte în cazul în care acesta are un repertoriu limitat despre ceea ce este acceptabil. Primul antet specific ce tipuri MIME sunt acceptate (de exemplu, text/html). Al doilea reprezint setul de caractere (de exemplu ISO-8859 sau Unicode-#-#). Al treilea se refer la metode de compresie (de exemplu, gzip). Al patrulea indic un limbaj natural (de exemplu, spaniola). Dac serverul are mai multe pagini din care poate s aleag , el poate utiliza aceast informa!ie pentru a furniza clientului pagina pe care o caut . Dac nu poate satisface cererea, este întors un cod de eroare "i cererea e"ueaz .

Antetul Host denume"te serverul. El este luat din URL. Antetul este obligatoriu. Este utilizat deoarece anumite adrese IP pot servi mai multe nume de DNS "i serverul are nevoie de o anumit modalitate de a spune c rui calculator s -i trimit cererea.

Antetul Authorization este necesar pentru protec!ia paginilor. În acest caz, clientul trebuie s demonstreze c are dreptul de a vedea pagina cerut . Acest header este utilizat în acest scop.

De"i cookie-urile sunt tratate în RFC 2#09 mai mult decât în RFC 26#6, "i ele au dou antete. Antetul Cookie este utilizat de clien!i pentru a întoarce serverului un cookie care a fost anterior tri-mis de o ma"in aflat în domeniul serverului.

Antetul Date poate fi utilizat în ambele sensuri "i con!ine ora "i data la care a fost trimis mesajul. Antetul Upgrade este folosit pentru a face mai u"oar crearea unei tranzi!ii c tre o viitoare (posibil incompatibil ) versiune a protocolului HTTP. Acesta permite clientului, s anun!e ce anume supor-t , "i serverului s afirme ceea ce folose"te.

Acum am ajuns la antetele utilizate exclusiv de c tre server în r spunsul cererilor. Primul, Server, permite serverului s spun cine este "i câteva propriet !i, dac dore"te.

SEC. 7.3 WORLD WIDE WEB 587

Urm toarele patru antete, toate începând cu Content-, permit serverului s descrie propriet !ile paginii pe care o transmite.

Antetul Last-Modified spune când a fost modificat ultima dat pagina. Acest antet joac un rol important în mecanismul de memorie ascuns .

Antetul Location este utilizat de server pentru a informa clientul c ar trebui s utilizeze un alt URL. Acesta poate fi folosit dac pagina a fost mutat , sau pentru a da permisiunea mai multor URL-uri de a referi aceea"i pagin (posibil pe servere diferite). Este de asemenea utilizat pentru companiile care au o pagin de Web principal în domeniul com, dar care redirec!ioneaz clien!ii la o pagin na!ional sau regional în func!ie de adresa lor IP sau limba preferat .

Dac o pagin este foarte mare, un client mic poate nu o dore"te dintr-o dat . Unele servere ac-cept cereri în anumite intervale de octe!i, astfel c pagina poate fi citit în mai multe unit !i mai mici. Antetul Accept-Ranges anun! asentimentul severului de a trata acest tip de cerere par!ial de pagini.

Al doilea antet pentru cookie, Set-Cookie, se refer la modul în care serverele trimit cookie-uri la clien!i. Este de a"teptat salvarea cookie-ului de c tre client "i returnarea acestuia la cereri ulterioare ale serverului.

Exemplu de utilizare HTTP Deoarece HTTP este un protocol ASCII, este destul de u"or pentru o persoana aflat la un ter-

minal (ca opus al programului de navigare) s vorbeasc direct cu serverele de Web. Este necesar doar o conexiune TCP la portul 80 pe server. Cititorii sunt încuraja!i s încerce personal acest scena-riu (preferabil dintr-un sistem UNIX, deoarece anumite sisteme nu returneaz starea conexiunii).

Trying 4. 7. 68.6... Connected to www.ietf.org. Escape character is ’^]’. HTTP/ . 200 OK Date: Wed, 08 May 2002 22:54:22 GMT Server: Apache/ .3.20 (Unix) mod_ssl/2.8.4 OpenSSL/0.9.5a Last-Modified: Mon, Sep 2000 3:56:29 GMT ETag: ”2a79d-c8b-39bce48d” Accept-Ranges: bytes Content-Length: 32 Content-Type: text/html X-Pad: avoid browser bug

<html> <head> <title>IETF RFC Page</title>

<script language=”javascript”> function url() { var x = document.form .number.value if (x.length == ) { x = ”000” + x } if (x.length == 2) { x = ”00” + x } if (x.length == 3) { x = ”0” + x } document.form .action = „/rfc/rfc” + x + „.txt” document.form .submit } </script>

</head> Fig. 7-44. Primele linii ale fi"ierului www.ietf.org/rfc.html.

588 NIVELUL APLICA!IE CAP. 7

Urm toarea secven! de comenzi va realiza acest lucru:

telnet www.ietf.org 80 >log GET /rfc.html HTTP/#.# Host: www.ietf.org

close

Aceast secven! de comenzi porne"te o conexiune telnet (adic TCP) pe portul 80 al serverului Web al IETF, www.ietf.org. Rezultatul sesiunii este redirectat c tre fi"ierul log pentru o inspec!ie ulterioar . Apoi urmeaz comanda GET denumind fi"ierul "i protocolul. Urm toarea linie este an-tetul obligatoriu Host. Linia r mas liber este de asemenea cerut . Ea semnaleaz serverului c nu mai sunt antete de cerere. Comanda close indic programului de telnet s întrerup conexiunea.

Fi"ierul log poate fi inspectat folosind un editor. Acesta ar trebui s înceap similar cu liniile de cod din fig. 7-44, cu excep!ia unei modific ri recente de c tre IETF.

Primele trei linii reprezint ie"irea programului telnet, "i nu de la serverul la distan! . Linia ce în-cepe cu HTTP/#.# este r spunsul IETF prin care spune c este dispus s vorbeasc HTTP/#.# cu tine. Apoi urmeaz un num r de antete "i apoi con!inutul. Am v zut deja toate antetele, cu excep!ia lui ETag care este un identificator de pagin unic, referitor la memoria ascuns , "i X-Pad care nu este standardizat, probabil o cale de sc pare pentru vreun program de navigare cu erori.

7.3.5 Îmbun t "iri ale performan"ei

Popularitatea Web-ului aproape c a fost propria sa distrugere. Servere, rutere "i linii folosite de Web sunt adesea supraînc rcate. Mult lume a început s denumeasc WWW-ul ca World Wide Wait (rom: a"teptare de întindere planetar ). Ca o consecin! a acestor întârzieri f r sfâr"it, cerce-t torii au dezvoltat diverse tehnici pentru îmbun t !irea performan!elor. Vom examina acum trei dintre ele: memoria ascuns , replicarea serverelor "i re!ele de livrare a con!inutului.

Memoria ascuns Un mod simplu de a îmbun t !i performan!a este de a salva paginile care au fost cerute pentru

cazul în care ele vor fi utilizate din nou. Aceast tehnic este efectiv în special pentru paginile care sunt vizitate foarte mult, ca www.yahoo.com "i www.cnn.com. Paginile pot fi p strate pentru utiliz ri ulterioare în memoria ascuns (eng.: cache). Procedura uzual este ca un proces, denumit proxy (rom.: delegat), s între!in aceast memorie. Pentru a utiliza memoria ascuns , un program de navi-gare poate fi configurat s adreseze toate cererile de pagini proxy-ului, "i nu serverului real unde se afl pagina respectiv . Dac proxy-ul are pagina, o returneaz imediat. Dac nu, aduce pagina de la server, o adaug în memoria ascuns pentru utilizarea ulterioar "i o întoarce clientului care a cerut-o.

Dou întreb ri importante aferente memoriei ascunse sunt:

#. Cine ar trebui s de!in memoria ascuns ? 2. Cât de mult timp ar trebui s stea paginile în memoria ascuns ?

Exist mai multe r spunsuri la prima întrebare. PC-urile individuale de obicei ruleaz proxy-uri, deci pot s caute rapid pagini vizitate anterior. Într-un LAN al unei companii, proxy-ul este în gene-ral o ma"in ce poate fi accesat de toate ma"inile din acel LAN, astfel c dac un utilizator se uit la o anumit pagin "i apoi alt utilizator din acela"i LAN vrea aceea"i pagin , ea poate fi adus din memoria ascuns a proxy-ului. Multe ISP-uri ruleaz proxy-uri, pentru a accelera accesul clien!ilor

SEC. 7.3 WORLD WIDE WEB 589

lor. De obicei toate memoriile ascunse opereaz în acela"i timp, deci cererile se duc ini!ial la proxy-ul local. Dac e"ueaz , proxy-ul local cere pagina proxy-ului din LAN. Dac "i aceasta e"ueaz , proxy-ul din LAN încearc la proxy-ul ISP-ului. Ultimul trebuie s reu"easc s aduc paginile, fie din memoria sa ascuns , fie de la o memorie ascuns de nivel superior, fie de la însu"i serverul ce de!ine pagina. O schem ce include mai multe memorii ascunse care pot fi încercate în secven! este denumit memorie ascuns ierarhic (hierarchical caching). O posibil implementare este ilustrat în fig. 7-45.

Fig. 7-45. Memorie ascuns ierarhic cu 3 proxy-uri .

Cât timp ar trebui paginile s r mân în memoria ascuns este un pic mai dificil de aflat. Anumi-te pagini nu ar trebui s fie p strate deloc în memoria ascuns . De exemplu, o pagin ce con!ine pre-!urile pentru cele mai active 50 de ac!iuni la burs se schimb la fiecare secund . Dac s-ar p stra în memoria ascuns , un utilizator ce ia o astfel de copie ar lua date vechi (adic dep "ite). Pe de alt parte, din momentul în care schimbul de ac!iuni s-a închis pe ziua respectiv , pagina va r mâne vali-d ore sau zile, pân când începe urm toarea licita!ie. Astfel, eficien!a men!inerii unei pagini în memoria ascuns poate varia foarte mult în timp.

Problema-cheie în determinarea elimin rii unei pagini din memoria ascuns este legat de ve-chimea pe care utilizatorii sunt dispu"i s o accepte (din moment ce paginile din memoria ascuns sunt !inute pe disc, cantitatea de memorare consumat reprezint rareori o problem ). Dac un proxy elimin repede paginile, el va întoarce rar o pagin veche, dar nu va fi prea eficient (adic va avea o rat sc zut de succes). Dac p streaz paginile prea mult, poate avea o rat mai mare dar cu pre!ul de a întoarce deseori pagini cu informa!ie expirat .

Exist dou abord ri în tratarea acestei probleme. Prima utilizeaz o euristic pentru a "ti cât timp s men!in fiecare pagin . O euristic des întâlnit este cea în care se !ine cont de antetul Last-Modified (vezi fig. 7-43). Dac o pagin a fost modificat cu o or în urm , se !ine în memoria ascun-s o or . Dac a fost modificat cu un an în urm , este evident o pagin foarte veche (de exemplu, o list a zeilor din mitologia greac "i cea roman ), deci poate fi p strat în memoria ascuns pentru un an, cu o probabilitate rezonabil c nu se va modifica în decursul anului. De"i aceast euristic func!ioneaz bine în practic , ea întoarce, totu"i, pagini vechi din când în când.

Cealalt abordare este mai costisitoare dar elimin posibilitatea paginilor vechi prin utilizarea unor caracteristici speciale ale RFC 26#6 care trateaz administrarea memoriei ascunse. Una din cele mai utilizate caracteristici este antetul de cerere If-Modified-Since, pe care un proxy poate s -l trimit unui server. El specific pagina pe care o vrea proxy-ul "i momentul la care pagina din me-moria ascuns a fost modificat ultima dat (din antetul Last-Modified). Dac pagina nu a mai fost modificat de atunci, serverul trimite înapoi un scurt mesaj Not Modified (codul de stare 304 din fig. 7-42), care indic proxy-ului s utilizeze pagina din memoria ascuns . Dac pagina a mai fost modifi-cat de atunci, este returnat noua pagin . În timp ce pentru aceast abordare este întotdeauna ne-

590 NIVELUL APLICA!IE CAP. 7

voie de un mesaj de cerere "i unul de r spuns, mesajul de r spuns va fi foarte scurt când intrarea în memoria ascuns este înc valid .

Aceste dou abord ri pot fi combinate u"or. Pentru primul T dup aducerea paginii, proxy-ul doar returneaz pagina clien!ilor ce o cer. Dup ce pagina a stat un timp în memoria ascuns , proxy-ul utilizeaz mesajul If-Modified-Since pentru a verifica valabilitatea acesteia. Alegerea T implic invariabil o euristic , depinzând de cât de mult timp a trecut de la modificarea paginii.

Paginile Web cu con!inut dinamic (de exemplu, cele generate de un script PHP) nu ar trebui ni-ciodat p strate în memoria ascuns , deoarece parametrii pot fi diferi!i la urm toarea accesare. Pen-tru a trata aceasta "i alte cauze, exist un mecanism general prin care un server instruie"te toate proxy-urile pân la client s nu foloseasc din nou pagina curent pân nu îi verific valabilitatea. Acest mecanism poate fi folosit de asemenea pentru orice pagin pasibil s fie modificat curând. Diverse mecanisme de control al memoriei ascunse sunt definite în RFC 26#6.

Mai exis o abordare în îmbun t !irea performan!ei, memoria ascuns proactiv . Când un proxy aduce o pagin de la un server, el poate inspecta pagina pentru a vedea dac ea con!ine hiper-leg turi. Dac este a"a, poate s lanseze cereri serverelor corespunz toare pentru a preînc rca în memoria ascuns paginile la care puncteaz , pentru cazul în care va fi nevoie de ele. Aceast tehnic poate reduce timpul de acces pentru cererile ulterioare, dar poate, la fel de bine, s inunde liniile de comunica!ie cu pagini care nu vor fi niciodat necesare.

În mod clar, memoria ascuns în Web este departe de a fi banal . Mult mai multe se pot spune despre ea. De fapt, s-au scris c r!i întregi pe aceast tem , de exemplu (Rabinovich "i Spatscheck, 2002; "i Wessels, 200#). Dar este timpul ca noi s trecem la un alt subiect.

Replicarea serverelor Memoria ascuns este o tehnic orientat spre client pentru îmbun t !irea performan!elor, dar

exist "i tehnici orientate pe server. Cea mai întâlnit abordare pentru îmbun t !irea performan!elor serverelor este replicarea con!inutului lor în mai multe locuri separate. Aceast tehnic este câteoda-t denumit oglindire (mirroring).

Într-o utilizare tipic a oglindirii într-o companie, pagina principal de Web con!ine câteva ima-gini cu leg turi c tre siturile Web regionale, de exemplu siturile din est, vest, nord "i sud. Utilizatorul urmeaz leg tura cea mai apropiat . Din acel moment, toate cererile se duc la serverul selectat.

Siturile oglindite sunt în general complet statice. Compania decide unde s plaseze copiile, dis-pune de un server în fiecare regiune, "i plaseaz (mai mult sau mai pu!in) întregul con!inut în fiecare loc (omi!ând, probabil, dez pezitoarele în situl de la Miami "i "ezlongurile în situl din Anchorage). Alegerea siturilor r mâne în general stabil luni sau chiar ani de zile.

Din p cate, Web-ul prezint un fenomen cunoscut ca aglomerare brusc (flash crowds) în care un sit Web care era anterior necunoscut, nevizitat, aproape mort, devine dintr-o dat centrul uni-versului. De exemplu, pân pe 6 noiembrie 2000, situl Web al secretarului de stat din Florida, www.dos.state.fl.us, informa tacit despre întâlnirile cabinetului statului Florida "i oferea instruc!iuni pentru a deveni notar în Florida. Dar pe 7 noiembrie 2000, când pre"edin!ia Statelor Unite depin-dea dintr-o dat de câteva mii de voturi disputate în câteva provincii din Florida, a devenit unul din primele 5 situri Web din lume. Evident, nu a putut suporta înc rcarea "i aproape c a murit strivit sub ea.

Este necesar un mod prin care un sit Web, ce observ dintr-o dat o cerere masiv a traficului, s se cloneze automat în atâtea loca!ii cât este necesar "i s p streze aceste situri opera!ionale pân când trece furtuna, moment în care opre"te majoritatea sau chiar totalitatea acestora. Pentru a avea

SEC. 7.3 WORLD WIDE WEB 59#

aceast abilitate, un sit are nevoie de o în!elegere prealabil cu o companie care de!ine mai multe situri, prin care se pot crea replici la cerere "i pentru care se pl te"te în func!ie de capacitatea pe care o folose"te în realitate.

O strategie "i mai flexibil este de a crea replici dinamice la nivel de pagini, în func!ie de unde vine traficul. Câteva cercet ri pe aceast tem sunt raportate în (Pierre ".a.., 200#; "i Pierre ".a.., 2002).

Re"ele de livrare de con"inut Culmea capitalismului este c cineva a descoperit cum s câ"tige bani din World Wide Wait.

Func!ioneaz în felul urm tor. Companiile denumite CDN (Content Delivery Networks, rom: re"ele de livrare de con"inut) vorbesc cu de!in torii con!inutului (situri muzicale, ziare, "i al!ii care doresc s fac disponibil con!inutul u"or "i rapid) "i se ofer s livreze acest con!inut utiliza-torilor finali în mod eficient, contra cost. Dup semnarea contractului, de!in torul con!inutului ofer CDN-ului con!inutul sitului s u Web pentru preprocesare (care va fi discutat imediat) "i apoi distribu!ie.

Apoi CDN vorbe"te cu un num r mare de ISP-uri "i se ofer s îi pl teasc bine pentru dreptul de a plasa un server administrat la distan! , plin de con!inut valoros, pe LAN-urile lor. Nu numai c este o surs de venit, dar asigur de asemenea clien!ilor ISP-urilor timpi de r spuns excelen!i pentru a ajunge la con!inutul CDN-ului, oferind astfel ISP-ului un avantaj competitiv fa! de alte ISP-uri care nu au acceptat oferta CDN-ului. În aceste condi!ii, colaborarea cu un CDN este ceva la mintea coco"ului pentru ISP. Ca o consecin! , cele mai mari CDN-uri au mai mult de #0.000 de servere r s-pândite în toat lumea. <html> <head><title>Furry Video</title></head> <body> <h >Furry Video’s Product List</h > <p>Click below for free samples.</p>

<a href=”bears.mpg”>Bears Today</a><br>, <a href=”bunnies.mpg”>Funny Bunnies</a><br> <a href=”mice.mpg”>Nice Mice</a><br> </body> </html> (a)

<html> <head><title>Furry Video</title></head> <body> <h >Furry Video’s Product List</h > <p>Click below for free samples.</p>

<a href=”http://cdn-server.com/furryvideo/bears.mpg”>Bears Today</a><br>, <a href=”http://cdn-server.com/furryvideo/bunnies.mpg”>Funny Bunnies</a><br> <a href=”http://cdn-server.com/furryvideo/mice.mpg”>Nice Mice</a><br> </body> </html> (b)

Fig. 7-46. (a) Pagina Web original . (b) Aceea"i pagin dup transformare.

592 NIVELUL APLICA!IE CAP. 7

Cu un con!inut replicat pe mii de situri în lumea întreag , exist în mod clar un poten!ial ridicat pentru îmbun t !irea performan!elor. Cu toate acestea, pentru o func!ionare bun , trebuie s existe o modalitate prin care s se redirecteze cererea clientului la cel mai apropiat server CDN, preferabil unul aflat la ISP-ul clientului. De asemenea, aceast redirectare trebuie f cut f r modificarea DNS-ului sau a oric rei alte p r!i a infrastructurii standard a Internet-ului. O descriere pu!in simpli-ficat despre cum lucreaz Akamai, cel mai mare CDN, este oferit în continuare.

Întregul proces începe din momentul în care furnizorul con!inutului trimite CDN-ului situl s u Web. Apoi CDN-ul trece fiecare pagin printr-un preprocesor care înlocuie"te toate URL-urile cu unele modificate. Modelul de lucru din spatele acestei strategii este acela c situl Web al furnizorului de con!inut este constituit din multe pagini foarte mici (doar text HTML), dar c aceste pagini au de obicei referin!e c tre fi"iere mari, precum imagini, audio "i video. Paginile HTML modificate sunt p strate pe serverul furnizorului de con!inut "i sunt aduse în mod obi"nuit; doar imaginile, comuni-ca!iile audio "i video merg pe serverele CDN-ului.

Pentru a vedea cum func!ioneaz aceast schem în realitate, se consider pagina Web a lui Furry (rom.: îmbl nit) Video din fig. 7-46(a). Dup preprocesare, ea este transformat în fig. 7-46(b) "i plasat pe serverul Furry Video ca www.furryvideo.com/index.html.

Când un utilizator introduce ca URL www.furryvideo.com, DNS-ul întoarce adresa IP a sitului Furry Video, permi!ând ca pagina (HTML) principal s fie adus în mod obi"nuit. Când se face clic pe oricare din hiper-leg turi, programul de navigare cere DNS-ului s caute cdn-server.com, ceea ce acesta chiar face. Programul de navigare trimite apoi o cerere HTTP c tre aceast adres IP, con-tând pe faptul c va primi înapoi un fi"ier MPEG.

Aceasta nu se întâmpl deoarece cdn-server.com nu g zduie"te nici un con!inut. În schimb, acesta este pe serverul fals de HTTP al CDN-ului. El examineaz numele fi"ierului "i numele serverului pentru a afla care pagin este necesar c rui furnizor de con!inut. De asemenea, examineaz adresa IP a cererii sosite "i o caut în baza sa de date pentru a determina unde este posibil s se afle utilizatorul. Cu o astfel de informa!ie, el determin care servere CDN de con!inut pot oferi utilizatorului serviciul cel mai bun. Aceast decizie este dificil deoarece serverul situat geografic cel mai aproape poate s nu fie cel mai apropiat în termeni de topolo-gie de re!ea, iar cel mai apropiat în termeni de topologie de re!ea poate fi foarte aglomerat în acel moment. Dup ce se face o alegere, cdn-server.com trimite înapoi un r spuns cu codul de stare 30# "i un antet Location cu URL-ul fi"ierului pe serverul CDN de con!inut cel mai apro-piat de client. Pentru acest exemplu, s presupunem c URL-ul este www.CDN-0420.com/ furryvideo/bears.mpg. Programul de navigare proceseaz apoi acest URL în mod normal pentru a ob!ine fi"ierul MPEG real.

Pa"ii urma!i sunt ilustra!i în fig. 7-47. Primul pas este c utarea www.furryvideo.com pentru a ob!i-ne adresa lui IP. Dup aceea, pagina HTML poate fi adus "i afi"at în mod obi"nuit. Pagina con!ine trei hiper-leg turi la cdn-server [vezi fig. 7-46(b)]. Când, s zicem, este selectat prima, este c utat (pasul 5) "i returnat (pasul 6) adresa sa de DNS. Când o cerere pentru bears.mpg este trimis la cdn-server (pasul 7), clientul este în"tiin!at c trebuie s se duc de fapt la CDN-0420.com (pasul 8). Când face acest lucru (pasul 9), i se d fi"ierul din memoria ascuns a proxy-ului (pasul #0). Proprie-tatea care face ca întregul mecanism s func!ioneze este pasul 8, serverul fals de HTTP redirectând clientul la un proxy CDN aflat aproape de client.

SEC. 7.3 WORLD WIDE WEB 593

. Caut" www.furryvideo.com 2. Este întoars" adresa IP a lui

Furry 3. Pagina HTML este cerut" de la

Furry 4. Este întoars" o pagin" HTML 5. Dup" selec!ia cu mouse-ul, se

caut" cdn-server.com 6. Este întoars" adresa IP a lui cdn-

server 7. Bears.mpg este cerut de la cdn-

server 8. Clientul este redirec!ionat c"tre

CDN-0420 9. Este cerut fi#ierul bears.mpg 0. Fi#ierul bears.mpg este întors

din memoria ascuns".

Fig. 7-47. Pa"ii în c utarea unui URL când se folose"te un CDN Serverul CDN la care este redirectat clientul este în mod tipic un proxy cu o memorie ascuns

preînc rcat cu con!inutul cel mai important. Dac totu"i cineva cere un fi"ier care nu este în memo-ria ascuns , acesta este adus de la serverul real "i dispus în memoria ascuns pentru o utilizare ulte-rioar . F când din serverul de con!inut un proxy "i nu o replic complet , CDN are abilitatea de a schimba dimensiunea discului, timpul de preînc rcare "i diver"i parametri de performan! .

Mai multe despre re!ele de livrare a con!inutului g si!i în (Hull, 2002; "i Rabinovich "i Spatscheck, 2002).

7.3.6 Web-ul f r fir

Exist un interes considerabil pentru dispozitivele mici, portabile, capabile s acceseze Web-ul printr-o leg tur f r fir. De fapt, primii pa"i în aceast direc!ie au fost deja f cu!i. Cu siguran! c vor fi o mul!ime de schimb ri în acest domeniu în anii ce vin, dar tot merit s examin m câteva din idele actuale legate de web-ul f r fir, pentru a vedea unde suntem acum "i încotro ne putem îndrep-ta. Ne vom concentra asupra primelor dou sisteme Web f r fir de scar larg care au spart pia!a: WAP "i i-mode.

WAP-The Wireless Application Protocol (Protocolul pentru aplica"ii f r fir) O dat ce Internet-ul "i telefoanele mobile au devenit lucruri comune, nu a durat mult pân când

cuiva i-a venit ideea s le combine într-un telefon mobil cu ecran încorporat pentru acces f r fir la po"ta electronic "i la Web. Acel „cineva” a fost consor!iul condus ini!ial de Nokia, Ericsson, Motorola "i phone.com (fosta Unwired Planet) "i care acum se laud cu sute de membri. Sistemul se nume"te WAP (Wireless Application Protocol - protocolul pentru aplica!ii f r fir).

Un dispozitiv WAP poate fi un telefon mobil îmbun t !it, PDA, sau calculator portabil f r servicii pentru voce. Specifica!ia le permite pe toate "i multe altele. Ideea de baz este s se folo-seasc infrastructura digital f r fir existent . Utilizatorii pot accesa o poart (eng.: gateway) WAP prin leg tura f r fir "i îi pot trimite cereri de pagini Web. Apoi, poarta controleaz memo-ria ascuns pentru pagina cerut . Dac exist , o trimite; dac nu exist , o ia de pe Internet-ul cu fir. În esen! , aceast înseamn c WAP #.0 este un sistem cu comutare de circuite cu o tax de

594 NIVELUL APLICA!IE CAP. 7

conectare pe minut relativ mare. Pentru a scurta o poveste lung , oamenilor nu le-a pl cut sa ac-ceseze Internet-ul pe un ecran mic "i pl tind la minut, astfel c WAP-ul a fost un fel de nereu"it (de"i au mai fost "i alte probleme). În orice caz, WAP-ul "i competitorul sau, i-mode (prezentat mai jos), par s convearg spre o aceea"i tehnologie, astfel c WAP 2.0 ar mai putea s fie un ma-re succes. Întrucât WAP #.0 a fost prima încercare pentru Internet-ul f r fir, merit s fie descris cel pu!in pe scurt.

WAP este de fapt o stiv de protocoale pentru accesarea Web-ului, optimizat pentru conexiuni cu o band de transfer mic folosind dispozitive f r fir ce au un procesor lent, pu!in memorie "i un ecran mic. Aceste cerin!e sunt evident diferite de cele pentru un PC standard de birou, scenariu care duce la ni"te diferen!e între protocoale. Nivelurile sunt prezentate în fig. 7-48.

Mediul aplica!iilor f"r" fir (WAE) Protocolul sesiune f"r" fir (WSP)

Protocolul tranzac!ie f"r" fir (WTP) Securitatea la nivelul transport f"r" fir (WTLS)

Protocolul pentru datagrame f"r" fir (WDP) Nivelul fizic (GSM, CDMA, D-AMPS, GPRS, etc.)

Fig. 7-48. Stiva de protocoale WAP. Nivelul cel mai de jos suport toate sistemele de telefonie mobil existent , inclusiv GSM, D-

AMPS "i CDMA. Rata de transfer pentru WAP #.0 este de 9600 bps. Deasupra acestora se afl pro-tocolul pentru datagrame, WDP (Wireless Datagram Protocol - protocolul pentru datagrame f r fir), care este de fapt UDP. Apoi vine un nivel pentru securitate, evident necesar într-un sistem f r fir. WTLS este un subset al SSL-ului de la Netscape, la care ne vom uita în cap. 8. Deasupra acestuia este un nivel tranzac!ie sigur sau nesigur , care se ocup de cereri "i r spunsuri. Acest nivel înlocu-ie"te TCP, care nu este folosit peste leg tura prin aer din motive legate de eficien! . Apoi vine un nivel sesiune, care este similar cu HTTP/#.#, dar cu câteva restric!ii "i extensii pentru motive de op-timizare. Deasupra acestuia se afl micro-programul de navigare (WAE).

Fig. 7-49. Arhitectura WAP.

SEC. 7.3 WORLD WIDE WEB 595

În afara costului, cel lalt aspect care cu siguran! a afectat acceptarea WAP-ului este faptul c nu folose"te HTML. În locul acestuia, nivelul WAE folose"te un limbaj de marcare numit WML (Wireless Markup Language – limbajul de marcare f r fir), care este o aplica!ie a XML. Drept consecin! , în principiu, un dispozitiv WAP nu poate accesa decât acele pagini care au fost converti-te la WML. Oricum, având în vedere c asta restric!ioneaz mult valoarea WAP-ului, arhitectura reclam un filtru direct de la HTML la WML pentru a cre"te mul!imea paginilor disponibile. Arhi-tectura este ilustrat în fig. 7-49.

Ca s fim corec!i, WAP-ul a fost, probabil, pu!in înaintea vremii sale. Când WAP-ul a fost lansat prima dat , XML abia era cunoscut în afara W3C "i astfel presa a anun!at lansarea sa spunând WAP NU FOLOSE$TE HTML. Un titlu mai clar ar fi fost: WAP DEJA FOLOSE$TE NOUL STAN-DARD HTML. Dar cum r ul fusese f cut, a fost greu de reparat "i WAP #.0 nu a prins niciodat . Vom rediscuta WAP-ul dup ce ne vom uita mai întâi la competitorul s u major.

I-Mode În timp ce un consor!iu multi-industrial de companii de telecomunica!ii "i de calculatoare a fost

ocupat cu construc!ia unui standard deschis folosind cea mai avansat versiune de HTML disponibi-l , alte dezvolt ri aveau loc în Japonia. Acolo, o japonez , Mari Matsunaga, a inventat o alt solu!ie pentru Web-ul f r fir numit i-mode (information mode – modul informa!ie). Ea a convins divizia „f r fir” a fostului monopol de telefonie japonez c ideea sa era corect "i în februarie #999 NTT DoCoMo (în traducere literal : Compania Japonez pentru Telefoane "i Telegraf oriunde te-ai du-ce) a lansat serviciul în Japonia. În 3 ani a avut peste 35 de milioane de abona!i japonezi, care puteau accesa peste 40.000 de situri Web speciale i-mode. În plus, a mai f cut ca majoritatea companiilor de telecomunica!ii s saliveze dup succesul s u financiar, mai ales datorit faptului c WAP nu p rea sa duc nic ieri. S vedem acum ce este i-mode "i cum func!ioneaz .

Sistemul i-mode are trei componente de baz : un nou sistem de transmisie, un nou telefon "i un nou limbaj pentru proiectarea paginilor Web. Sistemul de transmisie const în dou re!ele separate: re!eaua de telefonie mobil cu comutare de circuite existent (oarecum comparabil cu D-AMPS) "i o nou re!ea cu comutare de pachete construit în mod special pentru serviciile i-mode. Modul voce folose"te re!eaua cu comutare de circuite "i este taxat la fiecare minut de conectare. I-mode folose"te re!eaua cu comutare de pachete "i este întotdeauna activ (la fel ca la ADSL sau la cablu), astfel c nu exist taxarea pentru timpul de conectare. În locul acesteia, exist o tax pentru fiecare pachet trimis. Momentan nu este posibil s fie folosite ambele re!ele în acela"i timp.

Telefoanele arat ca ni"te telefoane mobile c rora li s-a ad ugat un mic ecran. NTT DoCoMo promoveaz masiv dispozitivele i-mode ca fiind mai degrab telefoane mobile decât terminale Web f r fir, de"i ele chiar asta sunt. De fapt, probabil c majoritatea clien!ilor nici nu sunt con"tien!i c sunt conecta!i la Internet. Ei consider dispozitivele lor i-mode ca fiind telefoane mobile cu facili-ta!i sporite. Pentru a p stra acest model de i-mode la nivel de serviciu, telefoanele nu pot fi pro-gramate de utilizatori, de"i ele con!in echivalentul unui PC din #995 "i ar putea probabil rula Win-dows 95 sau UNIX.

Când telefonul i-mode este pornit, utilizatorului îi este prezentat o list cu categoriile de servicii aprobate oficial. Sunt mult peste #000 de servicii grupate în aproximativ 20 de categorii. Fiecare ser-viciu, care este de fapt un mic sit Web i-mode, este oferit de c tre o companie independent . Cate-goriile importante din meniul oficial includ po"ta electronic , "tiri, meteo, sport, jocuri, cump r turi, h r!i, horoscop, distrac!ie, c l torii, ghiduri regionale, tonuri ale soneriei, re!ete, jocuri de noroc, servicii bancare si cota!iile bursei. Serviciul este oarecum orientat c tre adolescen!i "i oameni de 20-

596 NIVELUL APLICA!IE CAP. 7

30 de ani, care au tendin!a s se ata"eze de juc riile electronice, mai ales dac sunt în culori frumos asortate. Simplul fapt c peste 40 de companii vând tonuri ale soneriei spune ceva. Cea mai popula-r aplica!ie este po"ta electronic , care permite mesaje de pân la 500 de octe!i "i din acest motiv este v zut ca o mare îmbun t !ire fa! de SMS (Short Message Service – serviciul de mesaje scurte) care permite mesaje de numai #60 de octe!i. Jocurile sunt "i ele populare.

Sunt de asemenea peste 40.000 de situri Web i-mode, dar ele trebuie accesate mai degrab scriindu-se URL-ul lor, decât selectându-le dintr-un meniu. Dintr-un punct de vedere, lista oficial este ca un portal Internet care permite altor situri Web s fie accesate prin selec!ie în loc s li se scrie URL-ul.

NTT DoCoMo controleaz îndeaproape serviciile oficiale. Pentru a fi acceptat pe list , un servi-ciu trebuie s îndeplineasc o serie de criterii publice. De exemplu, un serviciu nu trebuie s aib o influen! negativ asupra societ !ii, dic!ionarele japonez-englez trebuie s aib suficiente cuvinte, serviciile cu tonuri pentru sonerie trebuie s adauge frecvent noi tonuri "i nici un sit nu poate s promoveze comportarea vicioas sau s se reflecte negativ asupra NTT DoCoMo (Frangle, 2002). Cele 40.000 de situri Internet pot face orice vor ele.

Modelul afacerii i-mode este atât de diferit de acela al Internet-ului conven!ional încât merit explicat. Taxa pentru abonamentul de baz i-mode este de câ!iva dolari pe lun . Cum exist o tax pentru fiecare pachet primit, abonamentul de baz include "i un mic num r de pachete. Ca alterna-tiv , clientul poate opta pentru un abonament cu mai multe pachete gratuite, cu o tax pe pachet ce scade repede pe m sur ce trece de la # MB pe lun la #0 MB pe lun . Dac pachetele gratuite sunt folosite pân la jum tatea lunii, pot fi cump rate on-line alte pachete adi!ionale.

Pentru a folosi un serviciu trebuie s te abonezi la el, fapt care se realizeaz printr-o simpl selec-!ie "i introducerea codului PIN personal. Majoritatea serviciilor oficiale cost în jur de #$-2$ pe lun . NTT DoCoMo adaug taxa la factura de telefon "i transfer 9#% celui care ofer serviciul, p strând 9%. Dac un serviciu neoficial are # milion de clien!i, trebuie sa trimit # milion de facturi de (apro-ximativ) #$ în fiecare lun . Dac acel serviciu devine oficial, NTT DoCoMo se ocup de taxare "i transfer lunar 9#0.000$ în contul din banc al serviciului. A nu avea de manipulat note de plat este un mare stimulent pentru ca cineva s devin distribuitor oficial de servicii, ceea ce genereaz veni-turi mai mari pentru NTT DoCoMo. De asemenea, fiind oficial ajungi în meniul ini!ial, ceea ce face situl t u mult mai u"or de g sit. Factura utilizatorului include convorbirile, taxele de abonamente i-mode, taxele de abonamente pentru servicii "i pachetele suplimentare.

În ciuda succesului s u masiv în Japonia, nu este de loc clar c i-mode va prinde "i în SUA "i Eu-ropa. Din unele puncte de vedere, situa!ia din Japonia este diferit de aceea din Vest. În primul rând, majoritatea poten!ialilor clien!i din Vest (spre exemplu adolescen!ii, studen!ii "i oamenii de afaceri) au deja un PC cu ecran mare acas "i aproape sigur o conexiune la Internet de cel pu!in 56 Kbps, adesea mult mai rapid . În Japonia, pu!ini oameni au PC-uri conectate la Internet acas , pe de o parte din cauza lipsei de spa!iu, dar "i din cauza taxelor exorbitante ale NTT pentru serviciile de telefonie local (undeva în jur de 700$ pentru instalarea unei linii "i #.50$ pe or pentru convorbiri locale). Pentru majoritatea utilizatorilor, i-mode este singura lor conexiune la Internet.

În al doilea rând, locuitorii din Vest nu sunt obi"nui!i sa pl teasc #$ pe lun pentru a accesa situl Web al CNN, #$ pe lun pentru a accesa situl Yahoo, #$ pe lun pentru a accesa situl Google "i a"a mai departe, f r s mai men!ion m câ!iva dolari pentru fiecare MB desc rcat. Majoritatea distribu-itorilor de Internet din Vest au acum o tax fix pe lun , independent de utilizarea real , în mare m sur ca r spuns la cererea clien!ilor.

SEC. 7.3 WORLD WIDE WEB 597

În al treilea rând, pentru mul!i japonezi, perioada de vârf în care folosesc i-mode este perioada în care se deplaseaz la sau de la serviciu sau "coal în tren sau în metrou. În Europa, mai pu!ini oa-meni se deplaseaz cu trenul decât în Japonia, iar în SUA abia dac se deplaseaz câ!iva. Folosirea i-mode acas , lâng un calculator cu un monitor de #7 !oli, conexiune ADSL de # Mbps "i to!i megaocte!ii gratui!i, nu se prea justific . Cu toate acestea, nimeni nu a prezis imensa popularitate a telefoanelor mobile în general, astfel c i-mode mai poate înc s -"i g seasc o ni" în Vest.

A"a cum am men!ionat mai sus, telefoanele i-mode folosesc re!eaua cu comutare de circuite existent pentru voce "i o nou re!ea cu comutare de pachete pentru date. Re!eaua pentru date se bazeaz pe CDMA "i transmite pachete de #28 de octe!i la 9600 bps. O diagram a re!elei este dat în fig. 7-50. Telefoanele folosesc LTP (Lightweight Transport Protocol – protocol simplificat de transport) pe o leg tur prin aer pân la o poart pentru conversie de protocoale. Poarta are o cone-xiune de band larg prin fibr optic la serverul i-mode, care este conectat la toate serviciile. Când utilizatorul selecteaz un serviciu din meniul oficial, cererea este trimis serverului i-mode, care !ine majoritatea paginilor în memoria ascuns pentru a-"i spori performan!a. Cererile pentru situri care nu sunt în meniul oficial ocolesc serverul i-mode "i merg direct pe Internet.

Fig. 7-50. Structura re!elei de date i-mode, ar tând protocoalele de transport. Telefoanele actuale au procesoare care func!ioneaz la aproximativ #00 MHz, câ!iva megaocte!i

de memorie ROM rapid , poate # MB RAM "i un ecran mic încorporat. I-mode necesit un ecran de cel pu!in 72x94 pixeli, dar unele dispozitive mai mari au chiar #20x#60 pixeli. Ecranele au de obi-cei culori pe 8 bi!i, ceea ce permite 256 de culori. Aceasta nu este suficient pentru fotografii, dar este adecvat pentru desenarea de linii "i imagini animate simple. Cum nu exist mouse, navigarea pe ecran se face cu s ge!ile direc!ionale.

Modulul de interac!iune cu utilizatorul Elemente de intrare Interpretor cHTML Java

Coordonator simplu de ferestre Comunica!ie de re!ea

Sistem de operare în timp real

Fig. 7-5#. Structura aplica!iilor i-mode.

598 NIVELUL APLICA!IE CAP. 7

Structura aplica!iilor este prezentat în fig. 7-5#. Nivelul cel mai de jos con!ine un sistem simplu de operare în timp real pentru controlul echipamentelor. Apoi vine un modul pentru comunicarea pe re!ea, folosind protocolul proprietar al NTT DoCoMo, LTP. Deasupra acestuia vine un simplu coordonator de ferestre care se ocup de text "i de imaginile simple (fi"iere GIF). Cu ecranele având doar aproximativ #20x#60 de pixeli în cel mai bun caz, nu sunt prea multe de coordonat.

Al patrulea nivel con!ine interpretorul de pagini Web (de exemplu, programul de navigare). I-mode nu folose"te întregul HTML, ci numai un subset al acestuia, numit cHTML (compact HTML – HTML compact), bazat în mare pe HTML #.0. Acest nivel permite de asemenea "i aplica!ii ajut -toare "i elemente de intrare, la fel cum fac "i programele de navigare pentru PC-uri. O aplica!ie aju-t toare standard este un interpretor pentru o versiune pu!in modificat a JVM.

La nivelul cel mai înalt se afl modulul de interac!iune cu utilizatorul, care controleaz comuni-ca!ia cu acesta.

S ne uit m acum mai în detaliu la cHTML. Dup cum am men!ionat, este aproximativ HTML #.0, cu câteva omisiuni "i câteva extensii pentru a fi folosit cu telefoane mobile. A fost trimis la W3C pentru standardizare, dar W3C nu a ar tat interes pentru el, a"a c probabil va r mâne un produs privat.

Majoritatea etichetelor de baz HTML sunt permise, incluzând aici <html>, <head>, <title>, <body>, <hn>, <center>, <ul>, <ol>, <©>, <li>, <br>, <p>, <hr>, <img>, <form> "i <input>. Etichetele <b> "i <i> nu sunt permise.

Eticheta <a> este permis pentru legarea la alte pagini, dar cu schema adi!ional tel pentru formarea numerelor de telefon. Dintr-un punct de vedere tel este analog cu mailto. Când o hiper-leg tur folosind schema mailto este selectat , programul de navigare deschide un formular pentru a trimite un mesaj electronic c tre destina!ia marcat în leg tur . Când este selectat o hiper-leg tur cu schema tel, programul de navigare formeaz num rul de telefon. Spre exemplu, o agend de tele-fon poate con!ine imagini simple ale unor persoane. Când se selecteaz una dintre acestea, telefonul îl va suna pe el sau pe ea. RFC 2806 prezint URL-urile pentru telefoane.

Programul de navigare cHTML este limitat în alte feluri. El nu suport JavaScript, cadre, foi de stil, culori sau imagini de fundal. De asemenea, nu suport imagini JPEG, deoarece acestea se de-comprim în prea mult timp. Sunt permise applet-urile Java, dar sunt (în prezent) limitate la #0 KB din cauza vitezei mici de transmisie a leg turii prin aer.

De"i NTT DoCoMo a eliminat câteva etichete HTML, a "i ad ugat unele noi. Eticheta <blink> face ca textul s se afi"eze "i apoi s dispar . De"i pare ciudat s interzici eticheta <b> (motivând c siturile Web nu ar trebui s se ocupe de prezentarea con!inutului) "i apoi s adaugi <blink> care nu se refer decât la prezentarea con!inutului, asta au f cut. O alt etichet nou este <marquee>, care î"i deplaseaz con!inutul pe ecran precum un monitor de burs .

Un element nou este atributul align al etichetei <br>. Este necesar, deoarece pentru un ecran ce are de obicei 6 rânduri de câte #6 caractere, exist un mare pericol ca rândurile s fie rupte în dou , ca în fig. 7-52(a). Align ajut la reducerea acestei probleme "i conduce la ceva ce seam n mai de-grab cu fig. 7-52(b). Este interesant s not m c limba japonez nu sufer când cuvintele sunt rupte între linii. Pentru textul kanji, ecranul este împ r!it într-un caroiaj dreptunghiular de celule de di-mensiune 9x#0 pixeli sau #2x#2 pixeli, în func!ie de caracterele suportate. Fiecare celul con!ine exact un caracter kanji, care este echivalentul unui cuvânt în englez . Desp r!irea mai multor cuvinte pe mai multe linii este întotdeauna admis în japonez .

SEC. 7.3 WORLD WIDE WEB 599

(a) (b)

Fig. 7-52. Lewis Caroll încape într-un ecran de #6x6. De"i limba japonez are zeci de mii de kanji, NTT DoCoMo a inventat #66 noi, numite emoji, cu

un factor de amuzament ridicat – de fapt, ni"te pictograme precum zâmbitorii din fig. 7-6. Acestea includ simboluri pentru semnele astrologice, bere, hamburger, parc de amuzament, zi de na"tere, telefon mobil, câine, pisica, Cr ciun, inim r nit , s rut, stare de spirit, somnolen! , "i desigur, unul semnificând ceva simpatic.

Un alt nou element este posibilitatea de a permite utilizatorilor s selecteze hiper-leg turi folo-sind tastatura, proprietate cu siguran! important pentru un calculator f r mouse. Un exemplu despre cum este folosit acest atribut este prezentat în fi"ierul cHTML din fig. 7-53.

<html> <body> <h > Selecteaz" o op!iune </h > <a href=”messages.chtml” accesskey=” ”> Verific" po#ta vocal" </a> <br> <a href=”mail.chtml” accesskey=”2”> Verific" po#ta electronic" </a> <br> <a href=”games.chtml” accesskey=”3”> Joac" un joc </a> </body> </html>

Fig. 7-53. Un exemplu de fi"ier cHTML. De"i partea client este oarecum limitat , serverul i-mode este un calculator de-a dreptul r sun -

tor, cu toate soneriile "i fluierele obi"nuite. El suport CGI, Perl, PHP, JSP, ASP "i tot ceea ce serverele Web suport de obicei.

Caracteristica WAP I-mode Ce este Stiv" de protocoale Serviciu Dispozitiv Telefon, PDA, calculator portabil Telefon Tipul de acces Prin telefon Tot timpul activ Re!eaua de suport Cu comutare de circuite Doua: circuite + pachete Rata de transfer 9600 bps 9600 bps Ecranul Monocrom Color Limbajul de marcare WML (aplica!ie XML) cHTML Limbajul script WMLScript Nici unul Taxarea utilizatorilor Pe minut Pe pachet Plata pentru cump"r"turi Cu cartea de credit Pe factura de telefon Pictograme Nu Da Standardizare Standard deschis al forumului WAP Proprietar NTT DoCoMo Locul de utilizare Europa, Japonia Japonia Utilizatorul tipic Omul de afaceri Adolescent"

Fig. 7-54. O compara!ie între prima genera!ie de WAP "i i-mode.

Veni vremea când morsa spuse c v a vorbi despre m ulte lucruri. De spre pantofi !i vapoare !i despr

Veni vremea când morsa spuse c va vorbi despre multe lucruri. Despre pantofi !i vapoare !i

600 NIVELUL APLICA!IE CAP. 7

O compara!ie rapid între WAP "i i-mode a"a cum au fost ele implementate în sistemele de pri-ma genera!ie este dat în fig. 7-54. În timp ce câteva diferen!e pot p rea mici, adesea ele sunt impor-tante. Spre exemplu, cei de #5 ani nu au c r!i de credit, astfel c posibilitatea de a cump ra lucruri prin comer!ul electronic "i de a fi taxa!i abia când primesc nota de plat la telefon reprezint un sti-mulent pentru interesul lor asupra sistemului.

Pentru alte informa!ii despre i-mode citi!i (Frengle, 2002; "i Vacca, 2002).

Web-ul f r fir de genera"ia a doua WAP #.0, bazat pe standarde recunoscute interna!ional, trebuia s fie o unealt important pen-

tru oamenii cu afaceri în derulare. A e"uat. I-mode a fost o juc rie electronic pentru adolescen!ii japonezi folosind numai elemente proprietare. A fost un mare succes. Ce s-a întâmplat dup asta? Fiecare parte a înv !at câte ceva din Web-ul f r fir de prim genera!ie. Consor!iul WAP a înv !at c important este con!inutul. S nu ai un num r mare de situri Web care î!i în!eleg limbajul de mar-care este fatal. NTT DoCoMo a înv !at c un sistem închis, proprietar, strâns legat de dispozitive mici "i de cultura japonez nu este un bun produs pentru export. Concluzia pe care ambele p r!i au tras-o este c pentru a convinge un num r mare de situri Web s -"i pun con!inutul în formatul t u, trebuie s ai un limbaj de marcare deschis, stabil "i care este universal acceptat. R zboaiele asupra formatelor nu sunt bune pentru progres.

Ambele servicii sunt aproape de a intra în cea de-a doua genera!ie a tehnologiei Web f r fir. WAP 2.0 a venit primul, a"a c îl vom folosi pe acesta ca exemplu. WAP #.0 avea unele lucruri bune "i acestea au fost continuate. Unul dintre acestea este c WAP poate folosi o mul!ime de re!ele dife-rite. Prima genera!ie folosea re!ele cu comutare de circuite, dar re!elele cu comutare de pachete au fost întotdeauna o alternativ "i înc mai sunt. Sistemele de a doua genera!ie vor folosi probabil co-mutarea de pachete, spre exemplu, GPRS-ul. Un altul este c WAP a fost ini!ial proiectat pentru a suporta o mare varietate de dispozitive, de la telefoane mobile pân la calculatoare portabile puter-nice, "i înc mai este.

WAP 2.0 are "i câteva caracteristici noi. Cele mai importante sunt:

#. Modelul de livrare a paginilor (push), al turi de cel de cerere (pull). 2. Suport pentru integrarea telefoniei în aplica!ii. 3. Mesageria multimedia. 4. Includerea a 264 de pictograme. 5. Interfa!a cu un dispozitiv de memorare. 6. Suport pentru plug-in-uri în browser.

Modelul de cerere este bine cunoscut: clientul cere o pagin "i o prime"te. Modelul de livrare (push) suport livrarea datelor f r a fi cerute, precum !inerea la curent cu cota!iile la burs sau aler-tele de trafic.

Vocea "i datele încep s se contopeasc , iar WAP 2.0 le suport într-o mul!ime de moduri. Am v zut un astfel exemplu mai devreme, la capabilitatea i-mode-ului de a lega o iconi! sau un text de pe ecran cu un num r de telefon ce trebuie format. Odat cu po"ta electronic "i telefonia este su-portat "i mesageria multimedia.

Marea popularitate a emoji-ului i-mode a stimulat consor!iul WAP s inventeze 264 emoji pro-prii. Categoriile includ animale, utilaje casnice, îmbr c minte, emo!ii, mânc ruri, corpul uman, ge-nuri, h r!i, muzic , plante, sporturi, timp, unelte, vehicule, arme "i meteo. Destul de interesant este faptul c standardul pur "i simplu nume"te fiecare pictogram ; nu d harta de pixeli real , probabil

SEC. 7.3 WORLD WIDE WEB 60#

de team c reprezentarea într-o cultur a „somnolen!ei” sau a „îmbr !i" rii” s nu insulte alt cul-tur . I-mode nu a avut aceast problem fiind îndreptat c tre o singur !ar .

A oferi o interfa! de stocare nu înseamn c fiecare telefon cu WAP 2.0 va veni cu un mare disc fix. Memoria ROM rapid este, de asemenea, un dispozitiv de stocare. O camer f r fir cu facilit !i WAP ar putea folosi memoria ROM rapid pentru stocarea temporar a imaginii înainte de a transmite cele mai bune cadre pe Internet.

În fine, plug-in-urile pot extinde capabilit !ile programului de navigare. Este oferit, de asemenea, un limbaj scriptic.

Mai multe diferen!e tehnice sunt de asemenea prezente în WAP 2.0. Dou dintre cele mai im-portante se refer la stiva de protocoale "i la limbajul de marcare. WAP 2.0 continu s suporte ve-chea stiv de protocoale din fig. 7-48, dar de asemenea suport "i stiva standard a Internet-ului cu TCP "i ©/#.0. Cu toate acestea, patru schimb ri minore (dar compatibile) au fost aduse TCP-ului (pentru a simplifica codul): (#) Folosirea unei ferestre fixe de 64 KB, (2) lipsa unui start lent, (3) MTU-ul maxim de #500 de octe!i "i (4) un algoritm de retransmisie u"or modificat. TLS este proto-colul pentru securitatea la nivel transport standardizat de IETF; îl vom examina în Cap. 8. Mai multe dispozitive ini!iale vor con!ine probabil ambele stive, cum se arat în fig. 7-55.

XHTML WSP © WTP TLS

WTLS TCP WDP IP

Nivelul fizic Nivelul fizic Stiva de protocoale

WAP .0 Stiva de protocoale

WAP 2.0

Fig. 7-55. WAP 2.0 suport dou stive de protocoale. Cealalt diferen! tehnic fa! de WAP #.0 este limbajul de marcare. WAP 2.0 suport

XHTML Basic, care este potrivit pentru dispozitivele mici f r fir. Întrucât NTT DoCoMo a fost de asemenea de acord s suporte acest subset, proiectan!ii de situri Web pot folosi acest format "tiind c paginile lor vor func!iona atât pe Internet-ul fix cât "i pe toate dispozitivele f r fir. Aceste decizii vor încheia r zboaiele legate de formatul limbajului de marcare care au împiedicat dezvolta-rea industriei Web f r fir.

Modulul Obligatoriu? Func!ia Exemple de etichete Structur" Da Structura documentelor body, head, html, title Text Da Informa!ii br, code, dfn, em, hn, kbd, p, strong Hiper-text Da Hiper-leg"turi a Liste Da Liste de articole dl, dt, dd, ol, ul, li Formulare Nu Formulare de completat form, input, label, option, textarea Tabele Nu Tabele dreptunghiulare caption, table, td, th, tr Imagini Nu Imagini img Obiecte Nu Applet-uri, har!i, etc. object, param Meta-informa!ii Nu Informa!ii suplimentare meta Leg"turi Nu Similar cu <a> link Baz" Nu URL-ul de start base

Fig. 7-56. Modulele "i etichetele din XHTML Basic.

602 NIVELUL APLICA!IE CAP. 7

Câteva cuvinte despre XHTML Basic sunt poate necesare. Acesta este gândit pentru telefoane mobile, televiziune, PDA-uri, dispozitive pentru vânzarea automat , pagere, ma"ini, jocuri mecanice "i chiar ceasuri. Din acest motiv nu suport foi de stil, scripturi sau cadre, îns cunoa"te majoritatea etichetelor standard. Acestea sunt grupate în ## module. Unele sunt obligatorii; altele sunt op!iona-le. Toate sunt definite în XML. Modulele "i câteva exemple de etichete sunt listate în fig. 7-56. Nu baleiat toate exemplele de etichete, îns mai multe informa!ii se pot g si la www.w3.org.

În ciuda în elegerii asupra folosirii XHTML Basic, o amenin are pânde!te WAP !i i-mode: 802."". A doua genera ie a Web-ului f#r# fir ar trebui s# func ioneze la 384 Kbps, mult mai mult decât cei 9600 bps ai primei genera ii, dar !i mult mai pu in decât cei "" Mbps sau 54 Mbps oferi i de 802."". Fire!te, 802."" nu este omniprezent, dar pe m#sur# ce mai multe restaurante, hoteluri, ma-gazine, companii, aeroporturi, sta ii de autobuz, muzee, universit# i, spitale !i alte organiza ii decid s# instaleze sta ii de baz# pentru angaja ii !i clien ii lor, se va ajunge probabil la o suficient# acoperire în zonele urbane astfel încât oamenii s# doreasc# s# mearg# pentru o cafea sau pentru a trimite un mesaj electronic la o braserie aflat# la câteva blocuri distan #, dar cu 802."" instalat. Firmele pot ad#uga automat embleme 802."" al#turi de emblemele care arat# ce c#r i de credit accept# !i asta din acela!i motiv: pentru a atrage clien i. H#r ile ora!elor (fire!te, desc#rcabile) pot marca zonele acoperite cu verde !i pe cele neconectate cu ro!u, astfel ca oamenii s# se poat# deplasa de la o sta ie de baz# la alta, a!a cum nomazii se mutau de la o oaz# la alta în de!ert.

De!i braseriile pot instala repede sta ii de baz# 802."", fermierilor probabil c# nu le va fi la fel de u!or, deci acoperirea va fi zonal# !i limitat# la zonele centrale ale ora!elor, din cauza r#spândirii limi-tate a semnalului 802."" (câteva sute de metri în cel mai bun caz). Aceasta poate duce la dispozitive f#r# fir cu dou# moduri, care folosesc 802."" dac# pot prinde un semnal !i recurg la WAP dac# nu.

7.4 MULTIMEDIA

De!i Web-ul f#r# fir este o tehnologie nou# si incitant#, ea nu este singura. Pentru mul i, multi-media reprezint# sarea !i piperul re elelor de calculatoare. Min ile ascu ite v#d imense provoc#ri tehnice în furnizarea de video (interactiv) la cerere în fiecare cas#. Gulerele albe v#d un profit imens în acestea. Întrucât multimedia necesit# o l# ime de band# mare, este destul de greu s# fie f#cut# s# func ioneze prin conexiuni fixe. Chiar !i calitatea video VHS prin leg#tura f#r# fir este la distan # de câ iva ani, a!a c# discu ia noastr# se va axa asupra sistemelor conectate.

Literal, multimedia înseamn# dou# sau mai multe media. Dac# editorul acestei c#r i voia s# se al#ture interesului la mod# despre multimedia, el putea anun a c# lucrarea folose!te tehnologia multimedia. În fond, aceasta con ine dou# media: textul !i grafica (desenele). Cu toate acestea, atunci când majoritatea oamenilor se refer# la multimedia, de fapt ei se refer# la combinarea între dou# sau mai multe media continue (continuous media), adic# media care trebuie s# se desf#!oare într-un interval bine definit, de obicei folosind interac iunea cu utilizatorul. În practic#, cele dou# media sunt audio !i video, adic# sunete plus filme.

Oricum, mul i vorbesc adesea despre sunetele audio pure, precum telefonia prin Internet sau ra-dio-ul prin Internet, ca !i cum ar fi tot multimedia, ceea ce cu siguran # nu sunt. De fapt, un termen mai bun ar fi fluxuri media (streaming media), dar vom urma mul imea !i vom considera sunetele audio în timp real ca fiind tot multimedia. În sec iunile urm#toare vom examina modul în care calcu-

SEC. 7.4 MULTIMEDIA 603

latoarele proceseaz# datele audio !i video, cum le comprim#, !i câteva aplica ii pentru re ele ale acestor tehnologii. Pentru o tratare cuprinz#toare (trei volume) a datelor multimedia în re ele, citi i (Steinmetz si Nahrstedt, 2002; Steinmetz si Nahrstedt, 2003a; !i Steinmetz !i Nahrstedt, 2003b).

7.4. Introducere in sunetele digitale

O und# (sunet) audio este o und# cu o dimensiune acustic# (presiune). Atunci când o und# acus-tic# intr# în ureche, pavilionul vibreaz#, f#când ca oasele urechii interne s# vibreze o dat# cu el, transmi ând vibra ii nervoase creierului. Aceste vibra ii sunt percepute drept sunete de c#tre ascult#-tor. Într-un mod similar, atunci când o und# acustic# love!te un microfon, acesta genereaz# un sem-nal electric, reprezentând amplitudinea sunetului ca func ie de timp. Reprezentarea, procesarea, memorarea, !i transmisia acestor semnale audio constituie p#r ile majore ale studiului sistemelor multimedia.

Intervalul de frecven # pentru urechea uman# este cuprins între 20 Hz !i 20.000 Hz, de!i unele animale, în special câinii, pot percepe frecven e mai înalte. Urechea percepe sunetele în mod loga-ritmic, a!a încât raportul a dou# semnale cu puterile A !i B este exprimat conven ional în dB (deci-beli) în concordan # cu formula:

dB = "0 log"0 (A/B)

Dac# definim limita inferioar# de audibilitate (o presiune de circa 0,0003 dyne/cm2) pentru o un-d# sinusoidal# de " KHz ca 0 dB, o conversa ie obi!nuit# este în jur de 50 dB !i pragul de durere este în jur de "20 dB, un interval dinamic cu un factor de " milion. Pentru a evita orice confuzie, A !i B de mai sus sunt numite amplitudini. Dac# trebuie s# folosim nivelul puterii, care este propor ional cu p#tratul amplitudinii, coeficientul logaritmului va fi "0, nu 20.

Urechea este surprinz#tor de sensibil# la varia ii ale sunetului care dureaz# doar câteva milise-cunde. Ochiul, în schimb, nu poate observa schimb#rile de nivel ridicat care dureaz# doar câteva milisecunde. Rezultatul acestei observa ii const# în faptul c# o varia ie de numai câteva milisecunde din timpul unei transmisii multimedia afecteaz# calitatea sunetului perceput mai mult decât afectea-z# calitatea imaginii percepute.

Fig. 7-57. (a) O und# sinusoidal#. (b) E!antionarea undei sinusoidale. (c) Cuantificarea e!antioanelor pe 4 bi i.

604 NIVELUL APLICA!IE CAP. 7

Undele audio pot fi convertite în form# numeric# de un ADC (Analog Digital Convertor – con-vertor analog numeric). Un ADC prime!te o tensiune electric# la intrare !i genereaz# un num#r binar la ie!ire. În fig. 7-57(a) se prezint# un exemplu al unei unde sinusoidale. Pentru reprezentarea acestui semnal în form# digitizat#, putem s#-l e!antion#m la fiecare T secunde, a!a cum pute i ob-serva prin în#l imea barelor în fig. 7-57(b). Dac# o und# sonic# nu este o und# pur sinusoidal#, ci o superpozi ie liniar# de unde sinusoidale, unde cea mai mare component# a frecven ei prezente este f, atunci teorema lui Nyquist (vezi cap. 2) spune c# este suficient s# se e!antioneze la frecven a 2f. E!antionând mai des, nu se ob ine nimic în plus, deoarece frecven ele mai înalte pe care discretiza-rea le poate detecta nu sunt prezente.

E!antioanele digitale nu sunt niciodat# exacte. E!antioanele pe 3-bi i din fig. 7-57© permit doar opt valori, de la -",00 la +",00 în pa!i de 0,25. Un e!antion pe 8-bi i permite 256 valori distincte. Un e!antion pe "6-bi i admite 65.536 valori distincte. Eroarea introdus# de num#rul finit de bi i de e!antionare se nume!te zgomot de cuantizare (quantization noise). Dac# este foarte mare, urechea îl detecteaz#.

Dou# exemple bine cunoscute de sunete e!antionate sunt telefonul !i compact discurile audio. Modularea impulsului în cod, folosit# în sistemul telefonic, utilizeaz# e!antioane pe 8 bi i de 8000 de ori pe secund#. În America de Nord !i Japonia, 7 bi i sunt pentru date, iar unul pentru control; în Europa to i cei 8 bi i sunt pentru date. Acest sistem furnizeaz# o vitez# a datelor de 56.000 bps sau 64.000 bps. Cu doar 8000 de e!antioane/sec, frecven ele peste 4 KHz sunt pierdute.

CD-urile audio sunt digitale, cu o rat# de e!antionare de 44."00 e!antioane/sec, suficient# pentru a putea capta frecven ele pân# la 22.050 Hz, care sunt bune pentru oameni, dar rele pentru iubitorii canini de muzic#. E!antioanele au fiecare "6 bi i !i sunt liniare în domeniul amplitudinii. Observa i c# e!antioanele pe "6-bi i permit doar 65.536 valori distincte, chiar dac# limita dinamic# a urechii este de " milion atunci când se m#soar# în unit# i de cel mai mic sunet audibil. Astfel, folosind doar "6 bi i pe e!antion, se introduce un zgomot de cuantizare (de!i întreaga rat# dinamic# nu este acope-rit# – CD-urile se presupune c# nu r#nesc). Cu 44."00 e!antioane/sec pe "6 bi i fiecare, un CD audio are nevoie de o l#rgime de band# de 705,6 Kbps pentru mono !i de ",4"" Mbps pentru stereo. De!i acesta este mai sc#zut decât necesit# video-ul (vezi mai jos), poate acapara aproape un canal întreg T" pentru transmiterea necomprimat# a sunetului stereo de calitate pentru CD în timp real.

Sunetele digitizate pot fi procesate u!or de calculatoare, prin programe. Exist# zeci de programe pentru calculatoarele personale care permit utilizatorilor s# înregistreze, s# afi!eze, s# editeze, s# amestece !i s# memoreze undele sonore de la surse multiple. Practic, toate înregistr#rile, edit#rile de sunete profesioniste sunt în prezent digitale.

Muzica este desigur un caz special de audio, dar unul important. Alt caz important este discursul. Discursul uman tinde s# fie între limitele de 600 Hz !i 6000 Hz. Discursul este format din vocale !i consoane, care au propriet# i diferite. Vocalele sunt produse atunci când coardele vocale sunt neob-struc ionate, producând rezonan e ale c#ror frecven e fundamentale depind de dimensiunea !i for-ma sistemului vocal !i de pozi ia limbii vorbitorului !i a gurii. Aceste sunete sunt aproape periodice pentru intervale în jur de 30 ms. Consoanele sunt produse atunci când coarda vocal# este par ial blocat#. Aceste sunete sunt mai pu in regulate decât vocalele.

Câteva sisteme de generare !i transmisie de voce pot folosi modelele de sisteme vocale pentru a reduce vocea la câ iva parametri (de exemplu, m#rimile !i formele diferitelor cavit# i), mai degrab# decât de a e!antiona forma de und# pentru voce. Oricum, modul de func ionare al acestor codoare de voce dep#!e!te domeniul acestei c#r i.

SEC. 7.4 MULTIMEDIA 605

7.4.2 Compresia audio

Pentru a ob ine calitatea unui CD audio este necesar# o l# ime a benzii de transmisie de ".4"" Mbps, dup# cum tocmai am v#zut. Evident, pentru a face practic# transmisia pe Internet este nece-sar# o compresie substan ial#. Mul i algoritmi de compresie audio au fost dezvolta i din acest motiv. Probabil cel mai popular dintre ele este MPEG audio, care are trei nivele (variante), dintre care MP3 (MPEG audio layer 3 – MPEG audio de nivelul 3) este cel mai puternic !i mai cunoscut. Pe Internet sunt disponibile mari cantit# i de muzic# în format MP3, nu toate legale, fapt care a generat numeroase procese venite din partea arti!tilor !i a proprietarilor de drepturi de autor. MP3 apar ine p#r ii audio a standardului MPEG pentru compresia video. Vom discuta despre compresia video mai târziu în acest capitol; s# vedem acum compresia audio.

Compresia audio poate fi f#cut# în dou# moduri. Prin codificarea formei de und" (waveform coding), semnalul este transformat (matematic) Fourier în componentele sale în frecven #. Fig. 2-"(a) arat# un exemplu de func ie de timp !i amplitudinile sale Fourier. Apoi, amplitudinea fie-c#rei componente este codificat# minimal. Scopul este de a reproduce exact forma de und# la cel#lalt cap#t folosind cât mai pu ini bi i cu putin #.

Cealalt# metod#, codificarea perceptiv" (eng. Perceptual coding), exploateaz# unele caracte-ristici ale sistemului auditiv uman pentru a codifica semnalul astfel încât s# sune la fel pentru ascult#torul uman, chiar dac# arat# destul de diferit pe osciloscop. Codificarea perceptiv# se ba-zeaz# pe !tiin a psihoacusticii – modul în care oamenii percep sunetul. MP3 se bazeaz# pe codi-ficarea perceptiv#.

Proprietatea de baz# a codific#rii perceptive este c# unele sunete pot masca alte sunete. Imagi-na i-v# c# transmite i în direct un concert de flaut într-o zi c#lduroas# de var#. Apoi, dintr-o dat#, un grup de muncitori din apropiere î!i pornesc ciocanele pneumatice !i încep s# distrug# strada. Nimeni nu mai poate auzi flautul. Sunetele sale au fost mascate de ciocanele pneumatice. Din punct de ve-dere al transmisiei, acum este suficient s# codific#m doar banda de frecven e folosit# de ciocanele pneumatice, deoarece ascult#torii oricum nu pot auzi flautele. Acest procedeu se nume!te mascarea frecven#ei (frequency masking) – proprietatea unui sunet de volum înalt dintr-o band# de frecven # de a ascunde un sunet mai slab dintr-o alt# band# de frecven # !i care s-ar fi auzit în absen a sunetu-lui de volum înalt. De fapt, chiar !i dup# ce ciocanele pneumatice înceteaz#, flautul nu se va putea auzi pentru o scurt# perioad# de timp, deoarece urechile opresc amplificarea sunetelor când acestea încep !i au nevoie de o perioad# de timp finit# pentru a o reporni. Acest efect se nume!te mascare temporal" (temporal masking).

Pentru a cuantifica aceste efecte, imagina i-v# experimentul ". O persoan# dintr-o camer# în care este lini!te î!i pune c#!tile conectate la placa de sunet a unui calculator. Calculatorul genereaz# o und# sinusoidal# nedistorsionat# la "00 Hz la o putere mic# ini ial dar cresc#toare în timp. Persoana este instruit# s# apese pe o tast# când aude sunetul. Calculatorul înregistreaz# nivelul curent al pute-rii !i repet# experimentul la 200 Hz, 300 Hz !i toate celelalte frecven e pân# la limita auzului uman. Când se face o medie pentru mai mul i oameni, un grafic al înregistr#rilor puterii necesare unui su-net pentru a fi auzit arat# ca cel din fig. 7-58(a). O consecin # direct# a acestei curbe este c# nu tre-buie s# codific#m frecven ele a c#ror putere se afl# sub pragul auzului. De exemplu, dac# puterea la "00 Hz ar fi fost 20 dB în fig. 7-58(a), ar fi putut fi omis# din sunetul final f#r# o pierdere sesizabil# de calitate, deoarece 20 dB la "00 Hz sunt sub nivelul de audibilitate.

606 NIVELUL APLICA!IE CAP. 7

Fig. 7-58. (a) Pragul de audibilitate ca func ie de frecven #. (b) Efectul de mascare.

Acum imagina i-v# experimentul 2. Calculatorul ruleaz# din nou experimentul ", dar de aceast#

dat# cu o und# sinusoidal# de amplitudine constant# !i frecven a "50 Hz, suprapus# peste frecven a de test. Descoperim c# pragul de audibilitate pentru frecven e de aproximativ "50 Hz este ridicat, a!a cum arat# !i fig. 7-58(b).

Consecin a acestei noi observa ii este c#, pe m#sur# ce descoperim care semnale sunt mascate de alte semnale din benzi de frecven # apropiate, putem omite mai multe frecven e din semnalul codifi-cat, economisind bi i. În fig. 7-58, semnalul de "25 Hz poate fi în întregime omis din semnalul de ie!ire !i nimeni nu va putea sesiza diferen a. Chiar !i dup# ce un semnal puternic dintr-o band# de frecven # se opre!te, cunoa!terea propriet# ilor sale de mascare temporal# ne permit s# continu#m s# omitem frecven ele mascate pentru un anumit interval de timp pân# când urechea î!i revine. Elementul de baz# al MP3 este transformarea Fourier a sunetului pentru a ob ine puterea pentru fiecare frecven # !i apoi transmiterea numai a frecven elor nemascate, codificându-le în cât mai pu- ini bi i cu putin #.

Cunoscând aceste informa ii, putem acum s# vedem cum se face codificarea. Compresia audio se face e!antionând forma de und# la 32 KHz, 44." KHz sau 48 KHz. E!antionarea se poate face pe unul sau dou# canale, în una din cele patru configura ii:

". Monofonic (un singur flux de intrare). 2. Dual monofonic (spre exemplu, o coloan# sonor# in englez# !i una în japonez#). 3. Stereo disjunct (fiecare canal comprimat separat). 4. Stereo unit (se exploateaz# la maxim redundan a inter-canale).

Mai întâi se alege rata bi ilor de la ie!ire. MP3 poate comprima un CD rock’n’roll stereo pân# la minim 96 Kbps cu pierderi de calitate greu perceptibile, chiar !i pentru fanii rock’n’roll care nu au probleme cu auzul. Pentru un concert de pian sunt necesari cel pu in "28 Kbps. Acestea difer# deoa-rece raportul semnal-zgomot pentru rock’n’roll este mult mai mare fa # de cel al unui concert de pian (cel pu in din punct de vedere ingineresc). Este de asemenea posibil s# alegem rate de ie!ire mai mici acceptând o pierdere în calitate.

Apoi e!antioanele sunt procesate în grupuri de ""52 (lungi de aproximativ 26 ms). Fiecare grup es-te întâi trecut prin 32 de filtre digitale pentru a ob ine 32 de benzi de frecven #. În acela!i timp, intrarea

SEC. 7.4 MULTIMEDIA 607

este dat# unui model psiho-acustic care determin# frecven ele mascate. Apoi, fiecare din cele 32 de benzi de frecven # este transformat# în continuare pentru a ob ine o rezolu ie spectral# mai fin#.

În faza urm#toare, bugetul de bi i disponibil este împ#r it între benzi, cât mai mul i bi i aloca i pentru benzile cu puterea spectral# nemascat# mai mare, cât mai pu ini bi i aloca i pentru benzile nemascate cu puterea spectral# mai mic# !i nici un bit alocat pentru benzile mascate. În final, bi ii sunt codifica i folosind codificarea Huffman, care asigneaz# coduri scurte numerelor care apar frec-vent !i coduri lungi celor care apar rar.

În realitate mai sunt multe de spus. Se folosesc de asemenea multe tehnici pentru reducerea zgomotelor, antialiasing !i exploatarea redundan ei inter-canale, dac# este posibil, dar acestea sunt în afara domeniului acestei c#r i. O introducere matematic# mai formal# în aceast# opera ie este dat# în (Pan, "995).

7.4.3 Fluxuri audio

S# trecem acum de la tehnologia audio digital# la trei dintre aplica iile sale pentru re ele. Prima este fluxul audio, adic# ascultarea sunetelor pe Internet. Aceasta se nume!te de asemenea !i muzic# la cerere. Celelalte dou# sunt radio-ul prin Internet !i respectiv vocea peste IP.

Internet-ul este plin de situri Web cu muzic#, multe dintre ele listând titluri de cântece pe care utilizatorii le pot selecta cu ajutorul mouse-ului pentru le asculta. Unele dintre acestea sunt situri gratuite (spre exemplu forma iile noi care încearc# s# î!i fac# publicitate); altele necesit# o plat# pen-tru muzic#, de!i ele ofer# de asemenea mostre gratuite (spre exemplu primele "5 secunde dintr-un cântec). Metoda cea mai rapid# de a asculta muzica este ilustrat# în fig. 7-59.

. Stabilirea conexiunii TCP 2. Trimiterea cererii HTTP GET 3. Serverul preia fi!ierul de pe disc 4. Fi!ierul este trimis înapoi progra-

mului de navigare 5. Programul de navigare scrie fi!ie-

rul pe disc 6. Programul pentru redarea fi!iere-

lor media preia fi!ierul bloc dup" bloc !i îl red"

Fig. 7-59. O metod# direct# pentru a implementa muzica selec ionabil# de pe o pagin# Web. Procesul începe când utilizatorul selecteaz# cu mouse-ul un cântec. Apoi intr# în ac iune pro-

gramul de navigare. Primul s#u pas este stabilirea unei conexiuni TCP cu serverul Web pe care exis-t# o hiper-leg#tur# la cântec. Pasul 2 este trimiterea unei cereri GET în HTTP pentru a cere cânte-cul. Ulterior (pa!ii 3 si 4), serverul cite!te cântecul (care este doar un fi!ier în formatul MP3 sau vre-un alt format) de pe disc !i îl trimite înapoi programului de navigare. Dac# fi!ierul este mai mare decât memoria serverului, acesta poate aduce !i trimite melodia în blocuri.

Folosind tipul MIME, de exemplu, audio/mp3, (sau extensia fi!ierului), programul de navigare caut# s# vad# cum ar trebui livrat fi!ierul. De obicei exist# o aplica ie ajut#toare asociat# cu acest tip de fi!ier, precum RealOne Player, Windows Media Player, sau Winamp. Întrucât în mod obi!nuit programul de navigare comunic# cu o aplica ie ajut#toare printr-un fi!ier auxiliar, acesta va salva mai întâi întregul fi!ier de muzic# pe disc ca un fi!ier auxiliar (pasul 5). Apoi, va porni programul de re-

608 NIVELUL APLICA!IE CAP. 7

dare a fi!ierului c#ruia îi va trimite numele fi!ierului auxiliar de pe disc. La pasul 6, programul pentru redarea fi!ierelor media va începe s# încarce !i s# reproduc# muzica, bloc dup# bloc.

În principiu, aceast# metod# este în întregime corect# !i va produce muzic#. Singura problem# este c# trebuie trimis prin re ea tot cântecul, înainte ca muzica s# înceap#. În cazul în care cântecul are 4 MB (o dimensiune tipic# pentru un cântec MP3) !i modemul este de 56 Kbps, utilizatorul va avea parte de aproape "0 minute de lini!te pân# când cântecul este desc#rcat. Nu to i îndr#gosti ii de muzic# agreeaz# aceast# idee. Mai ales având în vedere c# urm#torul cântec va începe tot dup# "0 minute de desc#rcare, iar cel de dup# acesta la fel.

Pentru a rezolva aceast# problem# f#r# a schimba felul în care func ioneaz# programul de navi-gare, siturile cu muzic# au venit cu urm#toarea schem#. Fi!ierul legat la titlul cântecului nu este fi!ie-rul real cu muzic#. În schimb, este ceea ce se nume!te un metafi$ier, adic# un fi!ier foarte scurt cu numele melodiei. Un metafi!ier tipic poate avea doar o singur# linie de text ASCII !i arat# astfel:

rtsp://joes-audio-server/song-0025.mp3

Când programul de navigare prime!te fi!ierul de o linie, îl scrie pe disc într-un fi!ier auxiliar, por-ne!te programul pentru redarea fi!ierelor media ca pe o aplica ie ajut#toare !i îi trimite acestuia numele fi!ierului auxiliar, ca de obicei. Programul pentru redarea fi!ierelor media cite!te fi!ierul !i vede c# acesta con ine un URL. Apoi contacteaz# joes-audio-server !i cere cântecul. Observa i c# programul de navigare nu mai face parte din circuit.

În cele mai multe cazuri, serverul numit în metafi!ier nu este acela!i cu serverul Web. De fapt, de obicei nu este nici m#car un server HTTP, ci un server specializat pe media. În acest exemplu, serve-rul media folose!te RTSP (Real Time Streaming Protocol - protocolul pentru fluxuri în timp real), indicat de numele rtsp al schemei. Acesta este descris în RFC 2326.

Programul de redare a fi!ierelor media are patru lucruri importante de f#cut:

". Controleaz# interfa a cu utilizatorul. 2. Trateaz# erorile de transmisie. 3. Decomprim# melodia. 4. Elimin# fluctua iile.

Majoritatea programelor de redare a fi!ierelor media din zilele noastre au o interfa # captivant# cu utilizatorul, uneori simulând o unitate stereo, cu butoane, mânere, glisoare !i afi!aje vizuale. Ade-sea exist# panouri frontale interschimbabile, numite învelitori, pe care utilizatorul le poate suprapu-ne peste panoul programului de redare. Programul de redare trebuie s# controleze toate acestea !i s# interac ioneze cu utilizatorul.

A doua func ie a sa este tratarea erorilor. Transmisia de muzic# în timp real folose!te rareori TCP deoarece o eroare !i o retransmisie pot introduce o pauz# inacceptabil de lung# în melodie. În locul acestuia, transmisia real# se face de obicei cu un protocol asem#n#tor cu RTP, pe care l-am studiat în Cap. 6. Ca majoritatea protocoalelor de timp real, RTP utilizeaz# UDP !i deci se pot pier-de pachete. Programul de redare este cel care trebuie s# trateze acest lucru.

În unele cazuri, muzica este între esut# pentru a face tratarea erorilor mai u!oar#. Spre exemplu, un pachet poate con ine 220 de e!antioane stereo, fiecare con inând o pereche de numere de "6 bi i, de obicei bune pentru 5 ms de muzic#. Dar protocolul poate trimite toate e!antioanele impare pen-tru un interval de "0 ms într-un pachet !i toate e!antioanele pare în urm#torul. Atunci un pachet pierdut nu reprezint# o pauz# de 5 ms în muzic#, ci pierderea tuturor celorlalte e!antioane pentru "0 ms. Aceast# pierdere poate fi tratat# u!or de programul de redare a fi!ierelor media interpolând e!antioanele anterioare !i urm#toare pentru a estima valoarea absent#.

SEC. 7.4 MULTIMEDIA 609

Fig. 7-60. Când pachetele con in e!antioane alternante, pierderea unui pachet reduce temporar re-

zolu ia în loc s# creeze o perioad# de pauz#. Folosirea între eserii pentru a recupera din erori este ilustrat# în fig. 7-60. Aici fiecare pachet re-

ine e!antioanele alternante în timp pentru un interval de "0 ms. În consecin #, pierderea pachetului 3, dup# cum este ar#tat, nu introduce o pauz# în muzic#, ci doar scade rezolu ia pentru un anume interval. Valorile absente pot fi interpolate pentru a oferi sunet continuu. Aceast# schem# particula-r# nu func ioneaz# decât cu e!antioane necomprimate, dar arat# cum o codificare inteligent# poate converti un pachet pierdut într-unul de calitate mai joas#, mai degrab# decât într-o pauz# de timp. În orice caz, RFC 3""9 d# o schem# care func ioneaz# cu date audio comprimate.

A treia func ie a programului de redare a fi!ierelor media este decomprimarea melodiei. De!i aceast# opera ie necesit# multe resurse, ea este relativ rapid#.

A patra func ie este eliminarea fluctua iilor, blestemul tuturor sistemelor în timp real. Toate sis-temele de fluxuri audio încep prin a depune într-un tampon "0-"5 sec. de muzic# înainte de a începe s# cânte, ca în fig. 7-6". Ideal, serverul va continua s# umple tamponul cu aceea!i vitez# cu care este golit de programul de redare a fi!ierelor media, îns# în realitate nu se întâmpl# a!a, astfel c# se poate recurge la umplerea tamponului în interiorul buclei.

Dou# solu ii pot fi adoptate pentru a ine tamponul plin. Cu un server de cereri (pull server), atâ-ta timp cât este loc în tampon pentru înc# un bloc, programul de redare continu# s# trimit# c#tre server cereri pentru câte un bloc suplimentar. Scopul s#u este s# in# tamponul cât mai plin posibil.

Fig. 7-6 . Programul de redare a fi!ierelor media stocheaz# intrarea de la serverul media !i reprodu-

ce din tampon în loc s# reproduc# direct de pe re ea.

6 0 NIVELUL APLICA!IE CAP. 7

Dezavantajul unui server de cereri este existen a unor cereri de date inutile. Serverul !tie c# a trimis tot fi!ierul, a!a c# de ce s# punem programul de redare s# întrebe încontinuu? Din acest mo-tiv, solu ia este folosit# rar.

Cu un server de for#are (push server), programul de redare a fi!ierelor media trimite o cerere PLAY, iar serverul nu face decât s# îi trimit# date încontinuu. Aici sunt dou# posibilit# i: serverul media ruleaz# cu vitez# normal# de playback sau ruleaz# mai repede. În ambele cazuri, unele date sunt puse în tampon înainte de a începe playback-ul. Dac# serverul ruleaz# la viteza normal# de playback, datele care vin de la acesta sunt ad#ugate la sfâr!itul tamponului, iar programul de redare !terge datele de la începutul tamponului. Atâta timp cât totul func ioneaz# perfect, cantitatea de date din tampon r#mâne constant# în timp. Aceast# schem# este simpl#, deoarece nu sunt necesare mesaje de control în nici o direc ie.

Cealalt# schem# de for are este cea în care serverul trimite date mai repede decât este nevoie. Avantajul acesteia este c# dac# nu se poate garanta c# serverul ruleaz# cu o viteza constant#, acesta are ocazia s# recupereze de fiecare dat# când r#mâne în urm#. O problem# este posibila dep#!ire a cantit# ii tamponului dac# serverul trimite date mai repede decât sunt consumate (!i trebuie s# poa-t# face asta pentru a putea evita pauzele).

Solu ia este ca programul de redare a fi!ierelor media s# defineasc# un nivel minim (low-water mark) !i un nivel maxim (high-water mark) în tampon. Practic, serverul trimite date pân# când tam-ponul este umplut la nivelul maxim. Apoi programul de redare a fi!ierelor media îi spune s# ia o pauz#. Cum datele vor continua s# intre în tampon pân# când serverul prime!te cererea de pauz#, distan a de la nivelul maxim pân# la sfâr!itul tamponului trebuie s# fie mai mare decât întârzierea produs# de l# imea de band# a re elei. Dup# ce serverul este oprit, tamponul începe s# se goleasc#. Când ajunge la nivelul minim, programul de redare a fi!ierelor media îi spune serverului media s# reia trimiterea. Nivelul minim trebuie pozi ionat astfel încât tamponul s# nu se goleasc# integral.

Pentru a ac iona asupra serverului de for are, programul de redare a fi!ierelor media trebuie s# îl controleze de la distan #. Acest lucru este asigurat de RTSP. Acesta este definit în RFC 2326 !i ofer# mecanisme de control al serverului pentru programul de redare. El nu se ocup# de fluxul de date, lucru f#cut de obicei de RTP. Comenzile principale oferite de RTSP sunt listate în fig. 7-62.

Comanda R spunsul serverului DESCRIBE Afi!eaz" parametrii media SETUP Stabile!te un canal logic între programul de redare !i server. PLAY Începe s" trimit" date clientului. RECORD Începe s" accepte date de la client. PAUSE Suspend" temporar trimiterea datelor. TEARDOWN Elibereaz" canalul logic.

Fig. 7-62. Comenzile RTSP de la programul de redare la server.

7.4.4 Radio prin Internet

O dat# ce a devenit posibil# transmiterea de fluxuri audio prin Internet, sta iilor radio comerciale le-a venit ideea s# emit# !i pe Internet, !i prin aer. Nu cu mult timp dup# asta, sta iile radio ale uni-versit# ilor au început s# î!i pun# semnalul pe Internet. Apoi studen ii !i-au înfiin at propriile sta ii radio. Cu tehnologia actual#, practic oricine î!i poate înfiin a o sta ie radio. Întreaga zon# a radio-ului prin Internet este foarte nou# !i în schimbare, îns# merit# s# spunem câte ceva despre ea.

SEC. 7.4 MULTIMEDIA 6

Exist# dou# solu ii generale pentru radio-ul prin Internet. În prima, programele sunt pre-înregis-trate !i stocate pe disc. Ascult#torii se pot conecta la arhivele sta iei radio !i pot alege !i desc#rca orice program, pentru a-l asculta. De fapt, aceasta este similar# cu fluxurile audio despre care tocmai am discutat. Este de asemenea posibil s# se stocheze fiecare program imediat dup# ce a fost transmis în direct, astfel încât arhiva s# func ioneze doar pentru, s# zicem, o jum#tate de or# sau mai pu in dup# transmisia în direct. Avantajele acestei solu ii sunt c# este u!or de realizat, toate tehnicile despre care am discutat func ioneaz# !i aici, iar ascult#torii pot alege dintre toate programele din arhiv#.

Cealalt# solu ie este transmiterea în direct pe Internet. Unele sta ii transmit prin aer !i prin In-ternet simultan, dar sunt din ce în ce mai multe sta ii radio exclusiv pe Internet. Unele tehnici care sunt aplicabile fluxurilor audio sunt aplicabile !i radio-ului în direct prin Internet, dar sunt !i unele diferen e cheie.

Un element asem#n#tor este necesitatea stoc#rii într-un tampon în situl utilizatorului pentru a mic!ora fluctua iile. Colectând "0 sau "5 secunde de radio înainte de începerea playback-ului, sune-tul poate fi men inut continuu chiar !i în cazul unor fluctua ii substan iale pe re ea. Atât timp cât pachetele ajung înainte s# fie nevoie de ele, nu conteaz# când au ajuns.

O diferen # de baz# este c# fluxurile audio pot fi transmise cu o vitez# mai mare decât viteza de playback, întrucât receptorul le poate opri când este atins nivelul maxim. Teoretic, asta îi d# timp pentru a retransmite pachetele pierdute, de!i aceast# abordare nu se folose!te de obicei. În contrast, radio-ul în direct este întotdeauna transmis la exact aceea!i rat# cu care este generat !i redat ascult#torului.

O alt# diferen # este c# o sta ie radio în direct are de obicei sute sau mii de ascult#tori simultan, în timp ce fluxurile audio sunt punct la punct. În aceste condi ii, radio-ul prin Internet ar trebui s# foloseasc# trimiterea multipl# cu protocoalele RTP/RTSP. Aceasta este cu siguran # cea mai eficien-t# cale de a func iona.

În practica actual#, radio-ul prin Internet nu func ioneaz# a!a. Ceea ce se întâmpl# de fapt este c# utilizatorul stabile!te o conexiune TCP cu sta ia !i fluxul este trimis prin conexiunea TCP. Fire!te, asta creeaz# diverse probleme, precum oprirea fluxului când fereastra este plin#, pierderea pachete-lor care au expirat !i sunt retransmise, !i a!a mai departe.

Motivul pentru care se folose!te trimiterea singular# TCP în locul trimiterii multiple RTP are trei p#r i. Prima, pu ine ISP-uri suport# trimiterea multipl#, astfel c# aceasta nu este practic o op iune. A doua, RTP este mai pu in cunoscut decât TCP !i sta iile radio sunt adesea mici !i au pu ine cuno!tin- e despre calculatoare, a!a încât este mai u!or de folosit un protocol în eles pe scar# larg# !i suportat de toate pachetele de aplica ii. A treia, mul i oameni ascult# radio-ul prin Internet la serviciu, ceea ce, în practic#, înseamn# adesea în spatele unui zid de protec ie (firewall). Mul i administratori de sistem î!i configureaz# zidul de protec ie pentru a-!i proteja LAN-ul de vizitatori nepofti i. De obicei ei accept# conexiuni TCP de la portul de la distan # 25 (SMTP pentru po!t# electronic#), pachete UDP de la portul de la distant# 53 (DNS), !i conexiuni TCP de la portul de la distan # 80 (HTTP pentru Web). Aproape orice altceva poate fi blocat, inclusiv RTP. Astfel, singura cale de a ob ine semnalul radio prin zidul de protec ie este ca situl Web s# pretind# c# este un server HTTP, cel pu in în fa a zidului de protec ie, !i s# foloseasc# servere HTTP care utilizeaz# TCP. Aceste m#suri severe, în timp ce ofer# doar o securitate minimal#, împing adesea cu for a aplica iile multimedia c#tre mo-duri de operare cu o eficien # drastic mai mic#.

Cum radio-ul prin Internet este un mediu nou, r#zboaiele asupra formatelor sunt în plin# înflori-re. Real Audio, Windows Media Audio !i MP3 concureaz# agresiv pe aceast# pia # pentru a deveni formatul dominant în radio-ul prin Internet. Un nou venit este Vorbis, care este tehnic similar cu

6 2 NIVELUL APLICA!IE CAP. 7

MP3, îns# are sursele disponibile !i este suficient de diferit pentru a nu folosi patentele pe care se bazeaz# MP3.

O sta ie tipic# de radio prin Internet are o pagin# Web ce îi listeaz# programul, informa ii despre DJ !i crainicii s#i !i multe reclame. Sunt de asemenea !i una sau mai multe iconi e pentru a afi!a forma-tele audio pe care le suport# (sau doar ASCULT ACUM dac# un singur format este suportat). Aces-te iconi e sau ASCULT ACUM sunt metafi!iere legate de tipul celor de care am discutat mai sus.

Când un utilizator selecteaz# una dintre iconi e cu mouse-ul, este trimis metafi!ierul. Programul de navigare îi folose!te tipul MIME sau extensia de fi!ier pentru a determina aplica ia ajut#toare cea mai potrivit# pentru metafi!ier (spre exemplu programul de redare a fi!ierelor media). Apoi scrie metafi!ierul într-un fi!ier auxiliar pe disc, porne!te programul de redare a fi!ierelor media !i îi trimi-te numele fi!ierului auxiliar. Programul de redare a fi!ierelor media cite!te fi!ierul auxiliar, vede URL-ul pe care acesta îl con ine (de obicei o schem# http în loc de rtsp pentru a evita problema zidu-lui de protec ie !i pentru c# unele aplica ii multimedia de succes lucreaz# astfel), contacteaz# serve-rul !i începe s# func ioneze ca un radio. Ca element exterior, audio con ine un singur flux, astfel c# http-ul func ioneaz#, îns# pentru video, care are cel pu in dou# fluxuri, http-ul nu mai e bun !i este necesar ceva de genul rtsp.

Fig. 7-63. O sta ie radio student.

O alt# dezvoltare interesant# în zona radio-ului prin Internet este o organizare prin care oricine,

chiar !i un student, poate s# înfiin eze !i s# opereze o sta ie radio. Componentele principale sunt ilustrate în fig. 7-63. Elementul de baz# al sta iei este un calculator normal cu o plac# de sunet !i un microfon. Aplica iile constau într-un program de redare a fi!ierelor media, precum Winamp sau Freeamp, cu un element de intrare pentru captur# audio !i un codec pentru formatul audio de ie!ire selectat, spre exemplu MP3 sau Vorbis.

Fluxul audio generat de sta ie este apoi trimis prin Internet c#tre un server mare, care se ocup# de distribu ia acestuia unui num#r mare de conexiuni TCP. De obicei serverul suport# multe sta ii mici. Acesta men ine de asemenea un director cu sta iile pe care le are !i ce emite fiecare în momentul cu-rent. Poten ialii ascult#tori merg la server, selecteaz# o sta ie, !i primesc date TCP. Exist# pachete de aplica ii comerciale pentru controlul tuturor par ilor, precum !i pachete cu sursele disponibile precum icecast. Exist# de asemenea !i servere care sunt doritoare s# se ocupe de distribu ie contra unei taxe.

SEC. 7.4 MULTIMEDIA 6 3

7.4.5 Voce peste IP

Cu mult timp în urm#, sistemul telefonic public comutat era în primul rând utilizat pentru trafi-cul de voce cu varia ii mici de trafic de date. Dar traficul de date a crescut din ce în ce mai mult, încât în "999, num#rul de bi i de date transporta i era egal cu num#rul de bi i de voce (deoarece vocea este în PCM pe leg#turile principale, poate fi m#surat# în bi i/sec). Pân# în 2002, volumul de trafic de date era cu un ordin de m#rime mai mare decât volumul de trafic de voce !i înc# cre!tea expo-nen ial, traficul de voce fiind aproape la acela!i nivel (5% cre!tere pe an).

Ca o consecin # a acestor numere, mul i operatori de re ele de pachete comutate au devenit dintr-o dat# interesa i de transportul vocii prin re elele lor de date. Cantitatea suplimentar# de ban-d# de transfer necesar# pentru voce este minuscul#, din moment ce re elele de pachete au o dimen-siune specific# traficului de date. Cu toate acestea, nota de plat# a unei persoane este mai mare pen-tru telefon, decât pentru Internet, în felul acesta operatorii de re ea v#zând telefonia pe Internet ca un mod de a câ!tiga mai mul i bani f#r# s# mai pun# alte cabluri în p#mânt. Astfel a luat na!tere tele-fonia pe Internet (cunoscut# !i sub numele de voce peste IP).

H.323 Un lucru era clar pentru toat# lumea înc# de la început !i anume c# dac# fiecare vânz#tor !i-ar fi

creat propria stiv# de protocoale, sistemul nu ar fi func ionat niciodat#. Pentru a evita aceast# pro-blem#, un num#r de participan i interesa i s-au adunat sub auspiciile ITU pentru a realiza standar-dele. În "996 ITU a lansat o recomandare H.323 intitulat# “Sisteme de telefonie vizual# !i echipa-mente pentru re ele locale care nu garanteaz# calitatea serviciului”. Doar industria telefonic# ar pu-tea gândi un astfel de nume. Recomandarea a fost revizuit# în "998 !i apoi acest H.323 revizuit a fost baza primelor sisteme universale de telefonie pe Internet.

H.323 este mai mult o prezentare arhitectural# a telefoniei pe Internet decât un protocol specific. El se refer# la un num#r mare de protocoale specifice pentru codificarea vocii, configurarea apelu-lui, semnalizare, transportul datelor !i alte aspecte mai mult decât s# specifice el însu!i aceste lucruri. Modelul general este reprezentat în fig. 7-64. În centru este o poart" (gateway) care conecteaz# la Internet re eaua de telefonie. Comunic# prin protocoalele H.323 pe partea de Internet !i prin proto-coalele PSTN pe partea de telefonie. Dispozitivele de comunica ie sunt denumite terminale. Un LAN poate avea un administrator de poart" (gatekeeper), care controleaz# punctele finale de sub jurisdic ia sa, numite zone.

Fig. 7-64. Modelul arhitectural H.323 pentru telefonia prin Internet.

6 4 NIVELUL APLICA!IE CAP. 7

O re ea de telefonie are nevoie de un num#r de protocoale. S# începem cu protocolul de codifi-care !i decodificare a vocii. Sistemul PCM pe care l-am studiat în Cap. 2 este definit în recomanda-rea ITU G.7 . Acesta codific# un singur canal de voce prin e!antion#ri de 8000 de ori pe secund# cu un model pe 8 bi i care s# redea vocea necomprimat# la 64 Kbps. Toate sistemele H.323 trebuie s# suporte G.7"". Cu toate acestea, alte protocoale de compresie a vocii sunt de asemenea permise (dar nu obligatorii). Acestea folosesc diferi i algoritmi de compresie pentru a face diferite compro-misuri între calitate !i l#rgime de band#. De exemplu, G.723. preia un bloc de 240 de e!antioane (30 ms de voce) !i folose!te codificarea predictiv# pentru a-l reduce la 24 octe i sau 20 octe i. Acest algo-ritm ofer# o rat# la ie!ire de 6,4 Kbps sau 5,3 Kbps (factori de compresie de "0 !i "2), respectiv, cu mici pierderi în calitatea perceput#. Sunt, de asemenea, permise !i alte codific#ri.

Din moment ce sunt permi!i mai mul i algoritmi de compresie, este necesar un protocol care s# permit# terminalelor s# negocieze ce algoritm vor folosi. Acest protocol poart# numele de H.245. De asemenea, se negociaz# !i alte aspecte ale conexiunii, ca de exemplu viteza de transmisie. RTCP este necesar pentru controlul canalelor RTP. De asemenea, este necesar un protocol pentru stabilirea !i eliberarea conexiunilor, asigurarea de tonuri, crearea de sunete de apel !i restul telefoniei standard. Aici este utilizat ITU Q.93 . Terminalele au nevoie de un protocol pentru a comunica cu adminis-tratorul de poart# (când acesta exist#). În acest scop este folosit H.255. Canalul PC – administrator de poart# pe care îl gestioneaz# este denumit canal RAS (Registration/Admission/Status, rom: Înre-gistrare/Admisie/Stare). Acest canal permite terminalelor s# intre sau s# p#r#seasc# zona, s# cear# sau s# elibereze band# de transfer !i s# asigure, printre altele, actualiz#ri de stare. În fine, un proto-col este necesar pentru transmiterea efectiv# a datelor. RTP este utilizat în acest scop. Este adminis-trat de RTCP, ca de obicei. Pozi ionarea tuturor protocoalelor este prezentat# în fig. 7-65.

Voce Control

G.7xx

RTP

RTCP H.225 (RAS)

Q.93 (semnali-zare apel)

H.245 (control

apel) UDP TCP

IP Protocolul de leg"tur" de date

Protocolul de nivel fizic

Fig. 7-65. Stiva de protocoale H.323. Pentru a vedea cum lucreaz# împreun# aceste protocoale, s# consider#m cazul unui terminal PC

pe un LAN (cu un administrator de poart#) care apeleaz# un telefon aflat la distan #. Mai întâi, PC-ul trebuie s# localizeze administratorul de poart#, astfel c# difuzeaz# un pachet UDP de aflare a ad-ministratorului de poart# pe portul "7"8. Când administratorul de poart# r#spunde, PC-ul afl# adre-sa IP a administratorului de poart#. Acum PC-ul se înregistreaz# la administratorul de poart# trimi ându-i un mesaj RAS într-un pachet UDP. Dup# ce a fost acceptat, PC-ul trimite administra-torului de poart# un mesaj de admitere RAS, cerând l#rgime de band#. Numai dup# ce banda a fost acordat# se poate face ini ierea apelului. Ideea de a cere l#rgime de band# în avans este aceea de a permite administratorului de poart# s# limiteze num#rul de apeluri pentru a evita supraînc#rcarea liniei de ie!ire !i a ajuta la asigurarea calit# ii necesare a serviciului.

În acest moment, PC-ul stabile!te o conexiune TCP cu administratorul de poart# pentru a ini ia apelul. Configurarea apelului folose!te protocoale existente de re ea de telefonie, care sunt orien-tate pe conexiuni, deci este necesar TCP-ul. În contrast, sistemul telefonic nu are nimic echivalent

SEC. 7.4 MULTIMEDIA 6 5

canalului RAS pentru a permite telefoanelor s#-!i anun e prezen a, astfel creatorii H.323 au fost nevoi i s# foloseasc# fie UDP, fie TCP pentru RAS, !i au ales protocolul cu supraînc#rcarea cea mai mic#, UDP.

În acest moment, când PC-ul are alocat# band# de transfer, el poate s# trimit# un mesaj Q.93" SETUP (configurare) peste conexiunea TCP. Acest mesaj specific# num#rul de telefon apelat (sau adresa IP !i portul, dac# este apelat un calculator). Administratorul de poart# r#spunde cu un mesaj Q.93" CALL PROCEEDING (începerea comunic#rii) pentru a confirma primirea cererii. Adminis-tratorul de poart# trimite mai departe mesajul SETUP c#tre poart#.

Poarta, care este jum#tate calculator, jum#tate comutator telefonic, lanseaz# un apel obi!nuit c#-tre telefonul dorit. Oficiul final la care este legat telefonul, apeleaz# telefonul destina ie !i trimite de asemenea un mesaj Q.93" ALERT (alert#) pentru a anun a PC-ul apelant c# a început s# sune. Când persoana de la cel#lalt cap#t al firului ridic# receptorul, oficiul final trimite înapoi un mesaj Q.93" CONNECT (conectare) pentru a anun a PC-ul c# are o conexiune.

Odat# stabilit# conexiunea, administratorul de poart# nu mai este în bucl#, de!i poarta înc# mai este. Pachetele urm#toare trec peste administratorul de poart#, ducându-se direct la adresa IP a por ii. În acest punct, avem doar un simplu tub între cele dou# p#r i. Aceasta este doar o conexiune la nivel fizic pentru transferul bi ilor, nimic mai mult. Nici un cap#t nu !tie nimic despre cel#lalt.

Protocolul H.245 este acum folosit pentru negocierea parametrilor apelului. El folose!te canalul de control H.245, care este întotdeauna deschis. Fiecare parte începe prin anun area capabilit# ilor sale, de exemplu, dac# poate suporta apeluri video (H.323 suport# apeluri video) sau conferin e, ce codific#ri suport# etc. În momentul în care fiecare cap#t !tie ce suport# cel#lalt, sunt stabilite dou# canale unidirec ionale !i un codor !i al i parametri sunt atribui i fiec#ruia. Din moment ce fiecare cap#t poate avea un echipament diferit, este foarte probabil s# fie diferite !i codoarele pe canalele de trimitere !i recep ie. Dup# ce s-au încheiat toate negocierile, fluxul de date utilizând RTP poate în-cepe. El este administrat prin RTCP, care joac# un rol în controlul congestiei. Dac# sunt prezente transmisii video, RTCP se ocup# de sincronizarea audio/video. Diferitele canale sunt ilustrate în fig. 7-66. Când oricare din cele dou# capete se închide, canalul Q.93" de semnalizare al apelului este utilizat pentru a opri conexiunea.

Fig. 7-66. Canale logice între apelant !i apelat în timpul apelului. Când se încheie apelul, PC-ul apelant contacteaz# din nou administratorul de poart# cu un mesaj

RAS pentru a elibera banda de transfer care i-a fost atribuit#. Alternativ, el poate s# fac# un nou apel. Nu am spus nimic despre calitatea serviciului, de!i aceasta este esen ial# pentru a face din vocea

peste IP un succes. Motivul este simplu, calitatea serviciului este în afara domeniului H.323. Dac#

6 6 NIVELUL APLICA!IE CAP. 7

re eaua transportatoare este capabil# s# produc# o conexiune stabil#, f#r# distorsiuni dinspre PC-ul apelant (de exemplu, folosind tehnicile pe care le-am discutat în cap. 5) înspre poart#, atunci calita-tea serviciului pe apel va fi bun#; altfel, nu va fi. Partea telefonic# folose!te PCM !i este întotdeauna f#r# distorsiuni.

SIP – Protocolul de ini#iere a sesiunii H.323 a fost conceput de ITU. Mul i oameni din comunitatea Internet l-au v#zut ca un produs

tipic telco: mare, complex, !i inflexibil. În consecin #, IETF a creat un comitet pentru a concepe un mod mai simplu !i mai modular pentru vocea peste IP. Rezultatele cele mai bune pân# în prezent se concretizeaz# în SIP (Session Initiation Protocol, rom: Protocolul de ini#iere a sesiunii), care este descris în RFC 326". Protocolul descrie configurarea apelurilor telefonice pe Internet, video confe-rin ele !i alte conexiuni multimedia. Spre deosebire de H.323, care este o întreag# suit# de protocoa-le, SIP este un singur modul, dar a fost conceput pentru a conlucra bine cu aplica iile Internet exis-tente. De exemplu, define!te numerele de telefon ca URL-uri, pentru a fi incluse în pagini Web, permi ând ca un clic pe o leg#tur# s# ini ieze un apel telefonic (asem#n#tor, schema mailto permite ca activarea unei hiper-leg#turi s# deschid# programul de trimitere al unui mesaj electronic).

SIP poate stabili sesiuni bilaterale (apeluri telefonice obi!nuite), sesiuni multilaterale (în care oricine poate auzi !i vorbi), !i sesiuni cu transmisie multipl# (un emi #tor, mai mul i receptori). Sesi-unile pot con ine audio, video, sau date, ultimul fiind folositor de exemplu pentru jocuri cu mai mul i utilizatori în timp real. SIP se ocup# doar cu configurarea, administrarea !i terminarea sesiunilor. Alte protocoale, ca RTP/RTCP, sunt utilizate pentru transportul datelor. SIP este un protocol de nivel aplica ie !i poate rula peste UDP sau TCP.

SIP suport# o varietate de servicii, inclusiv localizarea apelatului (care poate nu este la calculato-rul s#u de acas#) !i s# determine capabilit# ile acestuia, precum !i s# trateze mecanismele de confi-gurare !i terminare. În cel mai simplu caz, SIP seteaz# o sesiune de la calculatorul apelantului la cal-culatorul apelatului, deci s# trat#m mai întâi acest caz.

Numerele de telefon în SIP sunt reprezentate ca URL-uri utilizând schema sip, de exemplu, sip:ilse@cs.university.edu pentru utilizatorul ilse de pe calculatorul specificat de numele de DNS cs.university.edu. URL-urile SIP pot con ine adrese IPv4, IPv6, sau chiar numere de telefon.

Protocolul SIP este un protocol bazat pe text modelat în HTTP. Un cap#t trimite un mesaj în text ASCII ce con ine un nume de metod# pe prima linie, urmat# de linii adi ionale ce con in antete pentru transmiterea parametrilor. Multe dintre antete sunt luate din MIME pentru a permite proto-colului SIP s# conlucreze cu aplica iile Internet existente. Cele !ase metode definite de specifica ia de baz# sunt enumerate în fig. 7-67.

Metoda Descriere INVITE Cerere de ini#iere a unei sesiuni ACK Confirmare c" o sesiune a fost ini#iat" BYE Cerere de terminare a unei sesiuni OPTIONS Interogarea unui calculator despre capabilit"#ile sale CANCEL Anularea unei cereri în a!teptare REGISTER Informarea unui server de redirec#ionare despre loca#ia curent" a utilizatorului

Fig. 7-67. Metodele SIP definite în specifica ia de baz#. Pentru stabilirea unei sesiuni, apelantul fie creeaz# o conexiune TCP cu apelatul !i trimite un

mesaj INVITE, fie trimite mesajul INVITE într-un pachet UDP. În ambele cazuri, antetele din a

SEC. 7.4 MULTIMEDIA 6 7

doua !i urm#toarele linii descriu structura corpului mesajului ce con in capabilit# ile apelantului, tipurile de mediu de transmisie !i formatele. Dac# cel apelat accept# convorbirea, el r#spunde cu un cod de r#spuns de tip HTTP (un num#r de trei digi i conform grupurilor din fig. 7-42, 200 pentru acceptare). Dup# linia cu codul de r#spuns, apelatul poate de asemenea include informa ii despre capabilit# ile sale, tipurile de mediu de transmisie !i formate.

Conexiunea este realizat# prin mecanismul în elegerii în trei pa!i astfel c#, pentru a încheia pro-tocolul, apelantul r#spunde cu un mesaj de confirmare a recep ion#rii mesajului 200.

Oricare dintre cele dou# capete pot cere terminarea sesiunii prin trimiterea unui mesaj con inând metoda BYE. Când cel#lalt cap#t trimite confirmarea primirii acestuia, sesiunea este terminat#.

Metoda OPTIONS este utilizat# pentru a interoga o ma!in# despre propriile sale capabilit# i. Es-te în general folosit# înainte de ini ierea unei sesiuni pentru a afla dac# acea ma!in# este capabil# de transmisii de voce peste IP sau ce alt tip de sesiune este urm#rit.

Metoda REGISTER se refer# la abilitatea protocolului SIP de a urm#ri !i a se conecta la un utili-zator care nu este acas#. Acest mesaj este trimis unui server de localizare SIP care ine o eviden # a loca iilor utilizatorilor. Acel server poate fi mai târziu interogat pentru a afla loca ia curent# a utiliza-torului. Opera ia de redirec ionare este ilustrat# în fig. 7-68. Aici, apelantul trimite un mesaj INVITE unui server proxy pentru a ascunde posibila redirec ionare. Proxy-ul caut# apoi unde este utilizatorul !i îi trimite un mesaj INVITE. Apoi se comport# ca un intermediar pentru mesajele urm#toare în în elegerea în trei pa!i. Mesajele LOOKUP !i REPLY nu fac parte din SIP; orice protocol convenabil poate fi utilizat, depinzând de tipul de server de localizare utilizat.

Fig. 7-68. Utilizarea unui proxy !i servere de redirec ionare cu SIP. SIP are o varietate de alte caracteristici pe care noi nu le vom descrie aici, incluzând a!teptarea

apelului, ecranarea apelului, criptare !i autentificare. De asemenea, are abilitatea de a apela de la un calculator, un telefon obi!nuit, dac# este disponibil# o poart# de conversie corespunz#toare între Internet !i sistemul telefonic.

Compara#ie între H.323 $i SIP H.323 !i SIP au multe puncte în comun, dar !i diferen e. Ambele protocoale permit apeluri bila-

terale !i multilaterale folosind atât calculatoare, cât !i telefoane ca puncte finale. Ambele suport# negocierea parametrilor, criptarea !i protocoalele RTP/RTCP. Un rezumat al acestor asem#n#ri !i diferen e este dat în fig. 7-69.

6 8 NIVELUL APLICA!IE CAP. 7

No!iune H.323 SIP Conceput de ITU IETF Compatibilitate cu PSTN Da În mare parte Compatibilitate cu Internet Nu Da Arhitectura Monolitic" Modular" Completitudine Întreaga stiv" de protocoale SIP trateaz" doar configurarea Negocierea parametrilor Da Da Semnalizarea apelului Q.93 peste TCP SIP peste TCP !i UDP Formatul mesajului Binar ASCII Mediul de transmisie RTP/RTCP RTP/RTCP Apeluri multilaterale Da Da Conferin#e multimedia Da Nu Adresare Calculator sau num"r de telefon URL Terminarea apelului Explicit" sau eliberare TCP Explicit" sau la expirarea timpului Mesagerie imediat" Nu Da Criptare Da Da Dimensiunea standardelor 400 pagini 250 pagini Implementare Mare !i complex" Moderat" Stare Larg r"spândit" Prezent" !i viitoare

Fig. 7-69. Compara ie între H.323 !i SIP De!i seturile de caracteristici sunt similare, cele dou# protocoale difer# mult în concep ie. H.323

este un standard tipic, cu greutate, al industriei de telefonie, specificând întreaga stiv# de protocoale !i definind exact ce este permis !i ce este interzis. Abordarea duce la protocoale bine definite la fie-care nivel, u!urând interoperabilitatea. Pre ul este un standard mare, complex !i rigid, dificil de adaptat la aplica iile viitoare.

În contrast, SIP este un protocol tipic de Internet care lucreaz# prin schimbul de linii scurte de text ASCII. Este un modul u!or care conlucreaz# bine cu alte protocoale de Internet, dar mai pu in cu protocoalele de semnalizare din sistemul telefonic existent. Deoarece modelul IETF al vocii peste IP este în mare m#sur# modular, el este flexibil !i poate fi adaptat cu u!urin # la noi aplica ii. Partea nepl#cut# este cea a poten ialelor probleme de interoperabilitate, de!i acestea sunt discutate în în-tâlniri frecvente unde diver!i implementatori î!i testeaz# împreun# sistemele.

Vocea peste IP este o tem# prezent# !i viitoare. De aceea, deja exist# c#r i pe aceast# tem#. Câ-teva exemple sunt (Collins, 200"; Davidson !i Peters, 2000; Kumar !.a.., 200"; !i Wright, 200"). Edi- ia din mai/iunie 2002 a revistei Internet Computing are mai multe articole pe aceast# tem#.

7.4.6 Introducere la video

Pân# acum am discutat urechea în detaliu; este timpul s# ne mut#m la ochi (nu, aceast# sec iune nu este urmat# de una despre nas). Ochiul uman are proprietatea c# atunci când o imagine apare pe retin#, imaginea este p#strat# acolo pentru câteva milisecunde. Dac# o secven # de imagini este de-senat# linie cu linie la 50 imagini/sec, ochiul nu observ# c# prive!te imagini discrete. Toate sistemele video (de exemplu, televizorul) exploateaz# acest principiu pentru a produce imagini în mi!care.

Sisteme Analogice Pentru a în elege sistemele video, este bine s# pornim de la vechea televiziune simpl#, alb-negru.

Pentru a reprezenta imaginile bidimensionale din fa a ei ca o tensiune unidimensional# func ie de timp, camera de luat vederi scaneaz# imaginea cu o raz# electronic#, rapid de-a latul !i lent în josul

SEC. 7.4 MULTIMEDIA 6 9

ei, înregistrând intensitatea luminoas# a!a cum vine. La sfâr!itul scan#rii, numit cadru (frame), raza reia traseul. Aceast# intensitate este difuzat# ca func ie de timp, iar receptorii repet# procesul de scanare pentru reconstruc ia imaginii. Modelul de scanare folosit atât de camer# cât !i de receptor, este prezentat în fig. 7-70. (Camerele CCD integreaz# mai degrab# decât scaneaz#, dar unele came-re !i toate monitoarele scaneaz#.)

Fig. 7-70. Modelul de scanare folosit pentru video !i televiziunea NTSC.

Parametrii exac i de scanare variaz# de la ar# la ar#. Sistemul folosit în America de Nord !i de

Sud !i Japonia are 525 de linii de scanare, o rat# de aspect orizontal/vertical de 4:3 !i 30 de cadre/sec. Sistemul european are 625 de linii de scanare, aceea!i rat# de aspect de 4:3 !i 25 de cadre/sec. În ambele sisteme, câteva linii din vârf !i câteva din partea de jos nu sunt afi!ate (pentru a aproxima o imagine dreptunghiular# pe un tub catodic rotund original). Doar 483 din cele 525 de linii de scana-re NTSC (!i 576 din cele 625 de linii de scanare PAL/SECAM) sunt afi!ate. Raza este stins# în tim-pul revenirii verticale, a!a c# multe sta ii (în special în Europa) folosesc acest interval pentru difuzare de TeleText (pagini de text con inând !tiri, vreme, sporturi, pre uri la burs# etc.).

În timp ce 25 de cadre/sec sunt suficiente pentru a capta o mi!care lin#, la aceast# vitez# a cadrelor multe persoane, în special cei b#trâni, vor percepe imaginea tremurat# (deoarece imaginea veche a fost !tears# de pe retin# înaintea apari iei uneia noi). În loc s# se m#reasc# viteza cadrelor, care va cere s# se foloseasc# mai pu in# l#rgime de band#, este aleas# o alt# cale. În locul afi!#rii liniilor de scanare în ordine, întâi sunt afi!ate toate liniile de scanare cu numere impare, apoi cele cu numere pare. Fiecare din aceste jum#t# i de cadre este numit# câmp (field). Experimentele arat# c# de!i oamenii remarc# o pâlpâire la 25 de cadre/sec, ei nu o remarc# la 50 de cadre/sec. Aceast# tehnic# este numit# între#esere (interlacing). O televiziune sau video neîntre esut# este denumit# progresiv" (progressive). Observa i c# filmele ruleaz# la 24 fps, dar fiecare cadru este vizibil în totalitate pentru "/24 sec.

Video-ul color folose!te acela!i model de scanare ca monocromul (alb !i negru), cu excep ia fap-tului c# în locul afi!#rii unei imagini cu o singur# raz# mi!c#toare, sunt folosite trei raze care se mi!c#

620 NIVELUL APLICA!IE CAP. 7

la unison. Este folosit# câte o raz# pentru fiecare din cele trei culori aditive primare: ro!u, verde !i albastru (RGB). Aceast# tehnic# func ioneaz# pentru c# orice culoare poate fi construit# din super-pozi ia liniar# a ro!ului, verdelui !i albastrului cu intensit# ile corespunz#toare. Cu toate acestea, pentru transmiterea pe un singur canal, cele trei semnale de culori trebuie combinate într-un singur semnal compus (composite).

Atunci când a ap#rut televiziunea color, diverse metode de afi!are color erau tehnic posibile, !i diverse #ri au f#cut alegeri diferite, conducând la sisteme care sunt înc# incompatibile. (Observa i c# aceste alegeri nu au nimic în comun cu VHS, fa # de Betamax !i fa # de P2000, care sunt tehnici de înregistrare.) În toate #rile, o necesitate politic# a fost ca programele color s# fie recep ionate de televizoarele existente alb-negru. În consecin #, cea mai simpl# schem#, care codific# separat semna-lele RGB, nu a fost acceptat#. De asemenea, RGB nu este cea mai eficient# schem#.

Primul sistem color a fost standardizat în Statele Unite de Comitetul Na#ional de Standarde de Televiziune (National Television Standards Committee), care a împrumutat acronimul s#u standar-dului: NTSC. Televiziunea color a fost introdus# în Europa câ iva ani mai târziu, în momentul în care tehnologia a fost îmbun#t# it# substan ial, conducând la sisteme cu mare imunitate la zgomote !i culori mai bune. Acestea sunt numite SECAM (SEquentiel Couleur Avec Memoire, rom: culoare secven#ial" cu memorie), sistem folosit în Fran a !i în #rile din estul Europei, !i PAL (Phase Alter-nating Line, rom: linie cu faz" alternat") folosit în restul Europei. Diferen a în calitatea culorii între NTSC !i PAL/SECAM a condus la gluma c# NTSC înseamn# de fapt c# aceea!i culoare nu apare de dou# ori (Never Twice the Same Color).

Pentru a permite ca transmisiunile color s# fie v#zute de receptoarele alb-negru, toate cele trei sisteme combin# liniar semnalele RGB într-un semnal de luminan#" (luminance), !i dou# semnale de crominan#" (chrominance), de!i toate folosesc al i coeficien i pentru construc ia acestor semnale din semnale RGB. Interesant, ochiul este mai sensibil la semnalele de luminan # decât la cele de crominan #, astfel încât ultimele nu trebuie transmise cu mare acurate e. Ca rezultat, semnalul lu-minos poate fi difuzat la aceea!i frecven # ca !i vechiul semnal alb-negru, a!a încât poate fi recep io-nat pe televizoarele existente alb-negru. Cele dou# semnale de crominan # sunt difuzate în benzi înguste la frecven e înalte. Unele televizoare au butoane pentru controlul str#lucirii, nuan ei !i satu-r#rii (sau str#lucirii, tentei !i culorii) pentru controlul separat al celor trei semnale. În elegerea lumi-nan ei !i crominan ei este vital# pentru în elegerea modului în care func ioneaz# compresia video.

În ultimii ani, a existat un interes considerabil pentru HDTV (High Definition TeleVision, rom: televiziunea de înalt" defini#ie), care produce imagini mai bune dublând num#rul liniilor de scanare. Statele Unite, Europa !i Japonia au dezvoltat sisteme HDTV, toate diferite !i toate mutual incom-patibile. V-a i fi a!teptat la altceva? Principiile de baz# ale HDTV-ului în termeni de scanare, lumi-nan #, crominan # !i altele, sunt similare sistemelor existente. Cu toate acestea, toate cele trei forma-te au o aceea!i rat# a aspectului de "6:9 în loc de 4:3 pentru a le potrivi mai bine formatului folosit pentru filme (care sunt înregistrate pe 35 mm, cu o rat# de aspect de 3:2).

Sisteme digitale Cea mai simpl# reprezentare a video-ului digital este o secven # de cadre, fiecare constând dintr-

o gril# dreptunghiular# de elemente de imagine, adic# pixeli. Fiecare pixel poate fi un singur bit, pentru a reprezenta fie albul, fie negrul. Calitatea unui astfel de sistem este similar# cu cea ob inut# la transmiterea prin fax a unei fotografii color - adic# groaznic#. (Încerca i dac# pute i; sau fotocopi-a i o fotografie color la o ma!in# de copiat care nu rasterizeaz#.)

SEC. 7.4 MULTIMEDIA 62

Urm#torul pas este de a folosi 8 bi i pe pixel pentru a reprezenta 256 nivele de gri. Aceast# schem# d# o calitate ridicat# video-ului alb-negru. Pentru video color, sistemele bune folosesc 8 bi i pentru fiecare din culorile RGB, de!i aproape toate sistemele le amestec# pentru transmitere într-un video compus. În timp ce folosind 24 de bi i per pixel se limiteaz# num#rul de culori la "6 milioane, ochiul uman nu poate deosebi atâtea culori, deci nici vorb# de mai multe. Imaginile digitale color sunt produse folosind trei raze de scanare, una pentru fiecare culoare. Geometria este aceea!i cu cea pentru sistemul analogic din fig. 7-70, exceptând faptul c# liniile de scanare continue sunt înlocuite acum de linii formate din pixeli discre i.

Pentru a produce mi!c#ri line, video-ul digital, la fel ca video-ul analog, trebuie s# afi!eze cel pu- in 25 de cadre/sec. Oricum, deoarece monitoarele de bun# calitate ale calculatoarelor rescaneaz# deseori ecranul din imagini memorate de 75 de ori pe secund# sau mai des, între eserea nu este ne-cesar# !i, în consecin #, nu este folosit# în mod obi!nuit. Reafi!area (adic# redesenarea) aceluia!i cadru de trei ori la rând este suficient# pentru eliminarea pâlpâirii.

Cu alte cuvinte, continuitatea unei mi!c#ri este determinat# de num#rul de imagini diferite pe se-cund#, având în vedere c# pâlpâirea este determinat# de num#rul de ori pe secund# în care este de-senat ecranul. Ace!ti doi parametri sunt diferi i. O imagine afi!at# la 20 de cadre/sec nu va ar#ta dis-torsionat#, dar va pâlpâi, deoarece un cadru va disp#rea de pe retin# înainte ca urm#torul cadru s# apar#. Un film cu 20 de cadre diferite pe secund#, fiecare dintre acestea fiind desenat de patru ori la rând, nu va pâlpâi, dar va p#rea distorsionat.

Semnifica ia acestor doi parametri devine mai clar# atunci când consider#m l#rgimea de band# pentru transmisia video digital# printr-o re ea. Cele mai multe din monitoarele actuale folosesc rata de aspect de 4:3, astfel încât pot folosi tuburile ieftine din produc ia destinat# pie ei televizoarelor. Configura iile obi!nuite sunt "024x768, "280x960, !i "600x"200. Chiar !i cel mai mic dintre acestea cu 24 bi i pe pixel !i 25 cadre/sec are nevoie s# fie alimentat la 472 Mbps. Pentru aceasta ar fi nevoie de un purt#tor SONET OC-"2, !i de altfel rularea unui purt#tor OC-9 SONET în casa fiec#ruia nu este chiar la ordinea zilei. Dublarea acestei rate pentru a evita pâlpâirea este chiar mai pu in de do-rit. O solu ie mai bun# este transmiterea a 25 cadre/sec pe care calculatorul s# le memoreze !i s# le afi!eze de 2 ori. Televiziunea obi!nuit# nu folose!te aceast# strategie, deoarece televizoarele nu au memorie. $i chiar dac# ar avea memorie, sistemele analogice nu pot fi memorate în RAM f#r# o conversie prealabil# în form# digital#, care necesit# hardware în plus. Ca o consecin #, între eserea este necesar# pentru televiziunea obi!nuit#, dar nu !i pentru video digital.

7.4.7 Compresia video

Ar trebui s# fie evident acum c# transmisia materialului video în form# necomprimat# nu intr# în discu ie. Singura speran # este într-o compresie puternic#. Din fericire, numeroase cercet#ri de câte-va decenii au ajuns la mai multe tehnici de compresie !i algoritmi care fac posibil# transmisia de multimedia. În aceast# sec iune vom studia cum este realizat# compresia video.

Toate sistemele de compresie necesit# doi algoritmi: unul pentru comprimarea datelor la surs# !i altul pentru decomprimarea lor la destina ie. În literatur#, ace!ti algoritmi sunt denumi i algoritmi de codificare !i decodificare. Vom folosi !i aici aceast# terminologie.

Ace!ti algoritmi prezint# câteva asimetrii a c#ror în elegere este important#. Mai întâi, pentru multe aplica ii, un document multimedia, s# zicem un film, va fi codificat o dat# (atunci când este memorat pe un server multimedia), dar va fi decodificat de milioane de ori (atunci când este vizuali-zat de clien i). Aceast# asimetrie înseamn# c# este acceptabil ca algoritmul de codificare s# fie lent !i

622 NIVELUL APLICA!IE CAP. 7

s# necesite un hardware suplimentar scump, cu condi ia ca algoritmul de decodificare s# fie rapid !i s# nu cear# un hardware costisitor. Mai mult, operatorul unui server multimedia ar putea dori s# închirieze un supercalculator paralel pentru câteva s#pt#mâni, pentru a-!i codifica întreaga videote-c#, dar a cere clien ilor s# închirieze un supercalculator pentru 2 ore, pentru a vedea un film nu va avea mare succes. Multe sisteme de compresie fac eforturi pentru ca decodificarea s# fie rapid# !i simpl#, chiar cu pre ul încetinirii !i complic#rii codific#rii.

Pe de alt# parte, pentru multimedia în timp-real, precum conferin e video, codificarea lent# este inacceptabil#. Codificarea trebuie f#cut# din mers, în timp-real. În consecin #, multimedia de timp-real folose!te algoritmi sau parametri diferi i fa # de cei utiliza i pentru memorarea video-urilor pe disc, deseori cu mult mai pu in# compresie.

A doua asimetrie este c# procesul de codificare/decodificare nu trebuie s# fie inversabil. Adic#, atunci când se comprim# un fi!ier, acesta se transmite !i apoi este decomprimat, utilizatorul a!tep-tând s#-l ob in# pe cel original, exact pân# la ultimul bit. Cu multimedia, aceast# cerin # nu exist#. De obicei, este acceptabil ca un semnal video, dup# codificare !i decodificare, s# fie un pic diferit de original. Atunci când ie!irea decodificat# nu este egal# exact cu intrarea original#, sistemul se spune c# este cu pierderi (lossy). Dac# intrarea !i ie!irea sunt identice, sistemul este f"r" pierderi (lossless). Sistemele cu pierderi sunt importante, deoarece acceptarea unui num#r mic de informa ii pierdute poate oferi un avantaj imens în termenii de rat# de compresie posibil#.

Standardul JPEG Un film este doar o secven # de imagini (plus sunet). Dac# am putea g#si un algoritm bun pentru

codificarea unei singure imagini, acest algoritm ar putea fi aplicat succesiv fiec#rei imagini, pentru a ob ine compresia video. Exist# algoritmi buni de compresie a imaginii, deci s# începem acolo studiul nostru despre compresia video. Standardul JPEG (Joint Photographic Experts Group, rom: grupul comun al exper#ilor fotografi) pentru comprimarea imaginilor cu tonuri continue (de exemplu, foto-grafii), a fost dezvoltat de exper ii în fotografii lucrând sub auspiciile ITU, ISO !i IEC, un alt orga-nism de standarde. Este important pentru multimedia deoarece la o prim# aproximare, standardul multimedia pentru filme, MPEG, este codificarea JPEG a fiec#rui cadru separat, plus câteva carac-teristici pentru comprimarea între cadre !i detectarea mi!c#rii. JPEG este definit în Standardul International "09"8.

JPEG are patru moduri !i multe op iuni. Standardul este mai asem#n#tor cu o list# de cump#r#-turi decât cu un simplu algoritm. Pentru scopurile noastre, doar modul secven ial cu pierderi este relevant, iar acesta este ilustrat în fig. 7-7". Cu toate acestea, ne vom concentra asupra modului în care JPEG este folosit în mod normal pentru codificarea imaginilor video de 24-bi i RGB !i vom l#sa la o parte detalii minore pentru simplitate.

Fig. 7-7 . Func ionarea JPEG în modul secven ial cu pierderi.

Pasul " de codificare a imaginii cu JPEG este preg#tirea blocului. Pentru specificare, s# presupu-

nem c# intrarea JPEG este o imagine RGB de 640x480 cu 24 bi i/pixel, ca în fig. 7-72(a). Deoarece folosirea luminan ei !i crominan ei d# o mai bun# compresie, vom calcula mai întâi luminan a, Y, !i cele dou# crominan e, I !i Q (pentru NTSC), dup# formulele urm#toare:

SEC. 7.4 MULTIMEDIA 623

Fig. 7-72. (a) Date de intrare RGB. (b) Dup# preg#tirea blocului.

Y = 0,30R + 0,59G + 0, B I = 0,60R - 0,28G - 0,32B Q = 0,2 R - 0,52G + 0,3 B

Pentru PAL, crominan ele sunt notate cu U !i V !i coeficien ii difer#, dar ideea este aceea!i. SE-CAM difer# atât de NTSC cât !i de PAL.

Pentru Y,I !i Q sunt construite matrice separate, fiecare cu elemente între 0 !i 255. Apoi, blocuri p#trate de patru pixeli sunt aranjate în matricele I !i Q pentru a le reduce la 320x240. Aceast# redu-cere este cu pierderi, dar ochiul abia dac# observ#, deoarece el r#spunde la luminan # mai mult de-cât la crominan #. Cu toate acestea, întreaga cantitate de date este comprimat# cu un factor de doi. Acum se scade "28 din fiecare element al celor trei matrice pentru a aduce zero la mijlocul intervalu-lui. În fine, fiecare matrice este divizat# în blocuri de 8x8. Matricea Y are 4800 blocuri; celelalte dou# au "200 de blocuri fiecare, a!a cum se arat# în fig. 7-72(b).

Pasul 2 al lui JPEG const# în a aplica separat un DCT (Discrete Cosine Transformation, rom: transformare cosinusoidal" discret") pentru fiecare din cele 7200 de blocuri. Ie!irea fiec#rui DCT este o matrice de 8x8 cu coeficien ii DCT. Elementul DCT (0,0) este valoarea medie a blocului. Cele-lalte elemente spun cât# putere spectral# este prezent# la fiecare frecven # spa ial#. Teoretic, DCT este f#r# pierderi, dar în practic# folosirea numerelor în virgul# mobil# !i a func iilor transcendente introduce întotdeauna erori de rotunjire care conduc la o mic# pierdere de informa ii. În mod normal, aceste elemente se mic!oreaz# rapid cu distan a de la origine, (0, 0), a!a cum este sugerat în fig. 7-73.

Fig. 7-73. (a) Un bloc al matricei Y. (b) Coeficien ii DCT.

624 NIVELUL APLICA!IE CAP. 7

Odat# ce DCT-ul este complet, JPEG trece la pasul 3, numit cuantificare (quantization), în care coeficien ii DCT cei mai pu in importan i sunt elimina i. Aceast# transformare (cu pierderi) este f#cut# prin împ#r irea fiec#rui coeficient din matricea DCT de 8*8 la o pondere luat# dintr-o tabel#. Dac# toate ponderile sunt ", transformarea nu face nimic. Totu!i, atunci când ponderile cresc rapid de la origine, frecven ele spa iale înalte sunt eliminate imediat.

Un exemplu al acestui pas este prezentat în fig. 7-74. Aici vedem matricea ini ial# DCT, tabela de cuantificare !i rezultatul ob inut prin împ#r irea fiec#rui element DCT prin elementul corespunz#tor din tabela de cuantificare. Valorile din tabela de cuantificare nu fac parte din standardul JPEG. Fie-care aplica ie trebuie s# !i le furnizeze, permi ând s# se controleze raportul compresie/pierderi.

Fig. 7-74. Calculul coeficien ilor DCT cuantifica i.

Pasul 4 reduce valoarea (0, 0) a fiec#rui bloc (cea din col ul stânga sus), înlocuind-o cu diferen a fa # de elementul corespunz#tor din blocul precedent. Deoarece aceste elemente sunt mediile res-pectivelor blocuri, ele trebuie s# se modifice lent, astfel încât considerarea valorilor diferen iale ar trebui s# reduc# majoritatea dintre ele la valori mici. Diferen ele nu sunt calculate din celelalte va-lori. Valorile (0,0) sunt numite componente DC; celelalte valori sunt componente AC.

Pasul 5 liniarizeaz# cele 64 de elemente !i aplic# listei codificarea dup# lungimea succesiunilor. Scanarea blocului de la stânga la dreapta !i apoi de sus în jos nu va concentra zerourile împreun#, a!a încât se folose!te un model de c#utare în zigzag, ca în fig. 7-75. În acest exemplu, modelul în zig-zag produce 38 de 0-uri consecutive la sfâr!itul matricei. Acest !ir poate fi redus la un singur num#r spunând c# sunt 38 de 0-uri, tehnic# cunoscut# sub numele de codificare dup" lungimea succesiuni-lor (run-length encoding).

Acum avem o list# de numere care reprezint# imaginea (în spa iu transformat). Pasul 6, Huf-fman, codific# numerele pentru memorare sau transmitere, atribuind numerelor mai des întâlnite coduri mai scurte decât ale celorlalte numere.

SEC. 7.4 MULTIMEDIA 625

Fig. 7-75. Ordinea de transmitere a valorilor cuantificate.

JPEG poate p#rea complicat, aceasta pentru c# el este cu adev#rat complicat. Chiar !i a!a, deoa-

rece produce o compresie de 20:" sau mai bun#, este larg folosit. Decodificarea unei imagini JPEG cere execu ia algoritmului în sens invers. JPEG este aproape simetric: decodificarea ia acela!i timp ca !i codificarea. Aceast# proprietate nu este adev#rat# pentru to i algoritmii de compresie, a!a cum vom vedea acum.

Standardul MPEG În fine, ajungem la miezul lucrurilor: standardele MPEG (Motion Picture Experts Group, rom:

grupul exper#ilor în filme). Ace!tia sunt algoritmii principali folosi i pentru compresia video !i sunt standarde interna ionale din "993. Deoarece filmele con in atât imagini cât !i sunete, MPEG le poa-te comprima pe amândou#. Am studiat deja compresia audio !i a imaginilor, deci s# examin#m acum compresia video.

Primul standard finalizat a fost MPEG-" (Standard International """72). Scopul lui a fost de a produce ie!ire video de calitatea video recorder-elor (352x240 pentru NTSC) folosind o rat# de bi i de ",2 Mbps. O imagine 352x240 cu 24 bi i/pixel !i 25 cadre/sec are nevoie de 50,7 Mbps, deci redu-cerea lui la ",2 Mbps nu este în întregime trivial#. MPEG-" poate fi transmis pe linii torsadate la distan e modeste. MPEG-" este de asemenea folosit pentru memorarea filmelor pe CD-ROM.

Urm#torul standard din familia MPEG a fost MPEG-2 (Standard International "38"8), care a fost proiectat ini ial pentru comprimarea video de calitate de difuzare între 4 !i 6 Mbps, pentru a se potrivi într-un canal de difuzare NTSC sau PAL. Mai târziu, MPEG-2 a fost extins pentru a suporta rezolu ii înalte, incluzând HDTV. Este foarte cunoscut, el stând la baza DVD-ului !i a televiziunii prin satelit.

Principiile de baz# ale MPEG-" !i MPEG-2 sunt similare, dar detaliile sunt diferite. La o prim# aproximare, MPEG-2 este un superset al lui MPEG-", cu posibilit# i, formate de cadre, !i op iuni de codificare suplimentare. Vom discuta mai întâi MPEG-" !i apoi MPEG-2.

MPEG-" are trei p#r i: audio, video !i sistem, care le integreaz# pe celelalte dou#, ca în fig. 7-76. Codificatoarele audio !i video lucreaz# independent, ceea ce ridic# întrebarea cum se sincronizeaz# cele dou# fluxuri la receptor. Aceast# problem# se rezolv# având un ceas sistem de 90-kHz, care afi-!eaz# timpul curent pentru ambele codificatoare. Aceste valori sunt pe 33 de bi i, pentru a permite filmelor s# ruleze 24 de ore f#r# dep#!irea valorii maxime. Aceste amprente de timp sunt incluse în ie!irea codificat# !i propagate spre receptor, care le poate folosi pentru sincronizare între !irurile video !i audio.

626 NIVELUL APLICA!IE CAP. 7

Fig. 7-76. Sincronizarea fluxurilor audio !i video în MPEG-".

Acum s# consider#m compresia video MPEG-". Exist# dou# feluri de redundan # în filme: spa i-

al# !i temporal#. MPEG-" le folose!te pe amândou#. Redundan a spa ial# poate fi folosit# prin sim-pla codificare separat# a fiec#rui cadru cu JPEG. Aceast# abordare este câteodat# folosit#, în special atunci când se folosesc accese aleatorii la acela!i cadru, ca în editarea produc iilor video. În acest mod, este ob inut# o l#rgime de band# comprimat# în intervalul 8 Mbps - "0 Mbps.

O comprimare suplimentar# poate fi ob inut# profitând de faptul c#, în general, cadrele consecu-tive sunt aproape identice. Acest efect este mai mic decât poate ap#rea la prima vedere, deoarece mul i fabrican i de filme taie scenele la fiecare 3 sau 4 secunde (cronometra i filmul !i num#ra i sce-nele). Cu toate acestea, chiar o serie de 75 de cadre similare ofer# poten ialul unei reduceri mari fa # de simpla codificare separat# a fiec#rui cadru cu JPEG.

Pentru scene în care aparatul de filmat !i fundalul sunt fixe !i unul sau mai mul i actori se plimb# încet, aproape to i pixelii vor fi identici de la un cadru la altul. În acest caz, sc#zând fiecare cadru din cel precedent !i aplicând JPEG pe diferen a lor, se ob ine un rezultat bun. Cu toate acestea, pentru scenele în care aparatul de filmat mic!oreaz# sau m#re!te, aceast# tehnic# e!ueaz#. Este nevoie de ceva care s# compenseze mi!carea. Aceasta este exact ceea ce face MPEG; este principala diferen # între MPEG !i JPEG.

Ie!irea MPEG-" const# din patru tipuri de cadre:

". Cadre I (Intracoded) : Fotografii codificate JPEG auto-con inute. 2. Cadre P (Predictive): Diferen a bloc cu bloc fa # de ultimul cadru. 3. Cadre B (Bidirectional): Diferen ele fa # de ultimul !i de urm#torul cadru. 4. Cadre D (DC-coded): Medii ale blocurilor folosite pentru avans rapid.

Cadrele I sunt imagini codificate folosind JPEG, folosind de asemenea luminan a cu rezolu ie complet# !i crominan a cu jum#tate de rezolu ie de-a lungul fiec#rei axe. Este necesar s# facem ca aceste cadre I s# apar# periodic în !irul de ie!ire din trei motive. În primul rând, MPEG-" poate fi folosit pentru o transmisie cu trimitere multipl#, cu vizualizatori care le acordeaz# dup# dorin #. Da-c# toate cadrele depind de predecesoarele lor pân# la primul cadru, cineva care a pierdut primul cadru nu va putea decodifica cadrele succesive. În al doilea rând, dac# un cadru a fost recep ionat eronat, nu este posibil# decodificarea în continuare. În al treilea rând, f#r# cadre I, atunci când se face un avans sau o revenire rapid#, decodificatorul ar trebui s# calculeze fiecare cadru peste care trece, a!a încât s# !tie valoarea complet# a cadrului pe care este oprit. Din aceste motive, cadrele I sunt inserate la ie!ire o dat# sau de dou# ori pe secund#.

Cadrele P, în contrast, codific# diferen ele între cadre. Ele se bazeaz# pe ideea de macroblocuri (macroblocks), care acoper# "6x"6 pixeli în spa iul luminan ei !i 8x8 pixeli în spa iul crominan ei. Un macrobloc este codificat prin c#utarea cadrului precedent sau ceva care difer# foarte pu in de el.

SEC. 7.4 MULTIMEDIA 627

Un exemplu unde se folosesc cadrele P este redat în fig. 7-77. Aici vedem trei cadre consecutive care au acela!i fundal, dar difer# prin pozi ia unei persoane. Macroblocurile care con in scena fun-dalului se vor potrivi exact, dar macroblocurile con inând persoana vor fi afi!ate la o pozi ie cu o deplasare de valoare necunoscut# !i va trebui s# fie înregistrate.

Fig. 7-77. Trei cadre consecutive.

Standardul MPEG-" nu specific# cum trebuie f#cut# c#utarea, cât de departe s# se caute sau cât

de bun# trebuie s# fie o potrivire pentru a conta. Aceasta depinde de fiecare implementare. De exemplu, o implementare poate c#uta un macrobloc la pozi ia curent# din cadrul precedent !i toate celelalte deplas#ri ale pozi iilor ! x pe direc ia x !i ! y pe direc ia y. Pentru fiecare pozi ie, poate fi calculat num#rul de potriviri în matricea de luminan #. Pozi ia cu cel mai mare scor va fi declarat# câ!tig#toare, cu condi ia s# fi fost peste un prag predefinit. Altfel, macroblocul se spune c# lipse!te. Sunt desigur posibili !i al i algoritmi mai complica i.

Dac# este g#sit un macrobloc, acesta este codificat luând diferen a fa # de valoarea sa din cadrul anterior (pentru luminan # !i pentru cele dou# crominan e). Aceste matrice de diferen e sunt apoi subiectul unei transform#ri cosinusoidale discrete, sunt cuantificate, codificate cu lungimea succesi-unilor !i codificate Huffman, la fel ca !i cu JPEG. Valoarea pentru macrobloc în fluxul de ie!ire este vectorul de mi!care (cât de departe s-a mi!cat macroblocul din pozi ia lui precedent# pe fiecare di-rec ie), urmat# de lista de numere codificat# Huffman. Dac# macroblocul nu este localizat în cadrul precedent, valoarea curent# este codificat# cu JPEG, la fel ca în cadrul I.

Evident, algoritmul este puternic asimetric. O implementare este liber# s# încerce fiecare pozi ie plauzibil# din cadrul precedent, dac# vrea s-o fac#, într-o încercare disperat# de a localiza fiecare ul-tim macrobloc, oriunde s-ar fi mi!cat acesta. Aceast# tratare va minimiza fluxul MPEG-" codificat, cu pre ul unei codific#ri foarte lente. Aceast# abordare poate fi bun# pentru o singur# codificare a unei filmoteci, dar va fi groaznic# pentru o video conferin # în timp-real.

Similar, fiecare implementare este liber# s# decid# ce înseamn# un macrobloc „g#sit”. Aceast# libertate permite implementatorilor s# concureze prin calitatea !i viteza algoritmilor proprii, dar întotdeauna produce MPEG-". Indiferent de algoritmul de c#utare folosit, ie!irea final# este ori codificarea JPEG a macroblocului curent, ori codificarea JPEG a diferen ei între macroblocul cu-rent !i unul din cadrul precedent la o deplasare specificat# fa # de cel curent.

Pân# acum, decodificarea MPEG-" este direct#. Decodificarea cadrelor I este la fel ca decodifi-carea imaginilor JPEG. Decodificarea cadrelor P cere decodificatorului s# memoreze cadrul prece-dent !i apoi s# construiasc# noul cadru într-un nou tampon bazat pe macroblocuri codificate complet !i macroblocuri care con in diferen e fa # de cadrul precedent. Noul cadru este asamblat macrobloc cu macrobloc.

Cadrele B sunt similare cadrelor P, cu excep ia faptului c# ele permit ca macroblocul de referin # s# fie sau într-un cadru precedent sau în cel urm#tor. Aceast# libertate suplimentar# permite o com-pensare îmbun#t# it# a mi!c#rii !i este de asemenea util# atunci când obiectele trec înaintea sau în

628 NIVELUL APLICA!IE CAP. 7

spatele altor obiecte. Pentru a codifica cadrele B, codificatorul trebuie s# in# în memorie simultan trei cadre decodificate: cel vechi, actualul !i viitorul. De!i cadrele B furnizeaz# cea mai bun# com-presie, nu toate implement#rile le suport#.

Cadrele D sunt folosite doar pentru a face posibil# afi!area imaginilor de rezolu ie mic# atunci când se face o revenire sau o înaintare rapid#. Realizarea decodific#rii MPEG-" normal# în timp-real este destul de dificil#. Cerând ca decodificatorul s-o fac# atunci când se mi!c# prin video de zece ori mai repede decât normal, este prea mult. În schimb, cadrele D sunt folosite pentru a produce imagini de joas# rezolu ie. Fiecare intrare a cadrului D este valoarea medie a unui bloc, f#r# codifi-care ulterioar#, f#când u!oar# afi!area în timp-real. Aceast# facilitate este important# pentru a per-mite oamenilor s# caute prin video, la vitez# mare, o anumit# scen#.

Terminând tratarea lui MPEG-", s# trecem la MPEG-2. Codificarea MPEG-2 este fundamental similar# cu codificarea MPEG-" cu cadre I, P, !i B. Cadrele D nu sunt suportate. De asemenea, transformarea cosinusoidal# discret# folose!te un bloc de "0x"0 în loc de 8x8, pentru a avea cu 50% mai mul i coeficien i !i implicit o calitate mai bun#. Deoarece este destinat televiziunii !i DVD-ului, MPEG-2 suport# atât imagini progresive cât !i între esute, în timp ce MPEG-" suport# doar imagini progresive. Mai sunt !i alte detalii minore care difer# în cele dou# standarde.

În loc de a suporta un singur nivel de rezolu ie, MPEG-2 suport# patru: sc#zut (352x240), princi-pal (720x480), înalt-"440 ("440x""52) !i înalt ("920x"080). Rezolu ia sc#zut# este pentru VCR-uri !i compatibilitate cu MPEG-". Principalul nivel este cel normal pentru difuzarea NTSC. Celelalte dou# sunt pentru HDTV. Pentru o calitate foarte bun# a ie!irii, MPEG-2 ruleaz# în general la 4-8 Mbps.

7.4.8 Video la cerere

Mecanismul de video la cerere este câteodat# comparat cu un magazin de închiriere a casetelor video. Utilizatorul (clientul) selecteaz# una dintr-un num#r mare de casete video pe care le are la dis-pozi ie !i o ia acas# pentru vizionare. Doar c# pentru video la cerere, selec ia este f#cut# acas# folo-sind telecomanda televizorului !i caseta video începe imediat. Nu este necesar un drum pân# la maga-zin. Este inutil s# spunem c# implementarea video-ului la cerere este un pic mai complicat# decât descrierea lui. În aceast# sec iune vom face o prezentare a ideilor de baz# !i a implement#rii lor.

Este video la cerere într-adev#r precum închirierea unei casete video, sau mai degrab# precum alegerea unui film pentru vizionare la sisteme de televiziune prin cablu cu 500 de canale? R#spunsul are importante implica ii tehnice. În particular, utilizatorii de casete video închiriate sunt obi!nui i cu ideea s# opreasc# un film, s# se duc# la buc#t#rie sau la baie !i apoi s# continue din locul în care ca-seta video a fost oprit#. Telespectatorii nu se a!teapt# s# opreasc# un program.

Pentru a concura cu succes cu magazinele de închiriere, video-ul la cerere ar trebui s# poat# opri, porni !i relua casetele video la dorin #. Asigurarea acestei posibilit# i oblig# furnizorul de video s# transmit# o copie separat# fiec#rui utilizator.

Pe de alt# parte, dac# video-ul la cerere este v#zut mai mult ca o televiziune avansat#, atunci este suficient ca furnizorul de casete video s# porneasc# fiecare video popular la fiecare "0 minute !i s# ruleze non-stop. Un utilizator care dore!te s# vad# un astfel de film trebuie s# a!tepte cel mult "0 minute pentru ca el s# înceap#. De!i oprirea !i repornirea nu este posibil# aici, o persoan# care se întoarce în camer# dup# o scurt# pauz#, poate comuta pe un alt canal, care prezint# aceea!i caset# video, dar cu o întârziere de "0 minute. Ceva se va repeta dar nu va fi pierdut nimic. Aceast# schem# este numit# video aproape la cerere (near video on demand). El ofer# posibilitatea unui cost mult mai sc#zut, deoarece acela!i semnal de la furnizorul de casete video poate ajunge la mai mul i utili-

SEC. 7.4 MULTIMEDIA 629

zatori odat#. Diferen a între video la cerere !i video aproape la cerere este similar# cu diferen a între a circula cu ma!ina proprie !i a lua autobuzul.

Urm#rirea filmelor (aproape) la cerere este numai unul dintr-o gam# larg# de noi servicii posibi-le de când este disponibil# re eaua în band# larg#. Modelul general pe care mul i îl folosesc este ilus-trat în fig. 7-78. În centrul sistemului se afl# o re ea cu coloan# vertebral# de arie larg# (na ional# sau interna ional#) cu l#rgime de band# mare. La ea sunt conectate mii de re ele de distribu ie local#, cum ar fi cabluri TV sau sisteme distribuite ale companiei de telefoane. Sistemele de distribu ie loca-l# ajung în casele oamenilor, unde se opresc în cutii de conectare (set-top boxes), care sunt, de fapt, calculatoare personale specializate.

Fig. 7-78. Vedere general# a unui sistem video la cerere.

Mii de furnizori de informa ie sunt ata!a i la coloana vertebral# prin fibre optice de l#rgime de

band# mare. Unii dintre ace!tia vor oferi video cu plata-pe-vizualizare sau CD audio cu plata-pe-ascultare. Altele vor oferi servicii specializate, precum cump#r#turi de la domiciliu (cu posibilitatea de a roti o cutie de sup# !i a m#ri lista de ingrediente sau de a vedea un video-clip despre cum s# conduc# o ma!in# de cosit). F#r# îndoial# c# în curând vor deveni disponibile sporturile, !tirile, relu-#rile la „I Love Lucy”, accesul la WWW !i nenum#ratele alte posibilit# i.

În sistem sunt incluse !i servere locale care permit ca video-urile s# fie amplasate mai aproape de utilizatori (în avans), pentru a economisi l#rgimea de band# în timpul orelor de vârf. Cum se vor po-trivi una cu alta aceste piese !i cui vor apar ine se va dezbate destul în industrie. În cele ce urmeaz#, vom examina cum sunt create piesele principale din sistem: serverele video !i re eaua de distribu ie.

Video-Servere Pentru a avea video (aproape) la cerere, avem nevoie de video-servere (video servers) capabile s#

memoreze !i s# transmit# simultan un num#r mare de filme. Num#rul total de filme realizate este estimat la 65.000 (Minoli, "995). Atunci când este comprimat în MPEG-2, un film normal ocup# în

630 NIVELUL APLICA!IE CAP. 7

jur de 4 GB, a!a c# 65.000 de filme ar necesita în jur de 260 teraocte i. Ad#uga i la aceasta toate pro-gramele vechi de televiziune care au fost vreodat# realizate, filmele de sport, jurnalele sonore, cata-loagele vorbitoare pentru cump#r#turi etc. !i este clar c# ne confrunt#m cu o problem# de înmagazi-nare foarte dificil#.

Cea mai ieftin# solu ie pentru memorarea unui volum mare de informa ie este pe band# magne-tic#. Acesta a fost mereu cazul !i probabil va continua s# fie. O band# Ultrium poate memora 200 GB (50 filme) la un cost de circa " - 2 dolari/film. Actualmente sunt comercializate servere mari, mecanice, de benzi care p#streaz# mii de benzi !i au un bra robotic pentru extragerea fiec#rei benzi !i inserarea ei într-o unitate de band#. Problema cu aceste sisteme este timpul de acces (în special pentru al 50-lea film de pe band#), viteza de transfer !i num#rul limitat de unit# i de band# (pentru a servi n filme deodat#, unitatea necesit# n unit# i).

Din fericire, experien a cu magazinele de închiriat video, bibliotecile publice !i alte astfel de or-ganiza ii arat# c# nu toate produsele sunt la fel de populare. Experimental, atunci când sunt disponi-bile N filme, frac ia tuturor cererilor pentru filmul care ocup# locul k în topul popularit# ii este de aproximativ C/k. Aici C este calculat pentru a normaliza suma la ", cu formula:

C="/("+"/2+"/3+"/4+"/5+…+"/N)

Astfel, filmul de pe primul loc este de !apte ori mai popular decât filmul de pe locul !apte. Acest rezultat este cunoscut drept legea lui Zipf (Zipf, "949).

Faptul c# unele filme sunt mai populare decât altele sugereaz# o solu ie posibil# în forma ierar-hiei de memorare, a!a cum se arat# în fig. 7-79. Aici, performan a cre!te cu cât se urc# în ierarhie.

RAM

Disc magnetic

DVD

Arhivã pe bandã magneticã

Fig. 7-79. Ierarhia video-serverului de memorare.

O alternativ# la înregistrarea pe band# este memoria optic#. DVD-urile actuale memoreaz# 4.7

GB, suficien i pentru un film, dar urm#toarea genera ie va p#stra dou# filme. De!i timpii de c#utare sunt mici în compara ie cu discurile magnetice (50 ms fa # de 5 ms), costul lor sc#zut !i fiabilitatea ridicat# fac din tonomatele optice care con in mii de DVD-uri o alternativ# bun# fa # de band# în cazul filmelor cel mai mult folosite.

Urmeaz# discurile magnetice. Acestea au timp de acces mic (5 ms), viteza de transfer mare (320 MB/sec pentru SCSI 320), !i capacit# i substan iale (> "00 GB), care le fac potrivite pentru memo-rarea filmelor care sunt transmise efectiv (spre deosebire de simpla memorare pentru cazul c# cine-va ar dori vreodat# s# le vad#). Marele lor inconvenient este costul ridicat pentru memorarea filme-lor care sunt rar accesate.

În vârful piramidei din fig. 7-79 este RAM. RAM-ul este cel mai rapid mediu de stocare, dar !i cel mai scump. Atunci când pre urile la RAM ajung la 50 dolari/gigaoctet, un film de 4 GB va ocupa RAM în valoare de 200 dolari, a!a c#, existen a a "00 de filme în RAM va costa 20.000 dolari pentru 200 GB de memorie. În plus, ideea unui video-server care transmite "00 de filme, p#strându-le pe

SEC. 7.4 MULTIMEDIA 63

toate în RAM, începe s# devin# realizabil#. $i dac# video-serverul are "00 de clien i, dar ei se uit# simultan doar la 20 de filme diferite, ideea începe s# par# realizabil#, având un concept bun.

Deoarece un video-server nu este decât un imens dispozitiv de I/O în timp-real, el necesit# o alt# arhitectur# hardware !i software decât un PC sau o sta ie de lucru UNIX. Arhitectura hardware a unui video-server tipic este prezentat# în fig. 7-80. Serverul are una sau mai multe unit# i centrale de înalt# performan #, fiecare cu memorie local#, o memorie principal# partajat#, o memorie tampon RAM de mare capacitate pentru filmele populare, o varietate de echipamente de stocare pentru p#strarea filmelor !i hardware de conectare în re ea, în mod normal o interfa # optic# cu o re ea SONET sau ATM la viteza unui OC-"2 sau mai ridicat#. Aceste subsisteme sunt conectate printr-o magistral# de foarte mare vitez# (cel pu in de " GB/sec).

RAMlocal

RAMlocal

Memorieprincipalã

Memoriecache(RAM)pentru filme

Controlerde bandãmagneticã

Controlerde discoptic

Controlerde disc

magnetic

Interfatãde retea

Arhivã benzi Tonomat optic RAID

Cãtrecoloanavertebral ã

. . .

Magistralãde vitezã mare

CPU CPU

Fig. 7-80. Arhitectura hardware a unui video-server tipic.

Acum s inspect m programele pentru video-server. Unit !ile centrale sunt folosite pentru ac-

ceptarea cererilor utilizatorilor, localizarea filmelor, mutarea datelor între echipamente, taxarea clien!ilor, "i multe alte func!ii. Unele dintre acestea nu sunt critice în timp, dar multe altele sunt, a"a c unele, dac nu toate unit !ile centrale, va trebui s ruleze un sistem de operare de timp-real, cum ar fi un micronucleu de timp-real. În mod normal aceste sisteme împart munca în opera!ii mai sim-ple, fiecare cu un termen final cunoscut. Atunci planificatorul poate rula un algoritm de tip „alege termenul cel mai apropiat” sau un algoritm monoton al vitezelor (Liu "i Layland, #973).

Software-ul unit !ii centrale define"te "i natura interfe!ei pe care serverul o prezint clien!ilor (servere de virtualizare "i cutii de conectare). Exist dou tipuri populare. Primul este un sistem de fi"iere tradi!ional, în care clien!ii pot deschide, citi, scrie "i închide fi"iere. Spre deosebire de compli-ca!iile introduse de ierarhia de memorii "i considera!iile de timp-real, un astfel de server poate avea un sistem de fi"iere modelat dup cel din UNIX.

Al doilea tip de interfa! este bazat pe modelul video-recorderului. Comenzile adresate serveru-lui solicit deschiderea, rularea, oprirea, derularea rapid înainte "i înapoi a fi"ierelor. Diferen!a fa! de modelul UNIX este c atunci când este dat o comand PLAY, serverul continu s transmit date la o vitez constant , f r a necesita comenzi noi.

632 NIVELUL APLICA IE CAP. 7

Inima software-ului video-serverului este sistemul de gestiune a discului. Acesta are dou misiuni principale: plasarea filmelor pe discul magnetic atunci când trebuie extrase de pe band sau din memoria optic "i tratarea cererilor c tre disc pentru multiplele fluxuri de ie"ire. Plasarea filmelor este important , deoarece poate afecta foarte mult performan!ele.

Dou modalit !i de organizare a memor rii pe disc sunt ferma de discuri "i "irul de discuri. În ca-zul fermei de discuri (disk farm), fiecare unitate p streaz doar câteva filme întregi. Din motive de performan! "i fiabilitate, fiecare film trebuie s fie prezent pe cel pu!in dou unit !i, poate chiar mai multe. Cealalt organizare de memorare este cea de tablou de discuri (disk array) sau RAID (Re-dundant Array of Inexpensive Disks - tablou redundant de discuri ieftine), în care fiecare film este împ r!it pe mai multe unit !i, de exemplu blocul 0 pe unitatea 0, blocul # pe unitatea #, "i a"a mai departe, cu blocul n - # pe unitatea n - #. Dup aceasta, ciclul se repet , cu blocul n pe unitatea 0 "i a"a mai departe. Aceast organizare este numit repartizare (striping).

Un tablou de discuri repartizat are mai multe avantaje decât o ferm de discuri. Mai întâi, toate cele n unit !i pot rula în paralel, m rind performan!a cu factorul n. În al doilea rând, poate fi f cut redundant prin ad ugarea unei unit !i în plus la fiecare grup de n, unde unitatea redundant con!ine SAU EXCLUSIV bloc-cu-bloc ale celorlalte unit !i, pentru a permite recuperarea complet a date-lor în cazul în care o unitate se defecteaz . În sfâr"it, problema echilibr rii înc rc rii este rezolvat (nu este necesar plasarea manual pentru evitarea plas rii tuturor filmelor populare pe aceea"i unitate). Pe de alt parte, organizarea de tip tablou de discuri este mai complicat decât ferma de discuri "i mai sensibil la defecte multiple. De asemenea este nepotrivit pentru opera!ii ale video-recorder-ului, cum ar fi derularea rapid a unui film înainte sau înapoi.

Cealalt misiune a software-ului de disc este de a servi toate fluxurile de ie"ire de timp-real "i de a respecta constrângerile de timp ale acestora. Doar acum câ!iva ani, aceasta necesita algoritmi complec"i de planificare a sarcinilor, dar odat cu sc derea pre!urilor la memorie, încep s devin posibile abord ri mult mai simple. Pentru fiecare flux servit, este p strat în RAM o zon tampon (buffer) de, s zicem, #0 secunde de flux video (care înseamn un spa!iu ocupat de 5 MB). El este completat de un proces al discului "i golit de un proces al re!elei. Cu 500 MB de RAM, pot fi servite #00 de fluxuri direct din RAM. Desigur, subsistemul discului trebuie s aib o rat sus!inut de 50MB/sec pentru a p stra zonele tampon pline, dar un RAID construit din discuri SCSI de ultim genera!ie poate s îndeplineasc u"or aceast cerin! .

Re!eaua de distribu!ie Re!eaua de distribu!ie este un set de comutatoare "i linii între surs "i destina!ie. A"a cum vedem

în fig. 7-78, ea const dintr-o coloan vertebral conectat la o re!ea de distribu!ie local . În mod obi"nuit, coloana vertebral este comutat , dar re!eaua local nu.

Principala cerin! impus coloanei vertebrale este l rgimea de band mare. O alt cerin! era ca fluctua!ia s fie sc zut , îns acum, chiar "i cu cel mai mic PC este posibil stocarea într-un tampon a #0 secunde de video de înalt calitate MPEG-2 "i prin urmare, fluctua!ia sc zut nu mai este o necesitate.

Distribu!ia local este haotic , diferite companii încercând diferite re!ele în diferite regiuni. Companiile telefonice, companiile de TV prin cablu "i noii intra!i sunt convin"i cu to!ii c cel care ajunge primul va fi câ"tig torul cel mare. În consecin! asist m la o proliferare a tehnologiilor insta-late. În Japonia, unele companii de canalizare au intrat în afacerea Internet, sus!inând c ele au cele mai mari !evi în casele tuturor (introduc fibr optic prin ele, dar trebuie s fie foarte atente pe unde o scot). Cele patru scheme principale de distribu!ie local pentru video la cerere sunt identificate prin acronimele ADSL, FTTC, FTTH "i HFC. Le vom explica pe fiecare pe rând.

SEC. 7.4 MULTIMEDIA 633

ADSL a fost primul reprezentant al industriei telefonice în loteria distribu!iei locale. Am studiat ADSL în cap. 2 "i nu vom repeta acel material aici. Ideea este c fiecare cas din Statele Unite, Euro-pa "i Japonia are deja o pereche torsadat de cupru (pentru servicii telefonice analogice). Dac aceste fire pot fi folosite pentru video la cerere, companiile telefonice ar putea s elimine concuren!a.

Problema, desigur, este c aceste fire nu pot suporta nici chiar MPEG-# pe lungimea lor tipic de #0 km, ca s nu mai vorbim de MPEG-2. Filmele color, de înalt rezolu!ie, necesit 4-8 Mbps, de-pinzând de calitatea dorit . ADSL nu este suficient de rapid decât pentru bucle locale scurte.

Al doilea proiect al companiei telefonice este FTTC (Fiber To The Curb - fibr c tre vecin tate). În FTTC, compania telefonic instaleaz fibr optic de la oficiul final la fiecare cartier reziden!ial, terminat într-un echipament numit ONU (Optical Network Unit - unitate optic de re!ea). Cele #6 bucle locale de cupru se pot termina în ONU. Aceste bucle sunt acum atât de scurte, încât este posi-bil rularea duplex integral T# sau T2 peste ele, permi!ând filmele MPEG-# "i respectiv MPEG-2. În plus, deoarece FTTC este simetric, acum este posibil video conferin!a pentru cei care lucreaz acas "i pentru întreprinderile mici.

A treia solu!ie a companiei telefonice este de a introduce fibra optic în casele tuturor. Se nu-me"te FTTH (Fiber To The Home - fibr la cas ). În aceast schem , oricine poate avea OC-#, OC-3, sau chiar un purt tor mai performant, dac este cerut. FTTH este foarte scump, dar va deschide o gam larg de posibilit !i atunci când va fi introdus. În fig. 7-63 am v zut cum oricine ar putea s aib propriul s u post de radio. Ce-a!i zice de ideea ca fiecare membru al familiei s aib propriul post de televiziune? ADSL, FTTC "i FTTH sunt toate re!ele locale de distribu!ie punct-la-punct, ceea ce nu este surprinz tor dat fiind organizarea actual a sistemului telefonic.

O abordare complet diferit este HFC (Hybrid Fiber Coax - fibr coaxial hibrid ), care este so-lu!ia preferat actualmente, fiind instalat în prezent de c tre firmele de televiziune prin cablu. Aceasta este prezentat în Fig. 2-47(a). Povestea este urm toarea. Cablurile coaxiale actuale de la 300 la 450 MHz vor fi înlocuite prin cabluri coaxiale la 750 MHz, îmbun t !ind capacitatea de la 50 la 75 canale de 6 MHz la #25 canale de 6-MHz. $aptezeci "i cinci din cele #25 de canale vor fi folosi-te pentru transmiterea televiziunii analogice.

Cele 50 de canale noi vor fi modulate folosind QAM-256, care furnizeaz în jur de 40 Mbps pe canal, dând un total de 2 Gbps de l rgime de band nou . Capetele vor fi mutate în cartier, a"a încât fiecare cablu este doar pentru 500 de case. Simpla împ r!ire arat c fiec rei case îi poate fi alocat un canal dedicat de 4 Mbps, care poate fi folosit pentru un film MPEG-2.

De"i sun minunat, cere furnizorilor de cabluri s le înlocuiasc pe cele existente cu cabluri coa-xiale de 750 MHz, s instaleze noile capete de distribu!ie "i s elimine toate amplificatoarele unidi-rec!ionale - pe scurt, s înlocuiasc întregul sistem de TV prin cablu. În consecin! , volumul de in-frastructur nou este comparabil cu ceea ce este necesar companiilor telefonice pentru FTTC. În ambele cazuri, furnizorul re!elei locale trebuie s instaleze fibra optic în cartierele reziden!iale. Din nou, în ambele cazuri, fibra se termin la un convertor optic-electric. În FTTC, segmentul final este o bucl local punct-la-punct care folose"te perechi torsadate. În HFC, segmentul final este un cablu coaxial partajat. Tehnic vorbind, aceste dou sisteme nu sunt chiar atât de diferite pe cât vor s le prezinte creatorii lor.

Cu toate acestea, exist o diferen! real care merit s fie amintit . HFC folose"te un mediu parta-jat f r comutare sau dirijare. Orice informa!ie transmis prin cablu poate fi preluat de orice abonat f r mult zarv . FTTC, care este complet comutat, nu are aceast proprietate. Ca rezultat, operatorii HFC vor ca video-serverele s trimit fluxuri criptate, a"a încât clien!ii care nu au pl tit pentru un film, s nu-l poat vedea. Operatorii FTTC nu doresc criptarea deoarece m re"te complexitatea, scade per-

634 NIVELUL APLICA IE CAP. 7

forman!a "i nu furnizeaz securitate suplimentar în sistemul lor. Din punctul de vedere al unei com-panii care ruleaz un video-server, este o bun idee s se cripteze sau nu? Un server folosit de o com-panie telefonic sau unul din subsidiarii sau partenerii s i poate s decid s nu cripteze video-urile, pretinzând eficien!a ca motiv, dar de fapt pentru a cauza pierderi economice competitorilor HFC.

Pentru toate re!elele locale de distribu!ie, este posibil c fiecare cartier va fi echipat cu unul sau mai multe servere de virtualizare. Acestea sunt, de fapt, doar versiuni mai mici ale video-serverelor despre care am discutat înainte. Marele avantaj al acestor servere locale este c reduc înc rcarea coloanei vertebrale.

Ele pot fi preînc rcate cu filme fie dinamic, fie prin rezervare. Dac oamenii spun furnizorului în avans ce filme doresc, ele pot fi transferate pe serverul local în afara orelor de vârf. Aceast observa!ie orienteaz operatorii de re!ea spre atragerea personalului de la companiile aeriene pentru stabilirea tarifelor. Se pot imagina tarife în care filmele cerute cu 24 pân la 72 de ore în avans pentru a fi viziona-te mar!ea sau joia înainte de 6 seara sau dup ## seara, primesc o reducere de 27 la sut . Filmele co-mandate în prima duminic a lunii înainte de 8 diminea!a pentru a fi vizionate miercuri dup -amiaza, într-o zi a c rei dat este un num r prim, beneficiaz de o reducere de 43 la sut "i a"a mai departe.

7.4.9 MBone - Coloana vertebral" pentru trimitere multipl"

În timp ce toate aceste industrii fac planuri mari - "i îndelung mediatizate - pentru viitorul video la cerere (inter)na!ional, digital, comunitatea Internet "i-a implementat propriul sistem multimedia digital, MBone (Multicast Backbone - coloana vertebral cu trimitere multipl ). În aceast sec!iune vom face o scurt sintez a ceea ce este "i cum func!ioneaz .

MBone poate fi gândit ca radio "i televiziune Internet. Spre deosebire de video la cerere, unde accentul cade pe selectarea "i vizualizarea filmelor precomprimate memorate pe un server, MBone este folosit pentru difuzare audio "i video în form digital în lumea întreag prin Internet. Este ope-ra!ional de la începutul lui #992. Multe conferin!e "tiin!ifice, în special întâlniri IETF, au fost difuza-te, la fel ca "i evenimentele "tiin!ifice notabile, cum ar fi lansarea navetelor spa!iale. Prin MBone a fost difuzat un concert Rolling Stones, precum "i por!iuni din Festivalul de film de la Cannes. Este discutabil dac acesta poate fi calificat drept un eveniment "tiin!ific.

Din punct de vedere tehnic, MBone este o re!ea virtual situat deasupra Internet-ului. Ea con-st din insule cu posibilit !i de trimitere multipl , conectate prin tuneluri, a"a cum se arat în fig. 7-8#. În aceast figur , MBone const din "ase insule, de la A la F, conectate prin "apte tuneluri. Fieca-re insul (de obicei un LAN sau un grup de LAN-uri interconectate) suport trimitere multipl har-dware c tre calculatoarele gazd . Tunelurile propag pachetele MBone între insule. Cândva, în vii-tor, când toate ruterele vor fi capabile s gestioneze direct traficul cu trimitere multipl , aceast superstructur nu va mai fi necesar , dar pentru moment este func!ional .

Fiecare insul con!ine unul sau mai multe rutere specializate numite m-rutere (mrouters - rutere cu trimitere multipl ). Câteva dintre acestea sunt rutere normale, dar majoritatea sunt numai sta!ii UNIX care ruleaz software-ul special de nivel utilizator (dar ca supervizor). M-ruterele sunt conec-tate logic prin tuneluri. Pachetele MBone sunt încapsulate în pachete IP "i trimise ca pachete obi"-nuite cu trimitere unic la adresa IP a m-ruterului destina!ie.

Tunelurile sunt configurate manual. În mod uzual, un tunel este o cale pentru care exist o cone-xiune fizic , dar aceasta nu este o cerin! . Dac , accidental, calea fizic asociat unui tunel se defec-teaz , m-ruterele care folosesc tunelul nu vor observa, deoarece Internet-ul va redirija automat în-tregul trafic IP dintre ele prin alte linii.

SEC. 7.4 MULTIMEDIA 635

Fig. 7-8#. MBone const din insule de trimitere multipl conectate prin tunele.

Atunci când apare o nou insul "i dore"te s se ata"eze la MBone, precum G din fig. 7-8#, admi-

nistratorul s u trimite un mesaj anun!ând existen!a acesteia c tre lista de po"t a MBone-ului. Admi-nistratorii siturilor apropiate îl contacteaz pentru a stabili tunelurile. Câteodat tunelurile existente sunt reconfigurate, astfel încât s profite de noua insul pentru a optimiza topologia. La urma urme-lor, tunelurile nu au existen! fizic . Ele sunt definite prin tabele în m-rutere "i pot fi ad ugate, "terse, sau mutate prin simpla schimbare a acestor tabele. Tipic, fiecare !ar din MBone are o coloan verte-bral cu insule regionale ata"ate acesteia. În mod normal, MBone este configurat cu unul sau dou tuneluri care traverseaz oceanele Atlantic "i Pacific, aducând MBone-ul la scar global .

Astfel, în orice moment, MBone const dintr-o topologie specific alc tuit din insule "i tuneluri, independent de num rul adreselor de trimitere multipl utilizate curent "i de cine le ascult sau le urm re"te. Aceast situa!ie este foarte asem n toare cu cea a unei subre!ele normale (fizice), a"a încât i se aplic algoritmii normali de dirijare. În consecin! , MBone a folosit ini!ial un algoritm de dirijare, DVMRP (Distance Vector Multicast Routing Protocol - dirijare multi-destina!ie dup vecto-rul distan!elor) bazat pe algoritmul vectorului distan!elor al lui Bellman-Ford. De exemplu, în fig. 7-8#, insula C poate dirija c tre A prin B sau prin E (sau prin D). Î"i alege varianta luând valorile pe care i le dau nodurile despre distan!ele de la ele pân la A "i apoi ad ugând distan!a proprie pân la ele. În acest mod, fiecare insul determin ruta optim c tre fiecare alt insul . Totu"i, rutele nu sunt de fapt folosite în acest mod, ci a"a cum vom vedea în curând.

S consider m acum modul în care se realizeaz trimiterea multipl . Pentru a transmite la mai multe destina!ii un program audio sau video, o surs trebuie s achizi!ioneze mai întâi o adres de destina!ie multipl de clas D, care ac!ioneaz ca o frecven! de sta!ie sau un num r de canal. Adre-sele de clas D sunt rezervate prin folosirea unui program care caut într-o baz de date adrese de destina!ie multipl libere. Multe trimiteri multiple pot s se desf "oare în acela"i timp, iar un calcula-tor gazd poate „s se acordeze” pe cea de care este interesat prin ascultarea adrese de destina!ie multipl potrivite.

Periodic, fiecare m-ruter trimite un pachet de difuzare IGMP limitat la insula lui, întrebând cine este interesat de ce canal. Calculatoarele gazd care doresc s (continue s ) primeasc unul sau mai

636 NIVELUL APLICA IE CAP. 7

multe canale trimit alt pachet IGMP înapoi drept r spuns. Aceste r spunsuri sunt dispersate în timp pentru a evita supraînc rcarea LAN-ului local. Fiecare m-ruter p streaz o tabel cu canalele care trebuie puse în LAN-ul propriu, pentru a evita pierderea de l rgime de band prin canale de trans-mitere multipl pe care nu le vrea nimeni.

Trimiterile multiple se propag prin MBone dup cum urmeaz . Când o surs audio sau video genereaz un nou pachet, îl difuzeaz c tre insula sa local folosind facilit !ile hardware de trimitere multipl . Acest pachet este preluat de un m-ruter local, care îl copiaz pe toate tunelurile cu care este conectat.

Fiecare m-ruter care prime"te un astfel de pachet printr-un tunel verific dac pachetul a venit pe cea mai bun rut , adic cea pe care tabela proprie îi spune s o foloseasc pentru a ajunge la surs (ca "i cum ar fi o destina!ie). Dac pachetul a venit pe ruta cea mai bun , m-ruterul îl copiaz la toate celelalte tuneluri. Dac pachetul a ajuns pe o cale care nu este cea optimal , el este eliminat. Astfel, de exemplu, în fig. 7-8#, dac tabela lui C spune s se foloseasc B pentru a ajunge la A, atunci când un pachet cu trimitere multipl de la A ajunge la C prin B, el este copiat la D "i E. Cu toate acestea, atunci când un pachet cu trimitere multipl de la A ajunge la C prin E (nu este calea cea bun ), el este eliminat. Acest algoritm este algoritmul retransmiterii pe calea invers prezentat în Cap. 5. De"i nu este perfect, este destul de bun "i foarte u"or de implementat.

În plus fa! de folosirea algoritmului de c utare pe calea invers , pentru prevenirea inund rii In-ternet-ului "i pentru a limita domeniul trimiterii multiple, este folosit câmpul IP Time_to_live (timp de via! ). Fiecare pachet pleac cu o anumit valoare (determinat de surs ). Fiec rui tunel i se aso-ciaz o pondere. Un pachet este trecut printr-un tunel dac are o pondere suficient . Altfel este eli-minat. De exemplu, tunelurile transoceanice sunt configurate în mod obi"nuit cu o pondere de #28, a"a încât pachetele pot fi limitate la continentul de origine dându-li-se un timp de via! ini!ial mai mic sau egal cu #27. Dup trecerea printr-un tunel, câmpul Time to live este decrementat cu ponde-rea tunelului.

De când func!ioneaz algoritmul de dirijare MBone, s-au f cut multe cercet ri pentru a-l îmbu-n t !i. O propunere p streaz ideea dirij rii dup vectorul distan!elor, dar face algoritmul ierarhic, prin gruparea siturilor MBone în regiuni "i dirijarea în prima etap c tre acestea (Thyagarajan "i Deering, #995).

O alt propunere este de a folosi o form modificat a dirij rii în func!ie de starea leg turilor, în loc de dirijare dup vectorul distan!elor. În particular, un grup de lucru IETF se ocup de modifica-rea OSPF pentru a-l face potrivit pentru trimitere multipl în cadrul unui singur sistem autonom. Trimiterea multipl OSPF rezultat este numit MOSPF (Moy, #994). Modific rile se refer la crearea de c tre MOSPF a unei h r!i complete care, în plus fa! de informa!ia vizual de dirijare, s !in eviden!a insulelor de trimitere multipl "i a tunelurilor. Înarmat cu aceast topologie complet , este u"or s calcul m cea mai bun cale de la fiecare insul c tre fiecare alt insul folosind tuneluri-le. De exemplu, poate fi folosit algoritmul lui Dijkstra.

A doua arie de cercetare este dirijarea inter-AS. Aici un alt grup de lucru IETF dezvolt un algo-ritm numit PIM (Protocol Independent Multicast - transmitere multipl independent de protocol). PIM are dou versiuni, dup cum insulele sunt dense (aproape oricine vrea s se uite) sau rare (aproape nimeni nu vrea s se uite). Ambele versiuni folosesc tabele de dirijare standard cu trimitere unic în loc de a crea o topologie suprapus , a"a cum fac DVMRP sau MOSPF.

În PIM-DM (modul dens), ideea este de a t ia c ile inutile. T ierea func!ioneaz în modul ur-m tor. Atunci când un pachet cu trimitere multipl ajunge printr-un tunel „gre"it”, un pachet de t iere este trimis înapoi prin tunel, spunând emi! torului s nu-i mai transmit pachete de la sursa

SEC. 7.5 REZUMAT 637

respectiv . Când un pachet ajunge prin tunelul „bun”, este copiat pe toate celelalte tuneluri care nu s-au auto-t iat anterior. Dac toate celelalte tuneluri s-au auto-t iat "i canalul din insula local nu este interesat, m-ruterul trimite un mesaj de t iere înapoi prin canalul „bun”. În acest fel, trimiterea multipl se adapteaz automat "i merge doar unde este dorit .

PIM-SM (modul rar), descris în RFC 2362, lucreaz diferit. Aici ideea este de a preveni satura-rea Internetului, doar pentru c trei persoane din Berkeley vor s !in o conferin! peste o adres de clas D. PIM-SM func!ioneaz prin fixarea unor puncte de întâlnire. Fiecare dintre sursele dintr-un grup cu trimitere multipl PIM-SM î"i trimite pachetele la punctele de întâlnire. Orice sit interesat în ata"are, cere unui punct de întâlnire s -i seteze un tunel. În acest mod, tot traficul PIM-SM este transportat prin transmitere simpl , în loc de transmitere multipl . PIM-SM devine tot mai popular "i MBONE migreaz c tre folosirea lui. Pe m sur ce PIM-SM devine mai mult folosit, MOSPF dispare treptat. Pe de alt parte, însu"i MBONE pare într-un fel s stagneze "i probabil niciodat nu va deveni foarte popular.

Totu"i, multimedia prin re!ea este înc un domeniu foarte interesant, care evolueaz rapid, chiar dac MBONE nu devine un succes uria". Zilnic sunt anun!ate noi tehnologii "i aplica!ii. Mai mult, transmiterea multipl "i calitatea serviciului func!ioneaz împreun , dup cum se prezint în (Striegel "i Manimaran, 2002). Alt subiect fierbinte este transmisia multipl f r fir (wireless) (Gos-sain et. al., 2002). Întregul domeniu al transmisiunilor multiple "i orice este legat de el va r mâne, probabil, important pentru urm torii ani.

7.5 REZUMAT

Atribuirea numelor în Internet folose"te o schem ierarhic , numit sistemul numelor de dome-nii (DNS). La nivelul superior, exist bine cunoscutele domenii generice, incluzând com "i edu, pre-cum "i cele aproximativ 200 domenii pentru ! ri. DNS este implementat ca un sistem de baze de date distribuite, cu servere în întreaga lume. DNS p streaz înregistr ri cu adrese IP, centre de me-sagerie "i alte informa!ii. Prin interogarea unui server DNS, un proces poate stabili coresponden!a dintre un nume de domeniu Internet "i o adres IP folosit pentru a comunica cu acel domeniu.

E-mail este una din cele dou aplica!ii foarte populare din Internet. Oricine, de la copii la bunici, o poate folosi acum. Cele mai multe sisteme de po"t electronic din lume folosesc sistemul definit în RFC 282# "i 2822. Mesajele trimise în acest sistem folosesc antete de sistem ASCII pentru defini-rea propriet !ilor mesajului. Materiale cu diverse tipuri con!inut pot fi transmise folosind MIME. Mesajele sunt transmise folosind SMTP, care lucreaz f când o conexiune TCP de la sistemul surs la cel de destina!ie "i livrând în mod direct e-mail-ul peste conexiunea TCP.

O alt aplica!ie foarte popular pentru Internet este World Wide Web. Web-ul este un sistem pentru legarea documentelor "hipertext". Ini!ial, fiecare document era o pagin scris în HTML, cu posibile hiper-leg turi la alte documente. Azi, XML câ"tig teren în fa!a HTML. De asemenea, un mare volum de informa!ie este generat dinamic, folosind script-uri executate de server (eng.:server-side scripts) (PHP, JSP "i ASP), precum "i script-uri executate de client (eng.: client-side scripts) (de remarcat aici Javascript). Un program de navigare poate afi"a documentul stabilind o conexiune TCP cu serverul s u, cerând documentul "i apoi închizând conexiunea. Aceste mesaje de cerere con-!in o mul!ime de antete pentru asigurarea informa!iei suplimentare. Folosirea memoriei ascunse,

638 NIVELUL APLICA IE CAP. 7

replicarea "i re!elele de livrare a con!inutului sunt folosite pe scar larg pentru a îmbun t !i per-forman!ele Web-ului.

Web-ul f r fir este de-abia la început. Primele sisteme sunt WAP "i i-mode, fiecare cu ecrane mici "i lungime de band limitate, dar cele din genera!ia urm toare vor fi mai puternice.

Multimedia este "i ea o stea pe firmamentul re!elelor. Se permite ca semnalele video "i audio s fie digitizate "i transportate electronic pentru afi"are. Audio necesit mai pu!in l rgime de band , astfel c este mai avansat. Fluxurile audio, radio prin Internet "i vocea prin IP (voice over IP) sunt acum o realitate, iar noile aplica!ii apar permanent. Video la cerere este un domeniu de viitor, de mare interes. În sfâr"it, Mbone este un serviciu experimental, bazat pe televiziunea "i radioul digital trimise peste Internet.

7.6 PROBLEME

#. Multe calculatoare ale unor firme au trei identificatori universali, unici. Care sunt ei?

2. Dup informa!iile date în fig. 7-3, little-sister.cs.vu.nl se afl într-o re!ea de clas A, B, sau C?

3. În fig. 7-3, nu este nici un punct dup rowboat? De ce nu?

4. Ghici!i ce ar putea s însemne smiley-ul :-X (uneori scris ca :-#).

5. DNS folose"te UDP în loc de TCP. Pachetele DNS pierdute nu pot fi recuperate automat. Cau-zeaz acest lucru probleme, "i dac da, cum sunt ele rezolvate?

6. În plus fa! de problema pierderilor, pachetele UDP au o dimensiune maxim , uneori ajungând chiar la minimum 576 octe!i. Ce se întâmpl când numele DNS c utat dep "e"te aceast dimensiune? Poate fi trimis în dou pachete?

7. Se poate ca o ma"in cu un singur nume DNS s aib mai multe adrese IP? Cum ar putea s se întâmple acest lucru?

8. Este posibil ca un calculator s aib dou nume DNS care apar!in de dou domenii de nivel înalt? Dac da, da!i un exemplu plauzibil. Daca nu, explica!i de ce.

9. Num rul de companii cu site Web a crescut exploziv în ultimii ani. Ca rezultat, mii de companii au fost înregistrate în domeniul com, ducând la o înc rcare mare a serverului pentru acest do-meniu. Sugera!i o cale de a diminua aceast problem f r a schimba schema de nume (adic f r a introduce noi domenii de nivel înalt). Este permis ca solu!ia s impun schimbarea codu-lui de la client.

#0. Unele sisteme de e-mail suport în antet câmpul Content Return:. El specific dac corpul mesa-jului trebuie s fie returnat în cazul imposibilit !ii livr rii. Acest câmp apar!ine plicului sau con-!inutului?

SEC. 7.6 PROBLEME 639

##. Sistemele de po"t electronic au nevoie de registre pentru a putea c uta adresele de e-mail. Pentru a construi asemenea registre, numele ar trebui s fie separate în componentele standard (de exemplu nume, prenume) pentru a putea fi f cute c ut ri. Discuta!i unele dintre probleme-le ce trebuie rezolvate pentru acceptarea universal a unui astfel de standard.

#2. Adresa de e-mail a unei persoane este numele s u de utilizator @ numele DNS cu o înregistra-re MX. Numele de utilizator pot fi prenume, nume, ini!iale, tot felul de alte nume. S presupu-nem c o firm mare a decis c se pierdea prea mult e-mail din cauz c lumea nu cuno"tea numele de utilizator al destinatarului. Exist vreo modalitate pentru ca ei s rezolve aceast pro-blem f r schimbarea DNS-ului? Dac da, da!i o propunere "i explica!i cum func!ioneaz . Da-c nu, explica!i de ce este imposibil.

#3. Un fi"ier binar are lungimea de 3072 de bi!i. Cât de lung va fi dac îl codific m folosind base64, cu perechea CR+LF inserat dup fiecare 80 de octe!i transmi"i "i la sfâr"it?

#4. Considera!i schema de codificare MIME afi"abil -marcat . Men!iona!i o problem nediscutat în text "i propune!i o solu!ie.

#5. Da!i cinci tipuri MIME care nu sunt listate în text. Pute!i s verifica!i browser-ul dvs. sau s c u-ta!i pe Internet.

#6. S presupunem c vre!i s trimite!i un fi"ier MP3 la un prieten, dar ISP-ul prietenului limiteaz dimensiunea unui mesaj la # MB iar fi"ierul MP3 are 4 MB. Exist vreo modalitate de a rezolva problema aceasta folosind RFC 822 "i MIME?

#7. S presupunem c cineva instaleaz un demon de vacan! (vacation daemon) "i apoi trimite un mesaj chiar înainte de a ie"i din sistem. Din p cate, destinatarul este în vacan! de o s pt mân "i are de asemenea instalat un demon de vacan! . Ce se întâmpl în continuare? Replicile vor fi trimise dintr-o parte în alta pân când se va întoarce cineva?

#8. În orice standard, ca de exemplu RFC 822, este necesar o gramatic precis a ceea ce este permis astfel încât implement ri diferite s poat conlucreze. Chiar "i unit !ile simple trebuie s fie definite cu aten!ie. Antetele SMTP permit existen!a spa!iului între simboluri. Da!i dou definiri plauzibile ale spa!iului dintre simboluri.

#9. Demonul de vacan! este parte a agentului utilizator sau a agentului de transfer? Desigur, este instalat folosind agentul utilizator, dar cel care trimite replicile este chiar agentul utilizator? Ex-plica!i r spunsul.

20. POP3 permite utilizatorilor s aduc mesajele de e-mail dintr-o cutie po"tal de la distan! . Aceasta înseamn c formatul intern al cutiilor po"tale trebuie s fie standard pentru ca orice program POP3 de la client s poat s citeasc cutia po"tal de pe orice server de po"t electro-nic ? Discuta!i r spunsul.

2#. Din punctul de vedere al unui ISP, POP3 "i IMAP difer într-o m sur important . Utilizatorii POP3 î"i golesc în general cutiile po"tale zilnic. Utilizatorii IMAP î"i p streaz mesajele pe ser-ver un timp nedefinit. Imagina!i-v c vi se cere s sf tui!i un ISP ce protocol ar trebui s supor-te. Ce argumente a!i aduce?

640 NIVELUL APLICA IE CAP. 7

22. Po"ta pe Web(Webmail) folose"te POP3, IMAP sau nici unul? Dac folose"te unul din ele, de ce a fost ales acela? Dac nici unul, care este mai aproape de idee?

23. Când sunt transmise, paginile de Web sunt prefixate de antete MIME. De ce?

24. Când sunt necesare programe de vizualizare externe? Cum "tie un program de navigare pe care s -l foloseasc ?

25. Este posibil ca atunci când un utilizator urmeaz pe o hiper-leg tur în Netscape, s fie pornit un anumit program, iar urmând aceea"i hiper-leg tur în Internet Explorer s fie pornit un pro-gram complet diferit, chiar dac tipul MIME întors în ambele cazuri este identic? Explica!i r s-punsul.

26. Un server Web cu mai multe fire de execu!ie este organizat ca în fig. 7-2#. Dureaz 500 µsec s accepte o cerere "i s verifice memoria ascuns . Jum tate din timp, fi"ierul este g sit în memoria ascuns "i este întors imediat. Cealalt jum tate, modulul trebuie s se blocheze 9 ms pân când cererea la disc este ad ugat în coad "i procesat . Câte module ar trebui s aib serverul pen-tru a !ine procesorul ocupat tot timpul (presupunând c discul nu reprezint o gâtuire (bottleneck))?

27. URL-ul standard http presupune c serverul de Web ascult pe portul 80. Totu"i, e posibil ca un server de Web s asculte pe alt port. N scoci!i o sintax rezonabil pentru URL pentru accesa-rea unui fi"ier pe un port nestandard.

28. Cu toate c nu a fost men!ionat în text, o form alternativ pentru un URL este folosirea adre-sei IP în loc de numele s u DNS. Un exemplu de folosirea a adresei IP este http://!92.3!.23!.66/index.html. Cum "tie programul navigator dac numele ce urmeaz schema este un nume DNS sau o adres IP?

29. Imagina!i-v c cineva de la Departamentul CS din Stanford a scris un nou program pe care vrea s -l distribuie prin FTP. El pune programul în catalogul ftp/pub/freebies/newprog.c. Care es-te URL-ul probabil pentru acest program?

30. În fig. 7-25, www.aportal.com !ine eviden!a preferin!elor utilizatorilor într-un cookie. Un dez-avantaj al acestei scheme este c cookie-urile sunt limitate la 4KB "i dac preferin!ele sunt ex-tinse, de exemplu la multe valori ale ac!iunilor, echipe sportive, tipuri de "tiri, vremea în multe ora"e, ofertele din diverse categorii de produse "i altele, limita de 4KB ar putea fi insuficient . Proiecta!i o alternativ pentru p strarea preferin!elor utilizatorului pentru a nu avea aceast problem .

3#. Banca Sloth (Trând vie) dore"te s fac opera!iile bancare mai simple pentru utilizatorii mai lene"i, astfel încât dup ce un utilizator se autentific , banca îi returneaz identificatorul de cli-ent într-un cookie. Ce p rere ave!i de aceast idee? Va func!iona? Este o idee buna?

32. În fig. 7-26, în marcajul <IMG> apare parametrul ALT. În ce condi!ii este folosit de programul de navigare "i cum?

33. Realiza!i o imagine selectabil în HTML? Da!i un exemplu.

SEC. 7.6 PROBLEME 64#

34. Ar ta!i cum marcajul <a> poate fi folosit pentru a face "irul „ACM” un hiper-leg turi c tre http://www.acm.org.

35. Proiecta!i un formular pentru o nou companie, InterBurger, care permite comanda hamburge-rilor prin Internet. Formularul trebuie s con!in numele clientului, adresa, ora"ul, ca "i o op!iu-ne asupra dimensiunii (ori gigant, ori imens) "i o op!iune pentru brânz . Burger-ii urmeaz a fi pl ti!i la livrare cu bani ghea! , a"a c nu este necesar nici o informa!ie despre cartea de credit.

36. Proiecta!i un formular care cere utilizatorului s tasteze dou numere. Când utilizatorul apas pe butonul de trimitere, serverul întoarce suma lor. Scrie!i partea care ruleaz la server ca un script PHP.

37. Pentru fiecare din aplica!iile urm toare, spune!i (#) dac este posibil "i (2) dac este mai bine s se foloseasc un script PHP sau JavaScript "i de ce. (a) Afi"area unui calendar pentru orice lun începând cu septembrie #752. (b) Afi"area unui program al zborurilor de la Amsterdam la New York. (c) Graficul unui polinom cu coeficien!ii da!i de utilizator.

38. Scrie!i un program JavaScript care accept un întreg mai mare ca 2 "i spune dac este, sau nu, un num r prim. Nota!i c JavaScript are instruc!iunile if "i while cu aceea"i sintax ca în C sau Java. Operatorul modul este %. Dac ave!i nevoie de r d cina p trat a lui x, folosi!i Math.sqrt(x).

39. O pagin HTML este de forma: <html> <body> <a href=”www.info-source.com/welcome.html”> Ap sa!i aici pentru informa!ii </a> </body> </html>

Dac utilizatorul apas pe hiper-leg tur , este deschis o conexiune TCP "i este trimis o serie de linii la server. Scrie!i toate liniile trimise.

40. Antetul If-Modified-Since poate fi folosit pentru a vedea dac o pagin din memoria ascuns este înc valid . Cererile pot fi pentru pagini con!inând imagini, sunete, video etc., precum "i HTML. Crede!i c eficacitatea acestei tehnici este mai bun sau mai rea pentru imagini JPEG în compa-ra!ie cu HTML? Gândi!i bine la ceea ce „eficacitate” înseamn "i explica!i r spunsul vostru.

4#. În ziua unui mare eveniment sportiv, cum ar fi un campionat sportiv, mult lume se duce pe situl Web oficial. Este aceasta o aglomerare brusc în acela"i sens cu cel al alegerilor din Flori-da, în 2000? De ce sau de ce nu?

42. Are sens ca un singur ISP s aib rolul de CDN? Dac da, cum ar func!iona? Dac nu, care este gre"it în leg tur cu aceast idee?

43. În ce condi!ii folosirea unui CDN este o idee proast ?

44. Terminalele pentru Web-ul f r fir(Wirelss Web) au o l !ime de band mic , ceea ce face im-portant o codificare eficient . Proiecta!i o schem de transmitere eficient a textului în englez pe o leg tur f r fir c tre un dispozitiv WAP. Pute!i presupune c terminalul are câ!iva mega-

642 NIVELUL APLICA IE CAP. 7

octe!i de memorie ROM "i un procesor moderat de puternic. Indiciu: gândi!i-v cum transmite!i ceva în japonez , unde fiecare simbol este un cuvânt.

45. Un CD memoreaz 650 MB de date. Este folosit compresia pentru CD-uri audio? Explica!i ra!ionamentul.

46. În fig. 7-57(c) zgomotul de cuantificare apare datorit folosirii de e"antioane pe 4 bi!i pentru a reprezenta nou valori de semnale. Primul e"antion, la 0, este exact, dar câteva dintre urm toa-rele nu. Care este procentul de eroare la #/32, 2/32 "i 3/32 din perioad ?

47. Ar putea fi folosit modelul psiho-acustic pentru reducerea l rgimii de band necesare pentru telefonia Internet? Dac da, ce condi!ii, dac exist , ar trebui s fie îndeplinite pentru ca el s func!ioneze? Dac nu, de ce nu?

48. Un server de flux audio are o distan! pe sens de 50 ms cu un dispozitiv de redare (media plsyer). El emite la # Mbps. Dac media player-ul are o memorie tampon de # MB, ce pute!i spune despre pozi!ia minim "i cea maxim ?

49. Algoritmul de între!esere din fig. 7-60 are avantajul de a fi capabil s supravie!uiasc unei pier-deri ocazionale a unui pachet f r a introduce o pauz în redarea sunetului (playback). Totu"i, când este folosit pentru telefonia Internet, el are "i un mic dezavantaj. Care este el?

50. Transmisia de voce-peste-IP are acelea"i probleme cu zidurile de protec!ie (firewalls) ca "i transmiterea fluxurilor audio? Discuta!i r spunsul vostru.

5#. Care este rata de bi!i pentru transmiterea necomprimat a culorii la 800 x 600 cu 8 bi!i/pixel la 40 cadre/sec?

52. Poate o eroare de #-bit într-un cadru MPEG s afecteze mai mult decât cadrul în care a ap rut eroarea? Explica!i r spunsul vostru.

53. S consider m exemplul video-serverului cu #00.000 de clien!i, unde fiecare client vizioneaz dou filme pe lun . Jum tate din filme se transmit la 8 seara. Câte filme trebuie s transmit serverul simultan în acest interval de timp? Dac fiecare film necesit 4 Mbps, câte conexiuni OC-#2 necesit serverul pentru re!ea?

54. S presupunem c legea lui Zipf este îndeplinit pentru accese la un server video cu #0.000 de filme. Dac serverul memoreaz cele mai populare #000 de filme pe disc magnetic, iar restul de 9000 pe disc optic, da!i o expresie pentru frac!ia tuturor referin!elor care se vor face la discul magnetic. Scrie!i un mic program pentru evaluarea acestei expresii numerice.

55. Unii cyber-b g cio"i "i-au înregistrat nume de domenii care sunt ortografieri gre"ite ale siturilor companiilor cunoscute, ca de exemplu, www.microsfot.com. Face!i o list de cel pu!in cinci ase-menea domenii.

56. Numeroase persoane au înregistrat nume de domenii DNS de genul www.cuvânt.com, unde cuvânt este un cuvânt obi"nuit. Pentru fiecare din categoriile urm tore, enumera!i cinci situri Web "i spune!i pe scurt despre ce este vorba (de exemplu, www.stomach.com este un gastroenteorologist din LongIsland). Iat lista de categorii: animale, mâncare, obiecte de gos-

SEC. 7.6 PROBLEME 643

pod rie, p r!i ale corpului. Pentru ultima categorie, v rog r mâne!i la p r!ile corpului de de-asupra taliei.

57. Proiecta!i emoji-uri proprii folosind o hart de bi!i #2 x #2. Include!i prietenul, prietena, profe-sorul "i politicianul.

58. Scrie!i un server POP3 care accept urm toarele comenzi: USER, PASS, LIST, RETR, DELE "i QUIT.

59. Rescrie!i serverul din fig. 6-6 ca un server Web adev rat, folosind comanda GET de la HTTP #.#. Ar trebui s accepte "i mesajul Host. Serverul trebuie s men!in o memorie ascuns cu fi"ierele recent aduse de pe disc "i s serveasc cererile din aceast memorie atunci când este posibil.