Proiectarea Si Crearea Unui Web Server
INTRODUCERE
În prezent produsele soft se implementează foarte rapid, din cauza dezvoltării enorme a tehnologiilor informaționale, acumulării cunoștințelor și bibliotecilor de date, creării rețelelor pentru comunicare și schimb de informații.
Datorită progresului tehnico-științific tot mai mult se aplică sistema de stocare a informației în interiorul Web-Serverelor. Acest lucru nu a fost trecut cu vederea nici de o companie contemporană ce intenționează de a ieși pe arena mondială. Numai în anul trecut campania de reclamă desfășurată de cele mai mari corporații Soft ca Microsoft și Sun Microsystems au dat naștere a câteva zeci de noi Web-Servere Informaționale, numai vorbind de companiile comerciale electronice Samsung, Sharp și Mitsubishi. Acest lucru s-a dovedit a fi foarte avantajos, economisind sume enorme de bani, în primul rând din cauza excluderii din piață a agențiilor de reclamă, care necesită cheltuieli destul de mari.
Scopul acestui proiect este de a proiecta și elabora un mijloc de stocare a informației cât mai comod, simplu și ce este cel mai principal independent de platformele soft existente. Și anume, nu întâmlător în calitate de limbaj de scriere a acestui Web-Server a fost ales JAVA2. În prezent acesta este unicul limbaj de programare orientat pe obiecte , popular și independent de platformă. Produsele Soft contemporane sunt destul de elegante, comode și avantajoase, dar din păcate aproape toate sunt dependente de platforma utilizată.
Însă la elaborarea unor proiecte soft destul mari, puțini se gândesc la aceea, dar cum oare le va putea utiliza clientul care lucrează pe UNIX, Solaris sau Machintosh. Majoritatea programatorilor în prezent sau prins , voluntar sau involuntar, în așa numitul sindrom Microsoft Windows. Scopul principal al acestui proiect este de a conlucra cu toți clienții existenți care doresc să lucreze cu așa un tip de programe care sunt înțelese de orice mașină, fie la lucru, acasă sau la prieten.
Datorită tehnologiei JAVA2 am încercat să creez așa un tip de program. Și fie ca volumul de informație care va fi disponibil pe acest Web-Server să fie utilizat și înțeles de majoritatea utilizatorilor Web din rețeaua globală Internet. Desigur tipul de informație disponibilă pe acest Web-Server deja depinde de companiile ce-l vor utiliza în scopurile proprii.
1. INTERNET, WEB-SERVERE, JAVA – MIEZUL CIVILIZAȚIEI
1.1 Rețea globală – World Wide Web (WWW)
Internet – este rețeaua rețelelor, ce ne pune la dispoziție infrastructura pentru intersecția și posibilitatea folosirii informației. El ne pune la dispoziție un rînd de servicii, așa cum sunt poștra electronică,transmiterea fișierelor, conectarea in regimul terminalelor la distanță, convorbiri interactive, grupuri de știri, și WWW.
World Wide Web (se numește "WWW', "Web" sau "W3") – acesta este universul informației, ce este disponibilă din Internet. WWW a apărut ca un proiect informațional de rețea în CERN, laborator fizic european. WWW constă din programe, un set de protocoale și înțelegeri, ce se folosesc la primirea accesului la informație și căutarea acestea în Internet. Cu ajutorul folosirii tehnologiilor hipertextuale și multimedia WWW permite oricarui utilizator ușor de a adăuga orice informație, de a o evalua și de a o căuta.
Web-clienții, cunoscuți sub numele de web-brauzer, ne ofera interfața de utilizator pentru navigarea in lumea informației cu ajutorul metodei de accesare și click-are a mousului. Web-serverul oferă brauzerelor HTML și alte posibilități pentru primirea informației cu ajutorul protocolului HTTP. Brauzerele interpretează, formatează și evaluează documentele utilizatorilor. Ca rezultat final fiind remrezentarea multimedia a Internetului.
Web-serverele pot fi atacate , sau folosite ca locul, de pe care vor fi atacate alte componente interne ale rețelei organizației. Este necesar de a acorada securitatea unui șir de regiuni în Web-servere – a sistemului de operare, programele web-serverului, scripturile serverului și a altor programe.
Brauzerele însă aduc și ele la apariția unor ”srărturi”, însă acestea sunt mai puțin serioase, decât acele, ce pot apărea din cauza Web-serverului.
1.2 Web-serverele
Multe organizații în prezent susțin sait-uri WWW externe, ce descriu compania lor sau serviciile ce le acordă. Din cauza securității aceste servere de obicei se pun după brandmauer-ul companie. Web-saiturile pot fi cum niște realizări casnice , așa și niște saituri bine construite pentru mișcarea producției. Organizațiile pot cheltui un număr nu mic de bani și timp pentru realizarea acestor web-saituri, ce acordă un volum mare de informație întrun mod destul de avantajos sau care crează un stil al companiei(în dependență cu ce se ocupă compania). Cu alte cuvinte, web-saitul organizației este o formă de creare a imaginii și repuitației acestei companii.
Trebuie să fie puși responsabilii pentru elaborarea, dirijarea și administrarea web-saitului extern al companiei. În companiile mari aceasta poate poate intra în angajamentul a mai multor persoane. De exemplu, directorul comercial poate răspunde pentru găsirea și realizarea posibilităților noi de mișcare a producției și serviciilor, iar administratorul web-saitului – pentru realizarea pe el a strategiei generale, incluzând pregătirea coordonatorie conținutului lui și controlul bugetului lui. Șeful secției vânzări poate răspunde de punerea la evidență a totalurilor despre venituri, legate de conducera web-saitului. Iar maestrul Web va răspunde de aspactele tehnice a web-saitului, inclusiv elaborarea, susținerea legăturii cu el, intranet, poșta electronică, și siguranța brandmauer-ului. Mai repede e că programatorii vor răspunde de lucrul web-saitului, inclusiv instalarea, elaborarea programelor pentru el, dirijarea lor și documentarea. Pictorul-web se poate ocupa de crearea chipurilor grafice a web-saitului.
În unele organizații mai mici programatorul sau web-maestrul poate îndeplini majoritatea lucrurilor descrise mai sus și acordarea dărilor de seamă șefului secției de vânzări. În sfârșit într-o organizație destul de mică aceste sarcini pot deveni adaugate analiticului de sistem sau a administratorului ЛВС. Indiferent de acea cum se administrează web-saitul, toși oamenii, ce indeplinesc aceste sarcini trebuie sa aduca la viață politica companiei elaborată de către conducerea acesteia. Eșalonul de sus al organizației poate răspunde de posibilitatea creării unui astfel de sait, altor noi, sau modificarea celor disponibile.
În afară de aceasta, web-saiturile interne ale organizației, ce sunt puse în interiorul brandmauer-ul companiei, des se folosesc pentru transmiterea informației companiei lucrătorilor. Des se transmit felicitări cu ziua de naștere, graficul unor petreceri, dicționare telefonice ș.a.m.d. Însă ele se mai folosesc pentru pentru transmiterea unor informații interne despre proiecte, fiind deseori cxentrul informației pentru grupurile de cercetări. Chiar dacă web-saiturile interne nu sunt atăt de accesibile ca cele externe, ele trebuie să fie administrate cu ajutorul unor directive și conduceri strict realizate. Conducătorii grupurilor trebuie să răspundă de aceasta.
Oricine poate crea un sait de răspândire a informației, legată de orice întrebări, ce nu ieste legată de companie. Organizația trebuie să ia careva hotărâri cu privire la acceptarea ca supușii săi să aloce informație pe web-saituri străine.
Majoritatea organizațiilor folosesc Internetul pentru răspândirea informației despre ea și serviciile pe care le acordă. Dat fiind că ele alocă informația, dar nu o ascund, ei desriu aceste web-saituri ca “publice”, pe care nu se conține nici o informație confidențială, și de unde nu poate apărea nici un risc de pierdere. Problema constă în acea că chiar fiind această informație public disponibilă, web-saitul este o parte a organizației, și trebuie să fie protectat de vandalism.
Saiturile publice în MGM/Universal Studios, Nation of Islam, Ministerul justiției a SUA și CIA pot confirma această declarație. În ele au fost efectuate intrări nelegale în anul 1996 . Atacatorii au folosit locurile nu prea sigure din sistemul de operare, sub conducerea cărora lucrau Web-serverele. Ei schimbau un șir de pagini ale web-saiturilor, și în unele cazuri au adăugat câteva imagini porno, iar într-un caz au introdus careva măscărituri.
Chiar daca ca urmare a acestor atacuri a fost puardută reputația companiilor, aceasta poate fi destul , pentru a le trece dorul de a mai simți a doua oară așa ceva. Dacă atacanții schimbau descrierile serviciilor organizațiilor, falsificau prețurile, atunci consecințele putea deveni cu mult mai serioase.
Web-Server este un program, care răspunde de primirea cererilor de la brouzere, căutarea fișierelor necesare și întoarcerea conținutului lor. Până în prezent în întreaga lume sunt elaborate și larg utilizate câteva zeci de astfel de programe, care realizează aceste funcții. Practic pentru fiecare sistem de operare există un șir de satfel de programe. Unele dintre ele sunt independente de platformă și pot fi utilizate simultan în diferite Sisteme de Operare (SO). Dar din păcate majoritatea Web-Serverelor sunt orientate pentru utilizarea pe un SO concret. Printre acestea sunt și programe comerciale dar și de acelea care sunt răspândite gratis. Câteodată funcțiile Web-Serverului sunt doar o parte din funcțiile, expuse de programator în program. În afară de un set minim de probleme executabile, ce determină funcțiile Web-serverului, majoritatea programelor conțin în sine multe posibilități adăugătoare. Către acestea se referă limitarea dreptului de acces la unele documente aparte, posibilitatea securității criptografice a datelor ce sunt transmise și primite, crearea pe un calculator a mai multor Web-servere cu diferite nume domen, folosirea porturilor de intrare nestandarte pentru server. În afară de aceasta de la Web-servere deseori este așteptată susținerea lucrului cu SGBD și limbajele Perl și JAVA. În afară de setul de funcții, o influență mare la alegerea Web-Serverului de către utilizator este simplitatea configurării și comoditatea administrării. O importanță nu mică pentru accesarea serverelor o are și timpul de răspuns a programului la cererile clienților. În prezent (conform datelor Netcraft Web Server Survey) un lider ireproșabil printre Web-Servere este gratis disponibilul server Apache. În cei cinci lideri intră și serverele Microsoft Internet Information Server, Netscape, NCSA și WebSite.
1.3 Exemple de politici ale Web-serverelor
Risc minim
Utilizator
Pe web-saiturile organizației nu se poate aloca material murdară sau plictisitoare.
Pe web-saiturile organizației nu se poate afișa reclamă personală.
Managerul
Managerului și Utilizatorilor li se permite de a avea web-sait personal.
Materiale despre lucrători pe web-saituri sau accesibile cu ajutorul lor trebuie să fie minimale.
Membrii secției de automatizare
Trebuie să fie susținut și să fie accesibil pentru folosința internă o arhivă locală de programe a Web-serverelor și accesoriilor de publicare a informației pe ele.
Risc mediu
Utilizator
Utilizatorilor li se interzice instalarea sau accesarea Web-serverelor.
În privința paginilor web trebuie să se respecte o regulă elaborată de organizație ceea ce privește confirmarea documentelor, dărilor de seamă, a informației de Marketing ș.a.m.d.
Managerul
Managerilor și utilizatorilor li se permite susținerea web paginilor pentru participarea la proiecte sau elaborarea lucrului sau de spacialitate.
Membrul secției de automatizare
Web-serverul și orișicare alte date, ce sunt public disponibile, trebuie să fie alocate în afara brandmauer-ului organizației.
Web-serverul trebuie să fie configurat în așa mod, ca utilizatorii să nu aibă posibilitatea instalării scripturilor.
Toate protocoalele web trebuie să fi deconectate, în afară de HTTP, trebuie să fie deconectate (de exemplu, SMTP, FTP ș.a.m.d.)
Serverele Informați adăugătoare. Către acestea se referă limitarea dreptului de acces la unele documente aparte, posibilitatea securității criptografice a datelor ce sunt transmise și primite, crearea pe un calculator a mai multor Web-servere cu diferite nume domen, folosirea porturilor de intrare nestandarte pentru server. În afară de aceasta de la Web-servere deseori este așteptată susținerea lucrului cu SGBD și limbajele Perl și JAVA. În afară de setul de funcții, o influență mare la alegerea Web-Serverului de către utilizator este simplitatea configurării și comoditatea administrării. O importanță nu mică pentru accesarea serverelor o are și timpul de răspuns a programului la cererile clienților. În prezent (conform datelor Netcraft Web Server Survey) un lider ireproșabil printre Web-Servere este gratis disponibilul server Apache. În cei cinci lideri intră și serverele Microsoft Internet Information Server, Netscape, NCSA și WebSite.
1.3 Exemple de politici ale Web-serverelor
Risc minim
Utilizator
Pe web-saiturile organizației nu se poate aloca material murdară sau plictisitoare.
Pe web-saiturile organizației nu se poate afișa reclamă personală.
Managerul
Managerului și Utilizatorilor li se permite de a avea web-sait personal.
Materiale despre lucrători pe web-saituri sau accesibile cu ajutorul lor trebuie să fie minimale.
Membrii secției de automatizare
Trebuie să fie susținut și să fie accesibil pentru folosința internă o arhivă locală de programe a Web-serverelor și accesoriilor de publicare a informației pe ele.
Risc mediu
Utilizator
Utilizatorilor li se interzice instalarea sau accesarea Web-serverelor.
În privința paginilor web trebuie să se respecte o regulă elaborată de organizație ceea ce privește confirmarea documentelor, dărilor de seamă, a informației de Marketing ș.a.m.d.
Managerul
Managerilor și utilizatorilor li se permite susținerea web paginilor pentru participarea la proiecte sau elaborarea lucrului sau de spacialitate.
Membrul secției de automatizare
Web-serverul și orișicare alte date, ce sunt public disponibile, trebuie să fie alocate în afara brandmauer-ului organizației.
Web-serverul trebuie să fie configurat în așa mod, ca utilizatorii să nu aibă posibilitatea instalării scripturilor.
Toate protocoalele web trebuie să fi deconectate, în afară de HTTP, trebuie să fie deconectate (de exemplu, SMTP, FTP ș.a.m.d.)
Serverele Informaționale trebuie să fie alocate întro subrețea apărată pentru izolarea lor de la alte sisteme ale organizației. Aceasta scade probabilitatea, că serverul informațional va fi compromitat și folosit pentru a ataca alte sisteme ale organizației.
La folosirea posibilităților de administrare cu ajutorul WWW, trebuie de limitat accesul la el numai sistemelor autorizate (cu ajutorul adreselor IP, dar nu host-name). Întotdeauna trebuie de schimbat Pasword Default.
Risc Maxim
Utilizator
Utilizatorilor le este interzis sa încarce, să instaleze sau sa pornească programele Web-servelor.
Trebuie să fie controlul permanent al traficului de rețea pentru declanșarea Web-serverelor neautorizate. Operatorii acestor servere vor fi supuși unor pedepse administrative disciplinare.
Managerul
Conducerea organizației trebuie să dea în formă scrisă acordul de lucru al Web-Serverului, conectat la Internet.
Tot conținutul Web-serverelor companiei, ce sunt conectate la Internet, trebuie să fie acceptat și instalat de Web-maestru.
Informația confidențială nu trebuie să fie disponibilă cu ajutorul web-saitului.
Către informația alocată pe Web-server, sunt valabile toate legile cu privire la siguranța Informației. Deacea, înainte de a aloca informație în Internet, ea trebuie să fie revăzută și confirmată tot așa cum sunt confirmate documentele oficiale pe hârtie ale organizației. Trebuie să fie respectate drepturile de autor, și primită învoirea de alocare a informației pe web-sait.
Toate saiturile cu acces public trebuie să fie regulat testate la corectitudinea link-urilor, și nu trebuie să se afle în starea "under construction". La reconstruirea unor regiuni ele trebuie să fie indisponibile.
Membrul secției de automatizare
Nu trebuie să fie posibilități de dirijare a Web-serverului la distanță (adică de pe locurile , ce nu se află în consoli). Toate schimbările administratorului trebuie să se efectuieăe numai de pe consoli. Intrarea în sistemă cu dreptul de superutilizator trebuie să fie interzis.
Programele Web-serverelor și a sistemului de operare, sub dirijarea căreia lucrează Web-serverul, trebuie să conțină toate schimbările, recomandate de elaboratorul acestei versiuni.
Traficul de intrare HTTP trebuie să fie scanat, și despre apariția Web-serverelor neautorizate trebuie să se comunice.
Limitarea accesului la informație a utilizatorilor, adreselor care se termină cu .GOV sau .COM, oferă siguranța minimă pentru informația, ce nu este disponibilă tuturora. Se poate folosi un Server aparte sau oparte aparte pentru informația cu acces limitat.
După toate Web-saiturile trebuie să se efectuieze un control permanent ca parte întreaga a administrării rețelei. Acțiunile tuturor utilizatorilor, ce sunt suspectați pentru folosința necorrectă a Internetului, pot fi protocolate pentru arătarea folosinței față de ei a unor măsuri administrative.
Pe sistemele UNIX Web-serverele nu trebuie să luicreze cu drepturi de superutilizator.
Elaborarea și folosirea scripturilor CGI trebuie să fie într-un control permanent. Scripturile CGI nu trebuie să prelucreze datele de intrare fără controlul acestora . Orice programe externe, ce sunt accesate cu parametri din linia de comandă , nu trebuie să conțină maxisimboluri. Programatorii răspund pentru utilizarea expresiilor regulare corecte pentru scanarea maxisimbolurilor a procesorului de comandă și ștergerea lor înaintea transmiterei datelor de intrare programului de pe Server și sistemului de operare.
Toate Web-serverele organizației, conectate la Internet, trebuie să se afle între brandmauer și rețeaua internă a organizației. Orice Web-Servere interne ale organizației, ce susțin lucrul programelor critice a organizației trebuie să fie protejate de brandmauer-ele interne. Informația critică, confidențială și personală nici odată nu trebuie să fie păstrată pe un Web-Server exterior.
1.4 Java pentru crearea Web-serverului
Programul poarte fi scris în orice limbaj de programare, dar ea trebuie să lucreze pe orice tip de tehnică. Majoritatea utilizatorilor sistemei vor lucra în sisteme incompatibile, așa că ei nu vor putea folosi programul nostru cum se cuvine.
Problema poate fi simplificată cu ajutorul Internetului și a limbajului JAVA. Atunci nouă ne rămâne numai să scriem programul, care va lucra pe diferite platforme. Internetul le va permite utilizatorilor să acceseze comunicațiile internaționale comerciale pentru o plată destul de mică. Internetul va permite unui grup de oameni ce se află pe ambele părții a frontierelor statale, să se folosească de program tot așa de ușor cum , o poate face un grup local de utilizatori.
Prin urmare trebuie de creat aplicațiile server și client într-un limbaj de programare independent de platformă, așa cum este JAVA.
Până în prezent majoritatea programatorilor Web când primeau sarcina de a scri un Web-server, luau fără multe gânduri scenariul în limbajul Perl, ce folosește CGI (Common Gateway Interface), care mult timp a fost(pote chiar încă mai este) răspunsul la această sarcină. Iar dacă li se mai spunea ca serverul să fie destul de rapid, iarăși îl scriau în С++ ,tot cu interfața CGI.
CGI – este un protocol, care se folosește pentru rezolvarea funcțiilor dinamice Web. CGI ea careva date de intrare, le prelucrează și crează documentul MIME (Multimedia Internet Mail Extensions). Aceasta e o chestie destul de puternică , dar ea are și limitele sale. CGI este creat pe dialogul cu Web-brouzerul. Web-brouzerul înțelege documentele MIME și le arată , dar la aceasta totul și se termină. Dar să presupunem că dumneavoastră doriți să luați datele , apoi încă cumva să le prelucrați iar mai apoi să le afișați ?
Iar dacă noi vom scri acelaș Web-server în limbajul JAVA, noi vom primi posibilități adăugătoare, iar lansarea clientului în JAVA le va lărgi până la infinit. Clientul poate prelucra datele de intrare și să le afișeze în modul plăcut. În acest timp nu numai că se scot probleme surplus de pe server , dar și li se adaugă posibilități utilizatorilor, în rezultat prezentarea datelor se îmbunătățește. De exemplu, utilizatorul va putea shimba fonturile, și sisteme va putea amplasa afișarea datelor sub mărimea monitorului.
Scrierea programului WEB-serverului ne aduce la luarea asupra noastră a unor răspunderi, fiindcă serverul – posibil că este cea mai slabă cheie în Latele Internetului Dumneavoastră. Programa rău scrisă poate aduce la destrugerea calculatoruli sau, ce este încă mai rău la pierderea datelor. Serverele se scriu pentru răspândirea informației sau rezolvarea unor probleme.
Folosirea limbajului JAVA în calitate de limbaj de scriere a Web-serverului practic este ideal din punct de vedere a securității informației, doar la elaborarea JAVA se socoteau cu problemele secretului informației. Pointerul atașat nu prea drept nu va aduce la aceea, că sistema dumneavoastră va deveni deschisă și liberă pentru atacurile externe. Dar este foarte important de înțeles că , aplicația-JAVA are mai puține limitări , ca un applet. În prelabil ea se poate adresa discului, așa că noi trebuie să indicăm corect ce îi este permis serverului. Există o regulă empirică – de permis serverului accesul numai la acele fișiere care îi sunt necesare.
În programul scris în JAVA, posibilitatea apariției ferestrelor pentru atacuri externe sunt cu mult mai puține , decât într-un program scris în C++, și , posibil mai puține, decât la folosirea scenariilor scrise în Perl, dar nici un limbaj nu poate garanta securitate ideală.
În ceea ce privește viteza de lucru a programului JAVA de obicei se compară cu scenariul în limbajul Perl. Perl mai bine prelucrează textul, dar la rezolvarea majorității operațiilor JAVA nu se lasă în urmă.Programul scris în JAVA , va lucra nu cu mult mai lent ca , orișicare altă programă scrisă în alt limbaj.
JAVA – un limbaj orientat-pe-obiecte, și în el este incorporată strângerea gunoiului. Aceste două posibilități permit limbajului JAVA să folosească mai multă memorie, decât alte limbaje pentru Web-servere, așa cum sânt Perl și C. Pentru limbajele orientate-pe-obiect este tipic de a folosi mai multă memorie. Dat fiind că în limbajul JAVA este prezent strângerea gunoiului, el poate face această curățire sporadic. Sistema poate să nu curățe memoria până când nu va fi necesar, ne luând în considerație că aceasta este necesar altor programe. Aceasta înseamnă, că serverul scris în JAVA va ține în rezervă mai multă memorie, decât îi trebuie. Mai des este necesar de a compara prioritățile.
1.4.1 Fire de execuție
Pentru a scri un Web-Server în JAVA, trebuie de ținut cont ca procesul serverului să poată prelucra cererile a mai multor clienți concomitent. Pentru a rezolva această problema în Java există termenul fir de excuție. O aplicație Java rulează în interiorul unui proces al sistemului de operare. Acest proces constă din segmente de cod și segmente de date mapate într-un spațiu virtual de adresare. Fiecare proces deține un număr de resurse alocate de către sistemul de operare, cum ar fi fișiere deschise, regiuni de memorie alocate dinamic, sau fire de execuție. Toate aceste resurse deținute de către un proces sunt eliberate la terminarea procesului de către sistemul de operare.
Un fir de execuție este unitatea de execuție a unui proces. Fiecare fir de execuție are asociate o secvență de instrucțiuni, un set de regișitri CPU și o stivă. Atenție, un proces nu execută nici un fel de instrucțiuni. El este de fapt un spațiu de adresare comun pentru unul sau mai multe fire de execuție. Execuția instrucțiunilor cade în responsabilitatea firelor de execuție. În cele ce urmează vom prescurta uneori denumirea firelor de execuție, numindu-le pur și simplu fire .
În cazul aplicațiilor Java interpretate, procesul deține în principal codul interpretorului iar codul binar Java este tratat ca o zonă de date de către interpretor. Dar, chiar și în această situație, o aplicație Java poate avea mai multe fire de execuție, create de către interpretor și care execută, seturi distincte de instrucțiuni binare Java.
Fiecare dintre aceste fire de execuție poate rula în paralel pe un procesor separat dacă mașina pe care rulează aplicația este o mașină cu mai multe procesoare. Pe mașinile monoprocesor, senzația de execuție în paralel a firelor de execuție este creată prin rotirea acestora pe rând la controlul unității centrale, câte o cuantă de timp fiecare. Algoritmul de rotire al firelor de execuție este de tip round-robin.
Mediul de execuție Java execută propriul său control asupra firelor de execuție. Algoritmul pentru planificarea firelor de execuție, prioritățile și stările în care se pot afla acestea sunt specifice aplicațiilor Java și implementate identic pe toate platformele pe care a fost portat mediul de execuție Java. Totuși, acest mediu știe să profite de resursele sistemului pe care lucrează. Dacă sistemul gazdă lucrează cu mai multe procesoare, Java va folosi toate aceste procesoare pentru a-și planifica firele de execuție. Dacă sistemul oferă multitasking preemptiv, multitaskingul Java va fi de asemenea preemptiv, etc.
În cazul mașinilor multiprocesor, mediul de execuție Java și sistemul de operare sunt responsabile cu repartizarea firelor de execuție pe un procesor sau altul. Pentru programator, acest mecanism este complet transparent, neexistând nici o diferență între scrierea unei aplicații cu mai multe fire pentru o mașină cu un singur procesor sau cu mai multe. Desigur, există însă diferențe în cazul scrierii aplicațiilor pe mai multe fire de execuție față de acelea cu un singur fir de execuție, diferențe care provin în principal din cauza necesității de sincronizare între firele de execuție aparținând aceluiași proces.
Sincronizarea firelor de execuție înseamnă că acestea se așteaptă unul pe celălalt pentru completarea anumitor operații care nu se pot executa în paralel sau care trebuie executate într-o anumită ordine. Java oferă și în acest caz mecanismele sale proprii de sincronizare, extrem de ușor de utilizat și înglobate în chiar sintaxa de bază a limbajului.
La lansarea în execuție a unei aplicații Java este creat automat și un prim fir de execuție, numit firul principal. Acesta poate ulterior să creeze alte fire de execuție care la rândul lor pot crea alte fire, și așa mai departe. Firele de execuție dintr-o aplicație Java pot fi grupate în grupuri pentru a fi manipulate în comun.
În afară de firele normale de execuție, Java oferă și fire de execuție cu prioritate mică care lucrează în fundalul aplicației atunci când nici un alt fir de execuție nu poate fi rulat. Aceste fire de fundal se numesc demoni și execută operații costisitoare în timp și independente de celelalte fire de execuție. De exemplu, în Java colectorul de gunoaie lucrează pe un fir de execuție separat, cu proprietăți de demon. În același fel poate fi gândit un fir de execuție care execută operații de încărcare a unor imagini din rețea.
O aplicație Java se termină atunci când se termină toate firele de execuție din interiorul ei sau când nu mai există decât fire demon. Terminarea firului principal de execuție nu duce la terminarea automată a aplicației.
1.4.2 Sincromizarea firelor de execuție
În unele situații se poate întâmpla ca mai multe fire de execuție să vrea să acceseze aceeași variabilă. În astfel de situații, se pot produce încurcături dacă în timpul unuia dintre accese un alt fir de execuție modifică valoarea variabilei.
Limbajul Java oferă în mod nativ suport pentru protejarea acestor variabile. Suportul este construit de fapt cu granulație mai mare decât o singură variabilă, protecția făcându-se la nivelul obiectelor. Putem defini metode, în cadrul claselor, care sunt sincronizate.
Pe o instanță de clasă, la un moment dat, poate lucra o singură metodă sincronizată. Dacă un alt fir de execuție încearcă să apeleze aceeași metodă pe aceeași instanță sau o altă metodă a clasei de asemenea declarată sincronizată, acest al doilea apel va trebui să aștepte înainte de execuție eliberarea instanței de către cealaltă metodă.
1.5 Adresa Universală a Resurselor URL
Adresa IP dă posibilitatea de identificare a nodului, însă ea nui de ajuns pentru identificarea resurselor, ce se află pe acest nod, așa cum sunt aplicațiile ce lucrează sau fișierele. Pricina este evidentă – pe nodul, ce are o singură adresă IP, poit fi multe resurse diferite.
Pentru adresare pe resursele rețelei Internet se folosește așa numita adresă universală a resurselor URL (Universal Resource Locator). În formă generală această adresă are forma următoare:
[protocol]://host[:port][path]
Linia adresei se începe cu protocolul protocol, care tzrebuie să fie folosit pentru accesul la resurs. Documentele HTML, de exemplu, se transmet de la Web-server utilizatorilor îndepărtați cu ajutorul protocolului HTTP.
Pentru adresarea pe resursele din rețea prin intermediul protocolului HTTP se folosește următoarea formă a adresei universale a resurselor URL:
http://host[:port][path]
De exemplu host este obligatoriu. El trebuie să fie indicat ca adresa domenă sau adresa IP . De exemplu:
http://www.sun.com
http://157.23.12.101
Parametrul neprincipal port redă numărul portului pentru lucrul cu Serverul. Default pentru protocolul HTTP se folosește portul cu numărul 80, însă pentru un Web-server specializat acesta poate fi și altul.
Numărul potului identifică programul , ce lucrează în nodul rețelei TCP/IP și care conlucrează cu alte programe, ce se află pe același nod sau pe alt nod din rețea. Dacă elaborăm programul , ce transmite datele prin rețeaua TCP/IP cu folosirea , de exemplu, a interfeței socketelor Windows Sockets, atunci la crearea canalului de legătură cu calculatorul de la distanță trebuie de indicat nu numai adresa IP, dar și numărul portului , care se va folosi pentru transmisia de date.
Mai jos se arată , cum trebuie de arătat în adresa URL numărul portului:
http://www.myspecial.srv/:82
Iar acum să ne clarificăm cu parametrul path, ce determină calea spre obiect.
Deobicei orice Web-server are un catalog rădăcină, în care se situiază toate subdirectoriile. Cum în catalogul principal așa și-n subdirectoriile Web-serverului se pot afla documentele HTML, fișierele binare, fișierele cu imagini grafice , video și audio-fișiere, extensia Web-serverului în forma programelor CGI sau biblioteca reprizelor dinamice, extinzând posibilitățile serverului.
Dacă în calitatea adresei URL de arătat navigatorului numai numele domen al serverului , serverul va transmite navigatorului pagina sa principală. Numele fișierului acestei pagini depinde de server. Majoritatea serverelor pe baza sistemelor UNIX transmit default fișierul documentului cu numele index.html. Alte Web-servere pot folosi pentru acest scop numele default.htm sau careva altul , determinată după la instalarea serverului , de exemplu, home.html sau home.htm.
La relația pe documentul concret HTML sau pe fișierul altui orișicare obiect e de dorit de indicat adresa URL a căii sale, ce include numele fișierului, de exemplu:
http://www.glasnet.ru/~frolov/index.html
http://www.dials.ccas.ru/frolov/home.htm
Catalogul de bază al Web-serverului se indică prin simbolul /. În specificația protocolului HTTP se spune, că dacă calea nu este indicată, atunci se folosește catalogul principal.
1.6 Câte ceva despre Java Virtual Mashine(JVM)
Concepția și realizarea mașinilor virtuale (MV) exista destul de demult. Una dintre cele mai devremi dintre cele comerciale a fost mediul de programare UCSD p-System. Aceasta sistema a fost creata de catre doctorul Kenneth Bowles la Universitatea din California de Sud, Sun-Microsystems, ce era destinată pentru desfacerea acesteia pe piață. Rămâne însă fapt, că p-System a fost miezul sistemului de operare pentru Apple III. Ea a mai fost sistema, ce prezenta alternativa PC-DOS pentru IBM PC după invazia PC în anii ’80.
Ca și mediul de programare JAVA, UCSD p-System se baza pe limbajul primal (Pascal). Ea avea un pachet de biblioteci de baza a miezului, un format independent de platformă a fișierului obiectual, un pachet de pseudocoduri byte-orientate și determinarea MV pentru interpretarea acestora. p-System a fost instalată pe multe arhitecturi și a avut un succes pe piața realizarilor de programare verticale.
Principalul în limbajul de programare JAVA este nu aceea ca este ceva unical sau nou. Mediul de programare JAVA are succes din cauza că, se folosește de un sprigin financiar din partea unei companii destul de norocoase cu un nivel în creștere a elaborării de Soft.
1.6.1 Componentele JVM
La aruncarea privirii asupra mediului de programare JAVA se văd cinci părți componente:
Limbajul JAVA
Biblioteca de classe a miezului JAVA/Sun
Structura fișierului .class
Determinarea byte-codurilor
Specificația JVM
Trei din ele, structura fișierului .class, determinarea byte-codurilor, specificația JVM, iau permis tehnologiei JAVA să se răspândească atât de larg în așa un timp de scurt. Constructorii JAVA au căpătat o transportare momentană a oricărui fișier .class pe orice calculator de orice arhitectură, ce se folosea pentru compilarea codului inițial. Concepția “scris odată, se excută oriunde” se aduce la viață datorită răspândirii largi a realizării JVM pe orice platforme aparatale și arhitecturi.
1.6.2 Arhitectura Mașinii Virtuale
Mașina Virtuala – este o concepție programală, care se bazează pe concepția calcultorului imaginar cu un set de instrucțiuni logice, sau pseudocoduri, ce determină operațiile, care le poate îndeplini acest calculator. Într-un caz tipic compilatorul VM-orientat primește la intrare un limbaj careva inițial. În locul instrucțiunilor codului de mașină, orientate spre o arhitectură de aparat concretă, el generează fire de byte-coduri, care se bazează pe un set de instrucțiuni a calculatorului imaginar.
O altă parte a unificării este aceea, cum aceste instrucțiuni se execută. Aici pe primul plan iese interpretorul, care în lumea JAVA se numește mașină virtuală. Interpretorul – este doar o aplicație, care primește semantica pseudocodurilor calculatorului imaginar și le transformă în instrucțiunile mașinii concrete. În afară de aceasta, mașina virtuală crează un sistem de sprijin a timpului de execuție pentru realizarea semanticii instrucțiunilor. Sistemul de sprijin a timpului de execuție răspunde și de încărcarea fișierelor obiectuale (fișierele .class), reglarea memoriei și strângerea de gunoi.
Din cauza diferenței de mijloace de aparataj, ce sunt folosite pentru lucrul mașinii virtuale, ele de obicei se bazează pe concepția mașinii de steck. Mașina de steck nu folosește nici un fel de registre fizice pentru transmiterea informației de la o instrucție la alta. În loc de aceasta se folosește steckul, ce conține freimurile, care prezintă starea metodelor, operanzii instrucțiunilor , argumenții metodelor și variabilele locale. Mai este un pseudoregistru, care se numește registru PC , – pointer pe masiivul de byte-coduri pentru instrucțiunea curentă îndeplinibilă.
Logica etapei de interpretare a lucrului JVM este destul de simplă:
Fig.1 Ciclul interpretorului JVM
Este foarte important de atras atenția la două momente , ce se referă la aceea, cum interpretorul factic prelucreză instrucțiunile byte-codului:
Majoritatea procedurilor semantice, care execută mișcările, legate cu byte-codul dat, primesc operanzii săi din steck și aranjează rezultatele înapoi în steck.
Instrucțiunile reale deobicei au argumentele, care de obicei merg in firul de execuție a byte-codurilor nemijlocit după însăși instrucțiunea.
Ciclul este construit destul de primitiv. Tot ce poate el face, – aceasta este de a citi byte-codul și dea lansa procedura semantică ce-I este comună.
Există și alte tehnologii, pe care interpretorul le poate folosi pentru prelucrarea firului de execuție a byte-codurilor, ce reprezintă instrucțiunile îndeplinibile pentru MV. Este răspândită tehnica de interpretare ce se numește interpretor firal (threaded interpreter). Așa interpretor nu accesează prelucrarea ciclică către către firele de execuție a byte-codurilor. În loc de aceasta el efectuiază trecerea de la o semantică la alta precum, acul face cusăturile pe materie.
Un alt mod de optimizare, care are tot o mai mare popularitate, este folosirea așa numitului compilator “la timp” (JIT – compilatorul). JIT-tehnologia se folosește în Microsoft JVM, Microsoft Internet Explorer 3.0 (și mai târzii) și Netscape Navigator 3.0 (și mai târzii). Ideia JIT-compilatorului constă în aceea , că în loc de interpretarea fiecării instrucțiuni, la etapa excutării are loc translarea sectorului de byte-coduri nemijlocit în setul de coduri de mașină echivalente a unei sisteme întregi. După aceasta versiunea metodei translate în cod de mașină se păstrează în memorie și se folosește, atunci este chemată această metodă concretă.
În așa mod este ajuns la translarea pe diferite platforme, bazată pe fișiere .class și byte-coduri. În afară de acesta, datorită translarii unare la timp a byte-codului în cod de mașină, se ajunge la productivitate, ce este aproape de productivitatea programului , ce este translat direct în codul de mașină.
2. DESCRIEREA GENERALĂ A LIMBAJULUI DE POO JAVA ORIENTAT PE LUCRUL CU REȚEAUA
2.1 Bazele lucrului în rețea
Ken Thompson și Dennis Ritchie au elaborat sistemul de operare UNIX concomitent cu limbajul C la Bell Telephone Laboratories, Murray Hill, New Jersey, în anul 1969. În cursul a mai multor ani dezvoltarea UNIX se făcea în Laboratoarele Bell, câteva universități și în instituțiile de cercetare științifică, care aveau PDP-mașinile companiei DEC, pentru lucrul pe care UNIX și a fost elaborat. În 1978 Bill Joy ducea un proiect în Universitatea din California cu scopul adăugării a unui set de noi facilități la UNIX, așa ca memoria virtuală și posibilitățile full screen a ecranului. Către începutul anului 1984, taman, când Bill Joy a părăsit Universitatea și a creat compania Sun Microsystems, el a lansat sistemul 4.2BSD, vestită ca Berkeley UNIX.
Sistemul 4.2BSD a fost lansat cu sistemul de fișiere rapid, semnale sigure, legătura interprocesorală și, ce este cel mai important, lucrul în rețea. Susținerea lucrul în rețea, prima dată găsită în versiunea 4.2, până la urmă, a devenit practic un standart pentru Internet. Berkeley-realizarea protocoalelor TCP/IP rămâne un etalon de bază pentru comunicarea în Internet. Paradigma socketului pentru legătura interprocesorală și rețea la fel a fost larg primită în afara Berkeley. Chiar Windows și Macintosh la sfârșitul anilor ’80 au început să spuie “Berkeley-socket”.
2.2 Viziunea generală a socketurilor
Socketul de rețea (network socket) tare mult seamănă cu conectorul electric. Diferite conectoare de rețea ne pun la dispoziție căi standarte pentru furnizarea tensiunii necesare. Totul, ce înțelege protocolul standart, se poate “conecta” la socket și intra în legătură cu acesta. Pentru conectorii electrici nu are nici o importanță conectați dumneavoastră un bec sau un toaster la rețea. Până când aceștea ne furnizează electricitate cu 50 Hz, 220 V, toate aparatele vor lucra normal. Să ne gândim cum se crează contul nostru oersonal pentru energia cheltuită. Există un contor undeva între casa noastră și cea laltă parte a rețelei. Pentru fiecare kilowatt , care trece prin acest contor, nouă ne vine un cont. Contul ne vine la “adresa” personală. Chiar dacă electricitatea “curge” liber prin rețeaua de putere, toate conctoarele din casă au adresa lor specifică.
Aceeași ideie este folosită și la conectoarele de rețea – socketurile, în excepția celeea, că noi vorbim de protocoalele TCP/IP și IP-adrese, dar nu despre elctroni și adrese de stradă. IP (Protocolul Internetului) – este protocolul marșrutizării nivelului de jos, care desparte datele în pachete mici și le transmite pe adrese diferite prin rețea, dar nu garantează sosirea pachetelor transmise în punctul de destinație. TCP (Protocolul reglării transmiterii) – acesta este un protocol al unui nivel mai superior , care poate strâns să lege pachetele între ele, sortândule și retranslându-le după necesitate pentru transmiterea sigură a datelor. Al treilea protocol – UDP (Protocolul Datagram al Userului) – urmează după TCP și poate fi folosit nemjlocit pentru susținerea unei conecțiuni rapide și fără crearea legăturii, dar, ce-i drept, are o transportare de date nu sigură.
2.3 Client – Server
Deseori am auzit termenul client-server , aplicat ca noțiune la lucrul cu rețeaua. El pare atât de complicat, când citim despre el în instrucțiunele de marketing a unei corporații, dar în realitate acest termen este destul de simplu. Server – este totul, ce are un oarecare nivel despărțit (colectiv folosit). Există servere de calcul, care execută puterea de calcul; servere de tipar , care conduc cu comunitatea imprimantelor; servere de disk, care ne pun la dispoziție spațiul de diskuri care lucrează în rețea, și Web-Servere, care păstrează paginile Web. Client – pur și simplu un oarecare alt obiect, care dorește să primească acces la un server specific. Interconectarea între server și client este aceeași, ca interconectarea între bec și conectorul electric. Rețeaua de putere a casei – Server, iar becul – Client al acestei rețele. Serverul – este o resursă permanent disponibilă, pe când clientul se poate “deconecta” după ce, a fost deservit.
În Berkeley-socketuri noțiunea de socket permite unui calculator aparte să deservească mai mulți clienți aparte concomitent, tot așa, cu să deservească mai multe tipuri de informație. Pentru dirijarea cu astfel de deservire se introduce noțiunea de port, care este ca atare un socket numerotat pe o mașină concretă. Se spune, că procesul serverului “ascultă” portul, până când clientul nu se va conecta cu el. Serverului i se permite de aprimi mai mulți clienți, care sunt conectați la unul și același număr de port, însă fiecare seans ca atare este unic. Pentru a dirija cu multipla conectare a clienților, procesul serverului trebuie să fie multythread sau să aibă careva alte posibilități de multiplexarea a in/out concomitent.
2.4 Socketurile rezervate
După conectarea protocolului de nivel înalt garantează o dependență strictă a conecsiunii de portul acela, pe care îl folosiți. TCP/IP rezervează 1024 de porturi de registrul inferior pentru diferite protocoale. Portul cu numărul 21 – pentru protocolul FTP, 23 – pentru protocolul Telnet, 25 – pentru protocolul poștei electronice (e-mail), 79 – pentru protocolul Finger, 80 – pentru protocolul HTTP (cel mai des utilizat), 119 – pentru protocolul teleconferințelor ș.a.m.d. În competența fiecărui protocol intră susținerea unui mod predefinit de conlucrare cu portul.
De exmplu HTTP (Protocolul de transmitere a hipertextului) – este protocolul, pe care Web-Brouzerele și serverele îl folosesc pentru transmiterea paginilor de hipertext și a imaginilor. Acesta este un simplu protocol pentru un Web-Server de bază, ce rulează pagini web.
Iată cum acesta lucrează. Când clientul cere un fișier de pe HTTP-Server , el pur și simplu introduce numele fișierului într-un format special către un port predefinit și citește conținutul fișierului. Serverul la rândul său răspunde cu un număr codat al stării, pentru a anunța clientul, poate oare cererea fi prelucrată sau nu, și de ce. Exemplu de proceduri colegate ale clientului, ce necesită un fâșier aparte (cu numele index.html), și serverul, ce răspunde, că el cu succes a găsit fișierul și-l transmite clientului:
Tab. 1
Comunicarea Server-Client
Desigur, protocolul HTTP este mult mai complicat, decât exemplul adus mai sus, dar aceasta este desigur tranzacția sigură, pe care a-ți puteaua avea cu oricare Web-Server vecin.
Orice calculator în Internet are o adresă. Adresa Internet – este un număr, care unical identifică fiecare calculator din rețea. În IP-adrese sunt 32 de biți, și noi le folosim ca o succesiune din patru cifre care se află între 0 și 255, ce sunt separate cu puncte. Aceasta le face mai simple pentru memorizare, fiindcă ele sunt atașate nu aleator, dar ierarhic. Primii câțiva biți ai adresei prezintă classul rețelei (classurile sunt identificate cu literele A,B,C,D sau E). Majoritatea userilor din Internet se află în rețelele classului C. Calssul C conține mai mult de două millioane de rețele. Prima parte a adresei rețelei classului C se află între 192 și 224, iar ultima – identifică calculatorul individual. (Într-o rețea unară C se pot afla până la 256 de calculatoare.) Această schemă permite de a exista în rețelele classului C aproximativ a o jumătate de milliard de aparate.
Rețeaua Internet nu ar fi un loc foarte comod pentru navigare, dacă fiecare ar trebui să folosească adresarea numerară. Este greu de închipuit , de exemplu, o adresă de reclamă în forma http://127.0.0.1/ . Spre bucuria tuturor, pentru ierarhia paralelă a numelor există o alternativă – metoda simbolică de adresare. În adresarea simbolică larg este folosit Serviciul Numelo Domen (DNS).
2.5 Java și rețeaua
Limbajul de programare JAVA este special orientat pe rețelele globale, așa ca Internet. În limbajul JAVA sunt clase concrete elaborate pentru programarea de rețea. Clasele JAVA sunt cele mai comode (în comparație cu alte limbaje de programare orientate pe obiecte) pentru elaborarea aplicațiilor de rețea.
Aplicațiile JAVA sunt foarte bune pentru accesul prin rețea la fișierele aflate pe Web-Server , dar crearea aplicațiilor client și server cu ajutorul socketelor sunt în genere la un nivel de sus.
Appleturile JAVA pot lucra cu fișierele , aflate pe serverul Web, fără a încurca lucrului utilizatorului.
Să ne imaginăm numai , de exemplu, că trebuie să scoatem la ecranul utilizatorului o diagramă, datele inițiale pentru crearea cărea se află pe Web-server. Această problemă poate fi rezolvată prin două metode.
Prima constă în aceea că creăm o lărgire a Web-serverului în forma unei aplicații CGI sau ISAPI, care conform datelor inițiale dinamic formează imaginea grafică în formă de GIF fișier și-l transmit utilizatorului.
Însă pe calea rezolvării problemei cu ajutorul lărgirii Web-serverului vă așteaptă două probleme. În primul rând, de creat din program un fițier grafic colorat frumos în standartul GIF nu este atât de simplu – trebuie să vă descurcați cu formatul acestui fișier și să creați toate posibilitățile necesare. În al doilea rând, fișierul grafic ocupă foarte mult loc și se transmite pe canalele Internet destul de lent.
În acelaș timp fișieruil cu datele inițiale poate fi foarte compact. Apare întrebarea – nu se poate oare de transmis prin Internet numai datele inițiale, iar construirea diagramei grafice să se facă pe stația utilizatorului?
În aceasta constă metoda a doua, care presupune aplicarea appleturilor. Aplicația dumneavoastră poate, de exemplu, să primească prin rețea fișierul datelor inițiale, iar apoi pe baza conținutului acestui fișier să deseneze în fereastra sa diagrama circulară colorată. Volumul datelor transmise în comparație cu aplicarea lărgirii Web-serverului se reduce de zeci și sute de ori.
În afară de lucrul cu fișierele, amplasate pe Web-server, se pot crea canale independente între aplicațiile JAVA, care lucrează pe diferite calculatoare în rețea, cu ajutorul socketurilor.
Socketurile ne dau posibilitatea de a organiza o colaborare strânsă între appleturi și aplicațiile JAVA, în care appleturile au posibilitatea de ași transmite unul altuia date prin rețeaua Internet. Aceasta deschide posibilități enorme pentru prelucrarea informației pe shema client-server, aici în rolul serverului poate lucra orice calculator, conectat la rețea , dar nu numai serverul Web. Orice stație de lucru poate să se afle în acelși timp în calitate de server , și în calitate de client.
Schematic lucrul Java în rețea este prezentat în Anexa 6.
2.5.1 IP Adresele
Înainte de a începe elaborarea aplicațiilor de rețea pentru Internet, trebuie să ne clarificăm cu adresația calculatoarelor în rețea prin intermediul protocolului TCP/IP, pe baza căruia este construită rețeaua Internet.
Memoria internă pierde informațiile odată cu oprirea alimentării calculatorului. Pentru a salva informațiile utile, precum și programele de prelucrare ale acestora este nevoie de dispozitive de memorare permanente. Din această categorie fac parte discurile calculatorului.
Toate calculatoarele conectate la rețeaua TCP/IP, se numesc noduri (în terminologia originală nod – este host). Fiecare nod are ăn rețea adresa sa IP, cum am mai spus ceva mai înainte, care constă din patru cifre zecimale în intervalul de la 0 la 255, despărțite prin simbolul “punct” , de exemplu: 127.0.0.1
Fig.2 Adresa IP
Practic adresa IP este un număr binar de 32-biți. Numerele menționate reprezintă niște baiți aparte în adresa IP. Dar dat fiind că de a lucra cu cifrele îi este
comod doar calculatorului, a fost inventată sistema numelor de domen (DNS). La folosirea acestui sistem adreselor IP li se pune în corespondență așa numita adresă de domen, de exemplu, așa ca www.sun.com.
În Internet este o bază de nume domene răspândită pe toată lumea, în care este aranjată relația între numele domene și adresele IP în forma celor patru numere.
Practic după cum, cele patru numere ale IP-adresei descriu ierarhia de rețea de la stânga la dreapta, Internet-adresa simbolară, ce se mai numește adresa domen, descrie alocarea calculatorului în spațiul de nume de la dreapta la stânga.
Fig.3 Adresa DNS
De exemplu, adresa www.samsung.com se află în domenul com (se mai numește numele domenului de rădăcină), site-ul se numește Samsung (după numele companiei) , iar www – numele calculatorului specific, care este Web-Serverul Samsung. www corespunde celui mai din dreapta număr în echivalenta IP-adresă.
2.6 Crearea aplicațiilor de rețea în Java
Deci să cercetăm cum Java se atârnă față de toate aceste concepții de rețea. Java susține protocoalele TCP/IP cum prin calea lărgirii interfeței deja predefinite a I/O, așa și întroducând noi metode, necesare pentru crearea obiectelor I/O de rețea. Java susține două familii de protocoale – TCP și UDP. TCP-protocoalele se folosesc pentru I/O a firelor de execuție prin rețea.
2.6.1 Classa InetAddress
Sunăm noi pe telefon, trimitem scrisoare prin poștă sau creăm o legătură prin Internet, în toate aceste procese valoarea fundamentală o are adresa. Calssa InetAddress se folosește, pentru incapsularea cum a adresei IP, despre care am vorbit anterior, așa și adresa domen. Noi interacționăm cu această classă, folosind adresa domen a host-calculatorului, careeste ceva mai comod și înțeles, decâd echivalentul lui numeral. Această adresă numerală este ascunsă în interiorul classei InetAddress.
Classa InetAddress nu are constructore vizibile. Pentru crearea obiectului InetAddress este necesar de a folosi una din metodele productive disponibile. Metodele disponibile (factory methods) – sunt o înțelegere, cu ajutorul căreia metodele statice în classă întorc exemplarul classei date. Pentru crearea exemplarelor de tipul InetAddress se pot folosi trei metode:
public static InetAddress getLocalHost() throws UnknownHostException;
public static InetAddress
getByName(String hostName) throws UnknownHostException;
public static InetAddress[]
getAllByName(String hostName) throws UnknownHostException;
Metoda getLocalHost() pur și simplu întoarce obiectul InetAddress , care prezintă host-calculatorul local. Metoda geByName() întoarce obiectul de tipul (classei) InetAddress pentru calculatorul, numele căruia se transmite în parametrul hostName. Dacă aceste metode nu sunt capabile să perceapă numele calculatorului, ele aruncă excepția de tipul UnknownHostException.
Pentru Internet este ceva obișnuit folosirea numel unar pentru determinarea câtorva mașini. În lumea Web-Serverelor aceasta este o metodă pentru a permite un oarecare grad de maximizare a rețelei. Metoda productivă getAllByName () întoarce un massiv de InetAddress obiecte , ce reprezintă toate adresele, legate cu numele dat. El deasemeni aruncă exceptia UnknownHostException , dacă nu poate construi, cel puțin, unul din obiectele adrese pentru numele calculatorului indicat.
Classa InetAddress mai are deasemeni și câteva metode nestatice, care pot fi folosite pentru obiectele, care sunt întoarse de metodele numai ce discutate:
public byte[] getAddress();
Întoarce un massiv de baiți din patru elemente, care reprezintă IP-adresa obiectului prelucrat.
public String toString();
Întoarce o linie , care redefinește adresa IP și domen a host-calculatorului (de exemplu, “slavik.net/127.0.0.1”)
public String getHostName();
Întoarce o linie , care reprezintă numele host-calculatorului, legat cu obiectul InetAddress.
public boolean equals(Object obj);
Întoarce true, dacă obiectul ce trebuie întors are aceeași adresă-Internet, ca și obiectul primit prin parametrul obj.
public String getHostAddress();
Întoarce o linie , care reprezintă adresa host-calculatorului, legat cu obiectul InetAddress.
public int hashCode();
Întoarce hash codul obiectului chemat.
IP-adresa se găsește într-un set de Servere Cheshate ierarhic. Aceasta înseamnă, că calculatorul nostru local poate ști cum adresa sa proprie, așa și adresele serverelor învecinate într-un format automat reprezentat amestecat “adresa domen/IP-adresa”. Pentru alte nume (adică numele ce nu intră în această grupă) informația despre IP-adrese calculatorul nostru le poate cere de la serverul DNS local. Dacă acest server nu are o adresă specifică, el se poate adresa la un site îndepărtat și să ceară de la acesta această adresă. Astfel de succesiune de cerere a adresei poate să se prelungească pe toată calea până la serverul rădăcină, ce este numit InterNIC-server (adresa lui DNS este – internic.net). acest proces poate ocupa destul de mult timp, așa că este mai rațional de structurat codul în așa mod, ca să cheșăm informația IP-adreselor local, dar să nu le căutăm repetat.
2.6.2 Folosirea URL
Internetul contemporan deja nu mai este orientat pe protocoalele vechi (dar încă le mai susține) ca whois, finger și FTP, el este orientat pe protocoalele sistemei World Wide Web (WWW,Rețeaua globală). Web protocoalele – sunt o cuplare liberă (nu legată) de protocoale a nivelului superior și ale formatelor de fișiere, adunate în Web-brouzer (programul de navigare prin rețea). Un aspect cel mai important a acestei cuplări constă în aceea, că Tim Berners-Lee a inventat o metodă de masștabare a locației tuturor resurselor rețelei. Posibilitatea de a numi sigur totul și oriunde, începe a fi o paradigmă puternică (un principiu unic). Principiul dat este realizat prin locatorul universal de resurse URL, despre care s-a mai vorbit în capitolul 1.
URL ne pune la dispoziție o formă rațională și clară de identificare a informației adresaționale în rețelele Internet. URL-adresele sunt peste tot. Fiecare brouzer le folosește, pentru a identifica Web-informația. În realitate Web-sistema – este una și aceeași , ce era Internetul vechi cu toate resursele lui adresate (cu ajutorul URL) plus HTML fișierele. În interiorul bibliotecii de rețea Java a classelor java.net există și classa URL, care ne pune la dispoziție un interface API scurt și simplu pentru accesul la Internet-informație cu folosirea URL-adreselor.
Iată două exemple de URL-adrese:
http://www.slavik.net/
http://www.slavik.net:80/index.html
Specificația URL după câte știm este bazată pe patru componente.
Primul este – protocolul folosit, ce este despărțit de cealaltă partea locatorului prin două puncte (:). Protocoale unice sunt http, ftp, gopher și file, chiar dacă în ziua de azi totul este efectuat prin protocolul http (practic, majoritatea brouzerelor continuă să lucreze corect, dacă vom șterge “http://” din URL-specificație).
Al doilea component – numele (sau IP-adresa) host-calculatorului folosit, este limitat din dreapta cu slesh unar (/) sau (nu este necesar) cu doua puncte (:).
Al treilea component – numărul portului, este un parametru nu necesar, limitat din stânga (de la numele host-calculatorului) cu două puncte (:), iar din dreapta cu slesh unar (/). (Default se ia portul 80, portul specificat al protocolului HTTP. Astfel inscripția “:80” este de prisos.)
Al patrulea component – calea practică a fișierului.
Fiecare calculator definește un număr de operații care pot fi executate de unitatea sa centrală. Aceste operații sunt în principal destinate memorării sau recuperării informațiilor din memoria internă, calculelor aritmetice sau logice și controlului dispozitivelor periferice. În plus, există un număr de instrucțiuni pentru controlul ordinii în care sunt executate operațiile.
Majoritatea HTTP-Serverelor adaugă la URL-adrese, care se adresează direct la resursa catalogului, fișierul cu numele index.html. Deci, http://www.slavik.net/ – este una și aceeași, ca http://www.slavik.net/index.html.
Java classa URL are câteva constructore, fiecare din care poate arunca excepția MalformedURLException. Forma obișnuită de folosire a constructorului determină URL-ul, ce este identic celui, ce este arătat în lista Address a brouzerului :
Fig.4 Determinarea URL-ului
URL (String urlSpecifier)
Următoarele două forme a constructorilor ne permit să desfacem URL-ul pe elementele componente:
URL (String protocolName,String hostName, int port, String path)
URL (String protocolName, String hostName, String path)
Alt constructor des folosit permite de a folosi URL-ul existent ca un context pointer iar mai apoi de a crea un nou URL din acel context.Chiar dacă aceasta sună puțin nu prea înțeles, dar în realitate totul este destul de simplu și efectiv.
URL (URL urlObj, String urlSpecifier)
Pentru a primi permisuinea către biții practici sau informația despre conținutul classei URL, este necesar de crea obiectul URLConnection și de chemat metoda lui openConnection(), aproximativ astfel:
url.openConnection();
Metoda openConnection() are următoarea formă unică:
URLConnection openConnection()
El întoarce obictul URLConnection, legat de obiectul URL ce-l chiamă, și poate arunca exceptia de tipul IOException.
2.6.3 Classa URLConnection
URLConnection – classa folosirii publice pentru accesul la atributele resursei îndepărtate. Executând legătura cu serverul îndepărtat, se poate folosi URLConnection pentru vizionarea proprietăților obiectului îndepărtat înainte de transportarea lui practică în programul local. Aceste atribute sunt predefinite în specificația HTTP-protocolului și, au sens ca atare doar pentru obiectele URL, care folosesc acest protocol.
Classele URL și URLConnection sunt comode pentru orice program, care doresc să se unească la un HTTP-Server, pentru a extrage conținutul acestora. Dar în realitate pentru aplicațiile mult mai complicate mai bine este de arealiza pachetare proprii sigure, și de încetat cercetarea specificației HTTP-protocolului.
2.7 Socketurile TCP/IP ale Serverelor în Java
Java ne pune la dispoziție un socket-class pentru crearea aplicațiilor Server. Classa ServerSocket este folosit pentru construirea Serverelor, care ascultă programele clientului, fie locale sau îndepărtate pentru a se conecta cu acesta pe portulrile publicate. Dat fiind că Web-sistema foarte activ este folosită în rețelele Internet, în capitolul următor voi arăta cum se poate construi un Web-Server operațional (HTTP-Serverul “SlavikWebServer1.0”).
Classa ServerSocket foarte mult se deosebește de classa normală Socket. Când cream un obiect al classei ServerSocket, el se înregistrează în sistemă, precum că are interes la conectarea clienților. Cunstructorile ServerSocket indică numărul portului, pe care doriți să primiți conectarea, și (după dorință) de ce lungime ar trebui să fie coada pentru portul indicat. Lungimea cozii comunică sistemei, câți conecțiuni ale clienților ea le poate lăsa reținute înainte ce , ea pur și simplu va putea ignora conecțiunea. Valoarea dafault este egală cu – 50. În condiții nefavorabile constructorile pot arunca excepția de tipul IOException. Deci să vedem siganaturile și descrie scurtă a constructorilor classei ServerSocket:
ServerSocket(int port) – Creează socketul serverului pe portul indicat cu lungimea cozii default (50).
ServerSocket(int port,int maxQueue) – Creează socketul serverului pe portul indicat cu lungimea maximală a cozii maxQueue.
ServerSocket(int port,int maxQueue, InetAddress localAddress)- Pe un host-calculator grupal localAddress determină IP-adresa, cu care acest socket este legat.
Classa ServerSocket are o metodă adăugătoare (accept()), care este o chemare de blocare: ea va aștepta clientul, pentru a inițializa conecțiunea, iar mai apoi va întoarce un obiect Socket normal, care se va folosi pentru legătura cu clientul.
.
.
.
.
.
3. DESCRIEREA WEB-SERVERULUI “SlavikWebServer1.0”
În această lucrare de diplomă drept sarcină a fost pusă proiectarea și crearea unui Web-Server, în limbajul de programare orientat pe obiecte Java.
În continuare voi descrie Web-Serverul “SlavikWebServer1.0” care are destul de multe posibilități. Acest Web-Server are posibilitate de cheșare a datelor și poate fi folosit chiar și ca ProxyHTTPServer. El demonstrează socketurile clientului și serverului din Java descrise în capitolul precedent. Web-serverul susține operațiile GET și un diapazon îngust (care poate fi lărgit) de MIME-tipuri strict codate. MIME-tipurile – sunt niște descriptori ale tipurilor de date cu conținut multimedia în documentele poștei electronice. ProxyHTTPServerul – este o sistemă de program, în care fiecare cerere este deservită pe rând, în timp ce celelalte așteaptă deservirea. În elt sunt realizate niște strategii destul de naive de cheșare – el salvează totul și pentru totdeauna în memoria operativă (până la deconectare). Acționând ca ProxyServer, el la fel copie fiecare fișier primit în cheșul local, pentru care nu are nici o strategie pentru regenerare sau strângerea de gunoi , cu aceasta se ocupă altă parte a Web-Serverului. Dacă de lăsat toate aceste discuții la o parte, atunci aceste Web-Server – este un exemplu productiv a socketelor clientului și serverului, ce prezintă un interes mare pentru exploatare și poate fi destul de repede recalificat.
Realizarea acestui Web-Server este reprezentată de cinci classe și o interfață. Majoritatea funcțiilor acestui server sunt realizate în classa cea mai mare httpd, iar celelalte classe, susținătoare și ceva mai mici acționează numai ca structuri de date. Pentru a înțelege cum lucrează acest Web-Server, v-om descrie fiecare classă și metodă mai detaliat (începând cu classele susținătoare și terminând cu programul principal).
3.1 Classa MimeHider
Constructorii . Classul MimeHider este o subclassa a Hashtable, deacea în el este comod de ținut si de căutat perechile cheie/valoare, legate de MIME-data. El are doi constructori. Primul constructor creaza un obiect MimeHider gol fara cheie. Constructorul al doilea ea linia formatata ca MIME-date, și o analizează, pentru a determina conținutul inițial al obiectului.
Metoda parse(). Metoda parse () primește (prin parametrul său) linia MIME-formatului, execută analiza ei sintactică, extrage perechile cheie/valoare și le introduce în exemplarul dat al classei MimeHider. Pentru adesface datele de intrare pe linii individuale, ce se termină cu succesiunea CRLF (\r\n), metoda folosește obiectul de tipul StringTokenizer. Apoi el execută iterațiile peste fiecare linie, folosind succesiunea canonică while… hasMoreTokens()… nextToken(). Metoda parse () desface fiecare linie a MIME-data în două linii, ce sunt separate prin două puncte. Metoda tostring() extrage simbolurile înaintea celor două puncte, după ele și simbolurile spațiale ce urmează și le salvează în două variabile – key (cheia) și val (valoarea). După aceasta se chemă metoda put(), pentru a transmite această asociere a cheiei și valorii obiectului Hashtable.
Metoda toString(). Metoda data (folosește operatorul concatenației liniilor +) – și este inversia metodei parse (). Ea ia perechile curente cheie/valoare, salvate in MimeHider, si intoarce redare lor propozitionala in format MIME,unde dupa chei se introduc doua puncte si un spatiu, iar apoi-valoarea, după care urmează succesiunea CRLF.
Metoda put(), get(), și fix(). Metodele put() și get() în Hashtable ar lucra destul de bine pentru această aplicație, dacă nu un lucru destul de straniu. Specificațiile MIME au determinat câteva chei foarte importante, astfel ca Content-Type și Content-Length. Unele realizări mai devremi a MIME-sistemei, mai ales Web-brouzerele, își permiteau libertăți în ceea ce privește folosirea simbolurilor din registrul superior și inferior în aceste câmpuri. Unii folosesc Content-Type, alții Content-Length. Pentru a evita eșcurile posibile, Web-serverul meu încearcă să converteze toate cheile MimeHider de intrare și ieșire în forma lor canonică Content-Type. Eu eliberez metodele put() și get() de astzfel de transformări și folosesc în calitate de argument al chemării lor metoda fix().
Codul inițial al classei MimeHider se află în Anexa 1.
3.2 Classa HttpResponse
Classa HttpResponse – este pachetarul a tot, ce este legat cu răspunsul de la Web-Server. El este folosit de proxy partea Web-Serverului. Când trimitem cererea pe Web-Server, acesta ne răspunde cu un cod al stării în număr întreg, pe care-l păstrăm în statusCode , și cu echivalentul textual, pe care îl păstrăm în reasonPhrase. (Aceste nume ale variabilelor le-am luat din formulările specificației oficiale HTTP.) După răspunsul uniliniar urmează MIME-data, care conține partea următoare a informației răspunsului. Pentru analiza răspunsului dat folosesc obiectul descris anterior MimeHider , ce se conține în interiorul classei HttpResponse în variabila mh. Toate aceste variabile descrise nusunt declarate private, așa că classa principală httpd le poate folosi direct.
Constructorii .
La crearea obiectului HttpResponse constructorul cu parametrul string primește răspunsul neprelucrat de la WEB-Server și îl transmite in metoda parse() (pentru initializarea obiectului). Iar constructorul alternativ poate transmite metodei parse() codul starii calculat din timp, fraza pricină și MIME-data.
Metoda parse(). Metoda parse() ia datele neprelucrate, care au fost citite de pe WEB-Server, extrage din prima linie a acestor date statusCode (codul stării) și reasonPhrase (fraza pricină), iar din celelalte linii a datelor primite construiește MimeHider-obiectul(in variabila mh).
Metoda toString(). Metoda toString() – inversia metodei parse(). Ea ia valoarea curentă a obiectului HttpResponse și întoarce linia, pe care WEB-Clientul așteaptă s-o primească în calitate de răspuns de la WEB-Server.
Codul inițial al classei HttpResponse se află în Anexa 2.
3.3 Classa UrlCasheEntry
Pentru cheșarea conținutului documentelor pe WEB-Server, trebuie de unit URL-adresa, care se folosea pentru extragerea documentului, și descrierea insăși a documentului. Documentul este descris de MIME-data lui (adică de classa MimeHider) și de datele neprelucrate. De exemplu, afișarea ar putea fi descrisă de către classa MimeHider cu cheia content-Type:image/gif și datele neprelucrate ale imaginii, care sunt un massiv de baiți. Analogic, pagina web va avea perechea cheie/valoare Content-Type:text/html în classa ei MimeHider, în timp ce datele neprelucrate sunt conținutul paginii HTML. Variabilele exemplarului nu sunt indicate private, așa că classa principală httpd poate avea la ele acces direct.
Constructorul . Constructorul obiectului UrlCasheEntry primește (prin parametri) linia URL si MIME-data (in forma String si MimeHider-obiecte). Dacă MimeHider are câmpul cu denumirea Content-Length (în majoritatea cazurilor astfel de câmp este prezent), atunci, pentru a primi așa conținut, regiunea de date aleasă din timp trebuie să fie destul de mare.
Metoda append(). Metoda append() este folosită pentru adăugarea datelor în obiectul UrlCasheEntry. Ea are de afcere cu trei situații. În primul caz bufferul de date nu se împarte deloc. În al doilea – bufferul de date este foarte mic, pentru a conține datele de intrare, așa că el se redefinește. În ultimul caz datele de intrare sunt destul de bine coînțelese și sunt introduse direct în buffer. Mărimea inițială a bufferului de date se cercetează în variabila exemplară length, așa că ea întotdeuna conține datele despre mărimea corectă curentă a bufferului acesta.
Codul inițial al classei UrlCasheEntry se află în Anexa 3.
3.4 Interfața LogMessage
Această interfață simplă definește o singură metodă – log(), care are doar un parametru de tip String. El este folosit pentru a abstractiza (evalua) din clasul principal httpd redarea mesajelor. În cazul aplicației această metodă realizează redarea în forma afișării simple la console (adică scoaterea liniilor de masaje direct la ecran, după linia de comandă). Iar în cazul appletului, datele sunt adăugate în bufferul ferestrei.
Codul inițial al interfeței LogMessage se află în Anexa 4.
3.5 Classa principală httpd
Aceasta este classa principală și cea mai mare, care execută o mulțime de funcții. Deci să-l cercetăm metodă după metodă.
Codul inițial al classei httpd se află în Anexa 5.
Constructorul. Există cinci variabile exemplare principale: port, docRoot, log, cache, și stopFlag, și toate sunt declarate ca private. Trei din ele pot fi inițializate cu ajutorul unicului constroctor din această classă:
httpd(int p, String dr, LogMessage lm)
Constructorul dat initializeaza portul de ascultare, catalogul de extragere a fisierelor, si interfata pentru trimiterea mesajelor.
Variabila exmplară a patra (cache) , este un obiect Hashtable, unde toate fișierele se cheșează în memoria operativă și se inițializează la crearea obiectului. Cu mersul programului dirijează variabila stopFlag.
Partea statică. În această classă sunt câteva variabile statice importante. În variabila version se poate găsi versiunea, transmisă în câmpul Server al MIME-data. Sunt definite câteva constante: mime_text_html – MIME-tipul pentru HTML-fișiere; CRLF – MIME – siccesiunea sfârșitului liniei; indexfile – numele HTML-fișierului, returnat în locul cererilor neprelucrate ale directoriului, și buffer_size – mărimea bufferului, ce este folosit pentru I/O a datelor.
Massivul mt determină lista extensiilor numelor fișierelor și tipurilor-MIME predefinite pentru aceste fișiere. Variabila Hashtable types static este inițializată în blocul următor așa, ca să conțină massivul mt din consecutivitatea cheie și valoare. Metoda fnameToMimeType() poate fi folosită pentru întoarcerea tipului MIME corespunzător pentru fiecare nume de fișier (filename) transmis în ea. Dacă filename nu are nici una din extensiile tabelei mt, metoda fnameToMimeType() returnează defaultExt, sau “text/plain”.
Contoarele statice. După aceea sunt declarate încă cinci variabile exemplare. Ele sunt determinate fără private-modificator, pentru ca monitorul extern să poată viziona aceste valori cu scopul redării lor grafice. (Voi arăta aceste acțiuni mai târziu.) aceste variabile prezintă statistica folosirii Web-Serverului meu. Numărul neprelucrat de apăsări și de baiți se păstrează în hits_served și bytes_served. Numărul fișierelor și baiților, ce se află la momentul actual în cache-memorie, se păstrează în variabilele files_to_cache și bytes_to_cache. În sfârșit , se mai păstrează și numărul apăsărilor, care au fost deservite cu succes din cache în hits_to_cache.
Metoda toBytes(). Metoda de comoditate toBytes() se referă la un tip special de proceduri, ce se numesc "subprograme de comoditate" (convenience routine). Ea converteaza parametrul său String într-un massiv de bytes. Aceasta este necesar fiindcă String-obiectele Java se păstrează ca simboluri Unicode, pe când limbajul public al Internet-protocoalelor, așa ca HTTP, – sunt bine știutul ASCII codul pe 8 biți.
Metoda makeMimeHeader(). Metoda makeMimeHeader() este o metoda pentru comoditate, care este folosita pentru crearea MimeHider-obiectului cu citeva valori cheie introduse. MimeHider-obiectul returnat din aceasta metodă, conține în câmpul Date timpul curent si data, in cimpul WEB-Server – numele si versiunea WEB-Serverului meu, în câmpul Content-Type – parametrul type si in câmpul Content-Length – parametrul length.
Metoda error(). Metoda error() se foloseste pentru formatarea HTML-paginii, ce este transmisa Web-Clientilor, ce au transmis cererea ce nu poate fi finisata cu succes. Primul parametru code, este codul erorii returnate. Drept regulă deobicei ea are codul în diapazonul 400-499. Serverul meu transmite înapoi erorile 404 și 405. El folosește classa HttpResponse, pentru a incapsula codul intoarcerii într-un MIME-data respectiv (MimeHider). Metoda întoarce redarea liniară a răspunsului acesta, legat cu pagina HTML, necesară pentru afișre clientului. Pagina contine versiunea citibila a codului erorii, mesajului (msg) și URL-ul cererii, care a provocat eroarea.
Metoda getRawRequest(). Metoda aceasta este destul de simplă. Citește datele din firul de excuție de intrare, până nu va primi două simboale, unul dupa altul, newline. El caută numai newlinw și ignorează simbolul “\r”. Găsind a doua intrare al newline , ea introduce un massiv de bytes într-un String-obiect și-l returneaza. Ea va intoarce null (pointer gol), dacă firul de executie de intrare nu creaza două simboluri newline, unul după altul înainte de sfârșitul său. Mesajele de la serverul Web și client sunt formatate. Ele se încep cu o linie a stării, după care nimijlocit urmează MIME-data. Sfârșitul MIME-data este separat de cealaltă parte a conținutului cu două simboale newline “\n”.
Metoda logEntry().Metoda logEntry() se folosește pentru crearea dșrii de seama standartă la fiecare cerere a clientului către WEB-Server. Formatul pe care aceasta metoda îl redă corespunde standartului curent pentru fișierele de revistă HTTP. Această metodă are câteva variabile și metode ajutătoare, care sunt folosite pentru formatarea înregistrării datei la fiecare intrare registrațională. Pentru a converta numărul lunii în redarea lui liniară, este folosit massivul liniar months[]. Variabila host este inițiată de HTTP-ciclul principal, când acesta primește conecțiunea de la host-calculatorul dat. Metoda fmt02d() schimbă numerele întregi unare (0,…,9) în forma duală – cu zeroul cap. Apoi linia rezultantă se transmite prin interfața LogMessage variabilei log.
Metoda writeString(). Metoda writeString() este încă o metodă de comoditate. De ea se folosește pentru a ascunde transformarea String-obiectului intr-un byte-massiv (pentru al putea prezenta în formă de fir de execuție de ieșire).
Metoda writeUCE(). Metoda writeUCE() are parametrii de tipul OutputStream și UrlCasheEntry. Ea extrage informația din intrările cache-ului și apoi îi transmite Web-Clientului un mesaj, ce conține codul necesar al răspunsului, MIME-data si conținutul.
Metoda serveFromCache(). Această metodă booleană se străduie de a găsi URL-ul dat în cache. Dacă căutarea este finisată cu succes, atunci conținutul intrarii date a cache-ului i se transmite clientului (cu ajutorul metodei writeUCE()), apoi variabila hits_to_cache se marește cu 1 și programului de chemare i se transmite true. În caz contrar (când căutare eșuiază) i se intoarce false.
Metoda loadFile(). Această metodă primește (prin parametrii de chemare) obiectele de tipul InputStream (pentru firul de excuție de intrare al fițierului), String (pentru URL-ul fișierului corespunzător) și MimeHider (pentru MIME-data a acestui URL). Metoda loadFile() mai întâi crează un obiect nou al classei UrlCasheEntry cu informația, ce se conține în obiectul MimeHider primit. Apoi firul de execuție de intrare se citeste (pe bucăți de mărimea buffer_size bytes) și se adaugă la URL intrarea cache-ului UrlCasheEntry. UrlCasheEntry încărcat astfel este salvat în cache. La sfârsit , se execută reinoirea variabilelor files_in_cache și bytes_in_cache, și UrlCasheEntry obiectul se intoarce in programul de chemare.
Metoda readFile(). Metoda readFile() poate părea insuficientă în comparație cu metoda loadFile(). Însă nu-I chiar așa. Acestă metodă se folosește numai pentru citirea fișierelor, ce se află în afara sistemei locale de fișiere, pe când loadFile() este folosit pentru încărcarea firelor de excuție de orice tip. Dacă obiectul f de tip File există atunci pentru el se crează obiectul InputStream. Determină mărimea fișierului (în variabila file_length) și linia numelui fișierului se aduce la MIME-formă (în variabila mime_type). Apoi ambele variabile sunt folosite pentru crearea MIME-data respectiv (în variabila MimeHider mh). Apoi este chemată metoda loadFile(), pentru a executa citirea practică și cheșarea.
Metoda writeDiskCache(). Metoda writeDiskCache() primește obiectul UrlCacheEntry și-l scrie pe diskul local. Mai întâi aceasta crează (din URL-linie) numele directorului, schimbând sleșul (/) cu simbolurile, ce depind de sistemă (ce sunt păstrate în variabila de tip File sparatorChar). Apoi ea cheamă metoda mkdirs(), pentru a se încredința, că calea de disk locală există pentru URL-ul respectiv. În sfârsit el crează obiectul FileOutputStream, imitând desciderea unui fir de execuție a fișierului de intrare, scrie în el toate datele și-l închide.
Metoda handleProxy(). Metoda handleProxy() determină unul dintre cele două regimuri ale acestui WEB-Server. Ideia principală constă în aceea că: dacă ajustați WEB-Brouzerului dumneavoastra de a folosi acest server ca fiind Proxy-Server, atunci cererile transmise lui, vor include URL-adresa întreagă, de unde operațiile GET normale exclud părțile începătoare (“http://” și numele host-calculatorului). Metoda mea însă, primind (prin parametrul url) URL-ul întreg, găsește succesiunea “://”, sleșul următor (/) și cele două puncte nu neapărate (:) (pentru serverele ce folosesc numere de port nestandarte). După găsirea acestor simboluri ei îi sunt cunoscute host-calculatorul chemat, numărul portului, și URL-adresa unui document, care este necesar de ales de pe server. Apoi ea încearcă încercă să încarce să încarce versiunea documentului prealabil salvată nu din cache-ul operativ propriu. Dacă acțiunea dată se termină cu insucces, atunci se poate încerca da a o încărca din sistema de fișiere în RAM-cache și de repetat îcărcarea din cache. Dacă și aceasta a ieșuat el trebuie să citească acest document de pe site-ul îndepărtat.
Pentru a realiza acest algoritm, metoda deschide un socket (adică organizează o conecțiune nouă) cu site-ul îndepărtat și portul și trimite încolo GET cererea, cerând URL-ul, care ia fost transmis. Ce dată nu va primi de la site-ul îndepărtat, ea va transmite rezultatul clientului. Dacă codul stării în această dată este egal cu 200 (ce semnalează despre transmiterea cu succes a fișierului), atunci metoda citește firul de executie de date ce urmează după data în cache-intrarea nouă UrlCasheEntry și-l înscrie pe socketul clientului. După aceasta metoda cheamă writeDiskCache() , pentru a salva rezultatele acestei transmisiuni pe diskul local. În sfârșit el inregistrează tranzacția (chemând metoda LogEntry()), inchide socketurile și realizeazâ întoarcerea.
Metoda handleGet(). Parametrii metodei handleGet() arată, unde ea să înscrie rezultatele, URL de căutare si MIME-data de la WEB-Brouzer. Acest MIME-data va include linia User-Agent și alte atribute necesare. Mai intâi se incearca de a deservi URL-ul în afara RAM-cache-ului. Eșuând incercarea, metoda se uita in sistemul de fisiere in cautarea fisierului dupa URL-ul lui. Dacă fișierul nu există sau este necitibil WEB-Clientului i se comunică despre eroare. Altfel, el pur si simplu folosește metoda readFile(), pentru a primi conținutul fișierului și de al aloca în cache. Apoi se cheama metoda writeUCE(), pentru a transmite conținutul fișierului socketului clientului.
Metoda doRequest(). Metoda doRequest() se chemă doar odata la fiecare legatură cu WEB-Serverul. Mai întâi el analizează linia cererii și MIME-data ce intră. Dacă în linia cererii este depistată succesiunea “://”, atunci ea cheamă metoda handleProxy(), altfel este chemată handleGet(). Dacă în cerere sunt indicate metode, inegale cu GET, de exemplu, HEAD sau POST, atunci subprograma returnează clientului eroarea cu codul 405. HTTP cererea este , însă, ignorată dacă variabila stopFlag are valoarea true.
Metoda run(). Metoda run() se cheamă atunci, când se startează firul de execuție a WEB-Serverului. El crează o legatură nouă (obiectul ServerSocket) pe portul dat, intra intr-un ciclu infinit, ce cheama metoda accept() pe socketul serverului, iar mai apoi transmite Socket-obiectul rezultant la prelucrare în metoda doRequest().
Metoda start()și stop().Metodele start() si stop() sunt folosite pentru pornirea si respectiv stoparea procesului WEB-Serverului. Ele inițializeaza valoarea variabilei stopFlag.
Metoda main(). Aceste metode main() si log(), permit pornirea aplicației date din linia de comandă. El inițiază parametrul LogMessage, pentru ca să fie singur server, iar mai apoi pune la dispoziție afișarea simplă la ecran cu ajutorul metodei log().
Fig.5
3.6 Interfața grafică
Pentru afi mai comod de lucrat cu acest Web-server, iam realizat o oarecare interfață grafică care este destul de simplă și înțeleasă. Ia conține bară de meniu în care se conține toată informația necesară.
Pentru a proteja administratorul de încercarea cuiva de a intra nesanctionat pe Web-server și de al porni la startarea acestuia apre fereastra de dialog care vă invită să introduceți parola de acces:
Fig.6 Introducerea parolei
Dacă parola (știută doar de administrator se presupune) a fost introdusă corect atunci în fața dumneavoastră va apărea ceva de felul acesta (în dependență de sistemul de operare):
Fig.7 Interfața grafică
Dacă ceva nu este clar pentru administrator, în meniul principal al programului sunt toate indicațiile privind lucrul cu procesul Web-serverului.
4. PROTECȚIA MUNCII
Lucrul în domeniul protecției muncii în timpul de față urmărește una din cele mai importante direcții în domeniul ocrotirii sănătății și ușurarea condițiilor de muncă prin introducerea tehnologiilor noi și automatizarea producerii, înlăturarea muncii manuale pe regiunile dăunătoare ceea ce pozitiv se reflectă asupra sănătății oamenilor.
Sub noțiunea de protecție a muncii (PM) înțelegem un sistem de acte legislative, social-economice, tehnice, igienice și măsuri curativo-profilactice, care asigură securitatea, sănătatea oamenilor în procesul de producție. Asigurarea protecției muncii se realizează cât la proiectarea proceselor de producție, atât și la procesul de realizare a lor. Direcția tranșantă de îmbunătățire a condițiilor de muncă este trecerea la noi tehnologii avansate cu un înalt grad de protecție a muncii.
Protecția muncii este asigurată prin conducerea procesului de producție după standardele de protecție a muncii, normele igienice, instrucții pentru protecția muncii. Importanța tot mai majoră în asigurarea protecției muncii o capătă conducerea după sistemul standardelor de securitate a muncii (SSSM). În standarde sunt formulate cerințele de protecție față de procesele de producție, utilaj, producția industrială, mijloace de protecție individuală a lucrătorilor, sunt stabilite normele și cerințele față de parametrii care caracterizează zgomotul, vibrația, ultrasunetul, impurificarea aerului, protecția electrică și antiincendiară.
Cu problemele de protecție a muncii este legată și organizarea științifică a muncii, care ia în considerație crearea condițiilor bune de lucru, folosirea îmbrăcămintei speciale, instrumentelor de muncă speciale etc.
Metodele de protecție a muncii sunt compuse din cercetarea condițiilor de lucru în acela timp și a proceselor tehnologice, a utilajului, a încăperii de producție, analiza cazurilor accidentale și a bolilor profisionale. Măsurile legate de crearea condițiilor de protecție în procesul muncii la întreprinderi se efectuiază în mod planificat. Ele sunt concretizate în urma semnării contractului colectiv dintre administrație și comitetul sindical local. Aceste măsuri conțin trei parți: măsuri pentru prevenirea bolilor profesionale, măsuri pentru prevenirea cazurilor accidentale, măsuri pentru îmbunătățirea condițiilor de muncă.
Conducerea cu protecția muncii este însărcinată cu îndeplinirea următoarelor funcții:
Determinată de formarea organelor de conducere a protecției muncii, coordonarea și organizarea lucrărilor în domeniul protecției muncii, reglamentarea obligațiilor și ordinii de interacțiune a persoanelor care sunt antrenate în conducere, primirea și realizarea hotărârilor (conducerea totală și răspunderea pentru starea protecției muncii este lăsată pe seama directorului; coordonarea lucrărilor pentru protecția muncii se îndeplinește sub conducerea inginerului principal). Organizarea nemijlocită a protecției muncii la întreprinderi este pusă pe seama secțiilor (birouri) pentru protecția muncii, inginerilor de protecția muncii.
Pregătirea organizării lucrului la întreprinderi pentru crearea condițiilor sănătoase de lucru a muncitorilor, preîntâmpinarea cazurilor accidentale în procesul producerii și a bolilor profisionale (pentru aceste probleme răspunderea totală este pe seama secției protecției muncii).
Printre problemele de bază pe care le rezolvă secția de protecție a muncii mai sunt: îmbunătățirea organizării măsurilor pentru protecția muncii, introducerea ideilor noi în domeniul protecției muncii, efectuarea controlului situației protecției muncii la întreprinderi.
Problemele administrației secției și maiștrilor de producere sunt:
asigurarea bunăstării utilajului, sculelor, mijloacelor de transport, îngrădirilor, organizarea corectă a locurilor de muncă, controlul lucrărilor, dacă acestea se conduc de instrucții în activitatea sa, efectuarea la timp a instructajului persoanelor noi angajate.
Controlul nivelului protecției muncii este îndreptat la verificarea condițiilor de muncă a muncitorilor, la determinarea abaterilor de la standardele (SSSM), normele și legile controlului de stat și a altor documente normative a protecției muncii, controlul îndeplinirii de către servicii și subunități a obligațiunilor în domeniul protecției muncii, la primirea hotărârilor efective pentru înlăturarea neajunsurilor.
Formele de bază de control pot fi: controlul operativ a șefului sau a altor conducători, controlul social-administrativ (cu trei nivele), controlul efectuat de serviciile de protecție a muncii la întreprindere, controlul efectuat de organele superioare, controlul efectuat de organele de control statal și inspecția tehnică a muncii.
Controlul social-administrativ se îndeplinește la trei nivele. La primul nivel de control maistrul și inspectorul social pentru protecția muncii în fiecare zi controlează, înainte de începerea lucrului, securitatea la locurile de muncă.
La nivelul doi de control, în fiecare săptămână conducătorul secției și inspectorul social superior pentru protecția muncii, împreună cu tehnologul, mecanicul și energeticianul secției controlează nivelul securității muncii în secție.
La nivelul trei de control, în fiecare lună inginerul principal a uzinei și inspectorul principal cu atragerea specialiștilor întreprinderii (mecanicul principal, energeticianul principal, tehnologul principal) fac controlul condițiilor și protecției muncii la întreprindere în general, verifică eficacitatea controlul de nivelurile întâi și doi.
4.1 Analiza condițiilor de muncă , tehnica securității
Cerințele de bază a protecției muncii, necesare la proiectarea mașinelor și mecanizmelor sunt sicuritatea omului, fiabilitatea și comoditatea în expluatarea. Securitatea instalațiilor de producere se asigură prin alegerea corectă principiilor de funcționare a lui, schemelor cinematice, parametrilor funcționale și tehnologice a proceselor, folosirii diferitor mijloace de protecție. Ultimii trebuie să fiu introduși în instrucții de folosire. În cazul existenței la agregate motoarelor electrice, el trebuie să fie conficționat conform regulilor destinate componenții sistemelor electrice. Trebuie să fiu prevăzute mijloacele de protecție contra câmpurilor electromagnetice și electrice, impurificarii atmosferei cu: gaze, aburi, praf etc.
Influența câmpurilor electromagnetice de mare intensitate asupra omului constă în absorbția de către țesuturile corpului uman a energiei, însă influența principală îi revine câmpului electric. Nivelul de influență a câmpurilor electromagnetice asupra omului depinde de frecvență, de puterea emisiei, de durata acțiunii, de regimul de emisie (prin impulsuri sau continuu), și de asemenea de proprietățile individuale ale organismului. Influența câmpului electric de frecvență joasă provoacă dereglări în activitatea funcțională a sistemului cardio-vascular, și chiar la schimbări privind componența sângelui.
Influența câmpului electromagnetic de frecvență înaltă se reflectă sub forma efectului termic, care duce la ridicarea temperaturii corpului, la supraîncălzirea locală a țesuturilor corpului și a organelor cu o termoreglare slabă. Ca rezultat unii lucrători suferă din cauză insomniei, simt dureri în regiunea inimii, dureri de cap, ușor obosesc.
O mare importanță pentru funcționarea titulară a instalațiilor au dispozitive de control și măsurare și dispozitivelor de reglare și de dirijare. Locul de muncă și dispozitive de muncă trebuie să se proiecteze luând în vedere capacități fiziologici și psihologici a omului. E necesar de a organiza posibilitatea înregistrării rapide și corecte datelor dispozitivelor de măsurare șu control și dispozitivelor de reglare și de dirijare.
Lucrarea de diplomă, care prevede diagnosticarea și testarea funcționării titulare a aparatului M/D3 cu aparate destinate testării, a fost îndeplinită în laboratorul de cercetări științifice a catedrei de microelectronică a Universității Tehnice din Moldava, într-o încăpere cu suprafața de 75 m2 și volumul de 260 m3 și în care au lucrat 10 persoane, cărora le revine o suprafață mai mare ca norma sanitară prevăzută pentru un om (norma de un om fiind de 15 m3 și 4,5 m2).
Condițiile de muncă sanitaro-igienice sunt determinate de următorii factori: temperatura aerului, umeditate, viteza fluxului de aer, iluminare, ventilare.
În laborator sunt îndeplinite lucrări fără surplus de căldură. Reișind din STAS 12.1.005-88, care determină condițiile optimale și condițiile meteorologice admisibile pentru zona de lucru în laborator, în perioada caldă și rece a anului (temperatura aerului se menține în limita de 22-24˚C, viteza fluxului de aer nu este mai mare de 0.1 m/s și umiditatea relativa de 40-60 %).
Pentru locurile de muncă este folosită iluminarea naturală laterală cât și iluminarea artificială. Ziua, în caz dacă lumina naturală nu satisface normele, este adăugată și cea artificială, astfel încât putem avea iluminare combinată. Iluminarea naturală și artificială este reglamentată de normele de construcție și producere (CNCP 2-4-79).
În calitate de mărime normată pentru iluminarea naturală se folosește coeficientul de luminozitate naturală, pentru iluminarea artificială – mărimea luminozității minimale.
În general, în urma analizei condițiilor sanitar-igienice și a factorilor de producție dăunători și periculoși, putem face concluzia, că condițiile de lucru în ‘laboratorul de cercetări științifice’ a catedrei de microelectronică sunt satisfăcătoare, iar colaboratorii lui nu sunt supuși acțiunii factorilor de producție ce ar putea provoca apariția diferitor boli profesionale.
4.2 Noțiuni despre electrotraumatism
Acțiunea dăunătoare asupra oamenilor curentului electric, câmpului electric și static se manifestă prin electrotraumatizm și bolile profesionale. În corespundere cu STAS 12.1.009-76 electrotraumatizm eveniment care se caracterizează prin totalitatea electrotraumelor, adică traumelor provocate de acțiunea curentului electric sau de arcul electric. Oamenii ce au suferit electrotraumă sunt predispuse la bolile ce necesit tratament medical de lungă durată, iar aproximativ 12% din ele devin invalizi.
Urmările electrocutării depind de un șir de factori. Factorul de bază îl constituie amplituda și durata acțiunii curentului electric a sura corpului uman. Pentru curent alternativ cu frecvența de 50Hz și durata acțiunii 1s au loc următoarele:
0,6…1,5 mA – curentul de prag, care provoacă exitarea ușoară ;
10…15 mA – curentul de prag, care provoacă contracția mușchilor, care nu dă posibilitatea omului de a se elibera sinestăcător de la curentul. Parcurgerea curentului prin corpul omului pe un parcus de timp îndelungat este periculoasă pentru viață;
25…50 mA – curentul provoacă contracția mușchilor respiratori, este posibilă moartea de la înnădușire;
100 mA și mai mult – curent mortal.
Curentul direct este in 4 – 5 ori mai puțin periculos de cît curent alternativ de frecvența de 50 Hz. La creșterea frecvenței peste 1kHz pericolul electrocutării se micșorează. Urmările electrocutării depind și de drumul parcurs de curent prin omul. Cel mai periculos drum este “măna piciorul” sau “măna măna”. Rezistența corpului uman depinde de mai mulși factori așa ca: starea pielei, amplituda, stării fizice și psihice etc; și poate să varieze în limitele largi. În cazul folosirii curentului de 50Hz pentru calcule rezistența omului se socoate de 1kΩ. Amplituda tensiunei aplicate de asemenea influiențează asupra urmărilor electrocutării.
Conform STAS 12.1019-79 electrosecuritatea trebuie să fie asigurată de: construcția instalațiilor electrice; mijloace tehnice de protecție, festivități organizaționale și tehnice.
4.3 Calcularea protecției “legarea la nul”
Legarea la nul este o măsură de protejare a omului de electrocutare prin deconectarea strictă și rapidă a rețelei în caz de apariție a tensiunii pe carcasă (străpungerea izolației). Deconectarea strictă se efectuează, dacă curentul de scurt circuit format prin faza și firul nul este destul de mare pentru că declanșatorul să funcționeze corect. Firul nul de protecție se socoate firul care unește părțile legate la nul cu punctul neutral împămîntat a bobinei tensiunii curentului sau cu echivalentul ei. Legarea la nulul se folosește în rețele până la 1000V.
Legarea la nulul transformă scurtcircuitul la carcasa în scurtcircuit monofazic în rezultatul căruia reacționează protecția maximală a curentului care selectiv deconectează regiunea defectat de la reția.
Controlul legării la nulul: dispozitiv legat la nulul se controlează înainte de al introduce în expluatare și periodic în procesul funcționării și după reparație. Pentru măsurarea rezistenței “faza – nulul” se poate de folosit oarecare dispozitiv de măsurare a rezistenții de montaj (MC – 08, M372 ș.a.).
unde ISCP – curentul de scurtcircuit la pământ,
ISC – curentul de scurcircuit.
Scopul calculării instalației “legarea la nul” – determinarea secțiunii firului nul, care satisface condiție funcționării protecției maximale de curent. Valoarea protecției se determină după puterea instalației electrice protejate (expluatate).
Curentul de scurtcircuit trebuie să depășască valoarea curentului de protecție conform cerniților ПЭУ (pentru siguranțe IS.C.In, unde In curentul nominal al siguranței). Modul de calculare este următorul:
Alegem raza firului nul și fazic egală cu 4,5mm pentru puterea transformatorului de 750kW și calculăm suprafața secțiunii firului fazic și nul
Calculăm rezistențile firelor fazic și nul
unde RF,RN,LF,LN – lungimea și secțiunea firului fazic și nul corespunzător; ρ – rezistența electrică specifică ρCu=0,018 Ω·mm2/m, ρAl=0,028 Ω·mm2/m.
Se calculează rezistența circuitului “faza – nul”
unde RF – rezistența activă a firului fazic, Ω; RN – rezistența activă a firului nul, Ω; XC – rezistența inductivă a rețelei “faza-nul” și pentru rețele cu tensiune joasă (până la 1000V) și firele din cupru și aluminiu ea să neagă, deci XC este foarte misă și nu se e în considerație.
Calculăm curentul de scurtcircuit
unde ZT/3 – coeficientul de rezistență transformatorului și este egal cu 0,0364 pentru puterea transformatorului 750kW.
Comparăm valoarea curentului de scurtcircuit cu valoarea curentului nominal al siguranței.
Deci diametrul firelor este ales corect.
Măsuri antiincendiare
Laboratorul de cercetări științifice în care s-au efectuat lucrările, corespunde după pericolul de incendiere categoriei B, reieșind din normele de construcție și producere (pericolul de explozie și incendiu).
Cauza incendiului în laborator poate fi ieșirea din funcțiune a aparatelor sau dispozitivelor. De asemenea, o cauză a incendiului poate fi și suprasolicitarea echipamentelor.
Pentru a micșora probabilitatea incendiului în laborator trebuie să ne conducem de următoarele principii: de a controla bunăstarea echipamentului electric, de a controla bunăstarea izolației, folosirea siguranțelor.
În caz de incendiu este necesar de a deconecta dispozitivele de la rețea. Pentru stingerea incendiului se folosește extinctorul OY-5, care se află în laborator.
În concordanță cu normele de construcție și producere (NCP-2-80) încăperea se referă la primul nivel antiincendiar, deoarece construcția sub acțiunea focului nu arde și nu fumegă.
Posibilitatea de lichidare rapidă a incendiului este în mare măsură determinată de informarea la timp despre incendiu. O metodă răspândită de informare este legătura telefonică. Dar, una dintre cele mai certe sisteme de informare este totuși semnalizarea electrică incendiară (SEI).
Pentru informarea despre incendiu se folosesc stații radio cu unde scurte, care funcționează într-o rază de 45km.Ele sunt înregistrate în automobilile pompierilor.
Caracteristicile condițiilor sanitar-igienice și ale factorilor de producție dăunători și periculoși.
Tab.2
Factorii condițiilor de muncă
5.PROIECTAREA TEHNICO-ECONOMICĂ A PROIECTULUI
5.1 Situația generală
Lucrul cu Web-Serverele moderne elaborate cu ajutorul diferitor instrumentarii Soft este destul de dificil mai ales în cazul când numărul de clienți și de fișiere accesate în sistemul dat este destul de mare. De obicei elaborarea unui astfel de algoritm pentru eficiența lucrului Web-Serverului, efectuat fără utilizarea unor instrumentarii, tehnici specializate durează mult timp (până la câteva luni) și este strict individual pentru fiecare caz aparte. În final rar se obține o versiune a algoritmului care să nu includă careva erori sau să poată prelucra necesarul cererilor rulate în seansul specific de lucru.
Proiectul calculat și precăutat este elaborat utilizând modele și metode programabile optimizate. El poate fi utilizat în cele mai diverse ramuri: de la sisteme de rețea locale (rețele de calculatoare universitare, școlare, corporative, linii tehnologice) și până la unități de accesare din sfera socială globală.
Din aceste raționamente am recurs la proiectarea și elaborarea Web-Serverului “SlavikWebServer1.0” și implementarea lui practică într-o astfel de rețea care ar fi destul de aglomerată, dat fiind faptul că el permite realizarea unui set foarte larg de probleme. Astfel, Web-Serverul posedă o posibilitate de a fi utilizat în cele mai diverse ramuri a economiei naționale, ce-i permite să fie socotit ca un instrument de rețea foarte eficace.
Prin utilizarea unei tehnici sigure și a mijloacelor soft moderne se micșorează cheltuielile pentru întreținerea tehnică, care frecvent sunt comesurabile sau chiar depășesc cheltuielile necesare procurării computerilor și programelor soft.
Cercetările asupra algoritmului studiat și elaborat întră în categoria lucrărilor experimentale și de producere. Organizarea și petrecerea optimă a Lucrărilor Experimentale și de Producere (LEP) permite ridicarea calității și eficienței producției. În acest capitol am prezentat partea organizatorică a lucrărilor petrecute și aprecierea lor economică.
Lucrarea de diplomă conține nuanțe atât de lucrări de cercetări științifice cît și de lucrări de producere experimentală.
LEP conține următoarele etape generale:
elaborarea și concordarea sarcinii tehnice;
colectarea și studierea materialelor referitor la tema dată;
elaborarea sarcinii tehnice;
calculul cheltuielilor pentru LEP;
designul sarcinii tehnice;
argumentarea economică;
elaborarea antiproiectului;
elaborarea principiilor de rezolvare a sarcinii;
elaborarea structurilor principale;
elaborarea și testarea modelelor posibile;
documentarea proiectului;
elaborarea proiectului tehnic;
elaborarea modelului algoritmului;
controlul tehnologic;
argumentarea proiectului tehnic.
Elaborarea documentației pe algoritmul experimental:
elaborarea documentației textuale;
calculul cheltuielilor pe materiale.
5.2 Etapele de proiectare
La elaborarea lucrării s-a aplicat un algoritm bine întemeiat, în scopul micșorării timpului de lucru. Succesiunea acestui algoritm este următoarea:
Pregătirea pentru descrierea sarcinii.
Familiarizarea cu descrierea sarcinii.
Elaborarea algoritmului.
Scrierea programului conform schemei-bloc elaborate.
Depănarea programei.
Pregătirea documentației conform sarcinii.
Cheltuielile de muncă depuse pentru realizarea acestui proiect se calculează după formula :
t = to + tf + ta + ts + td + tdoc
to – cheltuielile de timp obținute la pregătirea pentru descrierea sarcinii.
tf – cheltuielile de timp obținute la familiarizarea cu descrierea sarcinii.
ta – cheltuielile de timp obținute la elaborarea algoritmului.
ts – cheltuielile de timp obținute la scrierea programului conform schemei-bloc elaborate.
td – cheltuielile de timp obținute la depănarea programei.
tdoc – cheltuielile de timp obținute la pregătirea documentației conform sarcinii.
Cheltuielile de timp pentru familiarizarea cu descrierea sarcinii, ținând cont de calificarea programatorului:
Tf=Q*B/(85*k)
Unde: Q=qc(1+p) numărul convențional de instrucțiuni în program
q – numărul de operatori. Numărul de operatori este de 1500. Estimarea acestui număr s-a efectuat cu ajutorul conducătorului de diplomă.
c – coeficient de complexitate (c =1.8, deoarece complexitatea programului este puțin dificilă).
p – coeficient de corecție a programului în timpul elaborării. Deoarece problema a fost discutată la începutul elaborării softului, schimbările adăugătoare au fost minime (p = 0.05).
B – coeficientul majorării cheltuielilor de lucru în urma insuficienței descrierii problemei. Deoarece cheltuielile utilizate pentru finisarea programului au fost puțin mai mari, acest coeficient este egal cu 1.8.
k– coeficientul de calificare a programatorului (k = 0.8, deoarece stajul de lucru e pînă la 2 ani).
Q=1500*1,8*(1+0,05)=2835
Tf= 2835*1,8/(85*0,8)=75,04
Cheltuielile de timp pentru elaborarea algoritmului:
Ta=Q/22*k=2835/(22*0,8)=161,07
Cheltuielile de timp pentru scrierea programului conform schemei-bloc elaborate:
Ts=Q/23*k=2835/(23*0,8)=154,07
Cheltuielile de timp pentru depănarea programei
Td=Q/4,3*k=2835/(4,3*0,8)=824,13
Cheltuielile de timp pentru pregătirea documentației conform sarcinii
Tdoc=Tm+Tr=Q/(19*k)+0,75*Q/(19*k)=1,75*2835/(19*0,8)=326,4
Deoarece am lucrat asupra programului câte 9 ore pe zi, rezultă că timpul de lucru Tlucru se v-a calcula în felul următor :
tzi = 9 ore/zi ;
t = to + tf + ta + ts + td + tdoc = 14+75,04+161,07+154,07+824,13+326,4 = 1554,71.
Tlucru= t / tzi= 1554,71 / 9 =172 zile
5.3 Etapele cercetării științifice.
În general efectuarea lucrărilor de cercetare științifică include următoarele etape:
Lucrările pregătitoare. La această etapă se face cunoștință cu direcțiile și natura lucrărilor de cercetare științifică, studierea experienței anterioare în domeniile corespunzătoare de cercetarea și motivarea tehnico-economică preventivă.
Etapa se încheie cu întărirea sarcinii tehnice.
Prelucrarea teoretică a temei. Aici se efectuează alegerea și motivarea direcției alese de cercetare și metodele de rezolvare a problemelor formulate, elaborarea ipotezelor de lucru, calculele teoretice, elaborarea metodicii cercetărilor experimentale.
Faza experimentală. La etapa dată se efectuează proiectarea, implimentarea, depanarea și montarea machetei. Etapa se finalizează cu efectuarea experimentelor, prelucrarea datelor obținute și verificarea lor cu rezultatele cercetărilor teoretice.
Faza perfecționării teoretice. La această etapă se realizează un șir de lucrări ce țin de corectarea părții teoretice în conformitate cu rezultatele obținute din experiență.
Faza finală. Etapa se caracterizează prin generalizarea rezultatelor cercetărilor efectuate, se elaborează darea de seamă pentru lucrarea de cercetare științifică, se determină eficacitatea reală a ei. Etapa se finalizează cu acordarea și întărirea rezultatelor cercetării la consiliul tehnico-științific.
Pentru cercetarea unor probleme complicate se utilizează o metodă complexă, care se bazează pe analiza în complex a proceselor și scopurilor din problema pusă. Metoda mai presupune și elaborarea unui scop, necesită determinări a fluxului de intrare și ieșire a informației, introducerea criteriilor de optimizare. Mai ales sunt importante metodele de modelare, care permit studierea proceselor complexe într-un regim de analiză preliminară.
5.4 Evaluarea economică a proiectului
Aprecierea economică a proiectului constă în determinarea eficienței așteptate a utilizării rezultatelor cercetării. Pentru determinarea eficienții economice este necesar de calculat cheltuielile pentru efectuarea cercetărilor. Unul din capitolele, care se include în planul de cheltuieli este “Materialele și semifabricatele procurate”. Denumirea materialelor, prețul lor și cantitatea necesară sânt date în tabelul 5.1. De asemenea aici se includ și cheltuielile de transport, luate ca 10% din suma totală a prețurilor materialelor.
Tab.3
Materialele și semifabricatele procurate
Mărimea salariilor lunare pentru diplomant și conducătorul diplomei au fost stabilite la 250.00 lei și 650.00 lei respectiv. Mai jos, conform timpului de lucru vom calcula salariile respective pe toată durata cercetării.
S(C) == 827,3 (lei);
S(D) == 1954,6 (lei);
unde:
Nzl – numărul de zile lucrate.
Conform datelor calculate anterior Nzl(D) = 172.
Deoarece consultațiile oferite de către conducătorul diplomei aveau loc în primele 20 săptămâni o dată pe săptămână și în ultimele 4 săptămâni de două ori, rezultă că Nzl(C) = 28.
Nzlt – numărul de zile lucrătoare într-o lună.
Sl – salariile lunare.
Tab.4
Prezentarea salariilor de bază
Salariile suplimentare constituie 12% din salariile de bază.
Tab.5
Prezentarea salariilor suplimentare
Defalcările în fondul social de asigurare sunt calculate în procente de la salariul lunar și cel suplimentar, și constituie 31% :
(2781,8+333,83) * 31% = 965,85 (lei)
În cheltuielile pentru elaborarea softului dat mai intră și cheltuielile legate de folosirea calculatorului. Calculatorul este mediul principal, cu ajutorul căruia s-a realizat proiectul de diplomă.
t = (ta + ts + td + tdoc )/9 = (161,07+154,07+824,13+326,4)/9 =163 (zile)
Așadar, conform etapelor de proiectare calculatorul a fost utilizat pe o perioadă de 163 zile, timp în care s-au desfășurat o serie de activități. Deoarece procurarea soft-ului și hard-ului în domeniul Tehnologiilor Informaționale este considerată investiție capitală, vom amortiza aceste cheltuieli timp de 2 ani, fiindcă aceste produse sunt supuse uzurii morale rapide. Să calculăm cheltuielile de energie electrică:
Ec = P C N
unde:
Ec – suma de bani cheltuită pentru energia folosită;
P – Puterea de lucru a calculatorului;
C – prețul (costul) unui kwatth;
N – numărul de ore.
Luând în considerație că am lucrat 9 ore pe zi atunci N =163 9= 1467(ore)
Ec = P C N = 0,4 0.65 1467 = 381,4 (lei)
Norma de amortizare constituie 30% din costul calculatorului, care este de 6500 lei, iar imprimanta 3250 lei.
Amortizarea calculatorului și a imprimantei se calculează conform formulei:
Acalculator= 6500*0.3*163/365 = 870,8 (lei)
Aimprimanta= 3250*0.2*163/365 = 290,3 (lei)
Tab.6
Cheltuieli pentru hard
Cheltuielile folosite pentru utilizarea calculatorului includ amortizarea și cheltuielile de energie, 1542,5 lei.
În timpul realizării sarcinii vor apărea cheltuielile suplimentare. Aceste cheltuieli sunt legate de gestionare, deservire, remunerarea muncii aparatului de conducere, cheltuieli legate de repararea încăperilor de producție, a inventarului, protecția muncii și a mediului ambiant etc.
Mărimea cheltuielilor de regie constituie 140% de la salariul de bază și cel suplimentar:
3115.63140% = 4361,9(lei)
În continuare se vor estima toate cheltuielile suportate pentru elaborarea softului. Ele vor include următoarele cheltuieli:
Cheltuieli pentru materiale .
Cheltuieli pentru salariul de bază.
Cheltuieli pentru salariul suplimentar.
Defalcări în fondul social.
Cheltuieli pentru arenda calculatorului.
Cheltuieli de regie.
Tab.7
Cheltuieli suportate pentru elaborarea programului
Tab.8
Estimarea prețului programului
5.5 Determinarea eficienței economice a proiectului
Aflăm rata profit – vînzări:
Din rezultatele obținute se vede că utilizarea proiectului este argumentată economic, iar beneficiul obținut este de 1454,3 lei (Republica Moldova). În cazul măririi numărului de cereri a acestui soft, la vânzarea lui va fi necesar de inclus numai cheltuielile de multiplicare care sunt foarte mici comparativ cu costul lui. În rezultat vom obține un supraprofit, ceea ce ar fi foarte rentabil pentru programator. Dar mai luând în considerație lansarea proiectului pe plan mondial profitul poate deveni imprevizibil, ceia ce ar duce la sporirea bunăstării cum a programatorului așa și a companiei de sprigin.
CONCLUZIE
Având ca scop major de a crea un Web-Server scris în Java și de a organiza lucrul acestuia prin mijloace Internet și intranet, acest proiect a fost implementat în rețeaua locală, pentru testare. Însă la general a stat problema de a crea un program accesibil, cu ajutorul diferitor mașini, ce lucrează pe diferite platforme operaționale. La implementarea acestui program este necesar de utilizat tehnlogia de securitate SSL (Secure Socket Layer), care asigură securitatea transmiterii informației.
Fiind destinat proiectul pentru lucrul pe diferite Sisteme de Operare, și anume pe cele folosite cel mai frecvent de utilizatorii mondiali, am atins scopul din plin, creând un Web-Server scris totalmente în limbajul de programere orientat pe obiecte JAVA2 și efectuând implementarea lui în rețeaua locală și globală. Problema independenței de platformă a fost depășită cu succes cum sa observat în procesul testării, pe calculatoarele ce rulau în sistemele de operare UNIX, Windows și Linux.
Web-Serverele scrise totalmente în Java, în lumea rețelei globale Internet fiind încă slab aplicate, la investițiile necesare va fi posibil de a le implementa din plin, creând din timp condiții necesare pentru lucrul pe piața mondială.
Am menționat că anul trecut multe companii mondiale sau încadrat în lumea Web-Serverelor. Acest lucru s-a dovedit a fi foarte avantajos, economisind sume enorme de bani, în primul rând din cauza excluderii din piață a agențiilor, care necesită cheltuieli destul de mari. În prezența investițiilor corespunzătoare și înțelegerea din plin a avantajului ce se află în fața Web-Serverelor scrise totalmente în Java pe viitor va fi posibilă lărgirea posibilității implementării a astfel de proiecte în rețeaua globală.
Un merit deosebit în crearea proiectului îi aparține produsului Sun Microsystems JSDK 1.3. Fiind un sistem de proiectare a programelor scrise în JAVA2 destul de puternic și avantajos.
BIBLIOGRAFIE
1. Дж.Вебер . Технология JAVA в подлиннике . QUE Corporation, 1996, "BHV-Санкт-Петербург", 2000
П.Ноутон, Г.Шилдт . JAVA2 -Наиболее полное руководство.- McGraw-Hill, 1999, Санкт-Петерсбург: BHV, 2001
Майкл Томас, Пaтpик Пател, Алан Хадсон, Доналд Болл (мл.) Секреты программирования для Internet на Java.- Ventana Press, Ventana Communications Group, U.S.A., 1996, Издательство "Питер Пресс", 1997
Аарон И.Волш Основы программирования на Java для World Wide Web.- IDG Books Worldwide,Inc., 1996, Издательство "Диалектика", 1996
Майкл Эферган Java: справочник.- QUE Corporation, 1997, Издательство "Питер Ком", 1998
Джейсон Мейнджер Java: Основы программирования.- McGraw-Hill,Inc., 1996, Издательская группа BHV, Киев, 1997
Documentația Sun Microsystems pe JSDK 1.3 și JAVA2.
Internet site-urile folosite :
http://www.sun.com
http://www.pencom.com
http://freebooks.narod.ru
http://softdev.omskreg.ru
http://jp.yo.lv
http://www.ugatu.ac.ru
ANEXE
Anexa 1 Codul sursă a classei de susținere MimeHider
/**
* @author Tsaranu Veaceslav Nicolae
* @version 1.0
*/
import java.util.*;
class MimeHider extends Hashtable {
void parse(String data) {
StringTokenizer st=new StringTokenizer(data,"\r\n");
while(st.hasMoreTokens()) {
String s=st.nextToken();
int colon = s.indexOf(':');
String key=s.substring(0,colon);
String val=s.substring(colon+2);
put(key,val);
}
}
MimeHider(){}
MimeHider(String d){
parse(d);
}
public String toString() {
String ret="";
Enumeration e=keys();
while(e.hasMoreElements()) {
String key=(String)e.nextElement();
String val=(String)get(key);
ret+=key+": "+val+"\r\n";
}
return ret;
}
// Aceasta functie simpla converteaza MIME-linia din orice
// forma de capitalizare in forma canonica.
private String fix(String ms){
char chars[]=ms.toLowerCase().toCharArray();
boolean upcaseNext=true;
for(int i=0;i<chars.length-1;i++) {
char ch=chars[i];
if(upcaseNext && 'a'<= ch && ch<='z'){
chars[i]=(char)(ch-('a'-'A'));
}
upcaseNext=ch=='-';
}
return new String(chars);
}
public String get(String key){
return (String)super.get(fix(key));
}
public void put(String key,String val){
super.put(fix(key),val);
}
}
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Anexa 2 Codul sursă a classei de susținere HttpResponse
/**
* @author Tsaranu Veaceslav Nicolae
* @version 1.0
*/
import java.io.*;
class HttpResponse {
int statusCode
String reasonPhrase
MimeHider mh;
static String CRLF="\r\n";
void parse(String request){
int fsp=request.indexOf(' ');
int nsp=request.indexOf(' ',fsp+1);
int eol=request.indexOf('\n');
String protocol=request.substring(0,fsp);
statusCode=Integer.parseInt(request.substring(fsp+1, nsp));
reasonPhrase=request.substring(nsp+1,eol);
String raw_mime_header=request.substring(eol+1);
mh=new MimeHider(raw_mime_header);
}
HttpResponse(String request){
parse(request);
}
HttpResponse(int code, String reason, MimeHider m) {
statusCode=code;
reasonPhrase=reason;
mh=m;
}
public String toString() {
return "HTTP/1.0" + statusCode + " " + reasonPhrase + CRLF + mh + CRLF;
}
}
Anexa 3 Codul sursă a classei de susținere UrlCasheEntry
/**
* @author Tsaranu Veaceslav Nicolae
* @version 1.0
*/
class UrlCasheEntry {
String url;
MimeHider mh;
byte data[];
int length=0;
public UrlCasheEntry(String u,MimeHider m) {
url=u;
mh=m;
String cl=mh.get("Content-Length");
if(cl != null) {
data=new byte[Integer.parseInt(cl)];
}
}
void append (byte d[], int n) {
if(data==null){
data=new byte[n];
System.arraycopy(d, 0, data, 0, n);
length=n;
}else if(length+n>data.length) {
byte old[]=data;
data=new byte[old.length+n];
System.arraycopy(old, 0, data, 0, old.length);
System.arraycopy(d, 0, data, old.length, n);
} else {
System.arraycopy(d, 0, data, length, n);
length += n;
}
}
}
Anexa 4 Codul sursă a interfeței LogMessage
/**
* @author Tsaranu Veaceslav Nicolae
* @version 1.0
*/
interface LogMessage {
public void log(String msg);
}
Anexa 5 Codul sursă a classei principale httpd
/**
* Classul principal care realizeaza WEB-Serverul 'SlavikWebServer 1.0'
* @author Tsaranu Veaceslav Nicolae
* @version 1.0
*/
import java.net.*;
import java.io.*;
import java.text.*;
import java.util.*;
class httpd implements Runnable, LogMessage {
private int port;
private String docRoot;
public LogMessage log;
private Hashtable cache=new Hashtable();
private boolean stopFlag;
String stop;
String user;
private static String version="1.0";
private static String mime_text_html="text/html";
private static String CRLF="\r\n";
private static String indexfile="index.html";
private static int buffer_size=10192;
static String mt[]={
"txt", "text/plain",
"html",mime_text_html,
"htm","text/html",
"gif","image/gif",
"class","application/octet-stream",
"jpg","image/jpg",
"jpeg","image/jpg"
};
static String defaultExt="txt";
static Hashtable types=new Hashtable();
static {
for(int i=0;i<mt.length;i+=2)
types.put(mt[i],mt[i+1]);
}
static String fnameToMimeType (String filename) {
if(filename.endsWith("/"))
return mime_text_html;
int dot=filename.lastIndexOf('.');
String ext=(dot>0)?filename.substring(dot+1):defaultExt;
String ret=(String)types.get(ext);
return ret != null ? ret: (String) types.get(defaultExt);
}
//variabilele date reprezinta statistica folosirii WEB-Serverului meu.
int hits_served=0;
int bytes_served=0;
int files_in_cache=0;
int bytes_in_cache=0;
int hits_to_cache=0;
private final byte toBytes(String s)[] {
byte b[]=s.getBytes();
return b;
}
private MimeHider makeMimeHeader (String type, int length) {
MimeHider mh=new MimeHider();
Date curDate=new Date();
TimeZone gmtTz=TimeZone.getTimeZone("GMT");
SimpleDateFormat sdf=new SimpleDateFormat("dd MMM yyyy hh:mm:ss zzz");
sdf.setTimeZone(gmtTz);
mh.put("Date",sdf.format(curDate));
mh.put("WEB-Server","SlavikWebServer/"+version);
mh.put("Content-Type",type);
if(length>=0)
mh.put("Content-Length",String.valueOf(length));
return mh;
}
private String error(int code,String msg,String url){
String html_page="<body>"+CRLF+"<h1>"+code+" " + msg + "</h1>"+CRLF;
if(url != null)
html_page += "Error when fetching URL: "+url+CRLF;
html_page += "</body>"+CRLF;
MimeHider mh=makeMimeHeader (mime_text_html, html_page.length());
HttpResponse hr=new HttpResponse (code,msg,mh);
logEntry("GET",url,code,0);
return hr+html_page;
}
//Citeste 'in', pina nu vor fi primite doua simboale \n in propozitie.
//Reseteaza toate simbolurile \r.
private String getRawRequest(InputStream in)
throws IOException {
byte buf[]=new byte[buffer_size];
int pos=0;
int c;
while ((c=in.read()) != -1) {
switch(c) {
case '\r':
break;
case '\n':
if(buf[pos-1]==c) {
return new String(buf,0,pos);
}
default:
buf[pos++]=(byte) c;
}
}
return null;
}
static String months[]= {
"Ian","Feb","Mar","Apr","Mai","Iunie",
"Iul","Aug","Sep","Oct","Noe","Dec"
};
private String host;
/**
* Aceasta metoda preface cifrele intregi unare(0,..,9) in forma dubla – cu 0 conducator.
*/
//fmt02d este echivalentul C functiei printf("%02d",i)
private final String fmt02d(int i) {
if(i<0) {
i=-i;
return ((i<9) ? "-0" : "-")+i;
}
else {
return ((i<9) ? "0" : "")+i;
}
}
private void logEntry (String cmd, String url, int code, int size) {
Calendar calendar=Calendar.getInstance();
int tzmin=calendar.get(Calendar.ZONE_OFFSET)/(60*1000);
int tzhour=tzmin/60;
tzmin -= tzhour*60;
log.log(host+"–["+
fmt02d(calendar.get(Calendar.DATE))+"/"+
months[calendar.get(Calendar.MONTH)]+"/"+
calendar.get(Calendar.YEAR)+":"+
fmt02d(calendar.get(Calendar.HOUR))+":"+
fmt02d(calendar.get(Calendar.MINUTE))+":"+
fmt02d(calendar.get(Calendar.SECOND))+":"+
fmt02d(tzhour)+fmt02d(tzmin)+"] /"+
cmd+" "+
url+" HTTP/1.0\" "+
code+" "+
size+"\n");
user=(host+"–["+
fmt02d(calendar.get(Calendar.DATE))+"/"+
months[calendar.get(Calendar.MONTH)]+"/"+
calendar.get(Calendar.YEAR)+":"+
fmt02d(calendar.get(Calendar.HOUR))+":"+
fmt02d(calendar.get(Calendar.MINUTE))+":"+
fmt02d(calendar.get(Calendar.SECOND))+":"+
fmt02d(tzhour)+fmt02d(tzmin)+"]");
hits_served++;
bytes_served += size;
}
private void writeString(OutputStream out,String s)
throws IOException {
out.write(toBytes (s));
}
private void writeUCE(OutputStream out, UrlCasheEntry uce)
throws IOException {
HttpResponse hr=new HttpResponse(200, "OK" , uce.mh);
writeString(out, hr.toString());
out.write(uce.data, 0, uce.length);
logEntry("GET", uce.url, 200, uce.length);
}
private boolean serveFromCache (OutputStream out, String url)
throws IOException {
UrlCasheEntry uce;
if((uce=(UrlCasheEntry)cache.get(url)) != null) {
writeUCE(out, uce);
hits_to_cache++;
return true;
}
return false;
}
private UrlCasheEntry loadFile (InputStream in, String url, MimeHider mh)
throws IOException {
UrlCasheEntry uce;
byte file_buf[]=new byte[buffer_size];
uce=new UrlCasheEntry(url, mh);
int size=0;
int n;
while ((n=in.read(file_buf)) >= 0) {
uce.append(file_buf, n);
size += n;
}
in.close();
cache.put(url, uce);
files_in_cache++;
bytes_in_cache += uce.length;
return uce;
}
private UrlCasheEntry readFile(File f, String url)
throws IOException {
if(!f.exists())
return null;
InputStream in=new FileInputStream(f);
int file_length=in.available();
String mime_type=fnameToMimeType(url);
MimeHider mh=makeMimeHeader(mime_type, file_length);
UrlCasheEntry uce=loadFile(in, url, mh);
return uce;
}
private void writeDiskCache (UrlCasheEntry uce)
throws IOException {
String path=docRoot+uce.url;
String dir=path.substring(0,path.lastIndexOf("/"));
dir.replace('/',File.separatorChar);
new File(dir).mkdirs();
FileOutputStream out=new FileOutputStream(path);
out.write(uce.data, 0, uce.length);
out.close();
}
//Clientul trimite serverului chemare in forma urmatoare:
//http://the.internet.site/the/url
//Serverul se pregateste sa primeasca chemarea de pe site si s-o intoarca…
private void handleProxy(OutputStream out, String url, MimeHider inmh){
try {
int start=url.indexOf("://")+3;
int path=url.indexOf('/',start);
String site=url.substring(start,path).toLowerCase();
int port=80;
String server_url=url.substring(path);
int colon=site.indexOf(':');
if(colon>0) {
port=Integer.parseInt(site.substring(colon+1));
site=site.substring(0,colon);
}
url="/cache/"+site+((port != 80) ? (":"+port) : "")+server_url;
if(url.endsWith("/"))
url += indexfile;
if(!serveFromCache(out, url)) {
if(readFile(new File(docRoot+url), url) !=null) {
serveFromCache(out, url);
return;
}
//Daca aceasta pagina deja nu a fost chesata, de deschis
//socket-legatura cu portul site-ului si de-i trimis GET-comanda.
//Serverul schimba "user-agent" pentru introducerea ai lui…
Socket server=new Socket(site,port);
InputStream server_in=server.getInputStream();
OutputStream server_out = server.getOutputStream();
inmh.put("User-Agent",inmh.get("User-agent")+
" via JavaCompleteReferenceProxy/"+version);
String req ="GET"+server_url + "HTTP/1.0" + CRLF + inmh+CRLF;
writeString(server_out, req);
String raw_request=getRawRequest(server_in);
HttpResponse server_response=new HttpResponse(raw_request);
writeString(out, server_response.toString());
if(server_response.statusCode==200) {
UrlCasheEntry uce=loadFile(server_in, url, server_response.mh);
out.write(uce.data, 0, uce.length);
writeDiskCache(uce);
logEntry("GET", site+server_url, 200, uce.length);
}
server_out.close();
server.close();
}
}catch (IOException e) {
log.log("Exception: "+e);
}
}
private void handleGet(OutputStream out, String url, MimeHider inmh) {
byte file_buf[]=new byte[buffer_size];
String filename=docRoot+url+(url.endsWith("/") ? indexfile : "");
try {
if(!serveFromCache(out,url)) {
File f=new File(filename);
if(!f.exists()) {
writeString(out, error(404, "Not Found", filename));
return;
}
if(!f.canRead()) {
writeString(out, error(404, "Permission Dinied", filename));
return;
}
UrlCasheEntry uce=readFile(f, url);
writeUCE(out, uce);
}
}catch (IOException e) {
log.log("Exception: "+e);
}
}
private void doRequest(Socket s) throws IOException {
if(stopFlag)
return;
InputStream in=s.getInputStream();
OutputStream out=s.getOutputStream();
String request=getRawRequest(in);
int fsp=request.indexOf(' ');
int nsp=request.indexOf(' ', fsp+1);
int eol=request.indexOf('\n');
String method=request.substring(0, fsp);
String url=request.substring(fsp+1, nsp);
String raw_mime_header=request.substring(eol+1);
MimeHider inmh=new MimeHider(raw_mime_header);
request=request.substring(0,eol);
if(method.equalsIgnoreCase("get")) {
if(url.indexOf("://") >= 0) {
handleProxy(out, url, inmh);
}else {
handleGet(out, url, inmh);
}
}else{
writeString(out, error(405, "Method Not Allowed" , method));
}
in.close();
out.close();
}
public void run() {
try {
ServerSocket acceptSocket;
acceptSocket=new ServerSocket(port,50);
while (true) {
Socket s=acceptSocket.accept();
host=s.getInetAddress().getHostName();
doRequest(s);
s.close();
}
}catch (IOException e) {
log.log("accept loop IOException: "+e+"\n");
}catch (Exception e) {
log.log("Exception: "+e);
}
}
private Thread t;
public synchronized void start() {
stopFlag=false;
if(t==null) {
t=new Thread(this);
t.start();
}
}
public synchronized void stop() {
stopFlag=true;
log.log("WEB-Serverul STOPAT: "+new Date()+"\n");
stop=("WEB-Serverul STOPAT: "+new Date()+"\n");
}
public httpd(int p, String dr, LogMessage lm) {
port=p;
docRoot=dr;
log=lm;
}
public static void main(String args[]){
httpd h=new httpd(80,"c://www", null);
h.log=h;
h.start();
try {
Thread.currentThread().join();
}catch(InterruptedException e){}
}
public void log(String m){
System.out.print(m);
}
}
Anexa 6 Accesarea informației prin sistemul Client-Server în Java
.
.
.
.
.
Anexa 7 Schema de prelucrare a cererii clientului de către Web-server.
Anexa 8 Descrierea schematică a proiectului “SlavikWebServer1.0”
Anexa 9 Accesarea informației cu ajutorul a “SlavikWebServer1.0”
Anexa 10 Schema rulării independente de platformă și Securității a proiectului “SlavikWebServer1.0”
Anexa 11 Schema bloc generală a programului proiectului “SlavikWebServer1.0”
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Proiectarea Si Crearea Unui Web Server (ID: 148805)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.