1 Aspecte introductive

1.1 Scurt istoric al Internet-ului

Cu aproape un secol şi jumătate în urmă, mai exact în 1858 se instala primul cablu transatlantic pentru facilitarea comunicării ultra rapide între cele două continente, Europa şi America de Nord. Deşi acest eveniment a fost considerat ca o deschidere de drumuri în era comunicaţiilor, din punct de vedere tehnic a fost un eşec. Abia în 1866 după încă două încercări eşuate se reuşeste pentru prima oară instalarea unui cablu transatlantic care va rămâne în funcţiune pentru aproape 100 de ani.

În octombrie 1957 URSS-ul lansează Sputnik, primul satelit artificial al pământului.

Ca răspuns, în februarie 1958 Departamentul de Aparare al Statelor Unite ale Americii înfiinţează Agenţia de Cercetare pentru Proiecte Avansate ARPA (Advanced Research Projects Agency). ARPA reunea cei mai de vază oameni de ştiinţa din SUA care reuşesc în doar 18 luni să dezvolte primul satelit spaţial al americii. Câţiva ani mai târziu ARPA îşi concentrează cercetările pe domeniul calculatoarelor şi reţelelor.

În 1969 începe să funcţioneze o reţea experimentală cu patru noduri numită ARPANET care se compunea din nodurile de la UCLA (University of California at Los Angeles), UCSB (University of California at Santa Barbara), SRI (Stanford Research Institute) şi UU (University of Utah)(Fig 1.1). Pentru fiecare nod era folosit un mini calculator echipat cu 12 K de memorie. Aceste minicalculatoare funcţionau ca “procesoare pentru mesaje” IMP (Information Message Processors).

Fig 1.1 Primele patru noduri ale retelei ARPANET

Până în 1972 reţeaua ARPANET avea deja 15 noduri şi 23 de calculatoare conectate, tot în acest an inventându-se şi un sistem de poştă electronică derivat din alte două sisteme, şi anume un program de poştă electronică intra-staţii (SNDMSG) şi un sistem de transfer de fişiere (CPYNET). [RFC1296]

În următorii ani multe alte organizaţii s-au conectat la ARPANET utilizând reţeaua în comunicaţii zilnice, acest lucru conferind succesul experimentului, ARPANET devenind în 1975 reţea operaţională. În 1983 din reţeaua ARPANET se separă o subreţea dedicată armatei SUA. Această reţea purta denumirea de MILNET, având câteva legături de acces stricte cu subreţeaua ARPANET. Odată cu creşterea explozivă a numărului de calculatoare conectate în reţea, nevoia dezvoltării unui sistem distribuit pentru controlul numelor de domenii devine o necesitate imediată.

[RFC2235]

Astfel în 1984 apare Sistemul Numelor de Domenii DNS (Domain Name System). La sfâşitul anilor 1980 numărul reţelelor conectate creşte exponenţial, ARPANET fiind deja surclasată de reţele mai moderne cărora le dăduse el însuşi naştere. Prin urmare, ARPANET-ul a fost închis şi demontat. De la începutul anilor ‘90 numărul calculatorelor conectate la INTERNET (care devenise un termen universal) practic se dubla de la an la an, ajungând în prezent la zeci de mii de reţele, zeci de milioane de calculatoare şi sute de milioane de utilizatori (Fig 1.2).

Fig 1.2 Expansiunea numărului de calculatoare în INTERNET

Liantul care legă această multitudine de calculatoare interconectate îl constituie modelul de referinţă TCP/IP şi pachetele de protocoale TCP/IP. TCP/IP constituie standardul comunicării inter-calculatoare şi face posibile servicii universale, în prezent putând fi comparat cu sistemul telefonic sau cu adoptarea lăţimii standard pentru căile ferate în secolul XIX.

1.2 Adrese IP

Suita de protocoale TCP/IP a fost adoptată ca standard militar al SUA (Military Standard, MIL STD) în 1983, toate calculatoarele conectate în reţeaua MILNET fiind obligate să treacă la folosirea acestor protocoale. Cu timpul această suită de protocoale a devenit un standard pentru întreaga reţea Internet datorită avantajelor majore prezentate asupra celorlate protocoale de comunicare în reţea.

Fiecare calculator conectat în reţeaua Internet este identificat prîntr-o adresă binară IP. Adresele binare nu se referă numai la sisteme conectate în reţea ci şi la alte resurse, de exemplu rutere. Combinaţia este unică: nu există două sisteme cu aceeaşi adresa IP. Fiecare pachet IP conţine în câmpurile “adresă sursă” şi “adresă destinaţie” câte o adresă IP pe 32 de biţi. Calculatoarele conectate în mai multe reţele au adrese separate şi distincte pentru fiecare reţea. Adresele IP sunt scrise în mod uzual în notaţia zecimală cu punct, fiecare octet fiind reprezentat în zecimal la la 0 la 255.

Orice adresă IP este structurată în două parţi componente, adresa reţelei, reprezentată de un prim grup de biţi, cei mai semnificativi, şi adresa gazdei reprezentată de al doilea grup de biţi. (Fig 1.3)

Fig 1.3

Structura unei adrese IP

Ruterele constituie “gările” Internetului, prin analogie cu sistemul căilor ferate. Ele rutează pachetele de date făcând posibilă comunicarea între reţele diferite aflate la mare distantă departăre unele de altele (Fig 1.4). Pentru cele mai multe rutere regulile de rutare sunt foarte simple, şi anume :

· Dacă sistemul destinaţie se află în reţeaua locală, pachetele de date sunt transmise direct acelui sistem.

· Dacă sistemul destinaţie se află într-o reţea diferită de cea locală, pachetele de date sunt transmise gateway-ului local care rutează conform unei tabele de rutare stabilite de administratorul reţelei.

Pentru ca informaţiile să fie transmise corect între două calculatoare prin intermediul Internetului protocoalele folosesc mai multe principii:

1. Adresarea – pentru livrarea datelor calculatorului destinaţie

2. Rutarea – pentru ca informaţia să ajungă la reţeaua destinaţie

3. Multiplexarea – pentru livrarea datelor procesului şi utilizatorului vizat. [CRH97]

Fig 1.4 Exemplu de transfer de date între două sisteme aflate în reţele diferite

1.3 Nume de domenii

Pentru sisteme comunicarea pe baza adreselor în format binar este esenţială, pentru operatorul uman însă memorarea unui număr mare de adrese este un lucru imposibil, având în vedere multitudinea de resurse disponibile şi necesare fiecărui individ.

Aici intervin numele de domenii. Scopul numelor de domenii este acela de a asigura un mecanism de denumire a resurselor astfel încât ele să denumească calculatoare gazdă, reţele, familii de protocoale, intraneturi, organizaţii, institute, firme, fiecare prezente în internet cu cel puţin o adresă IP. Reamintim aici că adresele IP în internet sunt unice, neexistând posibilitatea utilizării aceleiaşi adrese de către două calculatoare gazdă sau routere.

Regulile după care se alcătuiesc numele de domenii se doresc a fi cât se poate de generale, ideea acestui principiu constă în faptul că orice obiect existent să fie exprimat prîntr-un nume de domeniu cu intervenţii mininme asupra sa. Astfel, oricine ar dori sa-şi creeze un domeniu va trebui să ţină cont de câteva reguli generale, unele ţinând de sistemul numelor de domenii, altele pur şi simplu de obiectul pe care îl va denumi. De exemplu, o persoană care ar dori să denumească un calculator gazdă în internet ar trebui să ţină cont atât de regulile actualului sistem de nume de domenii cât şi de regulile vechiului HOSTS.TXT, evident din motive de compatibilitate (backwards compatibility). Această compatibilitate va impiedica apariţia problemelor generate de programe vechi adaptate la sistemul nou al numelor de domenii.

Fişierul HOSTS.TXT a fost primul sistem de numire al domeniilor, el conţinând perechi adresă IP/nume. În fiecare noapte toate calculatoarele din reţea (ARPANET) preluau acest fişier. Cu timpul însă dimensiunile lui au crescut exponenţial, odată cu raspândirea reţelei, actualizarea lui facându-se din ce în ce mai greu, evitarea coliziunilor de nume constituind o reală problemă. Astfel s-a conturat ideea unei baze de date distribuite care să rezolve toate aceste probleme generate de existenţa unui singur fişier HOSTS.TXT

[DNS98]

Urmatoarea sintaxă propusă va impiedica apariţia problemelor de compatibilitate ce ar putea apărea în majoritatea aplicaţiilor care folosesc DNS-ul. (eg. Mail, FTP, TELNET).

<domeniu> ::= <subdomeniu> | " "

<subdomeniu> ::= <etichetă> | <subdomeniu> "." <etichetă>

<etichetă> ::= <etichetă> [ [ <şir-lcc> ] <lit-cif> ]

<şir-lcc> ::= <lit-cif-crt> | <lit-cif-crt> <şir-lcc>

<lit-cif-crtp> ::= <lit-cif> | "-"

<lit-cif> ::= <literă> | <cifră>

<literă> ::= oricare dintre cele 52 de caractere de la A la Z şi a la z.

<cifră> ::= oricare dintre cele 10 cifre de la 0 la 9.

[RFC1034]

Trebuie precizat că deşi într-un nume de domeniu sunt permise atât litere mici cât şi majuscule, sistemul numelor de domenii nu este case sensitive, de exemplu aut.UTT.ro este echivalent cu aut.utt.ro. O etichetă trebuie sa respecte regulile reţelei ARPANET. Ea trebuie să înceapă cu o literă, iar la sfarşit trebuie să conţină o literă sau o cifră. În interior poate conţine litere, cifre sau cratimă. Există însă şi unele organizaţii care permit folosirea cifrelor la începutul etichetelor. Organizaţia DENIC permite înregistrarea domeniilor ale căror etichete încep cu cifre. Lungimea unei etichete nu poate depaşi 63 de caractere, iar numele unui domeniu incluzând şi etichetele subdomeniilor şi elementele separatoare, “.” nu poate depăşi 255 de caractere.

Din punctul de vedere al utilizatorului un nume de domeniu reprezintă o adresa în internet a unei organizaţii, firme sau persoane. Acest nume nu este altceva decât un parametru pasat unui resolver, o librărie locală, care îl va traduce într-o adresă IP. Bineînţeles utilizatorul poate cere rezolvarea unei adrese web, unei adrese de mail sau a unui nume de calculator. Desigur, pentru ca resolverul să poată găsi adresa IP corespondentă unui domeniu, pasat ca parametru, trebuie să execute o comandă de interogare a unei baze de date în care se află toate aceste nume de domenii.

Din punctul de vedere al resolverului baza de date în care este nevoit să caute este o baza de date distribuită, distribuţia fiind extrem de largă, ea fiind posibilă datorită serverelor DNS şi sistemului numelor de domenii. Sistemul Numelor de Domenii stabileşte corespondenţa între adresele IP (în format numeric) şi numele de domenii sub forma unor şiruri ASCII (American Standard Code of Information Interchange), aceste şiruri fiind mult mai uşor de reţinut, utilizat şi personalizat de către utilizator decât adresele IP.

Încă de la început, în reţeaua ARPANET exista un fişier HOSTS.TXT, care cuprindea toate sistemele gazdă şi adresele lor IP. Acest fişier era păstrat pe un server de unde era preluat în fiecare noapte de toate gazdele din reţea. Pentru o reţea formată din câteva sute de calculatoare aceasta era o abordare rezonabilă, dar când reţeaua s-a extins, având conectate mii de calculatoare toţi şi-au dat seama că această soluţie nu va functiona la nesfârşit. În primul rând s-ar fi ajuns la un fişier de o dimensiune uriaşă, iar dacă fişierul nu ar fi administrat centralizat s-ar fi ajuns şi la conflicte între numele de domenii.

Sistemul Numelor de Domenii constituie o bază de date distribuită, creată pentru a servi milioane de calculatoare într-un timp scurt şi cu o eficienţă maximă. Esenţa acestuia constă dintr-o schemă ierarhică de nume de domenii şi posibilitatea controlului local al bazei de date pe segmente. Informaţia este disponibilă tuturor utilizatorilor prin intermediul unei arhitecturi client/server. Partea de server a sistemului este jucată de serverele de nume iar partea de client este jucată de funcţii bibliotecă denumite resolver. Mecanismul care se ascunde în spatele rezolvării unui nume de domeniu (aflarea adresei IP corespunzătoare lui) este următorul:

Aplicaţia apelează o funcţie resolver pasându-i ca parametru numele domeniului pentru care se doreşte aflarea adresei IP. Resolverul trimite un pachet UDP (User Datagram Protocol) serverului DNS local, acesta caută adresa IP corespunzatoare numelui şi o returnează resolverului, care la rândul său returnează adresa programului apelant.

1.4 Nume de domenii internaţionale (IDNA)

În lume există foarte multe persoane şi chiar şi firme ale căror nume conţin diverse caractere specifice fiecărei limbi. Printre ele se afla nume ca Băsescu, Schröder, Müller, etc. Toate aceste persoane care doresc sa-şi anunţe prezenţa în imensa lume creată de internet o pot face, din primăva anului 2003 (Martie 2003), chiar cu numele lor, nefiind nevoiţi să recurgă la diferite metode de scriere alternativă. Prima organizaţie care a introdus domenii internaţionale, folosind noul standard IDNA (International Domain Names în Applications) a fost organizaţia JPNIC (Japan Network Information Center) care oferă spre înregistrare domenii jp.

În ultimii ani a existat o mare efervescenta în cadrul IETF cu privire la adoptarea unui standard privind folosirea în etichetele numelor de domenii a caracterelor “non ASCII”. În luna martie a anului 2003, IETF a aprobat trei documente importante, şi anume RFC 3490, RFC 3491 şi RFC 3492. Aceste trei documente fac posibilă în prezent utilizarea numelor de domenii internaţionale atât în cadrul aplicaţiilor internet cât şi în cadrul sistemului numelor de domenii DNS.

