Sunteți pe pagina 1din 4

8.

5 Determinarea unei adrese de


internet la pornirea sistemului.
Protocolul RARP

1. Determinarea adresei de
internet a unei staţii de lucru
Se ştie că adresele dintr-o reţea fizică sunt dependente de hardware şi că
fiecărei maşini care utilizează o internet cu TCP-IP i se atribuie una sau mai multe
adrese IP pe 32 biţi care sunt independente de adresa hardware a maşinii.
Programele de aplicaţii utilizează întotdeauna adresa IP atunci când indică o
destinaţie. Calculatoarele şi ruterele trebuie să utilizeze adresele fizice pentru a
transmite datagramele în reţelele aferente; ele se bazează pe tehnicile de determinare a
adreselor precum ARP pentru a realiza corespondenţa adreselor IP cu cele fizice.
De regulă, adresa IP a unei maşini este stocată pe un dispozitiv de memorie
secundară (hard disk), unde sistemul de operare o găseşte la pornirea maşinii. Dar cum
îşi poate afla adresa IP o maşină fără hard disk? Problema este crucială pentru
staţiile de lucru care îşi stochează fişierele pe un server aflat la distanţă, întrucât astfel
de maşini au nevoie de adresa IP înainte de a folosi protocolul standard de transfer de
fişiere din TCP/IP spre a obţine imaginea lor iniţială pentru pornire (boot-are).
Întrucât imaginea unui sistem de operare (OS), care are o anumită adresă IP
cuprinsă în codul OS, nu poate fi utilizată pe mai multe calculatoare, proiectanţii
încearcă, de obicei, să evite compilarea adresei IP a unei maşini în codul OS ori în
programele utilitare. În particular, codul de pornire (bootstrap) - aflat adesea în
memoria ROM - este, de regulă, alcătuit astfel încât aceeaşi imagine poate fi rulată
pe mai multe maşini. Când un astfel de cod începe a fi executat pe o maşină fără hard
disk, el foloseşte reţeaua pentru a intra în contact cu un server de la care să
obţinăadresa IP a maşinii.
Procedura de pornire (bootstrap) pare paradoxală: o maşină comunică cu un
server aflat la distanţă pentru a obţine o adresă necesară pentru a comunica. Dar
paradoxul este doar aparent, căci maşina ştie cum să comunice. Ea îşi poate folosi
adresa fizică pentru a comunica într-o singură reţea. Prin urmare, maşina trebuie să
recurgă temporar la modul de adresare al reţelei fizice în acelaşi mod în care OS
utilizează adresarea prin memoria fizică pentru a alcătui tabele de pagini necesare
adresării virtuale. De îndată ce o maşină îşi cunoaşte adresa IP, ea poate comunica
prin intermediul internet.
Ideea care stă la baza găsirii unei adrese IP este simplă: o maşină care are
nevoie să-şi conoscă adresa trimite o cerere unui server *) de pe o altă maşină şi
aşteaptă până când serverul îi trimite un răspuns. Se presupune că serverul are acces la

* )
Problematica serverelor va fi discutată într-un capitol ulterior.
un hard disk pe care stochează o bază de date cu adresele de internet. Maşina care
doreşte să-şi cunoască adresa de internet trebuie să-şi plaseze datele de identificare ăn
cererea pe care o trimite, astfel încât serverul să poată căuta adresa exactă şi să-i
trimită un răspuns. Atât maşina care emite cererea cât şi serverul care răspunde
utilizează adresele fizice de reţea pentru scurta lor comunicaţie. Dar cum ştie maşina
care emite cererea ce adresă are serverul? De regulă, el nu o ştie şi emite pur şi simplu
cererea într-o difuzare către toate maşinile din reţeaua locală. Vor răspunde unul sau
mai multe servere.
Ori de câte ori o maşină difuzează o cerere de aflare a adresei sale IP, ea
trebuie să se identifice în mod unic. Ar fi suficientă o identificare hardware, ca, de
exemplu, numărul de serie al CPU. Totuşi, identificarea ar trebui să fie ceva pe care
un program să o poată obţine cu uşurinţă. Scopul este acela de a crea o unică imagine
software ce se poate executa pe oricare procesor. Mai mult, lungimea sau formatul
informaţiei privind CPU poate varia de la un model de procesor la altul şi se doreşte
conceperea unui server care să accepte cererile de la toate maşinile dintr-o reţea fizică
utilizând un singur format.

