|
|
|
Se stie ca adresele dintr-o retea fizica sunt dependente de hardware si ca fiecarei masini care utilizeaza o internet cu TCP-IP i se atribuie una sau mai multe adrese IP pe 32 biti care sunt independente de adresa hardware a masinii. Programele de aplicatii utilizeaza intotdeauna adresa IP atunci cand indica o destinatie. Calculatoarele si ruterele trebuie sa utilizeze adresele fizice pentru a transmite datagramele in retelele aferente; ele se bazeaza pe tehnicile de determinare a adreselor precum ARP pentru a realiza corespondenta adreselor IP cu cele fizice.
De regula, adresa IP a unei masini este stocata pe un dispozitiv de memorie secundara (hard disk), unde sistemul de operare o gaseste la pornirea masinii. Dar cum isi poate afla adresa IP o masina fara hard disk? Problema este cruciala pentru statiile de lucru care isi stocheaza fisierele pe un server aflat la distanta intrucat astfel de masini au nevoie de adresa IP inainte de a folosi protocolul standard de transfer de fisiere din TCP/IP spre a obtine imaginea lor initiala pentru pornire (boot-are).
Intrucat imaginea unui sistem de operare (OS), care are o anumita adresa IP cuprinsa in codul OS, nu poate fi utilizata pe mai multe calculatoare, proiectantii incearca, de obicei, sa evite compilarea adresei IP a unei masini in codul OS ori in programele utilitare. In particular, codul de pornire (bootstrap) - aflat adesea in memoria ROM - este, de regula, alcatuit astfel incat aceeasi imagine poate fi rulata pe mai multe masini. Cand un astfel de cod incepe a fi executat pe o masina fara hard disk, el foloseste reteaua pentru a intra in contact cu un server de la care sa obtinaadresa IP a masinii.
Procedura de pornire (bootstrap) pare paradoxala: o masina comunica cu un server aflat la distanta pentru a obtine o adresa necesara pentru a comunica. Dar paradoxul este doar aparent, caci masina stie cum sa comunice. Ea isi poate folosi adresa fizica pentru a comunica intr-o singura retea. Prin urmare, masina trebuie sa recurga temporar la modul de adresare al retelei fizice in acelasi mod in care OS utilizeaza adresarea prin memoria fizica pentru a alcatui tabele de pagini necesare adresarii virtuale. De indata ce o masina isi cunoaste adresa IP, ea poate comunica prin intermediul internet.
Ideea care sta la baza gasirii unei adrese IP este simpla: o masina care are nevoie sa si conosca adresa trimite o cerere unui server de pe o alta masina si asteapta pana cand serverul ii trimite un raspuns. Se presupune ca serverul are acces la un hard disk pe care stocheaza o baza de date cu adresele de internet. Masina care doreste sa si cunoasca adresa de internet trebuie sa si plaseze datele de identificare an cererea pe care o trimite, astfel incat serverul sa poata cauta adresa exacta si sa-i trimita un raspuns. Atat masina care emite cererea cat si serverul care raspunde utilizeaza adresele fizice de retea pentru scurta lor comunicatie. Dar cum stie masina care emite cererea ce adresa are serverul? De regula, el nu o stie si emite pur si simplu cererea intr-o difuzare catre toate masinile din reteaua locala. Vor raspunde unul sau mai multe servere.
Ori de cate ori o masina difuzeaza o cerere de aflare a adresei sale IP, ea trebuie sa se identifice in mod unic. Ar fi suficienta o identificare hardware, ca, de exemplu, numarul de serie al CPU. Totusi, identificarea ar trebui sa fie ceva pe care un program sa o poata obtine cu usurinta. Scopul este acela de a crea o unica imagine software ce se poate executa pe oricare procesor. Mai mult, lungimea sau formatul informatiei privind CPU poate varia de la un model de procesor la altul si se doreste conceperea unui server care sa accepte cererile de la toate masinile dintr-o retea fizica utilizand un singur format.
Proiectantii protocoalelor TCP/IP si-au dat seama ca exista deja o unica informatie de identificare a unei masini si anume adresa fizica de retea a masinii. Utilizarea adresei fizice drept identificator unic prezinta doua avantaje. Intrucat un calculator obtine adresa sa fizica de la hardul interfetei de retea, astfel de adrese sunt intotdeauna disponibile si nu trebuie prinse in codul de pornire (bootstrap). Si, fiindca informatia de identificare depinde de retea si nu de marca sau modelul CPU, toate masinile dintr-o retea data vor furniza identificatori unicei intr-un format uniform. Prin urmare, problema devine inversa problemei de determinare a adresei IP: dandu-se adresa de retea fizica, sa se gaseasca o modalitate care sa permita unui server sa o converteasca intr-o adresa de internet.
O masina fara hard disk va utiliza protocolul de internet TCP/IP numit Protocol de determinare inversa a adreselor [Reverse Address Resolution Protocol (RARP)] pentru a obtine adresa ei IP de la un server. RARP este o adaptare a protocolului ARP si utilizeaza, asa cum am mentionat, acelasi format de mesaje. In practica, mesajul RARP trimis ca cerere de adresa de internet este putin mai general decat cel mentionat mai sus: el permite unei masini sa solicite adresa IP a unei terte masini la fel de simplu ca pe cea proprie. El permite, de asemenea, mai multe tipuri de retele fizice.
Ca si mesajul ARP, un mesj RARP este trimis de la o masina la alta incapsulat in campul de date al uni cadru de retea. De exemplu, Un cadru Ethernet care poarta o cerere RARP are antetul obisnuit - adresa sursei si cea a destinatiei, precum si un camp pentru tipul pachetului - la inceputul cadrului. Campul tipul cadrului contine valoarea 803516 care identifica con inutul cadrului ca fiind un mesaj RARP. Campul de date al cadrului contine mesajul RARP pe 28 octeti.
Fig. ce urmeaza ilustreaza modul in care un calculator utilizeaza RARP.
Emitatorul difuzeaza o cerere RARP in care se precizeaza pe el insusi atat ca expeditor cat si ca destinatar si furnizeaza adresa sa de retea fizica in campul pentru adresa hardware a destinatarului. Toate masinile din retea receptioneaza cererea, dar numai cele autorizate sa furnizeze serviciul RARP prelucreaza cererea si trimit un raspuns; astfel de masini sunt cunoscute sub numele - neoficial - de servere RARP. Pentru ca RARP sa se execute cu succes, reteaua trebuie sa contina macar un server RARP. Serverele raspund cererilor inscriind adresa IP a destinatarului in campul aferent, schimband tipul mesajului din cerere in raspuns si trimitand raspunsul direct masinii care a emis cererea. Aceasta din urma primeste raspunsuri de la toate serverele RARP, cu toate ca doar primul raspuns ii este util.
Trebuie avut in vedere ca intreaga comunicatie intre masina care isi cauta adresa IP si serverul care i-o furnizeaza trebuie sa se efectueze utilizand doar reteaua fizica In plus, protocolul permite unui calculator sa se informeze despre adresa oricarui alt calculator. Prin urmare, emitatorul cererii furnizeaza adresa sa hardware separat de adresa hardware a "tintei", iar serverul are grija sa trimita raspunsul la adresa hardware a emitatorului cererii. Intr-o retea Ethernet, faptul ca exista un camp pentru adresa hardware a emitatorului da impresia unei redundante, intrucat aceasta informatie este continuta si in antetul cadrului Ethernet. Dar nu toate hardware-urile de Ethernet ofera OS posibilitatea accesului la antetul cadrului fizic.
Ca orice comunicatie intr-o retea in care livrarea cadrelor se face cu minimum de efort, cererile RARP se pot pierde sau pot suferi alterari. Cum RARP utilizeaza direct reteaua fizica, nici un alt protocol nu se va ocupa de pauza de asteptare a confirmarilor receptiei corecte a cererilor sau de retransmiterea lor; cade in sarcina RARP sa faca fata acestor probleme. In general, RARP este utilizat doar in LAN-uri precum Etharnet, unde probabilitatea erorilor de transmisie este scazuta. Daca o retea are doar un server RARP, s-ar putea ca aceasta masina sa nu fie capabila sa faca fata solicitarilor, unele pachete putandu-se pierde.
Unele statii de lucru care se bazeaza pe RARP pentru boot-are, opteaza pentru retransmisia repetata pana cand primesc un raspuns. Alte implementari anunta defectiunea dupa numai cateva incercari, pentru a evita inundarea retelei cu trafic de difuzare inutil (de exemplu, in cazul ca serverul este indisponibil Intr-o retea Ethernet, disfunctionalitatile retelei sunt mai putin probabile decat supraincarcarea serverului. Obligand RARP sa retransmita rapid, se poate obtine un efect nedorit de inecare a unui server aglomerat cu si mai mult trafic. Utilizarea unei pauze de asteptare mari asigura un timp suficient de mare serverelor pentru a satisface cererea si a returna un raspuns.
Principalul avantaj al axistentei mai multor masini functionand ca servere RARP este acela ca face sistemul sa fie mai fiabil. In cazul caderii unui server sau al unui server prea incarcat ca sa mai poata raspunde, un alt server RARP va raspunde solicitarii. Prin urmare, este foarte probabil ca acest serviciu sa fie disponibil. Principalul dezavantaj al utilizarii mai multor servere consta in faptul ca, atunci cand o masina difuzeaza o cerere RARP, reteaua devine supraincarcata daca toate serverele incearca sa raspunda. De exemplu, intr-o Ethernet, utilizarea mai multor servere RARP duce la o mare probabilitate a coliziunilor.
Asadar se pune problema de a organiza serviciul de RARP de asemenea maniera incat el sa fie disponibil si fiabil fara a plati presul cu multiple raspunsuri simultane. Exista doua posibilitati, ambele implicand intarzierea raspunsurilor. Prima solutie consta in a atribui fiecarei masini care face cereri RARP cate un server principal [primary server]. In situatii normale, doar serverul principal atribuit unei masini raspunde la cererea sa RARP. Toate celelalte servere - servere de rezerva [backup server] - primesc cererea, dar nu fac decat sa inregistreze momentul sosirii acesteia. Daca serverul principal nu este disponibil, masina la care el a fost atribuit va astepta pe durata pauzei de asteptare (timeout) stabilite, dupa care va retransmite cererea. Ori de cate ori un server, care nu este principal, va primi o a doua copie a cererii RARP la scurt timp dupa prima, acesta va raspunde.
Cea de a doua solutie utilizeaza o metoda similara, dar care incearca sa evite transmiterea simultana de raspunsuri de catre serverele de rezerva. Fiecare masina de rezerva care primeste o cerere genereaza o intarziere aleatoare si apoi trimite raspunsul. In conditii normale, serverul principal raspunde imediat iar raspunsurile succesive vor fi intarziate, astfel incat exista o foarte mica probabilitate ca ele sa soseasca in acelasi moment. Cand serverul principal este indisponibil, masina care a emis cererea va fi nevoita sa astepte un scut timp pana ii soseste raspunsul. Alegand cu grija intarzierile, proiectantul poate sa se asigure ca masinile emitente de cereri nu vor proceda la o redifuzare inainte de primirea unui raspuns.