Pe parcursul dezbaterilor pe tema adoptării standardului pentru folosirea numelor de domenii internaţionale au existat mai multe propuneri privind scheme de encodare compatibilă ASCII, schema Punycode fiind singura acceptată şi utilizată în prezent. Din moment ce schema Punycode conţine doar caractere ale codului ASCII s-a pus problema existenţei unor suprapuneri ale numelor de domenii. Astfel, s-a convenit ca orice etichetă encodată conform Punycode să fie precedată de prefixul “xn--“, în acest mod va dispărea posibilitatea suprapunerii numelor de domenii. Desemnarea prefixului ACE a fost facută de IANA (Internet Assigned Numbers Authority, http://www.iana.org) împreună cu IESG (The Internet Engineering Steering Group, http://www.ietf.org/iesg.html). Desigur au mai existat şi alte scheme de encodare ACE, de exemplu RACE, care foloseşte prefixul “bq--“, AMC-ACE, BRACE, IDNE, KWAN, SENG, UDNS, DUERST bineînţeles în afară de Punycode, nici o altă schemă nu este acceptată în IDN-uri. O comparaţie între aceste scheme de encodare putând fi găsită la http://www.ietf.org, ca draft-ietf-idn-compare-01.txt. [draft-ietf-idn-compare-01.txt]

Până la apariţia standardului IDNA nu a existat nici un standard privind domeniile internaţionale. IDNA permite nu numai înregistrarea domeniilor folosind caracterele setului ASCII (literele alfabetului, cifre şi cratimă) ci şi înregistrarea de domenii folosind şi alte caractere, folosite pe scară largă în multe ţări din întreaga lume.

Standardul IDNA permite folosirea unui set larg de caractere din repertoriul Unicode, însă maparea se va face doar folosind caracterele din setul de caractere ASCII, care sunt admise pentru denumirea calculatoarelor gazdă în Internet. Această reprezentare este necesară ca o compatibilitate cu sistemul DNS. Astfel nu sunt necesare modificări ale infrastructurii existente, ci doar mici modificări la nivelul aplicaţiilor internet.

Standardul IDNA, după cum ii spune şi numele “International Domain Names in Applications” permite doar procesarea numelor de domenii. Procesarea textelor sau altor entităti fiind imposibilă.

1.5 Sistemul Numelor de Domenii (DNS)

Prima implementare a DNS-ului s-a numit Jeeves fiind urmată de BIND (Berkeley Internet Name Daemon) . Implementarea BIND a fost scrisă pentru sistemul de operare 4.3 BSD UNIX, ea fiind utilizată şi în prezent prezentând avantajul de a fi cea mai dezvoltată implementare a DNS-ului. BIND este în prezent dezvoltat şi întreţinut de către Internet Systems Consortium (ISC http://www.isc.org), o organizaţie nonprofit dedicată suportului infrastructural al Internetului.[DNS98]

Sistemul Numelor de Domenii este o bază de date distribuită. Această bază de date este construită cu ajutorul unei arhitecturi client/server, făcând posibil controlul local al segmentelor bazei de date şi totodată accesul tuturor clienţilor la orice segment al ei. Performanţa şi robusteţea acestui sistem este asigurată de sistemul de replicare a datelor şi memorare locală (caching) pentru o ulterioară accesare rapidă. Serverele de nume constituie partea de “server” a arhitecturii sistemului numelor de domenii, ele conţin fiecare câte un segment al bazei de date, servind aceste informaţii clienţilor numiţi resolver. Un resolver este în mare majoritate a cazurilor o funcţie de librărie care crează interogări pentru baza de date pe care le pasează serverelor de nume prin intermediul reţelei.

Orice resolver primeşte ca parametru un nume de domeniu, sau o adresă IP pentru care crează o interogare pe care o trimite unui server de nume local. Acesta va răspunde, dacă răspunsul se află memorat pentru o accesare rapidă, sau va pasa mai departe interogarea spre alte servere de nume. Răspunsul va fi creat pas cu pas şi retrimis serverului de unde a pornit interogarea. Serverul la rândul său va pasa răspunsul resolverului care îl va transmite aplicaţiei care a cerut rezolvarea numelui sau adresei IP.

Ideea structurii bazei de date DNS este similară cu structura sistemului de fişiere UNIX. Structura DNS este o structură arboreşcentă, fiecare nod având ataşată o etichetă unică pe nivel. Nodul rădacină are rezervată eticheta nulă sau “”. Ea este simbolizata utilizând caracterul “.” pentru DNS şi “/” pentru sistemul de fişiere UNIX. Orice nume de domeniu va avea astfel ultimul caracter eticheta nodului rădăcină, aceasta însă este adeseori omisă, existenţa ei fiind considerată implicită.

O reprezentare a structurii arboreşcente a DNS-ului în comparaţie cu structura sistemului de fişiere UNIX poate fi următoarea:

Fig 1.5 Prezentare comparativă structură DNS – sistemul de fişiere UNIX

Fiecare nod al acestei structuri arboreşcente joacă rolul de părinte al unei substructuri. În cazul DNS-ului fiecare substructură reprezintă o fracţiune a baze de date. Etichetele nodurilor reprezintă “domenii” în sistemul numelor de domenii, în sistemul fişierelor UNIX etichetele reprezintă numele unor directoare. Nodurile aflate într-o substructură sunt numite “subdomenii” şi sunt reprezentate ca şi fii ai nodurilor părinte sau fii ai domeniilor. Un domeniu poate avea mai multe subdomenii, numărul de subdomenii fiind totuşi limitat de numărul de caractere admis într-un domeniu, şi anume 255.

La fel cum aminteam şi mai înainte, fiecare etichetă este unică pe nivel, un nod părinte nu poate avea două ramuri cu aceeaşi etichetă. Astfel se asigură unicitatea în sistemul numelor de domenii şi se ocolesc eventualele probleme care ar putea apărea.

Fiecare domeniu este unic, la fel ca şi în structura de fişiere UNIX unde fiecare director este unic, bineînţeles referindu-ne la calea sa absolută (Fig 1.6).

Fig 1.6 Modul de asigurare al unicităţii în DNS/sistemul de fişiere UNIX

Numele unui domeniu se compune din concatenarea tuturor etichetelor, începând de la nivelul inferior înspre nodul radacină al structurii, adăugând un ultim punct după nume şi evident eticheta nulă a nodului radacină. Separarea etichetelor se face folosind caracterul “.”. În sistemul de fişiere UNIX o cale se compune pornind de la nodul radacină “/” înspre nivelul cel mai de jos al căii, spararea etichetelor fiecărui director făcându-se cu ajutorul caracterului “/” (Fig 1.7).

Fig 1.7 Modul de compunere al numelor de domenii DNS/directoare UNIX

Fiecare domeniu, conform structurii de baza de date distribuită, poate fi administrat separat de câte o organizaţie. Fiecare dintre organizaţiile care administrează domenii poate împărţi un domeniu în mai multe subdomenii, împărţind şi responsabilitatea administrării lor altor organizaţii. De exemplu organizaţia RNC (Romanian National R&D Computer Network) administrează domeniul ro (România), ea a predat responsabilitatea administrării subdomeniului utt.ro Universităţii Politehnice din Timişoara, la fel cum organizaţia InterNIC, administrator al domeniului edu (Educaţional) a predat responsabilitatea administrării domeniului berkeley.edu Universităţii Berkeley din California. Acest principiu este similar cu montarea la distanţă a unor sisteme de fişiere într-o structură de directoare UNIX.

De exemplu în figura următoare (Fig 1.8), administratorul calculatorului gazdă winken este responsabil pentru sistemul de fişiere montat pe staţia locală ca şi /usr/nfs/winken. [RFC2181]

Fig 1.8 Modul de delegare a zonelor DNS, respectiv montare sistemelor de la distanţă

Domeniile Top-Level originale, numite generic GTLD (Generic Top-Level Domain), divideau spaţiul numelor de domenii în şapte domenii:

*TLD*	*Descriere*	*Exemple*
com	organizaţii comerciale	Microsoft (microsoft.com)
net	organizaţii din infrastructura informaţională	ROEDU (roedu.net)
org	organizaţii noncomerciale	IETFT (ietf.org)
edu	organizaţii educaţionale	U.C. Berkeley (berkeley.edu)
gov	organizaţii guvernamentale	Casa Alba (whitehouse.gov)
mil	organizaţii militare	U.S. Army (army.mil)
int	organizaţii internaţionale	NATO (nato.int)

Cu timpul s-au conturat două categorii de domenii top level: generice şi nationale. Fiecare ţară deţine câte un domeniu obţinut dintr-o abreviere de două litere a numelui ţării respective:

*TLD*	*Descriere*	*Exemple*
ro	România	Universitatea Politehnică din Timişoara (utt.ro)
de	Germania	Firma NetBeat (netbeat.de)
at	Austria	Organizaţia NICAT (nic.at)
it	Italia	Firma Energie (energie.it)
nl	Olanda	Organizaţia SIDN Olanda (domain-registry.nl)

Domeniile pot fi considerate, în structura bazei de date DNS, ca indecşi, datele aferente lor fiind ataşate asemenea fişierelor dintr-un director în structura de fişiere a sistemului UNIX. Fiecare calculator gazdă din reţea are un nume de domeniu care pointează către informaţiile referitoare la acel calculator. Aceste informaţii pot fi constituite din adresa IP, routerul de mail, nameserver, etc. Un calculator gazdă poate avea mai multe nume, aliasuri, mai multe etichete în baza de date a numelor de domenii.

Aceste aliasuri pointează toate spre un nume oficial (canonical) al unui calculator gazdă. În figura următoare 1.7 mailhub.nv este un alias pentru numele oficial rincon.ba.ca (Fig 1.9).

Fig 1.9 Modul de pointare a unui alias spre numele canonical

2 Sistemul NetBeat

2.1 Prezentare generală

Firma NetBeat este o firmă germană, infiinţată în anul 1999 la Regensburg. Domeniul său de activitate este constituit din înregistrarea domeniilor, găzduirea paginilor web + CGI + PHP, oferirea de spaţiu pentru posta electronică (email) şi acces la baze de date (MySQL). Se asigură totodată suport telefonic şi asistenţă tehnică 24 de ore din 24. Astfel firma pune la dispoziţia clientului un sistem complex de creare şi administrare de domenii. Precizăm că sistemul se adreseză în general persoanelor fizice, interfaţa de înregistrare fiind una orientată pe înregistrări singulare de domenii. Un alt factor care atrage indeosebi clienţii persoane fizice îl constituie preţul extrem redus pentru serviciile oferite, firma având în momentul de faţa ca. 60 de mii de clienţi, persoane fizice şi juridice şi 80 de mii de domenii înregistrate.

Fig 2.1 Pagina principală a sistemului NetBeat

Elementul principal al sistemului îl constituie sistemul înregistrărilor de domenii. La ora actuală prin NetBeat se pot înregistra pe lângă domenii de şi domenii “generice” cum ar fi com, net, org, info sau biz. Ultimele domenii introduse, în luna mai a anului 2004, sunt domeniile it şi nl. Aceste domenii sunt disponibile într-o varietate de pachete.

Fiind o firmă germană, majoritatea domeniilor înregistrate sunt domenii de, urmate de domenii com, net şi info.

2.2 Principiul general de funcţionare

Interfaţa principală o constituie chiar pagina web prin care orice client işi poate comanda unul din domeniile oferite de firmă. Cu ajutorul acestei interfeţe clientul este informat asupra ofertei disponibile. Sunt prezentate pe scurt diversele pachetele oferite, informaţii privind ultimele noutăti şi bineînţeles linkurile spre date detaliate despre pachete, interfaţa clientului, ultimele noutăţi, suportul tehnic, contact şi bineînţeles condiţtiile generale. Accesând această interfaţă clientului i se pun la dispoziţie două posibilităţi de comandare a unui domeniu:

1. prin selectarea pachetului dorit

2. prin introducerea din pagina principală a numelui şi selectarea tipului de domeniu dorit.

Prin selectarea primei metode, clientul este redirecţionat către o pagină unde va găsi o scurtă descriere a pachetului ales, o casută (Fig 2.2) unde va introduce numele domeniului dorit şi un meniu cu ajutorul căruia va putea selecta tipul domeniului ales.

Fig 2.2 Căsuţa pentru alegerea unui domeniu

Selectând cea de-a două metodă, în cazul în care domeniul selectat este disponibil se va trece la prezentarea pachetelor din care clientul îşi va alege un anume tip de pachet (Fig 2.3). În caz contrar, dacă domeniul pe care l-a ales este deja ocupat, i se va aduce la cunostită acest lucru, având la dispoziţie un link înspre acel domeniu (domeniul ocupat) şi informaţiile necesare pentru cazul în care clientul este posesorul domeniului ocupat (domeniul fiind inregistrat prin intermediul altui provider) şi doreşte să-l transfere în sistemul NetBeat.

Fig 2.3 Pagina de selectarea a pachetului pentru un domeniu disponibil

După ce domeniul a fost ales, se trece la introducerea datelor personale (pentru un utilizator nou) sau la introducerea numărului de identificare al clientului şi a parolei acestuia. Această operaţie fiind completă, domeniul este gata pentru înregistrare şi configurare conform pachetului ales. Clientul va primi un email de confirmare a faptului că domeniul este gata pentru înregistrare şi de asemeana un link unde va trebui să confirme comanda facută.

În momentul în care domeniul va fi înregistrat iar toate configurările vor fi efectuate, se trimite din nou un mail către client, în care acesta este anunţat despre efectuarea cu succes a înregistrării şi configurării. De asemenea în acest mail de confirmare i se vor comunica şi datele aferente domeniului (adresa, nume utilizator şi parola FTP, adresa serverului de mail, numele şi parola pentru interfaţa de administarea a domeniului).

Interfaţa pentru administrare oferita clientului se compune dintr-o serie intreaga de “unelte” prin care acesta îşi poate administra conturile de postă electronică, subdomeniile, parolele sau datele personale.

2.3 Specificaţii

În continuare se urmăeşte expunerea specificaţiilor referitoare la dezvoltarea şi optimizarea sistemului NetBeat.

În primul rând s-a cerut optimizarea imediată a infrastructurii sistemului, deoarece aceasta devenise deja incapabilă să susţină noile tipuri de servicii care se cereau a fi oferite. În al doilea rând a fost cerută imbogăţirea ofertei de domenii disponiblă sub sistemul NetBeat. Acest lucru urma să se efectueze în două faze: mai întâi prin introducerea noilor tld-uri .info şi .biz iar mai apoi prin introducerea tld-urilor .it şi .nl.

S-a urmărit de asemenea şi imbogăţirea serviciilor oferite la nivelul interfeţei de administrare prin adăugarea facilităţilor de modificare a datelor personale, introducerea facilităţii pentru baze de date şi a facilităţii de achizitionare de spaţiu suplimentar pentru găzduirea paginilor web şi a bazei de date.

A fost necesară dezvoltarea imediată a unui sistem de control şi administrare a sistemului online de facturări.

Nu în ultimul rând precizăm nevoia imediată de introducere a protocolului IDNA. Acesta va perimite înregistrarea domeniilor internaţionale utilizând caractere specifice fiecărei ţări sau regiuni. În prima fază se va implementa protocolul pentru domeniile “de” urmată imediat de implementarea pentru domeniile “com”, “net” şi “info”.

3 Dezvoltare Teoretică

3.1 Standardul IDNA

3.1.1 Principii generale

Fiecare IDN (ne referim prin IDN la un domeniu care conţine alte caractere decât cele admise în mod normal) are o forma de prezentare menită a fi “arătată” utilizatorului prin intermediul aplicaţiilor compatibile cu standardul IDNA, această formă este aceea pe care utilizatorul se asteaptă sa o găsească şi pe care evident o înţelege. Ea conţine caracterele cu care utilizatorul este familiarizat şi este intâlnită doar la nivelul aplicaţiilor şi mai ales la nivelul dialogurilor cu utilizatorul. A două formă a unui IDN este forma encodată, care nu este inteligibilă de către utilizator şi evident nu se intenţionează folosirea acesteia în dialoguri cu utilizatorul decât în cazul în care aplicaţia nu este compatibilă cu standardul IDNA. De asemenea forma encodată reprezina forma sub care un domeniu reprezentat în baza de date distribuită a DNS-ului.

Ne referim la forma encodată, care este de fapt numele de domeniu efectiv înregistrat şi folosit în sistemul DNS, ca la forma ACE (ASCII Compatible Encoding) sau Punycode. O etichetă Punycode este invariabil precedată de secvenţa de caractere xn--, forma encodată urmând imediat după aceast prefix. Modul în care se ajunge de la forma neencodată (etichete conţin caractere speciale aparţinând setului Unicode), la forma encodată va fi prezentat în cele ce urmează.

În momentul în care o aplicaţie, compatibilă cu standardul IDNA, primeşte o cerere de procesare a unui domeniu care conţine caractere neaparţinând setului ASCII, ea trebuie în primul rând sa transforme eticheta în Unicode, mai apoi sa normalizeze eticheta respectiva pentru a fi compatibilă cu cerinţele generale URI. Al doilea pas va consta în encodarea efectivă a etichetei. Acest lucru presupune conversia etichetei pe 8 biti (Unicode) într-un format pe 7 biti, şi anume ASCII. Acest standard nu obligă nici o aplicaţie sa fie compatibilă cu el insuşi, progamatorii, administratorii sau utilizatorii pot alege modificarea aplicaţiilor, mentinând în acelaşi timp operabilitatea şi compatibilitatea cu infrastructurile existente. La momentul actual IDNA este singura opţiune disponibilă. Asigurarea compatibilităţii unei aplicaţii presupune modificări doar la nivelul aplicaţiei respective, oferind totodată flexibilitate la nivelul interfeţelor cu utilizatorul.

3.1.2 Limitări ale standardului IDNA

Protocolul IDNA nu rezolvă toate problemele de nivel lingvistic care pot apărea utilizând diferite scrieri existente. Multe corespondenţe importante atât de nivel lingvistic cât şi la nivelul scrierii nu sunt acoperite de acest protocol şi este necesară tratarea lor în mod separat în afara graniţelor protocolului IDNA. Ca exemplu precizăm ca numele introduse într-o combinaţie tradiţională şi simplificată a limbii chineze nu vor fi mapate într-un singur nume general. Un alt exemplu ar fi numele scandinave care conţin caracterul U+00F6 nu vor fi mapate cu U+00F8.

O alta problemă de mare importanţă care nu va fi tratată în cadrul protocolului IDNA este aceea a creşterii probabilităţii de introducere corectă a unui nume de domeniu internaţional pe baza unor informaţii obţinute pe diverse căi, cum ar fi nume de domenii prezente pe cărţi de vizită, panouri publicitare, anunţuri radio sau prin intermediul telefonului. În aceste cazuri există o mare probabilitate ca utilizatorul să inţeleagă şi să încerce să utilizeze în mod eronat un nume de domeniu. Trebuie precizat că astfel de probleme apar în mod frecevent şi în cazul reprezentării ASCII a numelor de domenii, mai exact pot apărea confuzii între majuscula “O” şi cifra “0” (zero). Astfel prin creşterea numărului de caractere admise în reperezentarea numelor de domenii va creşte impliciti şi probabilitatea apariţiei confuziilor. De precizat este faptul că această problemă, de o mare complexitate, aparţine domeniului lingvistic, modului de introducere a datelor folosind calculatoarele, etc.

3.1.3 IDNA în Aplicaţii

Protocolul IDNA aparţine (aşa cum s-a amintit şi în paragrafele anterioare) exclusiv de aplicaţii. Folosit în conjuncţie cu un resolver, protocolul IDNA joacă rolul unui translator între aplicaţie şi funcţia resolverului. În cazul sistemului DNS, protocolul IDNA precedă operaţia de scriere a numelor de domenii în zonele sistemului.

La nivelul aplicaţiilor întâlnim două operaţii importante care definesc miezul protocolului IDNA. Prima dintre ele numită ToASCII este cea care va fi utilizată înaintea trimiterii unui IDN spre o aplicaţie care necompatibila cu standardul IDNA. Operaţia este utilizată înaintea trimiterii unui domeniu internaţional ca parametru spre o funcţie resolver sau scrierii unui nume de domeniu într-o zonă DNS. A două operaţie, numită ToUnicode va fi utilizată la afişarea numelor de domenii internaţionale în interfeţele cu utilizatorul (de obicei nume de domenii obţinute din zonele DNS).

Este important de menţionat că utilizarea operaţiei ToASCII în procesul de encodare a unui nume de domeniu poate eşua. În cazul în care un nume de domeniu nu poate fi encodat utilizând operaţia ToASCII, aplicaţia va trebui sa deţină metode de semnalizare a acestui fapt, iar acel domeniu nu va putea fi utilizat ca un nume de domeniu internaţional. Operaţia ToUnicode nu va furniza însă niciodată rezultate eronate, fiind operaţia inversă operaţiei ToASCII.

Implementările IDNA vor fi obligate să proceseze etichetele numelor de domenii mai întâi folosind nameprep iar apoi Punycode. Obligatorie fiind atât ordinea precizată anterior cât şi prezenţa ambelor metode în procesarea oricărei etichete ale unui nume de domeniu internaţional. [RFC3490]

3.1.4 Terminologie

Orice cod singular Unicode va fi reprezentat sub forma “U+XXXX” (eg. U+002E, U+002D). Numărul de caractere care urmează după “+” poate varia între 4 şi 6.

Orice interval de coduri Unicode se va reprezenta prin valorile extremităţilor intervalului în hexazecimal, desparţite de secvenţa “..” (eg. 0..2C, 2E..2F).

O etichetă este o parte a unui nume de domeniu. Fiecare parte a unui nume de domeniu este delimitată de obicei utilizând caracterul “.”. Caracterele delimitatoare nu fac parte din etichete. De exemplu domeniul “aut.utt.ro.” este compus din etichetele “aut”, “utt”, “ro” şi evident eticheta nulă.

O etichetă internaţionalizata este o etichetă asupra căreia operaţia ToASCII nu va eşua. Acest lucru specifică faptul că orice etichetă care convine standardului STD13 este o etichteă internaţionalizată. Acest termen este un termen general cuprinzând atât etichetele “ASCII” cât şi cele “non-ASCII”. Deşi majoritatea caracterelor setului Unicode pot apărea în reprezentarea unui nume de domeniu internaţional, există situaţii în care operaţia ToASCII efectuată asupra unor etichete poate rezulta ca un eşec. Acele etichete nu vor intra în categoria etichetelor internaţionalizate.

Un nume de domeniu internaţionalizat sau IDN este un domeniu format doar din etichete internaţionalizate. Acest lucru implică faptul că orice nume de domeniu ASCII este un nume de domeniu internaţionalizat, chiar şi un nume de domeniu care nu foloseşte caractere “non-ASCII” este un nume de domeniu internaţionalizat.

O etichetă ACE este o etichetă internaţionalizată care poate fi reprezentată utilizând setul ASCII şi care are un corespondent echivalent unic nereprezentabil cu ajutorul setului de caractere ASCII. Orice etichetă internaţionalizată care nu poate fi reprezentată cu ajutorul setului de caractere ASCII poate fi convertită prin intermediul operaţiei ToASCII astfel incât reprezentarea în ASCII să fie posibiliă. Rezultatul operaţiei ToASCII va fi reprezentat de o etichetă ACE. O etichetă ASCII va fi lăsată nealterată de operaţia ToASCII.

Conversia unei etichete ACE spre o formă conţinând caractere “non-ASCII” se va face utilizând operaţia ToUnicode. Orice etichetă ACE este precedată de un prefix ACE.

Un container pentru nume de domeniu sau container domeniu este definit în această lucrare ca un argument al unei funcţii, un rezultat returnat de o funcţie, un elemet, etc. desemnat pentru a conţine un nume de domeniu. De exemplu un container domeniu poate fi argumentul funcţiei gethostbyname(), partea care urmează după semnul “@” dintr-o adresă de mail sau valoarea parametrului QNAME dintr-o interogare DNS. Trebuie ca nu orice text desemnând un nume de domeniu este clasificat ca şi un container domeniu, de exemplu numele unui domeniu apărând în câmpul body al unui mesaj nu reprezintă un container domeniu.

Un container domeniu compatibil IDN este un container domeniu creat special pentru a purta un nume de domeniu internaţional. Un container domeniu compatibil IDN va exista doar la nivelul aplicaţiilor, el neputând exista la nivelul infrastructurii sistemului DNS.

Un container domeniu incompatibil IDN este definit în această lucrare ca fiind orice container domeniu care nu este un container domeniu compatibil IDN.

3.1.5 Condiţii şi aplicabilitate

Utilizarea protocolului IDNA presupune respectarea unor cerinţe impuse de acesta. Vom enumera în continuare cele 4 cerinţe pentru conformitatea cu protocolul IDNA:

1 De fiecare dată când pentru separarea etichetelor într-un nume de domeniu se va folosi caracterul “.”, următoarele caractere vor trebui recunoscute ca şi cacaterul “.”: U+002E, U+3002, U+FF0E, U+FF61.

2 Un domeniu care urmează să fie plasat într-un container domeniu incompatibil IDN (vezi subcapitolul Terminologie) obligatoriu trebuie sa conţină numai caractere aparţinând setului de caractere ASCII. Un domeniu compus din etichete care conţin caractere “non-ASCII” va putea fi transformat într-o formă corespunzatoare containerului incompatibil IDN, utilizând operaţia ToASCII pentru fiecare etichetă, iar toate separatoarele (în cazul în care se va folosi caracterul “.”) vor fi aduse la forma U+002E.

3 Etichetele ACE nu vor apărea în interfeţele cu utilizatorul în majoritatea cazurilor. Exceptie de la aceasta regulă vor face cazurile în care nu se vor putea afişa alt fel de etichete decât etichetele ACE sau în cazurile în care afişarea lor este cerută în mod explicit. În cazul în care nu se cunoaşte cu certitudine felul în care pot fi afişate etichetele se vor putea utiliza ambele variante, fiecare având avantajele sau dezavantajele sale. Alegând afişarea etichetelor conţinând caractere “non-ASCII” există riscul ca acestea să nu poată fi randate şi evident afişate. Alegând prezentarea etichetelor ACE acestea vor fi cu siguranţă neinteligibile de către utilizator.

4 La orice comparare a două etichete, un rezultat pozitiv al comparării acestora se va obtine dacă şi numai dacă formele lor ASCII (obţinute prin aplicarea operaţiei ToASCII) sunt egale. Precizăm faptul că se va executa o comparare în care literele mari şi mici vor fi echivalente.

Din punct de vedere al aplicabilităţii, protocolul IDNA este unul foarte general, el putând fi utilizat pentru orice container domeniu, evident nu şi în locurile unde este explicit interzis. IDNA este aplicabil în majoritatea protocoalelor precedente lui, bineînţeles sub o forma ASCII.

La nivelul sistemului DNS, IDNA nu este aplicabil în cazul valorilor câmpurilor NAME şi RDATA ale căror clasă (CLASS) nu este IN. Acest lucru este valabil pentru orice clasa diferită de clasa IN.

3.1.6 Operaţii de conversie

În acest paragraf vor fi prezentaţi paşii necesari efectuării unei conversii şi operaţiille ToASCII şi ToUnicode. Parametrii pasati către ToASCII şi ToUnicode sunt evident etichete, fie ele secvenţe de caractere Unicode sau ASCII. În cazul în care o etichetă va fi reprezentată folosind alt set de caractere decât Unicode sau US-ASCII, aceasta va trebui “transcodată” în Unicode.

Pornind de la numele întreg al unui domeniu, paşii necesari unei conversii sunt urmatorii:

1 Stabilirea tipului numelui de domeniu, după cele două tipuri precizate de [STRINGPREP] în RFC 3454. Tipurile numelor de domenii sunt următoarele: “şir de caractere inmagazinat” sau “şir de caractere interogare”. În cazul în care numele domeniului se dovedeşte a fi de tipul “şir interogare” se va seta semaforul “AllowUnassigned”.

2 Împărţirea numelui de domeniu în etichete, separatorii de etichete nu vor intra în componenţa acestora.

3 Stabilirea impunerii restricţiilor pentru numele calculatoarelor gazdă, prevăzute în [STD3] care defineşte regulile de generare a numelor calculatoarelor gazdă (hostnames). În general aplicaţiile executau acest pas chiar şi înaintea introducerii standardului IDNA, şi deci vor putea continua efectuarea acestei operaţii exact ca înainte. În cazul în care au fost impuse restricţiile conforme standardului [STD3] se va seta semaforul “UseSTD3ASCIIRules”;

4 Procesarea fiecărei etichete utilizând după caz fie operaţia ToASCII fie ToUnicode. În mod uzual se va folosi operaţia ToASCII dacă se doreşte înmagazinarea unei etichete într-un container domeniu incompatibil IDN sau operaţia ToUnicode dacă se va dori afişarea într-o interfaţa cu utilizatorul a unui nume de domeniu internaţional.

5 Dacă a fost utilizată operaţia ToASCII în pasul 4, şi s-a folosit ca separator de etichete caracterul “.”, toti separatorii vor fi convertiţi la U+002E.

În următoarele două subparagrafe se vor defini principiile generale ale operaţiilor ToASCII şi ToUnicode.

Mentionăm faptul că se vor utiliza nume de proceduri şi nume de semafoare specifice. Evident aceste denumiri nu sunt obligatorii în implementarea protocolului IDNA. Orice implementare care va furniza aceleaşi rezultate ca şi rezultatele specificate în RFC 3490 va fi conforma cu protocolul IDNA. [RFC3490]

3.1.6.1 ToASCII

Operaţia ToASCII preia o secvenţa de coduri de caractere Unicode care alcatuieşte o etichtetă şi o transformă într-o secveţă de coduri de caractere în intervalul ASCII (0..7F). Dacă operaţia ToASCII se încheie cu succes, secvenţa originală va fi echivalentă cu cea rezultată în urma efectuării operaţiei.

Operaţia ToASCII poate eşua. Aceasta se va finaliza cu un eşec, dacă parcurgerea oricarui pas pe care ii implică eşuează. Dacă, la conversia unui domeniu, compus din mai multe etichete, operaţia ToASCII va eşua, acel domeniu va fi considerat inutilizabil în contextul domeniilor internaţionale. Aplicaţia în care se va efectua conversia va trebui prevazută cu metode de semnalizare a eşuarii operaţiei ToASCII.

Parametrii de intrare ai operaţiei ToASCII sunt: secvenţa de coduri de caractere Unicode, semaforul “AllowUnassigned” şi semaforul “UseSTD3ASCIIRules”. Rezultatul furnizat de operaţia ToASCII va fi o secvenţa de coduri de caractere ASCII sau eroare.

Operaţia ToASCII nu va modifica niciodată un şir de coduri de caractere ASCII (deşi ar putea eşua). Aplicarea de mai multe ori a operaţiei ToASCII asupra unui şir de coduri de caractere are acelaşi efect ca şi aplicarea ei o singură dată.

Operaţia ToASCII presupune parcurgerea urmatorilor paşi:

1. Se verifică dacă secvenţa de coduri caractere conţine coduri caractere din afara intervalului ASCII (0..7F). În caz afirmativ se va trece la pasul 2, în caz contrar se va trece la pasul 3.

2. Se parcurg paşii specifici nameprep şi se semnalează orice eroare ar putea apărea. Semaforul “AllowUnassigned” aparţine metodei nameprep.

3. Dacă semaforul “UseSTD3ASCIIRules” este setat se vor verifica următoarele:

Absenţa urmatoarelor coduri de caractere: 0..2C, 2E..2F, 3A..40, 5B..60, şi 7B..7F.

Absenţa cratimelor la începutul sau sfârşitul şirului de caractere. Mai exact absenţa codului caracter U+002D de la începutul sau sfârşitul unei etichete.

4. Dacă secvenţa codurilor de caractere conţine coduri din afara intervalului ASCII (0..7F) se va trece la pasul 5, în caz contrar se trece la pasul 8.

5. Se verifică secvenţa astfel încât ea să nu înceapă cu prefixul ACE (vezi paragraful 1.4).

6. Se va encoda secvenţa conform algoritmului Punycode şi se va semnala orice eroare ar putea apărea.

7. Se va adauga şirului encodată prefixul ACE.

8. Se va verifica dimensiunea şirului rezultat (dimensiunea şirului codurilor de caracter). Această dimensiune trebuie să se afle în intervalul [1, 63].

3.1.6.2 ToUnicode

Operaţia ToUnicode preia o secvenţă de coduri de caractere Unicode care alcătuiesc o etichetă şi returnează de asemenea o secvenţă de coduri de caractere Unicode. Dacă secvenţa furnizată la intrare este o etichetă ACE atunci rezultatul furnizat va fi o o etichetă internaţionalizată echivalentă, care nu va fi prezentă în forma ACE, altfel se va returna secvenţa furnizată în forma intactă.

Şansele de eşuare a operaţiei ToUnicode sunt nule. Şirul de coduri de caractere pe care le furnizează operaţia ToUnicode nu va fi niciodată mai lung decât sirul pasat ca parametru. Numărul de octeţi necesari reprezentării unui cod caracter poate varia în funcţie de tipul de encodare a caracterelor.

Parametrii de intrare ai operaţiei ToUnicode sunt: o secvenţa de coduri de caractere, semaforul “AllowUnassigned” şi semaforul “UseSTD3ASCIIRules”. Rezultatul furnizat de operaţia ToUnicode va fi o secvenţă de coduri de caractere Unicode.

În executia operaţiei ToUnicode se vor parcurge urmatorii paşi:

· Se verifică dacă toate codurile de caracter din secvenţa furnizată se află în intervalul ASCII (0..7F). În caz afirmativ se trece la pasul 3.

· Se parcurg paşii specifici nameprep şi se semnalează orice eroare ar putea apărea. Semaforul “AllowUnassigned” aparţine metodei nameprep.

· Se va verifica dacă secvenţa începe cu prefixul ACE şi se salvează o copie a acesteia.

· Se renuntă la prefixul ACE.

· Decodarea secvenţei utilizând algoritmul metodei Punycode şi semnalează orice eroare ar putea apărea. Salvează o copie a secvenţei rezultată după acest pas.

· Se va aplica ToASCII.

· Se va verifica dacă rezultatul operaţiei ToASCII este acelaşi cu secvenţa salvată în pasul 3.

· Se returnează secvenţa salvată în pasul 5.

3.1.7 Prefixul ACE

Prefixul ACE este utilizat în cadrul etichetelor pentru a deosebi o secvenţă encodată de o altă secvenţa neencodată. Prefixul ACE este alcatuit din două caractere alfanumerice, urmate de două cratime. El nu poate lua forme deja existente în implementari anterioare, cum ar fi: "bl--", "bq--", "dq--", "lq--", "mq--", "ra--", "wq--"

şi "zq--". Operatiile ToASCII şi ToUnicode trebuie să recunoască prefixul ACE sub orice formă de scriere s-ar afla acesta (utilizând orice combinaţie de litere mari şi mici). Prefixul ACE aferent standardului IDNA este “xn--“. Acest lucru inseamnă ca orice etichetă ACE va fi de forma “xn--de-jg4avhby1noc0d”, unde “de-jg4avhby1noc0d” reprezină partea generată de algoritmul Punycode.

3.1.8 Specificaţii pentru componentele DNS din aplicaţii

IDNA presupune efectuarea modificărilor doar la nivelul aplicaţiilor, mai exact la nivelul componentelor din aplicaţii care folosesc nume de domenii şi interactionează cu DNS-ul. Astfel aplicaţiile trebuie să asigure posibilitatea introducerii de către utilizatori a numelor de domenii internaţionale, afişarii numelor de domenii internaţionale şi procesării intrărilor şi ieşirilor de la şi către sistemul DNS şi evident alte sisteme şi protocoale.

Sistemul componentelor şi interfeţelor dintre utilizatori şi sistemul DNS poate fi reprezentat grafic după cum urmează:

Fig 3.1 Reprezentarea generică a protocolului IDNA

3.1.9 Introducerea şi afişarea domeniilor internaţionale în aplicaţii

Aplicaţiile pot fi dezvoltate să afişeze şi să ofere posibiliatatea introducerii domeniilor în orice set de caractere se doreşte. Modul în care se face introducerea şi modul în care se face afişarea fiind opţiunea fiecărui programator şi sau utilizator. IDNA nu intervine în nici un fel asupra interfeţei dintre utilizator şi aplicaţie.

Aplicaţiile compatibile IDNA oferă posibiliatatea afişarii şi introducerii numelor de domenii în două formate, şi anume: în formatul internaţionalizat utilizând orice set de caractere suportat de aplicaţie, sau formatul etichete ACE. În cazul în care se vor folosi pentru afişare etichetele ACE, acestea trebuie neaparăt să includă prefixul ACE. Introducerea şi afişarea etichetelor ACE poate fi posibilă în aplicaţii, însă acest lucru nu este indicat, decât în cazurile în care acest lucru este cerut explicit sau nu se dispune de o alta soluţie alternativă. Forma encodată ACE este inexpresivă şi neinteligibilă şi nu trebuie expusă utilizatorilor decât în cazul în care acest lucru este obligatoriu. Totusi pentru o mai bună compatibilitate, există posibilitatea afişarii unui dialog, în care utilizatorul va putea alege forma de afişare dorită. În acest caz, forma encodată ACE, nu va trebui setată ca prestabilită.

Numele de domenii sunt vehiculate foate des, stocate şi transportate de-a lungul reţelei informaţionale. Ele pot fi prezente în conţinutul mesajelor electronice sau paginilor web. Este important de reţinut faptul că numele de domenii pot fi conţinute atât în containere domenii cât şi în alte părţi, ca şi conţinut al diferitelor protocoale existente. În cadrul protocoalelor şi documentelor un nume de domeniu poate apărea reprezentat în orice set de caractere. În cadrul protocoalelor sau documentelor care specifică în mod explicit utilizarea unei serii de seturi de caractere sau unui singur set de caractere, se recomandă utilizarea seturilor conform specificaţiilor oferite de acel protocol. În orice protocol sau document care permite transmiterea caracterelor în format internaţional, se va utiliza metoda de transmitere folosită de acel protocol. Un protocol care foloseşte containere domenii are deja capacitatea procesării caracterelor ASCII. Astfel procesarea etichetelor ACE poate fi executată imediat de aceste protocoale, faca nici o modificare a aplicaţiei sau protocolului.

3.1.10 Concluzii şi Securitate

Standardul IDNA propune un mod deosebit de eficient de rezolvare a problemei utilizarii numelor de domenii pe scară largă în reţeaua Internet. Modificarile necesitate fiind relativ uşor de realizat, la nivelul fiecărei aplicaţii care se doreşte a fi compatibilă cu standardul IDNA. Nu sunt necesare modificări ale infrastructurilor, în special ale infrastructurii DNS, care acceptă procesarea doar a domeniilor în format ASCII. De aici rezultă nevoia de a proteja infrastructura DNS de contactul cu numele de domenii în format IDN. Aceasta protejare se execută la nivelul aplicaţiilor, numele fiind transformate pentru a fi acceptate de orice server DNS existent. La nivelul serverelor root, din cauză că în general o etichetă ACE are o dimensiune sensibil mai mare decât etichetele curente, va fi necesară o laţime de bandă proporţional mai mare. De altfel din cauză că interogările şi raspunsurile pentru domeniile internaţionale sunt mai mari decât cele uzuale, se va trece de multe ori la utilizarea protocolului TCP în locul protocolului UDP.

Acest algoritm descrie o metodă de encodare a numelor de domenii, făcându-le compatibile cu standardele STD3 şi STD13. Astfel nu va fi afectată nici o componenţa prin utilizarea acestei metode. Sistemul DNS rămâne intact. Modificarile aduse aplicaţiilor fiind în responsabilitatea programatorilor şi administratorilor aplicaţiilor respective. Urmând îndeaproape normele protocolului IDNA securitatea acestor aplicaţii nu ar trebuie să presupună creeare problemelor de securitate. [RFC3490]

3.2 Nameprep

Nameprep este o metodă derivată din metoda Stringprep definită în documentul RFC 3454, din Decembrie 2002. Metoda nameprep defineşte modul de pregătire a unui set de caractere dintr-un nume de domeniu internaţional (IDN) pentru a mari posibilitatea ca introducerea unui nume de domeniu şi compararea acestuia să dea rezultate cât mai folositoare utilizatorilor de pretutindeni.

Metoda nameprep este parte integrantă a unei suite de protocoale care definesc împreună standardul IDNA. Această metodă stabileşte unele reguli pentru a ajuta orice utilizator sa folosească şi să introducă orice nume de domeniu internaţional în cadrul aplicaţiilor, şi de asemenea să obţină de cele mai multe ori rezultatele scontate. Aceste reguli se vor referi în continuare doar la numele de domenii internaţionale, metoda nameprep fiind special concepută pentru acestea.

Nameprep va procesa doar etichete, procesarea domeniilor nefiind scopul acestei metode. IDNA va apela metoda nameprep pentru fiecare etichetă a unui domeniu în parte, şi nu pentru numele domeniului în întregime.

Nameprep defineşte următoarele:

· Aplicabilitatea metodei pentru: numele de domenii internaţionale procesate de IDNA.

· Setul de caractere pentru parametrii de intrare şi ieşire ai metodei: Setul de caractere Unicode 3.2 (definit şi în stringprep, Anexa A).

· Tipul de mapări folosite: Mapările folosite sunt definite în stringprep sub forma tabelelor B.1 şi B.2).

· Tipul normalizarii folosite: Tipul normalizării folosite este cel utilizat şi în stringprep, normalizarea de forma KC. Forma de normalizare KC mapează un număr mare de “caractere de compatibilitate” cu echivalentele lor. Unele interfeţe permit introducerea caracterelor de compatibilitate în locul caracterelor de bază. Folosing forma KC în locul formei C va avea ca efect portivirea mai multor şiruri de caractere lucru aşteptat de către utilizator.

· Utilizarea caracterelor bidirectionale: definite în stringprep secţiunea 6. În această secţiune se explică utilizarea seturilor de caractere definibile atât de la dreapta la stânga cât şi de la stânga la dreapta. Ignorarea acestui aspect poate duce la ambiguităţi în procesul de afişare şi citire a textului.

· Caracterele interzise spre iesire: Aceste caractere sunt definite în stringprep şi sunt specificate cu ajutorul urmatoarelor tabele:

o Tabela C.1.2

o Tabela C.2.2

o Tabela C.3

o Tabela C.4

o Tabela C.5

o Tabela C.6

o Tabela C.7

o Tabela C.8

o Tabela C.9 [RFC3491]

3.3 Punycode

Punycode reprezintă o metodă eficientă de encodare şi transfer special concepută pentru a fi utilizată în aplicaţiile care folosesc nume de domenii internaţionale. Punycode transformă în mod unic şi reversibil un şir de caractere Unicode într-un şir ASCII. Caracterele ASCII din stringul Unicode vor rămâne nemodificate, iar caracterele “non-ASCII” vor fi reprezentate în mod unic prin combinaţii ale caracterelor permise deja a fi utilizate în construirea numelor de domenii (literele de la “a” la “z”, cifrele de la “0” la “9” şi bineînţeles caracterul “-“).

Punycode reprezintă o instanţă a metodei “Bootstring”, care este o metodă mult mai generală, concepută pentru a fi utilă în operaţiille de transformări ale şirurilor de caractere. Bootstring este algoritmul care permite ca printr-un şir restrâns de caractere să reprezinte în mod unic orice şir extras dintr-un set de caractere mult mai mare. Punycode reprezintă o instanţiere a metodei Bootrstring, special concepută pentru standardul IDNA.

IDNA descrie o arhitectură pentru suportarea standardizată a numelor de domenii internaţionale. Etichetele conţinând caractere “non-ASCII” pot fi reprezentate prin intermediul etichetelor ACE care conţin numai caractere ASCII, adăugându-se la început prefixul ACE. Aceste etichete conţinând numai caractere ASCII, şi formate cu ajutorul prefixului ACE, reprezintă şiruri encodate cu ajutorul algoritmului Punycode. Desigur, şir de caractere, fără prefixul ACE reprezintă sirul Unicode encodat folosind algoritmul Punycode.

Bootstring reprezintă o metodă mai generală, care deţine următoarele atribute:

1. Totalitate: orice şir extins (prin şir extins inţelegem un şir reprezentat într-un set de caractere extins) poate fi reprezentat printr-un şir de caractere primar (un şir de caractere primar reprezinta un şir de caractere reprzentate într-un set restrans de caractere).

2. Unicitate: există cel mult un şir de caractere primar care reprezintă un şir de caractere extins.

3. Reversibilitate: orice şir extins, transformat într-un şir primar poate fi retransformat la forma sa iniţială ca şir extins.

4. Eficeinţa encodării: raportul lungimii unui şir encodat asupra unu şir extins este foarte mic, lucru care prezintă un mare avantaj mai ales în transformarea etichetelor numelor de domenii, acestea fiind limitate prin documentul RFC 1034 la 63 de caractere.

5. Simplitate: algoritmii de transformare (encodare, decodare) sunt relativi simpli, fiind foarte uşor de implementat.

6. Inteligibilitate: codurile caracter primare din şirurile extinse vor fi lăsate nemodificate, deşi ţinta acestei metode bate spre eficienţă şi nu inteligibilitate.

Algorimtul Punycode, fiind o instanţă a algoritmului Bootstring urmează îndeapoape caracteristicile acestuia, inclusiv atributele amintite mai sus. Deşi Punycode pune la dispoziţie o soluţie completă pentru operaţiille ToASCII şi ToUnicode, aceasta mai oferă şi alte facilităţi. La o privire de ansamblu Punycode este alcătuit din două ramuri, şi anume o ramură de encodare sau codificare şi o ramură de decode sau decodificare. Fiecare dintre acestea stând la baza operaţiilor ToASCII şi respectiv ToUnicode. Prezentarea exactă a algoritmilor acestor metode nu face însă obiectul acestei lucrari. Algorimtii de encodare şi decodare, în forma oficială pot fi gasiţi în documentul RFC 3491 accesând adresa http://www.rfc-editor.org/rfcsearch.html.

Punycode este parte integrantă a protocolului IDNA, utilizat la conversia etichetelor în etichete ACE. Punycode nu a fost creat pentru a servi în alte scopuri decât conversia etichetelor numelor de domenii. Cu atât mai mult nu a fost creat pentru a servi la conversia textelor arbitrar alese. [RFC3492]

3.4 HTML & CSS

La începutul anilor ‘90, un grup restrâns de fizicieni de la CERN (Laboratorul European de Fizică a Particulelor), au elaborat şi publicat un limbaj pentru crearea documentelor în format electronic şi un sistem de distribuire a acestora care permitea folosirea documentelor electronice multimedia în reţeaua Internet. Acest punct a marcat naşterea limbajului HTML (HiperText Markup Language).

Documentele nu mai erau distribuite sub forma unor colecţii fragmentate de text, imagini şi sunete şi erau înglobate eficient sub forma unor documente HTML. Sistemele World Wide Web permiteau “hipertext linking” (legătura prin hipertext), prin care documentele pot face referiri automate la alte documente, localizate oriunde în lume. Ceea ce a avut ca rezultat scăderea timpului de căutări a referinţelor şi creşterea productivităţii.

Explozia World Wide Web a avut loc însă când un grup de studenţi şi cadre didactice de la National Center for Supercomputing Applications (NCSA), de la Universitatea din Illinois, Urbana-Champaign a prezentat un browser web numit Mosaic. Deşi destinaţia sa primară era afişarea documentelor HTML, îngloba şi facilităţi de accesare a altor resurse din Internet, cum ar fi arhivele de software FTP, şi colecţiile de documente organizate sub sistemul Gopher.

HTML este un limbaj de formatare a documentelor şi specificare a “hyperlink-urilor”. Limbajul defineşte sintaxa şi plasarea unor instrucţiuni speciale, înglobate în document. Aceste instrucţiuni nu sunt afişate de către browser ci îi indică acestuia modul în care trebuie afişat conţinutul documentului, incluzând text, imagini şi alte medii. Limbajul indică de asemenea modul în care documentul se comportă interactiv prin legături speciale hipertext (numite hypertext links, hyperlink sau pur şi simplu links). Aceste legături conectează documentul cu alte documente aflate pe acelaşi calculator sau pe alte calculatoare, precum şi cu alte resurse Internet, cum ar fi FTP sau Gopher.

Cascading Style Sheets reprezintă o modalitate generală de a configura în detaliu redarea vizuală a elementelor unui document HTML. Standardul HTML oferă un suport redus pentru specificarea exactă a redării vizuale a elementelor HTML, preferând o definire la nivel logic a majorităţii elementelor şi lăsând la discreţia browserelor redarea vizuală a elementelor.

Folosind tehnica CSS, autorul documentului HTML poate specifica atribute fizice pentru redarea vizuală, cum ar fi, culoarea textului, culoarea de fond, mărimea caracterelor, distanţele între elemente, etc.

3.5 Limbajul Perl

Limbajul Perl a fost creat de Larry Wall, într-un efort de a crea rapoarte pentru sisteme de urmărire a problemelor din produsele software. Larry Wall, crease astfel un limbaj interpretat (scripting language) şi l-a publicat pe Internet, pentru oricine ar dori să-l folosească în scopuri asemănătoare. În spiritul “freeware” foarte multe persoane au început să contribuie la dezvoltarea acestui limbaj, ajungând în zilele noastre la un limbaj de programare robust, utilizat pe scara foarte largă, în varii domenii. Perl a devenit limbajul preferat pentru dezvoltarea aplicaţiilor CGI, deşi este folosit pe scară largă pentru metoda de dezvoltare prin prototipizare rapidă, cât şi ca “limbaj de legatură” care face posibile interacţiunile între sisteme diferite. Perl este foarte popular printre administratorii de sistem care folosesc acest limbaj pentru automatizarea diferitelor procese.

Limbajul Perl prezintă un grad ridicat de portabilitate. Deşi îşi află originile strans legate de sistemul de operare Unix, Perl a fost făcut disponibil pentru o mare varietate de platforme, printre acestea aflându-se şi sistemul de operare Windows. Limbajul Perl oferă instrumente puternice de manipulare a textului, combinate cu elemente preluate din limbajul C şi o serie de facilităţi specifice aplicaţiilor shell. Perl a fost proiectat pentru a fi un limbaj practic (uşor de folosit, eficient, complet), şi nu un limbaj elegant şi minimal. Aceste caracteristici fac din limbajul Perl limbajul cel mai adecvat pentru aplicaţiile CGI.

Perl este un limbaj care oferă instrumente puternice de prelucrare a textului. Printre ele enumerăm crearea foarte uşoară a rapoartelor, formatelor şi bineînţeles “pattern matching”. Sintaxa limbajului Perl este foarte apropiată cu cea a limbajului C, Perl însă fiind un limbaj de programare interpretat (scripting language), de aici denumirea de “scripturi” a programelor dezvoltate în Perl. Instrumentul “pattern matching” este un instrument foarte puternic ce permite programatorului scanarea unor cantităţi mari de text într-un timp foarte scurt. Deşi limbajul Perl a fost optimizat pentru manipularea textului, el poate prelucra la fel de comod şi date în format binar.

Una din cele mai puternice şi folositoare facilităţi ale limbajului Perl este fără îndoială cea oferită de expresiile regulate (Regular Expression). Expresiile regulate sunt un set de caractere şi reguli care permit descrierea unor modele de text (şabloane), într-un mod analog binecunoscutelor cactere “*” şi “?” folosite pentru descrierea generală a numelor de fişiere în sistemul de operare DOS şi UNIX.

Spre deosebire de C, controlul memoriei este automat, variabilele create dinamic fiind dealocate automat atunci când nu mai există nici o referinţă spre ele. Script-urile perl care rulează cu privilegii speciale (root privileges) sunt mult mai sigure decât programele C care rulează cu aceleaşi privilegii, datorită unor mecanisme de urmărire a fluxurilor de date care pot preveni multe riscuri de securitate. O altă facilitate a limbajului Perl este gestionarea automată a memoriei (aşa numitul “automatic garbage collecting”). Atât variabilele globale cât şi cele locale sunt alocate automat la prima menţionare a lor şi sunt deasemenea dealocate automat atunci când nu mai există referiri la ele. Acest lucru este realizat prin păstrarea în tabela de simboluri a unui contor de referinţe, care este incrementat ori de câte ori apare o nouă referinţă la variabila respectivă şi este decrementat atunci când o referinţă dispare (ori prin ieşirea din domeniul de validitate pentru variabile locale ori prin folosirea funcţiei “undef” care forţează distrugerea conţinutului unei variabile). Această facilitate, deşi scade din performanţele de viteză ale limbajului, şi nu permite manipularea directă a pointer-ilor precum în C, uşureaza mult munca programatorului şi previne apariţia aşa-numitelor “memory leaks” care pot conduce la degradarea performanţelor sistemului, la apariţia unor riscuri de securitate şi chiar la coruperea datelor.

Limbajul Perl suportă trei tipuri de date:

1 Tipul Scalar – care poate conţine un caracter, un şir de caractere, un număr întreg sau real, sau o referinţă spre altă variabilă.

2 Tipul Array - este un şir de date scalare, indexate prin numere pornind de la zero. De asemenea tipul poate avea mai multe dimensiuni, astfel putând lua forma unui vector sau a unei matrici.

3 Tipul Hash - este un şir asociativ de scalari, adică un şir în care elementele sunt indexate prin şiruri de cactere. Tipul este oarecum asemănător tipului struct din limbajul C, sau tipului record din limbajul Pascal.

Tipurile de date, utilizate în limbajul, Perl se deosebesc prin folosirea unui prefix de dimensiunea unui caracter. Astfel, numele unei variabile de tip scalar va fi precedat de caracterul “$”, numele unei variabile de tipul array va fi precedat de caracterul “@” iar numele unei variabile de tipul hash va fi precedat de caracterul “%”.

La fel ca şi în cazul limbajului C, care îşi găseşte aplicabilitatea în foarte multe domenii datorită marii varietăţi de biblioteci disponibile, Perl pune la dispoziţia programatorului posibilitatea de a ataşa module funcţionale (biblioteci) oricărui script. Astfel, există o foarte largă varietate de module (packages), fişiere perl, de obicei având extensia “.pm”, care joacă rolul bibliotecilor din limbajul C. Acestea sunt incluse de obicei la începutul scriptului şi definesc structuri de date şi clase de obiecte folositoare pe parcursul rulării acestuia. Exista de altfel şi o importantă resursă de astfel de librării, destinate special limbajului Perl, acestea se găsesc într-o formă foarte bine organizată, accesând site-ul http://www.cpan.org.

Dintre cele mai uzuale module amintim:

1 Modulul CGI – care oferă instrumente bogate şi o colecţie de clase pentru controlul şi gestionarea paginilor HTML cât şi a parametrilor obtinuti de la serverul web.

2 Modulul DBI – este un modul care oferă accesul la resursele unor baze de date, independent de tipul acestora. El oferă o serie de metode şi clase foarte utile pentru lucrul cu seturi mari de informaţii. Comunicarea cu serverele de baze de date se face cu ajutorul unor drivere oferite de DBI::DBD.

3 Modulul Net::Daemon – oferă un set de instrumente flexibile pentru creeara comodă a aplicaţiilor de tip server, permiţând controlul automat al memoriei şi numărului proceselor şi firelor de execuţie necesare pe parcursul funcţionării.

4 Modulul IO::Socket – pune la dispoziţia programatorului un set larg de instrumente pentru creeara şi controlul socketurilor în aplicaţii.

5 Modulul IO::File – este un modul util pentru gestionarea rapidă şi comodă a fişierelor. Acesta include metode rapide pentru crearea, citirea, scrierea şi ştergerea fişierelor.

Toate aceste module au fost utilizate în dezvoltarea componentelor sistemului NetBeat. Pe lângă acestea mai exista un număr de pachete, special create pentru dezvoltarea componentelor sistemului NetBeat. Acestea vor fi prezentate pe larg în capitolul următor. [LTJ00]

3.6 Tehnologia Client – Server

Tehnologia Client – Server presupune existenţa a două componente de baza sub forma a două entităţi:

· Serverul – gestionează resursele unui sistem într-un mod transparent pentru client.

· Clientul – accesează resursele puse la dipoziţia sa de către server.

Comunicarea între client şi server se face utilizând un protocol prestabilit. Resursele sunt puse la dispoziţia clientului de către server prin accesarea lor directă (Fig 3.2).

Fig 3.2 Modelul Client – Server

În mod uzual serverul rulează ca instanţă singulară, deşi se pot utiliza mai multe instanţieri în cazul unui volum de procesare mare a informatiei şi evident în cazul unui volum mare de conectări. De asemenea pot exista mai multe instanţieri ale serverului din principii de sigurantă sporită şi sau echilibrarea încărcării instanţelor server (principiu cunoscut ca “load balancing”). În schimb, numărul de instanţe client poate varia de la o singură instanţiere până la cifre de oridinul miilor. Programele client vor putea accesa secvenţial sau concurent resursele puse la dispoziţie de către server (Fig 3.3). Modul în care se oferă accesul la aceste resurse depinzând în totalitate de arhitectura serverului. În cazul în care accesul la resurse nu se poate executa în mod concurent de către server, acesta va putea folosi metode de multiplexare pentru a simula accesul concurent pentru clienţi.

Cube: Client 1

Fig 3.3 Model de acces concurent a trei clienţi la un server

Tehnologia Client – Server prezintă următoarele avantaje:

· Controlul Accesului – la nivelul serverului se poate implementa o politică de acces la resurse, aceasta permite sau interzice permanent sau temporar accesul anumitor clienţi la resursă, sau poate oferi acces prioritar unor anumiţi clienţi.

· Transparenţa – clienţii nu trebuie să cunoască detaliile de acces la resurse (cum ar fi de exemplu localizarea ei sau modalitatea de acces direct la diferite resurse). Aceste detalii le cunoaşte doar serverul, care accesează direct resursa oferindu-le clienţilor doar strict informaţiile necesare.

3.7 Tehnologia CGI

CGI (Common Gateway Interface) a fost prima tehnologie care permitea afişarea paginilor create dinamic prin intermediul serverelor web. CGI permite serverului să genereze pagini dinamic, nefiind necesară crearea acestora în prealabil.

Tehnologia CGI este o interfaţă care permite extinderea funcţionalităţii serverelor web, făcând posibilă interacţiunea acestuia cu utilizatorul care accesează resursele sale. Din punct de vedere teoretic această tehnologie permite extinderea capabilităţii serverului de a interpreta şi procesa date primite de la utilizatori prin intermediul browserelor web. Acest lucru este deosebit de util, oferind clientului posibilitatea selectarii doar a anumitor rezultate pe care acestă le doreşte, în urma furnizării unui set de date de intrare. Din punct de vedere practic, tehnologia furnizează programatorului posibilităţi de a crea programe care interacţionează foarte uşor cu serverul web şi resursele acestuia (Fig 3.4).

Comunicarea dintre un program şi serverul web, utilizând tehnologia CGI, este standardizată. Programatorul putând dezvolta seturi de programe portabile, independente de tipul serverului web, cunoasterea detaliilor de implementare a tehnologiei CGI nefiind necesară.

Fig 3.4 Simplă reprezentare a principiului CGI

Tehnologia presupune parcurgerea anumitor paşi, atât de către server cât şi de către client (browserul web). Astfel:

· Utilizatorul introduce datele în browser şi le trimite prin intermediul acestuia înspre serverul web. Interfaţa care permite introducerea datelor se numeşte “form”.

· Serverul apelează aplicaţia CGI care preia datele introduse de către utilizator. Datele sunt preluat prin intermediul unor parametrii, fiecare parametru având un nume şi o valoare, principiul fiind asemanator cu pasarea parametrilor înspre o funcţie.

· Aplicaţia CGI procesează datele cerute de către utilizator şi îi răspunde acestuia generând datele de ieşire. De obicei datele de ieşire sunt prezentate utilizatorului sub forma unei pagini HTML.

· Serverul preia răspunsul aplicaţiei CGI şi-l trimite browserului care afişează răspunsul primit.

Formurile constituie un subset al limbajului HTML, fiind constituit din mai multe entităţi cum ar fi: câmpuri text, casuţe de dialog, butoane, casuţe “radio-button”, casuţe “check-box” şi meniuri. Pentru a expedia datele conţinute într-un form, utilizatorul va trebui să apese butonul “Submit”. Astfel, se va rula aplicaţia CGI, având ca parametrii de intrare datele furnizate de utilizator prin intermediul formului.

Comunicarea cu bazele de date se efectuează cu ajutorul aplicaţiilor CGI, care preiau, formateaza şi oferă spre afişare orice date solicitate de utilizator. Acest lucru se datorează imposibiliaţii de comunicare directă între bazele de date şi serverele web, deoarece ambele folosesc protocoale diferite, incompatibile. În acest mod se pot accesa diverse resurse ale căror protocoale nu sunt compatibile cu protocolul HTTP folosit de serverele web.

Vom exemplifica în continuare prin intermediul unei reprezentări grafice, rolul pe care îl are o interfaţa CGI în dialogul utilizatorului (prin intermediul unui browser web) cu o baza de date Oracle.

Fig 3.5 Principiul gateway-ului CGI

Implementarea aplicaţiilor CGI se poate face într-o varietate largă de limbaje de programare (Perl, C sau chiar shell scripting). Cerinţele de bază pe care limbajul trebuie să le îndeplinească sunt capabilităţile de citire/scriere pentru standard input, respectiv output.

3.8 Limbajul SQL

SQL a fost dezvoltat spre sfârşitul anilor 1970, la un laborator IBM, în San Jose, California. Iniţial SQL a fost destinat produsului sistemului de gestionare a bazelor de date relaţionale DB2, un produs al companiei IBM.

Diferenţa între sistemele de gestionare a bazelor de date (DBMS) şi sistemele de gestionare a bazelor de date relaţionale (RDBMS) constă în faptul că acestea din urmă oferă un limbaj orientat pe seturi (“set-oriented”, adică operează pe seturi de date) pentru baza de date. De obicei limbajul utilizat este limbajul SQL.

SQL permite administratorului bazei de date să efectueze mai multe operaţii de management al baze de date. Printre aceste operaţii se află operaţii la nivelul structurii bazei de date, cât şi la nivelul managementului informaţiilor conţinute în aceasta.

Astfel administratorul are posibilitatea :

· Modificării structurii bazei de date.

· Schimbării setărilor legate de securitate.

· Adaugării permisiunilor referitoare la baze de date sau la tabelele pentru utilizatori.

· Extragerii de informaţii din baza de date.

· Modificării conţinutului bazei de date.

La nivelul utilizatorului găsim doar posibilităţi de populare, modificare sau stergere a datelor conţinute în baza de date. Aceste operaţii sunt garantate utilizatorilor de către administratori, aceştia putând conferi seturi de permisiuni separate pentru fiecare utilizator în parte.

Principalele instructiuni SQL sunt:

· SELECT - selectează un set de date din una sau mai multe tabele sau baze de date.

· INSERT - adaugă o înregistrare într-o tabelă a bazei de date.

· DELETE - elimină un set de înregistrări dintr-o tabelă a bazei de date.

· UPDATE - modifică valorile câmpurilor unui set de înregistrări.

Sintaxa simplificată a instrucţiunii SELECT:

SELECT câmp [,câmp…] FROM tabelă [,tabelă…] [WHERE condiţie [AND/OR condiţie…]] [ORDER BY câmp [,câmp]];

Câmpurile specificate după SELECT reprezintă setul de date care se doreşte a fi returnat. Tabelele specificate după cuvantul cheie “FROM” sunt tabelele din care fac parte câmpurile referite în instrucţiune. Clauza opţională “WHERE” specifică un set de condiţii pe care operaţiunea de extragere a datelor trebuie să le îndeplinească, iar clauza opţională “ORDER BY” specifică câmpurile după care se doreşte a se ordona seturile de date returnate.

Sintaxa simplificată a instrucţiunii INSERT:

INSERT [INTO] tabelă [(câmp [,câmp…])] VALUES (valoare [,valoare…]);

Tabela menţionată după cuvintele cheie “INSERT INTO” este tabela în care se va insera înregistrarea. Valorile din lista “VALUES (…)” sunt valorile inserate. Dacă nu se specifică valori pentru fiecare câmp al tabelei, atunci trebuie menţionate câmpurile pentru care au fost specificate valori sub forma ( câmp [,câmp…]).

Sintaxa simplificată a instrucţiunii DELETE:

DELETE FROM tabelă [WHERE condiţie [AND/OR condiţie…]];

Instrucţiunea şterge din tabela menţionată înregistrările ce verifică setul de condiţii specificat. Dacă nu se specifică nici o condiţie, se vor şterge toate înregistrările din tabelă (ATENŢIE: după executarea comenzii nu se va cere nici o confirmare pentru certificarea acţiunii efectuate).

Sintaxa simplificată a instrucţiunii UPDATE:

UPDATE tabelă SET câmp=valoare [,câmp=valoare…] [WHERE condiţie [AND/OR condiţie…]];

Instrucţiunea modifică înregistrările din tabela specificată ce îndeplinesc setul de condiţii date (sau toate înregistrările dacă nu se specifică nici o condiţie), atribuind câmpurilor specificate valorile respective.

Cele mai populare implementări de sisteme de baze de date SQL sunt : Microsoft SQL, Oracle, MySQL sau PostgreSQL, ultimele două reprezentând implementări open source.

4 Prezentarea Componentelor Software

4.1 Arhitectura generală a sistemului NetBeat

Sistemul NetBeat este alcătuit din şase componente principale, care gestionează una sau mai multe resurse fiecare. Aceste componente sunt strâns legate între ele, nucleul care le ţine fiind reprezentat de baza de date. Baza de date stă în centrul coodronării tuturor componentelor, ea furnizează datele pe baza cărora fiecare componentă activează în cadrul sistemului. Componentele principale sunt:

1. Interfaţa cu utilizatorul – care constituie principalul mod de comunicare între sistem şi utilizator. De aici se pot executa orice configurări ale domeniilor aflate în posesia utilizatorului.

2. Sistemul de înregistrare – care constituie un mecanism complex format din mai multe componente, în strânsă legatură cu alte componente principale ale sistemului.

3. Sistemul de hosting – aflat în strânsă legatură cu baza de date acesta crează printr-un modul al serverului Apache hosturile virtuale ale clienţilor.

4. Sistemul de mail – gestionează căsuţele poştale ale clienţilor, utilizând de asemenea baza de date ca element principal al funcţionării şi controlului căsuţelor poştale.

5. Sistemul DNS – este un sistem de control a creării zonelor şi gestionare a resurselor serverelor DNS ale sistemului.

6. Sistemul bazei de date – gestionează conturile utilizatorilor la baza de date.

Vom prezenta în continuare o schemă generală a componentelor şi interacţunile dintre componente în sistemul NetBeat:

Reserved: Utilizator

Fig 4.1 Schema generală a principiului de funcţionare al sistemului NetBeat

Observăm prezenţa unui sistem de sincronizare în interiorul sistemului de înregistrare. Acest sistem de sincronizare deţine sarcina controlului componentelor sistemului de înregistrare, sincronizărilor şi rulărilor periodice a elementelor de executie ale acestora. Rularea elementelor de execuţie se face periodic, prelucrându-se astfel o coadă de aşteptare, în care sunt introduse continuu cererile utilizatorilor. Aceste cereri vor fi puse în oridinea stadiului de prelucrare în care se află, ele putând avansa secvenţial sau nesecvenţial în funcţie de tipul domeniului şi stadiul în care se află.

Conform schemei prezentate anterior, utilizatorul comunică cu sistemul printr-o interfaţă realiazată utilizând tehnologia CGI. Aplicaţiile CGI sunt implementate utilizând limbajul Perl. De comunicarea cu utilizatorul se mai face şi prin intermediul poştei electronice, spre acesta fiind trimise mai multe mesaje conţinând coduri de confirmare sau informaţii referitoare la procesul de înregistrare al domeniilor.

Interfaţa cu utilizatorul, sistemul de înregistrare, baza de date pot coexista pe un singur calculator. Desigur pentru a spori performanţele de viteză ale sistemului este de preferat folosirea mai multor sisteme, pentru fiecare componentă în parte. La fel ca şi aplicaţiile CGI, marea majoritate a aplicaţiilor din cadrul componentelor sistemului au fost realizate utilizând limbajul de programare Perl. Există însă şi unele aplicaţii realizate în limbajul C, evident din motive de creştere a vitezei, limbajul C dovedindu-se a fi capabil de viteze foarte ridicate în lucrul cu bazele de date.

Sistemele de mail, DNS, hosting şi baze de date sunt localizate pe sisteme separate, comunicarea între ele făcându-se utilizând tehnologia client-server. De altfel, sistemele de mail, DNS, hosting şi bază de date sunt sisteme server, care execută diferite operaţii la comanda sistemului de sincronizare al componentei de înregistrare. Precizăm faptul ca sistemele de mail şi de hosting deţin mai multe instanţieri, câte una pentru fiecare sistem pe care acestea rulează. La fel sistemul DNS este alcătuit din două componente, una primară, de creare şi generare a zonelor serverului de nume primar, şi o componentă care actualizează zona serverului de nume secundar.

Comunicarea cu sistemele care oferă domenii (registrări) se face în prezent utilizând trei metode. Felul în care se execută procesul de înregistrare, sincron sau asincron depinde invariabil de serviciile puse la dispoziţie de către registrar şi registry.

4.2 Prezentarea bazei de date

Baza de date a sistemului NetBeat este implementată cu ajutorul serverului MySQL 3. Principalele tablele care alcătuiesc sistemul sunt:

· Tabela cozii de procesare (queue) – această tabelă conţine toate domeniile care se află în stadiul de procesare. Aici sunt specificate tipul domeniului (typ), nivelul de procesare actual (status), codul de confirmare (code), data intrării în procesare (datum), tipul înregistrării (kk, normală sau transfer).

· Tabela domeniilor active (konten) – conţine numărul de identificare al clientului (nummer), numele domeniului (domain), tipul acestuia (typ), data la care a fost inregistrat (datum), adresa serverului de hosting (ip), numele serverului de mail (mailserver), fanionul pentru blocare (blockiert), forma ACE a domeniului (domain_ace) şi parola serverului de FTP al domeniului (ftp_pass).

· Tabela casuţelor poştale (mail) – ţine evidenţa tuturor căsuţelor poştale prezente în sistem, fie ele POP3 sau forward. Toate informaţiile sunt stocate folosind câmpurile : domain, nummer pentru stocarea numelui domeniului şi a identificatorului client, typ pentru stocarea tipului de casuţă poştală, name contţne numele casuţei poştale, passwort va conţine parola casuţei în cazul în care aceasta este o casuţă POP3 iar ziel va conţine adresa ţintă pentru casuţele de tip redicrectare.

· Tabela facturilor (rechnungen) – conţine absolut toate datele despre facturile unui domeniu, aceste date includ: numele domeniului, tipul serviciului facturat, valoarea facturată, valuta în care este exprimată valoarea facturii, fanionul care indică dacă o factură a fost platită sau nu, stadiul în care se află factura, data trimiterii facturii, a reminder-elor, câmpul pentru observaţii, etc.

Structura tabelelor se alflă în Anexa 1, de la sfarşitul acestei lucrări. În această anexă sunt prezentate atat numele tabelelor şi câmpurilor cât şi tipul şi dimensiunile acestora şi indecşii aferenţi.

4.3 Interfaţa cu utilizatorul

Aşa cum am amintit şi în paragraful anterior, interfaţa cu utilizatorul este realizată folosind tehnologia CGI. Toate aplicaţiile care intră în componenţa acesteia fiind realizate utilizând limbajul Perl. Interfaţa este găzduită pe un server web propriu, fiind compusă din mai multe secţiuni.

O prima secţiune este cea care permite verificarea disponibilităţii unui nume de domeniu, crearea unui utilizator nou şi evident comandarea unui nume de domeniu. Această secţiune este compusă din trei aplicaţii CGI, fiecare având un rol bine determinat. Utilizatorul, pentru a comanda un domeniu, va trebui să parcurgă urmatorii paşi:

1. Alegerea şi verificarea disponibilităţii numelui de domeniu. De acest pas se va ocupa aplicaţia CGI denumită “domain”.

2. După ce alegerea numelui a fost efectuată cu succes, se trece la alegerea unui pachet aferent acestui nume. Alegerea şi fixarea acestuia se va executa prin intermediul aplicaţiei CGI “kudat”.

3. Al treilea pas constituie introducerea numelui utilizatorului şi a parolei, sau crearea unui nou utilizator. Evident, toate datele introduse de către utilizator vor fi verificate şi în caz de succes se va introduce o nouă intrare în coada de aşteptare, de unde urmează să fie procesată de către sistemul de înregistrări. Toate aceste operaţii fiind efectuate de către aplicaţia “bestellen”.

4.3.1 Module Perl ale aplicaţiilor CGI

Pentru a centraliza unele operaţii des întalnite în aplicaţiile CGI care alcătuiesc interfaţa cu utilizatorul au fost create o serie de module specifice sistemului NetBeat. Astfel la momentul actual există următoarele module:

4.3.1.1 Modulul de configurare (IniFile.pm)

Modul pentru crearea şi mai ales obţinerea parametrilor de configurare pentru diverse aplicaţii CGI. Aceşti parametrii sunt stocaţi într-un fişier definit în modulul IniFile în formatul fişierelor de configurare Windows, fiind constituit din perechi cheie / valoare. Modulul este constituit dintr-un obiect IniFile care pune la dispoziţia programatorului următoarele metode de gestionare a fişierului de configurări:

1. IniFile::AddKey(<cheie>,<valoare>) – permite adăugarea unei perechi cheie valoare în fişierul de configurare.

2. IniFile::ReadKey(<cheie>) – returnează valoarea aferentă cheii pasate ca parametru.

3. IniFile::ChangeKey(<cheie>,<valoare>) – modifică valoare aferentă cheii furnizată ca parametru. Această metodă nu va introduce o cheie în cazul în care nu gaseste cheia pentru care se cere modificarea.

4. IniFile::DeleteKey(<cheie>) – şterge din fişierul de configurări intrarea cheii furnizate ca parametru.

4.3.1.2 Modulul validării datelor (netbeat.pm)

Modulul netbeat.pm conţine funcţii pentru verificarea numelor de domenii, apelate din aplicaţiile CGI ale interfeţei sistemului. Astfel există funcţii pentru validarea corectitudinii numelui de domeniu şi funcţii pentru verificarea disponibilităţii acestuia. Validarea numelui de domeniu se face utilizând mai multe şabloane (pattern-uri), aceasta trebuind să se încadreze în aceste şabloane pentru a putea fi validat. Verificarea disponibilităţii unui domeniu se face prin intermediul protocolului finger 79/tcp. Serverul finger fiind şi el special dezvoltat pentru a centraliza operaţiille de verificare a disponibilităţii domeniilor, însă despre acesta vom discuta putin mai târziu.

Pe lângă aceste metode există şi o metodă de verificare a sesiunilor de lucru ale utilizatorilor. Precizăm că ordinea parcurgerii paşilor pentru comandarea unui domeniu este strictă. Orice violare a acestei ordini putând duce la crearea problemelor de securitate, astfel facilitând accesul neautorizat la diverse componente ale interfeţei. Începând cu primul pas, fiecărei sesiuni i se atribuie un identificator de sesiune, cu care va avea dreptul să treacă la pasul următor. Aceste sesiuni sunt stocate în baza de date, şi pe măsură ce utilizatorul execută paşii spre comandarea domeniului, ele sunt verificate şi reactualizate la fiecare pas. Parcurs fiind şi ultimul pas, cheia sesiunii se va şterge, eliberând astfel tabela sesiunilor temporare şi prevenind o supraîncărcare a acesteia.

Detaliile tabelei în care sunt stocate temporar sesiunile utilizatorilor sunt prezentate în continuare:

Nume Camp	Tip	Descriere
domain	varchar(70)	Numele domeniului din sesiunea utilizatorului
sessionID	varchar(100)	Identificatorul sesiunii utilizatorului
wwhen	timestamp(14)	Data şi ora la care a fost creată sesiunea

Câmpul wwhen este foarte util deoarece prin intermediul său se poate verifica dacă o sesiune a expirat sau înca mai este valabilă. O sesiune care depaşeste 30 de minute este automat considerată invalidă.

Funcţiile modulului netbeat.pm sunt următoarele:

1. check_domain_syntax(<domain>) – verifică dacă numele domeniului pasat prin parametrul <domain> este valid din punct de vedere sintactic. Funcţia va returna valoarea 1 (adevărat) în caz de succes sau 0 (fals) în cazul în care domeniul nu este valid.

2. check_domain_avail(<domain>) – va verifica dacă domeniul pasat prin parametrul <domain> este disponibil sau nu. Acest lucru se va face utilizând serviciul whois pus la dispoziţie de registri-ul DENIC. Interogarea se face utilizând modulul IO::Socket. De asemenea pentru verificarea domeniilor “.com, .net, .org, .info, .biz, .it şi .nl” se va utiliza acelaşi modul şi pentru conectarea la serverul finger propriu sistemului NetBeat.

3. check_reg_temp(<domain>) – verifică validitatea şi valabilitatea sesiunilor utilizator pentru fiecare pas efectuat.

Aplicaţia CGI “domain”, ca şi toate celelalte aplicaţii este iniţializată cu un set de configurări prin intermediul modulului “IniFile.pm”.

4.3.1.3 Modulul protocolului IDNA (Punycode.pm)

Modulul Punycode.pm este un modul recent introdus, care a permis integrarea în sistemul NetBeat a posibilităţii înregistrării domeniilor internaţionale (IDN). Modulul, special creat pentru sistemul NetBeat pune la dispoziţie trei metode, oferind o interfaţa simplă de encodare, decodare şi verificare a domeniilor internaţionale. Arhiterctura modulului urmăreşte îndeaproape specificaţiile protocolului IDNA, implementând cele două operaţii pentru conversia numelor de domenii internaţionale ca metode: ToASCII şi ToUnicode.

Modulul este constituit din următoarele metode:

1. UTF8ToPuny(<utf8_domain>) – funcţia preia un nume de domeniu, reprezentat în setul de caractere UTF8 şi îl transformă în forma sa ACE, conform principiilor prezentate în capitolul “Dezvoltare Teoretică”.

2. PunyToUTF8(<ace_domain>) – funcţia preia un nume de domeniu compus din etichete ACE şi îl tranformă folosind reprezentarea sa pe setul de caractere UTF8.

3. CheckEncoding(<utf8_domain>,<ace_domain) – verifică prin comparaţie echivalenţa formelor IDN şi ACE ale aceluiaşi nume de domeniu.

4.3.1.4 Modulul verificării datelor bancare (pruefziffer.pm)

Acest modul permite verificarea veridicităţii datelor introduse de client în câmpurile referitoare la banca şi contul curent propriu. Modulul preia datele clientului (nume, prenume, numărul contului, codul poştal şi numele institutului de creditare) şi le valideză utilizând metode de conectare la servere ale băncilor germane. Modulul joacă rolul unei cutii negre (blackbox), care are ca intrări datele clientului şi care va furniza un răspuns pozitiv sau negativ, depinzând de rezultatele verificărilor efectuate.

4.3.1.5 Modulul generări paginilor interfeţei (CGI::FastTemplate)

FastTemplate este un modul foarte des utilizat în sistemul NetBeat, acesta facilitează crearea de pagini dinamice utilizând aplicaţiile CGI. Modulul permite folosirea paginilor HTML preformatate (templates), în care aplicaţia CGI va putea substitui cuvintele cheie cu valori efective. Astfel există o mare varietate de pagini preformatate, care conţine bineînţeles cuvinte cheie în locurile în care trebuie introdusă informaţia creată dinamic, asemenea unei persoane care completează un formular, aplicaţia CGI va completa pagina preformatată, obţinând astfel o serie de avantaje legate de dimensiunea aplicaţiei şi omogenitatea codului conţinut. Aplicaţia CGI nu va mai fi nevoită să conţină fragmentele paginilor HTML pe care urmează să le afişeze.

Se va crea o instanţiere a unui obiect CGI::FastTemplate, precizând locaţia directorului care conţie paginile preformatate.

$tmpl = new CGI::FastTemplate("templates/");

Mai apoi se definesc parametrii acestui obiect, cum ar fi numele paginilor preformatate care urmează a fi folosite. Fiecarei pagini i se va atribui o denumire generică, pe care programatorul o va utiliza pe parcursul aplicaţiei.

$tmpl->define(

main => "template_main.html",

data => "domain_error.html"

);

Se poate observa definirea a două pagini preformatate denumite “main” şi “data”. Urmează atribuirea valorilor pentru câmpurile cheie conţinute în aceste pagini preformatate:

$tmpl->assign(ART => "<input type=\"hidden\" name=\"art\" value=\"$art\">" );

În acest moment, având completate câmpurile cheie ale paginii preformatate închidem sesiunea de lucru cu o validare şi mai apoi tipărire a paginii către server:

$tmpl->parse( MAIN => [ "data", "main" ] );

$tmpl->print("MAIN");

4.3.2 Aplicaţii CGI ale interfeţei cu utilizatorul

Interfaţa cu utilizatorul se compune din două mari părţi, şi anume, partea de comandare a unui domeniu şi partea de administrare a acestuia. La partea de comandare am amintit deja aplicaţiile CGI “domain”, “kudat” şi “bestellen”. Descrierea pe scurt a acestora făcându-se în paragraful anterior. În continuare vom prezenta aplicaţia CGI “kundencenter” care permite oricarui utilizator administrarea domeniilor deţinute, a căsuţelor poştale electronice, a subdomeniilor şi a datelor sale personale.

Dezvoltarea aplicaţiei începe prin setarea tuturor parametrilor de configurare, utilizând atât modulul IniFile cât şi setări locale, ca atribuiri de valori unor constante globale. Se setează valorile variabilelor pentru controlul bazei de date, valorile actuale ale parametrilor necesari sistemelor de gestionare a căsutţlor poştale, a serverlor de hosting şi a serverului de bază de date. De asemenea se incarcă în variabile preţurile diferitelor servicii cu taxă adaugată oferite în cadrul interfeţiei de administrare.

La orice apel al acestei aplicaţii se va verifica operaţia care se doreşte a se efectua, se va identifica şi se va pune în rulare modulul corespunzător respectivei operaţii. Fiecare operaţie este constituită dintr-una sau mai multe funcţii, care indeplinesc independent taskuri bine stabilite pe diverse componente ale sistemului. Fiecare funcţie sau combinaţie de funcţii interacţionează în mod direct cu componentele sistemului, oferind astfel o viteză sporită în executarea taskurilor dorite.

De exemplu pentru modificarea parolei de FTP a unui domeniu, se apelează mai întâi o funcţie “change_ftp_pw” care va pune la dispoziţia utilizatorului, printr-o pagină generată dinamic, un meniu în care acesta îşi va alege domeniul a carui parola doreşte sa modifice. După alegerea domeniului şi a parolei se va trece la executarea comenzii primite. Mai exact se apelează o altă funcţie, “do_change_ftp_pw” care se va conecta la serverul de hosting pe care se află domeniul ales, şi va cere sistemului de hosting schimbarea parolei.

În secvenţa de cod următoare se va exemplifica obtinerea şi afişarea listei de domenii a clientului care doreşte modificarea parolei FTP.

$res = $DB->query("SELECT * FROM konten WHERE nummer=$REMOTEUSER ORDER BY domain");

for ( $i = 0 ; $i < $erg->numrows ; $i++ ) {

%hash = $erg->fetchhash;

$domains .= "<option>$hash{domain}</option>";

}

&Show_Output( "kundencenter/pwchange.html", $domains );

Interogarea SQL va selecta toate domeniile clientului identificat prin numărul continut în variabila “$REMOTEUSER” şi le va depune in variabila %hash cu ajutorul interfeţei Perl la baza de date. Utilizând variabila %hash se vor genera în continuare elementele meniului din care utilizatorul îşi va putea alege domeniul dorit.

Funcţia “Show_Output” înglobează metodele oferite de modulul CGI::FastTempleate usurând astfel munca programatorului pe parcursul aplicaţiei CGI. Conform parametrilor pasaţi funcţiei Show_Output se va iniţializa pagina preformatată “kundencenter/pwchange.html” şi va fi generat dinamic meniul conţinând domeniile utilizatorului.

Aplicaţia CGI “kundencenter” pune la dispoziţia utilizatorului un set complet de instrumente pentru administrarea atât a domeniilor cât şi a datelor sale. Instrumentele puse la dispoziţia utilizatorului se află în aplicaţia CGI sub forma mai multor funcţii.

În continuare vom face o enumerare a funcţiilor îndeplinite de aceste instrumente:

· Schimbarea parolei (aici sunt incluse instrumente atât pentru schimarea parolei pentru interfaţa de administrare, a parolei pentru FTP şi a parolei căsuţei poştale “postmaster”, căsuţă poştală implicită asociată fiecărui domeniu).

· Schimbarea adresei de mail, din setul datelor personale ale clientului.

· Administrarea redirectărilor, incluzând instrumente de creare, modificare şi stergere a redirectărilor pentru fiecare domeniu sau subdomeniu deţinut.

· Administrarea căsuţelor poştale, incluzând instrumente pentru crearea, modificarea şi ştergerea căsuţelor poştale pentru fiecare domeniu deţinut.

· Administrarea subdomeniilor, incluzând la fel, instrumente de creare, modificare şi stergere.

· Definirea cererilor pentru transferul domeniilor deţinute la alt provider, către sistemul NetBeat.

· Verificarea stadiului unui domeniu în curs de creare.

· Afişarea statisticilor referitoare la traficul executat de orice domeniu, numărul de accesări, distribuţia resurselor accesate şi distribuţia pe reţele a surselor de unde s-au accesat resursele web.

· Modificarea contactului unui domeniu

· Achiziţionarea cu taxă adăugată a unui număr suplimentar de căsuţe poştale POP3.

· Achziţionarea cu taxă adăugată a unui volum de spaţiu suplimentar pentru domeniile de tipul “level drei”.

· Modificarea serverului de mail (mail exchanger-ului) pentru orice domeniu deţinut.

· Modificarea serverelor de nume pentru orice domeniu deţinut.

· Afişarea statisticii privind numărul facturilor emise şi neplătite până la momentul accesării instrumentului.

Toate aceste instrumente întrunesc şi satisfac nevoile actuale ale utilizatorilor sistemului NetBeat.

4.4 Sistemul de înregistrare a domeniilor

Sistemul de înregistrare se află într-o strânsă legatură cu sistemul de sincronizare, care rulează periodic o suită de aplicaţii interactionând cu toate componentele sistemului NetBeat. Fiecare aplicaţie parcurge coada de aşteptare, procesând intrârile alfate pe nivelul de procesare care-i corespunde.

Nivel	Descriere	Tranziţii Posibile	Tipuri de domenii
0	Domeniul intră în coada de procesare.	1	Orice tip de domeniu
1	Domeniul este introdus în zonele serverului DNS. Se trimite cererea de înregistre a domeniului.	2	de, it, nl
1		3, E	com, net, org, info, biz
2	Domeniul aşteaptă răspunsul cererii de înregistrare.	2+,U, 3,E	de
2	Domeniul aşteaptă răspunsul cererii de înregistrare.	3, E	it, nl
2+	Domeniul are propriul său contact	3, U, E	de
3	Domeniul a fost înregistrat cu succes.	4, E	Orice tip de domeniu
4	Domeniul a fost instalat pe serverul web, mail şi bază de date.	5, E	Orice tip de domeniu
5	Confirmarea efectuării cu succes şi ieşirea din coada de procesare.		Orice tip de domeniu
U	Domeniul aşteaptă actualizarea datelor clientului.	E	de
N	Transferul domeniului a fost refuzat	1	com, net, org, info, biz
E	Domeniul a întampiat o eroare		Orice tip de domeniu

Tabelul nivelurilor de procesare ale sistemului de înregistrare de domenii

Nivelele întâlnite în coada de aşteptare sunt reprezentate atât prin cifre cât şi prin caractere sau combinaţii de caractere. Astfel există o suită de aplicaţii care procesează intrările din coada de aşteptare în funcţie de tipul domeniului şi nivelul la care se află în procesul de înregistrare. Fiecare dintre ele îndeplineşte o funcţie bine stabilită, avansând intrârile procesate pe alte nivele superioare sau chiar nivele de eroare.

Vom prezenta în continuare aplicaţiile sistemului de înregistrări insoţite de o scurtă descriere a principiului de funcţionare şi a efectului asupra intrărilor din coada de aşteptare. Precizăm ca oridnea prezentării este exact ordinea obligatorie de rulare a acestora, pentru că un ciclu de înregistrare sincronă să se poată executa într-un singur ciclu de rulare a aplicaţiilor.

4.4.1 Introducerea domeniilor în serverul DNS (nsenter.pl)

Această aplicaţie preia domeniile aflate în coada de aşteptare pe primul nivel, mai exact nivelul “0” şi transmite instantei sistemului DNS de pe serverul primar (prin intermediul unei conexiuni socket la acesta) o comanda de refacere a zonelor şi introducere în zona a domeniilor selectate. Pasul doi îl constituie transmiterea către serverul DNS secundar a comenzii de copiere a zonelor de pe serverul DNS primar. Acesti paşi fiind indepliniti se trece la incrementarea nivelului tuturor domeniilor aflate pe nivelul “0”.

4.4.2 Controlul cererilor de înregistrare (domainreg.pl)

Aceasta este aplicaţia care trimite inregistrarile efective către registri-uri, utilizând una din metodele de comunicare prezentate în schema principiului de functionare a sistemului NetBeat. Pentru ca un domeniu să poată fi procesat de acest script este necesar ca el să fi fost confirmat în prealabil de către utilizator. Domeniile neconfirmate rămân în coada de aşteptare timp de 30 de zile de la data comandării, după care sunt mutate într-o tabelă de stocare a comenzilor neconfirmate. Dacă în acest interval de 30 de zile domeniul este confirmat, el va fi procesat cu prima ocazie a rulării scriptului domainreg.pl. Scriptul preia fiecare domeniu confirmat, aflat pe nivelul “1” şi decide unde şi în ce mod va trimite cererea de înregistrare pentru acesta. Pentru înregistrarea domeniilor “de” se va trimite un mail de înregistrare către un robot de procesare a registrarului. Precizăm că registrarul este un terţ care se află între sistemul NetBeat şi registry. Registry-ul reprezintă autoritatea care pune la dipoziţie înregistrarea unui anume tip de domeniu. Sistemul de înregistrare al domeniilor “de” este un sistem asincron. Domeniul este trecut pe un nivel de aşteptare, “2” unde va rămâne până la obţinerea unui răspuns din partea registrarului.

Domeniile com, net, org, info şi biz folosesc pentru înregistrare protocolul HTTP. Limbajul Perl pune la dispoziţie modulul LWP pentru accesarea şi controlul informaţiilor prin HTTP, asemenea unui browser web. Înregistrarea este una sincronă, adică imediat după formularea şi trimiterea cererii de înregistrare sistemul primeşte un raspuns, fie el de confirmare a faptului că înregistrarea s-a încheiat cu succes, fie un raspuns de eroare, însoţit bineînţeles de mesajul de eroare. Controlul transmiterii cererii de înregistrare prin LWP se face utilizând un modul de interfaţare între aplicaţia domainreg.pl şi acest modul. Modulul intermediar oferă un obiect, căruia i se vor ataşa parametrii înregistrării. Odată ataşaţi aceşti parametrii, se va apela o metodă care va trimite efectiv cererea de înregistrare. Aplicaţia deţine două funcţii cu ajutorul cărora prelucrează imediat răspunsul furnizat de serverul web al registrarului. Acestea vor seta nivelul domeniulul pe “3” în caz de succes sau “E” în caz de eroare.

Domeniile it şi nl sunt ultimele tipuri de domenii adăugate sistemului NetBeat. Înregistarea lor se face utilizând tehnologia client – server. Ca şi în cazul domeniilor de, procesul de înregistrare a acestor domenii este unul asincron. Aplicaţia conţine o funcţie de conectare la serverul de înregistrări, o funcţie pentru pasarea parametrilor cererii de înregistrare către acesta şi o funcţie de procesare a răspunsului oferit de server. Serverul asignează câte un identificator unic fiecărei cereri de înregistrare. Funcţia care se ocupă de procesarea răspunsului preia acest identificator şi îl stochează pentru referiri ulterioare la acesta.

Aplicaţia mai dispune de funcţii pentru raportarea erorilor şi efectuarea diferitelor cosmetizări ale datelor de înregistrare înaintea expedierii acestora către registrar.

4.4.3 Verificarea înregistrării domeniilor .de (checkdomains.pl)

Această aplicaţie execută ciclul de verificare pentru domeniile “de” aflate în starea de aşteptare, după trimiterea cererii de înregistrare, modificare a datelor personale sau a contacţilor aferenţi. Fiecare domeniu “de” aflat pe nivelul “2”, “2+” sau “U” va fi verificat şi procesat conform raspunsului primit, în caz că acesta există. Verificarea se face utilizând o facilitate oferită de către registrar, care a pus la dispoziţia sistemului NetBeat un instrument de scanare rapidă a stării domeniilor aflate în aşteptare. Comunicarea cu acest instrument se face utilizând tehnologia client – server.

4.4.4 Verificarea înregistrării domeniilor .it şi .nl (PXY_PND_CHK.pl)

Scriptul PXY_PND_CHK.pl permite verificarea stării domeniilor it şi nl aflate în starea de aşteptare, urmată trimiterii cererii de înregistrare. Domeniile aflate pe nivelul “2” vor fi asociate cu identificatorul cererii de înregistare. Astfel se va face verificarea utilizând acest identificator, corespondenţa dintre domenii şi identificatori fiind ţinută într-o tabelă separată numită “pending”. Aplicaţia conţine funcţii de verificare a identificatorilor pentru domenii şi contacţi, funcţii de raportare a erorilor şi funcţii de conectare la serverul registrarului. Aplicaţia se va conecta la acest server pentru fiecare domeniu aflat în lista de aşteptare, cerând starea identificatorului asociat domeniului respectiv. Stările asociate identificatorului pot fi :

· PENDING – domeniul se află încă în aşteptare, el va fi lăsat în această stare până la primirea unui raspuns de succes sau eroare.

· SUCCESS – cererea de înregistrare a domeniului a fost efectuată cu succes. Nivelul domeniului va fi setat la valoarea “3”.

· FAILED – semnalează apariţia unei erori la procesul de înregistrare şi furnizează totodată şi mesajul de eroare. Nivelul domeniului va fi setat pe “E” şi va fi creat un raport conţinând mesajul de eroare primit.

4.4.5 Instalarea şi configurarea domeniilor (setup.pl)

Acest script efectuează operaţiille de instalare a domeniului pe serverul de mail, serverul web şi serverul de baze de date. Instalarea se va face în funcţie de pachetul domeniului. Scriptul conţine funcţii de conectare la serverle sistemelor componente, comandând pentru fiecare domeniu setul de operaţii care trebuiesc executate. La instalarea domeniului pe serverul de mail, se va trimite o comandă către serverul componentă, care va crea referinţele domeniului în acest sistem. Pentru instalarea domeniului pe serverul de hosting, se va trimite o comandă serverului acestei componente care va crea structură de directoare aferentă pachetului ales. Pentru fiecare pachet se vor seta opţiunile privind volumul spaţiului alocat, drepturile de rulare a aplicaţiilor CGI în Perl şi a scriptelor PHP. De asemenea se va pune la dispoziţia clientului un set minim de instrumente web, prin care acesta îşi va putea crea o pagină web.

4.4.6 Expedierea datelor de acces ale domeniilor (senddata.pl)

Această aplicaţie va trimite mesajele email de confirmare, va crea câte un cod de acces unic pentru fiecare client în parte şi va finaliza procesul de înregistrare a unui domeniu. De asemenea la îndeplinirea cu succes a tuturor sarcinilor va scoate domeniul din coada de procesare, acesta fiind deja complet instalat în sistemul NetBeat. În acest moment toate serviciile oferite împreună cu un nume de domeniu devin funcţionale. Mai trebuie precizat că, accesul la interfaţa de administrare pentru prima oară, se va face pe baza codului unic al fiecărui client, pe care acesta îl va primi prin poştă. Acest lucru verifică veridicitatea adresei clientului.

4.4.7 Verificarea transferurilor de domenii (NSI-KKScanner.pl)

Acest ultim script a fost creat recent pentru verificarea automată a domeniilor aflate în procesul de transferare de la un alt provider înspre sistemul NetBeat. Scriptul scanează de fiecare dată baza de date a registrarului domeniilor com, net, org, info şi biz aflate în stadiul de transfer. Dacă transferul a fost acceptat de către providerul domeniului va fi iniţiată procedura de modificare a datelor providerului şi instalare în sistemul NetBeat.

În cazul în care transferul nu va fi acceptat, domeniul va fi setat pe niveul “N” de unde urmează sa fie pornită o noua cerere de transfer sau chiar scoaterea din lista de procesare.

4.5 Integrarea protocolului IDNA

Lansarea ofertei pentru domeniile internaţionale “de” a fost facută la data de 1 Aprilie 2004 orele 10:00 de către organizaţia DENIC din Germania. Conform estimării specialiştilor germani odată cu lansarea domeniilor internaţionale în germnia, va creşte treptat numarul de domenii IDN înregistrate anual. De exemplu la data de 29 Aprilie 2004, dintr-un total de 7.564.303 de domenii 209.936 erau domenii internaţionale. În data de 3 Martie 2004 au fost lansată oferta domeniilor “.de” internaţionale în sistemul NetBeat. În decurs de câteva saptămâni a fost lansată şi oferta domeniilor internaţionale “.com”, “.net” şi “.info”. Introducerea protocolului IDNA a presupus importante modificari ale sistemului DNS, sistemului de hosting şi cel al serverelor de mail.

4.5.1 Integrarea protocolului IDNA în sistemul interfeţei cu utilizatorul

În primul rând trebuie precizat faptul că introducerea numelor de domenii internaţionale prin intermediul interfeţei se poate face doar setând browserul pe encodarea UTF8. S-a observat că la setarea browserului folosind setul de caractere UTF8, toate caracterele speciale prezente în paginile HTML deveneau neinteligibile. Acest lucru s-a datorat faptului ca la crearea paginilor nu s-a utilizat reprezentarea acestora pusă la dispoziţie de limajul HTML (¨, ä &ouml, etc). Astfel a fost nevoie ca toate caracterele speciale sa fie înlocuite cu echivalentele lor. Acest lucru a fost posibil prin crearea unui script în limbajul Perl, care parcurge recursiv structura de directoare a sistemului, prelucrând fiecare fişier .html şi înlocuind toate apariţiile caracterelor nepermise cu echivalentele acestora, independente de tipul encodării folosite.

De asemena au fost necesare modificări ale aplicaţiilor CGI care şi ele conţineau texte şi chiar etichete ale butoanelor alcătuite cu aceste caractere nepermise. Cel mai mare volum de muncă a fost necesar la parcurgerea şi înlocuirea literelor din aplicaţia “kundencenter”.

Evident s-au efectuat modificări ale paginilor “News” şi “Infos” prin intermediul cărora utilizatorul este informat asupra setarilor pe care trebuie sa le faca pentru a putea înregistra domenii internaţionale prin sistemul NetBeat.

4.5.2 Integrarea protocolului IDNA la nivelul bazei de date

Integrarea protocolului IDNA la nivelul bazei de date s-a putut realiza relativ uşor, datorită faptului că serverul MySQL permitea stocarea datelor reprezentate în setul de caractere UTF8 primite din interfaţa cu utilizatorul. Acest mod de stocare a numelor de domenii în formatul UTF8 a reprezentat cea mai comodă soluţie, nefiind necesar un numar mare de conversii pentru interfaţa cu utilizatorul, informaţiile fiind afişate exact în formatul în care au fost introduse. Din motive de compatibilitate cu serverle de webhosting care îşi construiesc adresele virtuale direct din baza de date, s-a introdus un câmp suplimentar în tabela “konten” în care sunt stocate domeniile active. De asemenea a fost necesară şi modificarea tabelei “konten_free” în care sunt stocate domeniile inactive. Câmpul suplimentar conţine, evident numele domeniului în formatul ACE. Adresele virtuale ale serverelor de webhosting fiind preluate direct din acest câmp. Câmpul “domain_ace” este iniţializat odată cu restul datelor despre domeniu, la intrarea acestuia în tabela domeniilor active “konten”. În restul tabelelor domeniile apar în formatul UTF8.

4.5.3 Integrarea protocolului IDNA la nivelul sistemului de înregistrări

Firmele registrar care oferă suportul înregistrării domeniilor internaţionale pun la dispoziţia “reseller-ilor” (în categoria carora face parte şi NetBeat) mai multe metode de comandare a domeniilor. Spre exemplu cererile de înregistrare a domeniilor de către robotul registrarului Cronon se face trimiţând domeniile în formatul UTF8. După cum am precizat şi în subcapitolul anterior, stocarea numelor de domenii în baza de date se face atât în format UTF8 cât şi în format ACE. Acest lucru facilitând accesul rapid al diferitelor sisteme componente care necesită cantităţi de informaţii din baza de date. De asemeana interfaţa web a registrarului NSI (com, net, org, info şi biz) este configurată pentru a funcţiona folosind setul de caractere UTF8. Exact ca şi în cazul interfeţei NetBeat şi interfaţa NSI necesită setarea browserului pe encodarea UTF8. Atât limbajul Perl cât şi setul de caractere al bazei de date permite utilizarea domeniilor în format UTF8.

Au fost necesare modificări majore la sistemul de verificare a al validităţii domeniilor “de”, organizaţia DENIC înlocuind sintaxa interogărilor pentru whois. Astfel a fost necesară introducerea unei funcţii în modului netbeat.pm care se va ocupa generarea interogarilor whois şi transmiterea raspunsului într-o variabila prestabilită. Prezentam în continuare o implementare a funcţiei “GetWois”:

sub GetWhois {

my $req = shift;

my $host = shift;

my $sock = new IO::Socket::INET (PeerAddr => $host,

PeerPort => 43,

Proto => 'tcp',);

print $sock $req . "\n";

my $result;

$result .= $_ while(<$sock>);

return $result;

}

Se poate observa utilizarea modulului IO::Socket:INET pentru conectarea la serverul de whois al organizaţiei DENIC, trimiterea unei interogări, stocarea rezultatului într-o variabliă text şi returnarea acesteia la ieşirea din funcţie.

Asociată acestei funcţii mai există şi funcţia “ValidateDomain” folosită atât pentru validarea sintaxei unui domeniu internaţional, cât şi pentru verificarea dacă setul de caracetere din componenţa acestuia este reprezentat în UTF8.

4.5.4 Integrarea protocolului IDNA la nivelul serverelor DNS

Serverle DNS folosesc o implementare a sistemului DNS numită TinyDNS. Această implementare deţine un sistem foarte simplu de control numelor de domenii. În principiu există un singur fişier în care sunt organizate domeniile după o sintaxă specifică sistemului TinyDNS. În cazul sistemului NetBeat acest fişier este creat la fiecare ciclu de rulare al aplicaţiei “nsenter.pl”. Aplicaţia “nsenter.pl” comandă serverului componentei DNS iniţializarea operaţiei de generare a unui nou fişier direct din baza de date. Deoarece generarea acestui fişier trebuie facută într-un timp restrâns, utilizarea limbajului Perl aici, nu reprezintă o soluţie optimă. Astfel s-a apelat la utilizarea limbajului C, care este de ca. 20 de ori mai rapid decât Perlul în lucrul cu bazele de date.

Odată cu introducerea protocolului IDNA, s-a modificat formatul în care sunt stocate numele domeniilor în baza de date. Generarea fişierului nu a mai putu fi posibilă utilizând acelaşi mecanism, deoarece programul C genera fişiere în care numele domeniilor erau reprezentate în formatul UTF8, lucuru total inadmis în zonele serverelor DNS. Deoarece modificarea programului în C ar fi durat destul de mult, iar timpul avut la dispoziţie a fost cât se poate de restrâns, s-a optat pentru o “corectare” a fişierului creat de programul C. Astfel, cum limbajul Perl oferă cel mai bun suport de lucru cu fişierele text, s-a creat un script care corectează într-un timp record fişierul zonelor TinyDNS. În fişierul serverului DNS există trei categorii de intrări.

La fel cum în implementarea BIND a DNS-ului există entry-uri ca IN MX pentru mailexhanger, IN NS pentru nameserver şi IN A pentru adrese ip, fişierul TinyDNS se compune din următoarele tipuri de intrări:

· .nume-domeniu.de::ns1.netbeat.de\n – aceasta linie este echivalentă cu entry-ul IN NS dintr-o zonă a implementării BIND. Trebuie precizat că primul caracter, şi anume caracterul “.” specifică tipul liniei, şi anume entry care specifică serverele de nume ale unui domeniu. În exemplul prezentat mai sus domeniul “nume-domeniu.de” are ca server de nume pe “ns1.netbeat.de”.

· +nume-domeniu.de:192.168.1.2\n – aceasta este linia echivalentă entry-ului IN A în sistemul zonelor implementării BIND.

· @nume-domeniu.de::mail.nume-domeniu.de:10\n – echivalenta entry-ului IN MX din implementarea BIND.

Prezentăm în continuare secvenţa de corectare a fisierului TinyDNS:

while ($linein = <IN>) {

if ($linein =~ m/.*[@+\.](.*\.[a-z]{2,4})::?.{3,}$/i) {

$match = $1;

if ($match =~ m/[^a-z0-9\.\-]/i) {

$ace = Punycode::UTF8ToPuny($match);

$linein =~ s/$match/$ace/;

}

print OUT $linein;

}

Şablonul /.*[@+\.](.*\.[a-z]{2,4})::?.{3,}$/ caută toate liniile care conţin caracterele @, + sau . urmate de o combinaţe ce se poate considera un nume de domeniu. Numele de domeniu este stocat în variabila $match, după care se face verificarea dacă întradevăr combinaţia găsită reprezintă un nume de domeniu. Mai apoi se trece la trecerea domeniului din reprezentarea UTF8 în reprezentarea ACE. Variabila $linein va conţine rezultatul schimbării textului din variablia $match (forma UTF8 a domeniului) cu textul din variabila $ace (forma ACE a domeniului). În ultimul pas se rescrie linia în fişierul dată al implementării TinyDNS.

4.5.5 Integrarea protocolului IDNA în sistemul serverelor de mail

Integrarea protocolului IDNA în sistemul serverelor de mail a ridicat probleme la partea autentificării utilizatorilor. Deoarece numele utilizatorilor căsuţelor poştale POP3 este compus atât din numele efectiv al căsuţei cât şi din numele domeniului, a fost nevoie de prezentarea domeniului în forma ACE către utilizator. Menţionăm încă o dată că această adaptare a trebuit executată într-un timp record. Din aceste motive au avut mai mare succes soluţiile bazate pe rezultate rapide decât cele care necesitau schimbări imporante la nivelul infrastructurii componentelor sistemului. Astfel, utilizatorului ii este prezentată forma ACE a domeniului. Din fericire utilizând programul Outlook sau alte programe pentru gestionarea conturilor de email POP3, utilizatorul nu va fi nevoit să memoreze numele domeniului în format ACE, acesta putând fi salvat automat şi reutilizat de nenumarate ori.

4.5.6 Integrarea protocolului IDNA la nivelul serverelor web

Fiecare domeniu căruia îi este ataşat un spaţiu pe un server web, este prezent la nivelul serverului ca un utilizator normal, având însă drepturi restrânse în sistem. Numele utilizatorilor în sistem sunt daţi de numele domeniului. La fel şi locaţia resurselor web pentru fiecare domeniu se gaseşte la locaţia “/home/nume-domeniu.de”. Si aici a fost nevoie de intervenţia transformării numelor de domenii deoarece, cererile care ajung la serverul web sunt în format ACE.

De asemenea nu este posibilă gestionarea numelor utilizatorilor în format UTF8. Inaintea instălrii domeniului pe webserver se va face transformarea de nume, pentru ca acesta să poată fi creat cu succes. Modulul serverului Apace, denumit mod_netbeat crează lista numelor virtuale direct din baza de date, utilizând câmpul special creat “domain_ace”.

S-au efectuat de asemenea modificări la sistemul de generare a redirectărilor “FrameSet” şi “Redirect”, găzduit pe un sever separat. Sistemul de generare a redirectărilor este un sistem dinamic care citeşte “adresa ţintă” direct din baza de date. De fiecare dată când un domeniu “redirect” este accesat, se accesează de fapt serverul de redirect al sistemului de hosting NetBeat. De aici se porneşte o interogare a bazei de date care va returna adresa ţintă, spre care se va face imediat redirectarea. Şi în acest caz a fost nevoie de transformarea numelui domeniilor pasate deoarece în baza de date redirectările sunt indexate după numele domeniilor şi a subdomeniilor de tipul “redirect”. Înarmat cu numele în formatul corect, sistemul de generare a redirectărilor poate găsi într-un timp foarte scurt adresa ţintă a redirectării.

4.6 Optimizări şi modernizări ale sistemului

De-a lungul timpului sistemul NetBeat a tins sa devina un sistem care oferă servicii complete şi sigure utilizatorilor de pretutindeni. Sistemul a fost creat, ca un mijloc de testare a unei piete în crestere, succesul dobandit şi ascensiunea rapidă fiind factorii care au dus la existenţa lui până în prezent. În mare parte, principiile generale de functionare au ramas aceleaşi, efectuandu-se însă schimbari majore ale sistemelor de facturari şi managementul contabilitatii, sistemului de înregistrare de domenii şi sistemului de control al acesteora.

4.6.1 Modificări şi optimizări ale interfeţei

La nivelul interfeţei au existat mai multe valuri de “optimizari”. În primul rând au fost introduse noi pagini preformatate, aferente noilor servicii incluse. S-a introdus facilitatea schimbarii adresei de email a clientului, chiar de către acesta. Adresa de email a clientului este necesar a fi una valida şi activa datorita faptului ca toate facturile domeniilor detinute de acesta se vor trimite înspre aceasta adresa. Schmibarea adresei se face evident în doi paşi: în primul pas utilizatorul va introduce noua adresa de email şi va cere modificarea acesteia. Noua adresa, împreună cu cererea clientului şi un cod de confirmare se vor stoca într-o tabela temporara. Clientul va primi la noua adresa un mesaj email care va conţine un link spre o aplicaţie CGI, care are ca parametru codul confirmarii operaţiei de schimbare a adresei de email. Adresa URL înspre aplicaţia CGI este de forma : http://www.netbeat.de/exec/emailconfirm?90009187935001

De asemenea s-a introdus un pas suplimentar pentru operaţia de comandare cu suprataxa a unui numar suplimentar de căsuţei poştale POP3. Acest lucru a fost posibil prin intercalarea între interfaţa de comandare şi procesul efectiv de adaugare a casutelor de email, a unei pagini suplimentare. Aceasta pagina va initia un dialog cu utilizatorul în care acesta va fi rugat sa certifice operaţia de comandare a numărului suplimentar de căsuţei poştale POP3. Utilizatorului ii sunt puse la dispoziţie două link-uri exprimand optiunile posibile ale acestui pas. Selectand prima opţiune, adică linkul “Ja” clientul confirma faptul ca este de acord sa achizitioneze în regim cu taxa adaugata a unui numar ales de căsuţei poştale POP3. Alegând link-ul “Nein” acesta va fi redirectat înapoi la interfaţa de comandare a numărului de căsuţei suplimentare.

S-a mai introdus o interfaţa pentru achizitionarea cu taxa adaugata a unui volum suplimentar al spatiului web. Clientului ii este prezentată o interfaţa unde sunt prezentate preturile practicate, volumul maxim al spatiului care poate fi comandata şi lista domeniilor detinute care conţine numele domeniului, volumul de spaţiu standard şi volumul de spaţiu achizitionat suplimentar. Urmeaza un meniu în care sunt prezentate domeniile pentru care inca se mai poate comanda spaţiu suplimentar, insotit de un meniu de unde se va putea alege volumul spatiului suplimentar. Exact ca mai înainte, după ce a fost verificată corectitudinea comenzii se va trece într-o pagina de confirmare a operaţiei şi mai apoi la cumpararea efectivă a spatiului suplimentar.

Interfaţa pentru comandarea sau controlul contului de baze de date oferit, consta din afişarea datelor pentru fiecare domeniu ales. Aceste date includ numele domeniului, numele serverului unde se afla baza de date, locatia interfeţei de configurare web a bazelor de date şi ale tabelelor, numele utilizatorului pentru baza de date, parola aferenta acestui utilizator, dimensiunea bazei de date şi data inceperii contractului. De asemenea se prezintă un meniu care include diverse operaţii posibile pentru un cont la baza de date. Aceste operaţii sunt: schimbarea parolei utilizatorului bazei de date, optimizarea bazei de date, modificarea dimensiunii bazei de date (cu taxa adaugata), ştergerea sau dezactivarea bazei de date şi evident, reactivarea acesteia.

4.6.2 Optimizări ale sistemului de înregistrare a domeniilor

În primul rând trebuie menţionat faptul ca poate cea mai importanta optimizare a fost aceea a introducerii facilitatii înregistrărilor de domenii în mod sincron. Precizăm faptul ca inregistrarile de domenii com, net, org, info şi biz se efectueaza la momentul de faţa în mai putin de o secunda. În trecut, aceste înregistrări durau chiar şi zile intregi, existand o mai mare posibilitate de procesare a informatiei în mod eronat, datorita timpilor mari de aşteptare. De asemenea s-a creat cu aceasta ocazie un sistem online de urmarire a intrărilor care intampina erori în cadrul procesului de înregistrare.

Orice domeniu com, net, org, info sau biz care trecea dintr-un motiv sau altul pe nivelul “E” este foarte uşor de urmarit. Interfaţa pune la dispoziţia utilizatorului lista domeniilor aflate pe nivelu “E”, mesajele de eroare care au aparut în timpul procesului de înregistrare şi o serie de unelte de depanare a acestuia.

O alta facilitate introdusa în sistemul de înregistrare a domeniilor a fost aceea a procesării centralizate a tuturor raspunsurilor primite de la registrari, evident în funcţie de protocolul utilizat. Dacă în trecut, pentru fiecare tip de domeniu exista câte o funcţie de prelucrare a raspunsurilor din partea registrarului, în momentul de faţa, acest lucru se face cu ajutorul a două funcţii pentru protocolul HTTP şi a altor două funcţii pentru protocolul client – server.

Functiile aferente protocolului HTTP prelucreaza fiecare fie mesajele obţinute din procesul de înregistrare a contactelor (“ParseHandle”) fie raspunsurile obţinute din procesul de înregistrare a domeniilor (“ParseDomain”). Functiile aferente protocolului client – server servesc, una pentru formatarea cererii de înregistrare şi trimiterea acesteia în mod centralizat, iar cealalta pentru prelucrarea raspunsului primit de la serverul registrarului.

De asemenea a fost introdusa o funcţie pentru “cosmetizarea” şi aducerea la o forma unanim acceptată de către registrari. Datele conţinute în baza de date nefiind uniforme ca reprezentare sau format.

4.6.3 Optimizări ale controlului asupra domeniilor

Cel mai important sistem realizat pe structura existenţa în combinaţie cu sistemul de facturari este cel care permite blocarea şi deblocarea automată a domeniilor. Astfel, dacă facturile emise pentru un anume domeniu ajung sa fie neplatite până la 21 de zile de la data facturarii, acestea se vor trece automat într-o stare “blocat”. Starea blocat este în fapt o redirectare a acelui domeniu către o pagina de avertizare a sistemului NetBeat, prin care utilizatorul este anunţat asupra neplatii şi blocarii temporare a serviciilor oferite, aferente domeniului respectiv. Aceasta redirectare este similară cu o “scurtcircuitare din centrala” a respectivului domeniu. În fiecare zi, la un interval de trei ore se ruleaza o aplicaţie care scaneaza tabela facturilor şi identifica toate domeniile care trebuiesc blocate. Acestea se marcheaza în tabela activa a domeniilor prin stetarea campului “blockiert” pe “J”. De asemenea aplicaţia care genereaza fisierul cu date, al sistemului TinyDNS va tine cont de toate domeniile marcate ca blocate şi va efectua redirectarea direct din intermediul nameserverului.

Pentru deblocarea automată a domeniilor, care intretimp au fost platite, se ruleaza în fiecare seara o aplicaţie care scanează baza de date, parcurgand mai întâi tabela domeniilor active, având câmpul “blockiert” pe “J”. Apoi, pentru fiecare dintre aceste domenii se verifica în tablea facturilor dacă toate facturile domeniului sunt achitate. În caz afirmativ se reseteaza câmpul “blockiert” al bazei de date.

4.6.4 Realizarea sistemului de gestionare a facturilor

Prin aceasta realizare s-a dorit crearea unei interfeţe web, pentru gestionarea online a facturilor domeniilor şi serviciilor oferite de sistemul NetBeat. Sistemul este deosebit de complex, datorita multiplilor parametrii care trebuiesc luati în seama în procesul de gestionare. Astfel se pune la dispoziţia utilizatorului o pagina principala în care acesta poate executa diverse operaţii.

Prima dintre ele este cea de verificare a sumei totale incasate pentru o anumita data. Mentionam ca suma totala incasata în acest sistem, pentru fiecare zi, trebuie sa coincida exact cu suma totala primita din partea bancilor partenere. Operatorii sistemului detin ciferele exacte pentru fiecare zi. La incheierea zilei, acestia pot verifica dacă sumele coincid sau nu.

Sistemul este realizat ca aplicaţie CGI, folosind limbajul Perl. Cu ajutorul modulelelro CGI şi DBD a fost implementata structura complexa de afisari şi procesari, fie ele automate sau comandate de utilizator. Aplicaţia este împărţită în 5 părţi componente: o parte de selectare a modului de lucru, o parte de afişare a modului client, o parte de procesare pentru operaţiille efectuate pe interfaţa client, o parte de afişare a modului factura şi o parte a procesării acestui mod. Pe lângă aceste ramuri principale mai exista şi ramuri de verificare a sumei zilnice, şi linkuri înspre diferite servicii conexe cum ar fi aplicaţii CGI de stornare, regenerare sau retrimitere a facturilor.

Modurile de procesare aferente modurilor de afişare client sau factura sunt invizibile pentru operator. La apasarea butonului “Process” de către operator, sistemul intra automat în modul de procesare, totodată afisand pagina principala a sistemului. A fost implementat şi un mecanism prin care, se pot memora setarile facute la începutul fiecărei sesiuni de lucru. Astfel, operatorul nu va mai trebui sa introduca de fiecare data data pentru care doreşte sa efectueze operaţii. De asemenea acesta nu va mai fi nevoit sa aleaga banca partenera sub care se lucreaza, pentru fiecare banca existand un set de facturi. Facturile se clasifica pe banci în funcţie de banca la care acestea sunt platite de către client.

5 Utilizarea sistemului NetBeat

Dezvoltarea continua atât a interfeţei cât şi a mecanismului şi ofertelor sistemului NetBeat a dus la obtinerea unei interfeţe intuitive şi uşor de folosit. Asa cum am amintit şi în capitolele precedente interfaţa sistemului cu utilizatorul se compune din două părţi. O parte în care se poate crea un utilizator nou şi comanda un domeniu, şi o interfaţa de administrare a domeniilor detinute de către client.

5.1 Prezentarea pachetelor disponibile

Pe prima pagina sunt prezentate pe scurt cele sase pachete cu care se poate achiziţiona un nume de domeniu. Aceste pachete sunt :

de redirect – pachetul conţine un domeniu de, o casuta postala POP3, 100 de subdomenii şi 100 de căsuţei poştale tip forward. În baza de date acest tip este reprezentat prin codul “dom”. Domeniile redirect nu detin spaţiu web. Pentru acestea se poate specifică un URL tinta care va fi accesat de fiecare data când este accesat acest domeniu.

cno redirect – pachetul este aproape identic cu pachetul prezentat anterior, diferenta dintrele cele două fiind doar tipul domeniului oferit. În acest caz se pot alege oricare dintre tipurile com, net, org, info, biz, it sau nl.

level eins de – conţine un nume de domeniu de, 5 Mb spaţiu web, o casuta postala POP3, un subdomeniu, 5 căsuţei poştale de tip forward şi un set de aplicaţii CGI uzuale cum ar fi o aplicaţie contor, forum şi guestbook. Pachetul este ideal pentru crearea paginilor personale, sau a paginilor cu un volum mic de informaţii cum ar fi prezentari, istorice, etc.

level eins cno – acest pachet conţine aceleaşi servicii oferite de pachetul “level eins de” cu deosebirea ca în locul unui domeniu de se oferă unul din domeniile com, net, org, info, biz, it sau nl. De asemenea pachetele difera şi prin pretul de vanzare, observam ca un pachet “level eins de” este aproape de patru ori mai ieftin.

level zwei – acest pachte conţine un domeniu de orice tip (de, com, net, org, info, biz, it sau nl), 10 căsuţei poştale POP3, 100 de subdomenii, numar nelimitat de căsuţei poştale de tip forward, setul standard de aplicaţii CGI şi posibilitatea de creare şi rulare a scripurilor CGI sau PHP proprii.

level drei – pachetul de top oferit de firma NetBeat conţine un domeniu de orice tip (de, com, net, org, info, biz, it sau nl), 20 de căsuţei poştale POP3, un numar nelimitat de subdomenii cât şi un numar nelimitat de căsuţei poştale de tip forward. De asemenea este prezent setul standard de aplicaţii CGI şi evident posibilitatea dezvoltarilor de aplicaţii CGI şi scripturi PHP proprii. La toate acestea se adauga şi un spaţiu de 2 Mb de baza de date.

5.2 Comandarea unui domeniu

Comandarea unui domeniu se face într-un mod intuitiv şi permite verificarea disponibilitatii unui nume de domeniu chiar de pe prima pagina a sistemului. Utilizatorul va introduce în casuta din dreapta numele domeniului dorit, va selecta tipul acestuia şi va apasa butonul “ok”. În cazul în care domeniul selectat nu mai este disponibil, se va afişa un mesaj de avertizare care conţine şi link-uri înspre domeniul cautat şi o casuta unde clientul va putea verifica disponibilitatea altor domenii (Fig 5.1).

Fig 5.1 Pagina de avertisment la comandarea unui domeniu indisponibil

De asemenea se va executa şi verificarea sintactică a domeniului. Acesta trebuie sa se incadreze în regulile de alcatuire ale unui nume de domeniu. El nu trebuie să depaseasca 63 de caractere, sa nu înceapă sau sa se sfarseasca prin caracterul cratima şi sa folosească doar literele alfabetului (incluzand caractere speciale, regionale, lucru posibil datorita compatibilităţii cu sistemul IDNA), cifre şi cratima.

Pentru a putea comanda un domeniu internaţional, utilizatorul va trebui sa-şi seteze browserul pe encodarea UTF8. Mentionam faptul ca setarea browserului este obligatorie, verificarea unui domeniu internaţional, fără browserul setat pe UTF8 va duce la invalidarea numelui ales şi implicit a imposibilitatii comandarii acestuia. Instructiunile pentru setarea browserului se pot găsi în secţiunea “Infos” a interfeţei sistemului NetBeat.

În cazul în care domeniul este disponibil utilizatorului ii va fi prezentată o pagina din care îşi putea alege un pachet, sau va putea vizualiza detalii despre fiecare pachet (Fig 5.2). El poate alege tipul conexiunii pentru comanda pe care urmează sa o faca. Se poate opta între comanda securizată utilizând protocolul HTTPS sau comanda nesecurizata prin intermediul protocolului HTTP.

Fig 5.2 Pagina care permite alegerea pachetului dorit

Dupa alegerea pachetului, utilizatorului ii va fi rezentata pagina care constituie ultimul pas în procesul de înregistrare. Aici se prezintă atât o interfaţa pentru crearea rapidă a unui nou utilizator cât şi posibiliatatea autentificarii cu ajutorul unui identificator şi o parola, pentru cazul în care utilizatorul este deja client al firmei NetBeat. Dacă se opteaza pentru crearea unui client nou, va trebui sa se tina seama de regulile de introducere a datelor personale. Datele personale introduse, trebuie sa corespunda cu realitate, codul de confirmare pentru accesul la interfaţa de administrare se va trimite prin posta, la adresa specificata de către utilizator.

În prima parte a paginii pentru introducerea datelor personale, sunt prezentate datele comenzii efectuate (numele domeniului, pachetul acestuia precum şi pretul pachetului ales). De asemenea i se aduce la cunostinta utilizatorului necesitatea introducerii unei adrese valide unde va primi cartea postala cu codul interfeţei de administrare.

În a două parte a paginii se va putea alege tipul contului care va fi creat. Astfel se poate specifică dacă acest cont se va face ca persoana juridica sau fizica. Pentru a crea un cont persoana juridica, se selecteaza casuta de interogare “Ja, ich vertrete eine juridische Person” (Fig 5.3). Selectand aceasta casuta, utilizatorul va trebui sa introduca numele şi numărulde TVA al firmei pe care o reprezintă. Numărul de TVA va fi validat conform unor reguli de validare generala. De asemenea numele nu trebuie sa contina alte caractere decât literele alfabetului, cifre, cratima şi spaţiu.

Fig 5.3 Căsuţa pentru specificarea tipului contului creat

În cazul în care se va dori crearea unui cont persoana fizica, se va lasa neselectata casuta amintita mai sus. Urmeaza partea în care clientul îşi va introduce datele personale (Fig 5.4). Acesta va trebui sa introduca numele, prenumele, strada, codul postal, orasul, tara, numărulde telefon şi adresa sa de email. Pentru introducerea numelui, prenumelui, strazii şi orasului va trebui respectat modul de reprezentare cerut. Astfel datele se vor reprezenta utilizând literele alfabetului, cifrele, caracterul cratima sau punct. Ultimul caracter este permis doar pentru introducerea numelui strazii.

Fig 5.4 Introducerea datelor personale ale clientului

În continuare este solicitata introducerea datelor contului din banca deţinut. Mentionam ca înregistrarea nu se va putea efectua fără introducerea unui set de date corect (numele posesorului, numărulcontului, identificatorul şi numele institutiei de creditare).

Introducerea acestor date se face doar în scopul certificarii credibilitatii persoanei în cauza. Firma NetBeat nu va utiliza aceste date pentru retragera contravalorii domeniilor comandate.

În cazul în care utilizatorul deţine deja un cont în sistemul NetBeat acesta se va putea autentifica introducand identificatorul sau în sistem şi, evident, parola aferenta acestuia (Fig 5.5). Mentionam ca în faţa fiecărui identificator se va adauga prefixul “wS”.

Fig 5.5 Introducerea identificatorului utilizator şi a parolei

Ultima parte consta necesita confirmarea acordului cu “contidiile generale de utilizare” ale firmei NetBeat şi verificarea varstei. Se va selecta casuta “Ja, ich erkenne die AGB von NetBeat an.” După o prealabila lecturare a acestor conditii. Linkul către prezentarea conditiilor generale se afla sub textul subliniat mai sus. Verificarea varstei se va face prin casuta de introducere text “Jahre”. Varsta minima admisa fiind 18 ani (Fig 5.6). Odata butonul “Bestellen” apasat, comanda este validata şi dacă toate datele introduse sunt corespunzatoare, se va trimite un mail de comfirmare la adresa clientului, prin care acesta va da drumul efectiv la înregistrarea domeniului. În cazul în care datele introduse nu sunt corecte, va fi afişată o pagina de avertizare în care vor fi prezentate câmpurile necorespunzatoare.

Fig 5.6 Confirmarea acordului cu condiţiile generale si verificarea vârstei

5.3 Interfaţa de administrare

Administrarea unui domeniu se face utilizând interfaţa CGI “kundencenter”. Aceasta poate fi accesata apasand butonul “kundencenter” din bara de componente a oricărei pagini NetBeat. Clientului ii va fi prezentată pagina conţinând toate instrumentele de administrare disponibile (Fig 5.7).

Fig 5.7 Interfaţa principală a sistemului de administrare

Primul instrument, “passwort aendern” pune la dispoziţia clientului posibilitatea schimbarii setului de parole detinute în sistemul NetBeat (Fig 5.8). Aici intra parola contului pentru interfaţa NetBeat, parola casutei poştale implicite “postmaster” şi parola pentru accesul FTP pe serverul web unde este gazduit domeniul acestuia.

Fig 5.8 Interfaţa de modificare a parolelor utilizatorului

Dupa ce parola şi confirmarea ei au fost introduse se va apasa butonul “Ändern”. Dacă parolele introduse coincid efectuarea schimabarii parolelor a fost efectuată cu succes. În caz contrar utilizatorul va fi avertizat asupra erorii şi va relua procesul de la inceput.

Al doilea instrument, “email adresse aendern” oferă posibilitatea clientului de asi modifica adresa de email din setul de date personale stocat (Fig 5.9) în baza de date a sistemului NetBeat. Clientul îşi va introduce noua adresa de email după care va apasa butonul “Ändern”. Dacă verificarea adresei s-a efectuat cu succes şi aceasta valida, se va genera un cod de confirmare care se va trimite către noua adresa. Adresa va fi schimbata efectiv doar în momentul în care clientul va confirma aceasta operaţie.

Fig 5.9 Interfaţa pentru schimbarea adresei de email a clientului

Al treilea instrument, “weiterleitungen” permite administrarea redirectarilor pentru domeniile din pachetul “redirect” şi pentru subdomeniile create (Fig 5.10). Clientul îşi va alege un domeniu din lista domeniilor care premit redirectarea, va alege tipul redirectarii şi va introduce URL-ul spre care va pointa acesta.

Tipurile de redirectari sunt :

· Redirect – permite redirectarea către o alta pagina, afisand însă în bara de adrese locatia paginii spre care a fost redirectat.

· FrameSet – permite redirectarea către o alta pagina, afisand însă în bara de adrese numele domeniulul pentru care s-a facut redirectarea.

· DNS – redirecteaza domeniul direct de la nivelul serverului DNS.

Fig 5.10 Interfaţa de creare a redirectărilor

Prin apasarea butonului “Eintragen” se va realiza efectiv redirectarea către locatia aleasa. Apasand însă butonul “Entfernen” redirectarea către subdomeniul ales va fi stearsa, acesta fiind refirectat implicit înspre o pagina preformatata a sistemului NetBeat.

Al patrulea instrument, “email adressen einrichten”, permite managementul casutelor poştale pentru fiecare domeniu în parte (Fig 5.11). În prima faza utilizatorul îşi va alege domeniul dorit din lista domeniilor active pe care le deţine. Alegând domeniul ajunge în interfaţa de administrare a casutelor poştale. Aici va putea crea sau sterge casutele poştale dorite.

Fig 5.11 Interfaţa de administrare a căsuţelor poştale

Pentru a crea o casuta postala noua, utilizatorul va trebui sa introduca numele casutei poştale în casuta din dreapta numelui de domeniu din sectuinea “Neues Postfach”. De asemenea va trebui sa aleaga şi tipul casutei poştale: POP3 sau Forward. În cazul în care se opteaza pentru o casuta de tip POP3, în casuta text din dreapta va trebui introdusa parola pentru aceasta casuta. Apasand butonul “Hinzufügen” casuta va fi creată şi va apărea în partea de sus a interetei de administrare. De asemenea se va trimite o cerere de creare a casutei pe serverul de email al domeniului. În cazul alegerii tipului Forward, în casuta din dreapta va fi introdusa adresa la care se va face redirectarea.

În partea de sus a interfeţei sunt prezentate casulte poştale existente. Aici putem găsi informaţii despre tipul casutei sau adresa spre care este redirectata casuta. Selectand casuta din dreapta numelui unei adrese şi apasand butonul “Löschen” se va initializa operaţia de stergere a casutei.

Al cincelea instrument, “subdomains” permite administrarea subdomeniilor ataşate domeniilor detinute (Fig 5.12). La fel ca şi în cazul interfeţei adreselor email, mai întâi se va alege domeniul pentru care se doreşte creare sau ştergerea unui subdomeniu. Apoi va fi afişată interfaţa pentru administrarea subdomeniilor.

Fig 5.12 Interfaţa de administrare a subdomeniilor

În partea de sus sunt afişate toate subdomeniile aferente unui domeniu împreună cu un link pentu ştergerea acestora. În partea de jos vom găsi o casuta text în care se va introduce numele subodmeniului ales. Apoi se va apasa butonul “OK”. Dupa crearea subdomeniului, I se va putea atasa o redirectare folosind instrumentul “weiterleitungen” prezentat mai sus.

Al saselea instrument este denumit “domainuebernahme”. Prin intermediul acestui instrument se poate lansa o cerere de transfer al unui domeniu de la un alt provider către providerul NetBeat. Utilizatorul va trebui sa introduca numele domeniului dorit şi sa aleaga unul dintre cele 6 pachete disponibile. De asemenea va trebui sa introduca şi numele contactului aferent domeniului care urmează sa fie transferat. Apasand butonul “Abschicken” se va trimite cererea de transfer către providerul domeniului şi totodată se va înregistra cererea de transfer în baza de date a sistemului NetBeat.

Al saptelea instrumet, “bestellstatus abfragen”, permite verificarea starii de procesare pentru un domeniu comandat. Se va introduce numele domeniului în casuta text pusa la dispoziţie de interfaţa şi se va apasa butonul “Status prüfen“. Va fi afisat stadiul în care se afla domeniul, bineînţeles cu o scurta descriere aferenta nivelului de procesare.

Instrumentul numărulopt este: “zugriffsstatistik“. De aici se pot accesa statisticile pentru domeniile utilizatorului (Fig 5.13). Alegând un domeniu şi apasand butonul “Ausfüren” clientul va fi redirectat către pagina care afiseaza statisticile domeniilor. Aici clientul va putea urmari numărulde request-uri pentru fiecare domeniu în parte. De asemenea vor putea fii vizualizate statistici pentru fiecare luna a anului, statistici pentru accesarea fiecărei resurse în parte cât şi statistici generale anuale pentru domeniul ales.

Fig 5.13 Statistică anuală pentru domeniul doishpe.de

Al noualea instrument “update, adminc eintrag” permite modificarea contactului aferent unui domeniu de. Acest lucru presupune selectarea domeniului şi introducerea noului contact dorit. Apasand butonul “OK” sistemul va genera un mail de “update” pentru acel domeniu care va fi trimis spre procesare robotului de înregistrare al organizatiei DENIC. Dacă operaţia a fost efectuată cu succes, datele domeniului vor fi modificare corespunzator, în caz contar datele vor rămâne nemodificate.

Al zecelea instrument este “pop account nachkauf”. Prin intermediul acestui instrument se pot achiziţiona cu taxa adaugata un numar suplimentar de căsuţei poştale POP3 (Fig 5.14). La accesarea paginii se afiseaza lista domeniilor, numărulde căsuţei POP3 detinute de fiecare domeniu şi un link pentru cumpararea unui numar suplimentar de 5 căsuţei poştale. La accesarea linkului utilizatorul este intrebat prin intermediul unei pagini de confirmare dacă doreşte sa continue de cumparare a numărului suplimentar de căsuţei.

Fig 5.14 Interfaţa de achzitionare a căsuţelor poştale suplimentare

În cazul în care clientul va confirma actiunea se va incrementa numărulde căsuţei POP3 şi se va introduce o intrare în tabela facturilor reprezentand contravaloarea numărului suplimentar de căsuţei poştale ales.

Instrumentul cu numărul11 este: “webspace nachkauf”. Prin intermediul acestui instrument se poate achiziţiona un volum suplimentar de maxim 50 de Mb spaţiu web pentru domeniile de tipul “level drei”. Interfaţa este compusa din trei părţi (Fig 5.15). În prima parte este prezentat pretul spatiului suplimentar şi volumul maxim pentru care se poate opta. A două parte consta din afişarea spatiului curent pentru fiecare domeniu “level drei” deţinut.

Fig 5.15 Interfaţa de achiziţionare a spaţiului web suplimentar

A treia parte constituie interfaţa de unde se va comanda volumul spatiului suplimentar. Dupa alegerea domeniului şi al volumului dorit se va apasa butonul “Submit”. Dupa ce se va verifica dacă volumul ales adunat cu volumul actual de spaţiu deţinut nu depaseste limita maxima admisa, se va trece la partea de confirmare a operaţiei. Dacă operaţia a fost confirmata se va modfica limita de spaţiu a domeniului pe serverul de hosting şi se va introduce o intrare în tablea facturilor care reprezintă contravaloare volumului suplimentar de spaţiu ales.

Instrumentul “statistik” oferă posibilitatea clientului de a verifica dacă exista facturi neemise sau neplatite pentru domeniile pe care le deţine sau pentru serviciile pe care le-a comandat. Se afiseaza fiecare intrare neplatita sau nefacturata din tablea facturilor incluzand data emiterii, valoarea facturii şi obiectul facturat.

Instrumentul “mailexchanger aendern” oferă posibilitatea utilizatorului experimentat de a-şi modifica mailexchanger-ul pentru orice domeniu deţinut (Fig 5.16). Interfaţa se compune dintr-un meniu pentu selectarea domeniului şi o casuta text în care va fi introdus noul mailexchanger. Dacă valoare introdusa în câmpul text va fi verificată şi validata se va proceda la modificarea valorii mailexchangerului în baza tablea domeniilor active din baza de date a sistemului.

Fig 5.16 Interfaţa de schimbare a mailexchanger-ului

Instrumentul “nameserver aendern” permite utilizatorului experimentat modificarea serverelor DNS pentru un domeniu ales (Fig 5.17).

Fig 5.17 Interfaţa de modificare a serverelor DNS

Interfaţa este similară cu cea pentru schimbarea serverului de mail. Ea se compune din lista domeniilor clientului, casutele pentru introducerea serverului DNS primar şi secundar şi butoanele de executare a operatiti şi resetarea intrărilor DNS pe standard.

Ultimul instrument este instrumentul “mysql datenbanken” cu ajutorul căruia se administrează conturile de baze de date aferente domeniilor “level drei”. Interfaţa presupune alegerea domeniului pentru care urmează sa se faca administrearea contului bazei de date aferente (Fig 5.18).

Fig 5.18 Interfaţa pentru administrarea contului de bază de date

Interfaţa prezintă datele contului de baza de date pentru domeniul ales. Se prezintă numele domeniului căruia ii aparţine baza de date, numele serverului bazei de date, adresa interfeţei web pentru controlul bazelor de date şi al tabelelor (PHPMyAdmin), numele utilizatorului bazei de date, parola aferenta acestuia, dimensiunea bazei de date şi data inceperii contractului.

Ultimul rând constituie meniul operaţiilor posibile:

· Modificarea parolei contului de baza de date.

· Optimizarea bazelor de date şi tabelelor aferente acestui cont.

· Modificarea dimensiunii bazei de date – permite creşterea dimensiunii bazei de date până la 20 Mb.

· Renuntarea la baza de date – presupune ştergerea acesteia şi incetarea platii pentru spatiul suplimentar cumparat (dacă acesta exista).

· Reactivarea bazei de date – presupune reularea activitatilor specifice şi resetarea la parametrii standard.

Pe lângă toate aceste instrumente clientului i se pune la dispoziţie suport tehnic 24 de ore din 24. Suportul tehnic include suportul telefonic 24 de ore din 24 şi suport per mail. În prezent la centrul pentru support lucreaza 12 angajati, 9 dintre ei raspunzand de suportul tehnic iar restul de 3 raspunzand de suportul pe probleme de contabilitate.

De asemenea clientul are la dispoziţie paginile de informaţii şi noutăţi. Pagina “Infos” conţine informaţii utile care vin în ajutorul clientului pentru a clarifica problemele des intalnite pe parcursul înregistrării unui domeniu.

Pagina “News” conţine ultimele noutăţi, oferte şi servicii oferite de firma NetBeat cât şi noutăţi din sfera activitatii de înregistrare a domeniilor pe plan mondial.