2. Protocolul de determinare
inversă a adreselor (RARP)
Proiectanţii protocoalelor TCP/IP şi-au dat seama că există deja o unică
informaţie de identificare a unei maşini şi anume adresa fizică de reţea a maşinii.
Utilizarea adresei fizice drept identificator unic prezintă două avantaje. Întrucât un
calculator obţine adresa sa fizică de la hardul interfeţei de reţea, astfel de adrese sunt
întotdeauna disponibile şi nu trebuie prinse în codul de pornire (bootstrap). Şi, fiindcă
informaţia de identificare depinde de reţea şi nu de marca sau modelul CPU, toate
maşinile dintr-o reţea dată vor furniza identificatori unicei într-un format uniform. Prin
urmare, problema devine inversa problemei de determinare a adresei IP: dându-se
adresa de reţea fizică, să se găsească o modalitate care să permită unui server să o
convertească într-o adresă de internet.
O maşină fără hard disk va utiliza protocolul de internet TCP/IP numit
Protocol de determinare inversă a adreselor [Reverse Address
Resolution Protocol (RARP)] pentru a obţine adresa ei IP de la un server.
RARP este o adaptare a protocolului ARP şi utilizează, aşa cum am menţionat,
acelaşi format de mesaje. În practică, mesajul RARP trimis ca cerere de adresă de
internet este puţin mai general decât cel menţionat mai sus: el permite unei maşini să
solicite adresa IP a unei terţe maşini la fel de simplu ca pe cea proprie. El permite, de
asemenea, mai multe tipuri de reţele fizice.
Ca şi mesajul ARP, un mesj RARP este trimis de la o maşină la alta
încapsulat în câmpul de date al uni cadru de reţea. De exemplu, Un cadru Ethernet
care poartă o cerere RARP are antetul obişnuit - adresa sursei şi cea a destinaţiei,
precum şi un câmp pentru tipul pachetului - la începutul cadrului. Câmpul tipul
cadrului conţine valoarea 803516 care identifică con’inutul cadrului ca fiind un
mesaj RARP. Câmpul de date al cadrului conţine mesajul RARP pe 28 octeţi.
Fig. ce urmează ilustrează modul în care un calculator utilizează RARP.
A B C D

( a )

A B C D

( b )

Emiţătorul difuzează o cerere RARP în care se precizează pe el însuşi atât ca


expeditor cât şi ca destinatar şi furnizează adresa sa de reţea fizică în câmpul pentru
adresa hardware a destinatarului. Toate maşinile din reţea recepţionează cererea, dar
numai cele autorizate să furnizeze serviciul RARP prelucrează cererea şi trimit un
răspuns; astfel de maşini sunt cunoscute sub numele - neoficial - de servere RARP.
Pentru ca RARP să se execute cu succes, reţeaua trebuie să conţină măcar un server
RARP. Serverele răspund cererilor înscriind adresa IP a destinatarului în câmpul
aferent, schimbând tipul mesajului din cerere în răspuns şi trimiţând răspunsul direct
maşinii care a emis cererea. Aceasta din urmă primeşte răspunsuri de la toate serverele
RARP, cu toate că doar primul răspuns îi este util.
Trebuie avut în vedere că întreaga comunicaţie între maşina care îşi caută
adresa IP şi serverul care i-o furnizează trebuie să se efectueze utilizând doar reţeaua
fizică. În plus, protocolul permite unui calculator să se informeze despre adresa
oricărui alt calculator. Prin urmare, emiţătorul cererii furnizează adresa sa hardware
separat de adresa hardware a “ţintei”, iar serverul are grijă să trimită răspunsul la
adresa hardware a emiţătorului cererii. Într-o reţea Ethernet, faptul că există un câmp
pentru adresa hardware a emiţătorului dă impresia unei redundanţe, întrucât această
informaţie este conţinută şi în antetul cadrului Ethernet. Dar nu toate hardware-urile
de Ethernet oferă OS posibilitatea accesului la antetul cadrului fizic.

3. Temporizarea tranzacţiilor
RARP
Ca orice comunicaţie într-o reţea în care livrarea cadrelor se face cu minimum
de efort, cererile RARP se pot pierde sau pot suferi alterări. Cum RARP utilizează
direct reţeaua fizică, nici un alt protocol nu se va ocupa de pauza de aşteptare a
confirmărilor recepţiei corecte a cererilor sau de retransmiterea lor; cade în sarcina
RARP să facă faţă acestor probleme. În general, RARP este utilizat doar în LAN-uri
precum Etharnet, unde probabilitatea erorilor de transmisie este scăzută. Dacă o reţea
are doar un server RARP, s-ar putea ca această maşină să nu fie capabilă să facă faţă
solicitărilor, unele pachete putându-se pierde.
Unele staţii de lucru care se bazează pe RARP pentru boot-are, optează pentru
retransmisia repetată până când primesc un răspuns. Alte implementări anunţă
defecţiunea după numai câteva încercări, pentru a evita inundarea reţelei cu trafic de
difuzare inutil (de exemplu, în cazul că serverul este indisponibil). Într-o reţea
Ethernet, disfuncţionalităţile reţelei sunt mai puţin probabile decât supraîncărcarea
serverului. Obligând RARP să retransmită rapid, se poate obţine un efect nedorit de
înecare a unui server aglomerat cu şi mai mult trafic. Utilizarea unei pauze de
aşteptare mari asigură un timp suficient de mare serverelor pentru a satisface cererea şi
a returna un răspuns.

4. Servere RARP principale şi


de rezervă
Principalul avantaj al axistenţei mai multor maşini funcţionând ca servere
RARP este acela că face sistemul să fie mai fiabil. În cazul căderii unui server sau al
unui server prea încărcat ca să mai poată răspunde, un alt server RARP va răspunde
solicitării. Prin urmare, este foarte probabil ca acest serviciu să fie disponibil.
Principalul dezavantaj al utilizării mai multor servere constă în faptul că, atunci când o
maşină difuzează o cerere RARP, reţeaua devine supraîncărcată dacă toate serverele
încearcă să răspundă. De exemplu, într-o Ethernet, utilizarea mai multor servere
RARP duce la o mare probabilitate a coliziunilor.
Aşadar se pune problema de a organiza serviciul de RARP de asemenea
manieră încât el să fie disponibil şi fiabil fără a plăti preşul cu multiple răspunsuri
simultane. Există două posibilităţi, ambele implicând întârzierea răspunsurilor. Prima
soluţie constă în a atribui fiecărei maşini care face cereri RARP câte un server
principal [primary server]. În situaţii normale, doar serverul principal atribuit unei
maşini răspunde la cererea sa RARP. Toate celelalte servere - servere de rezervă
[backup server] - primesc cererea, dar nu fac decât să înregistreze momentul sosirii
acesteia. Dacă serverul principal nu este disponibil, maşina la care el a fost atribuit va
aştepta pe durata pauzei de aşteptare (timeout) stabilite, după care va retransmite
cererea. Ori de câte ori un server, care nu este principal, va primi o a doua copie a
cererii RARP la scurt timp după prima, acesta va răspunde.
Cea de a doua soluţie utilizează o metodă similară, dar care încearcă să evite
transmiterea simultană de răspunsuri de către serverele de rezervă. Fiecare maşină de
rezervă care primeşte o cerere generează o întârziere aleatoare şi apoi trimite
răspunsul. În condiţii normale, serverul principal răspunde imediat iar răspunsurile
succesive vor fi întârziate, astfel încât există o foarte mică probabilitate ca ele să
sosească în acelaşi moment. Când serverul principal este indisponibil, maşina care a
emis cererea va fi nevoită să aştepte un scut timp până îi soseşte răspunsul. Alegând cu
grijă întârzierile, proiectantul poate să se asigure că maşinile emitente de cereri nu vor
proceda la o redifuzare înainte de primirea unui răspuns.