Mecanismul de acțiune al sistemului de operare UNIX prizelor - General - Sisteme de operare - Articole Directory - atelier de fier
Mecanismul de UNIX Sockets
Mecanismul de prize (prize) a apărut pentru prima dată în versiunea 4.3 BSD UNIX (UNIX Distribution Software Berkeley - filiala UNIX, a început să se dezvolte la UC Berkeley). Mai târziu, el a devenit unul dintre cele mai populare sisteme, mesaje de rețea. Astăzi, acest mecanism este pus în aplicare în mai multe sisteme de operare, este uneori menționată ca Berkeley Sockets, omagiind fondatorilor săi, cu toate că există un număr mare de implementări sale pentru diferite sistem UNIX, precum și pentru alte sisteme de operare, cum ar fi sistemele de operare Windows, în cazul în care este numit Sockets windows (WinSock).
Mecanismul de soclu oferă o interfață de mesagerie convenabilă și destul de universal pentru dezvoltarea rețelei de aplicații distribuite. Versatilitatea oferă următorul concept.
Mecanismul de soclu de mesaje oferă următoarele primitivele sunt implementate ca apeluri de sistem.
s = soclu (domeniu, tipul, protocol)
Procesul trebuie să creeze o priză înainte de al utiliza. apel sistem Socket creează un nou socket cu parametrii care definesc domeniul de comunicare (domeniu), tipul de conexiune susținută de soclu (tip) și protocolul de transport (de exemplu, TCP sau UDP), care se va menține conexiunea. În cazul în care protocolul de transport nu este specificat, sistemul selectează automat protocolul corespunzător tipului de soclu. Domeniul Notă determină valorile posibile ale celorlalți doi parametri. apel sistem returnează un descriptor de socket creat de soclu, care este folosit ca identificator priză în operațiunile ulterioare.
bind (s. adr. addrlen)
- Cerere pentru a stabili o conexiune la o priză la distanță:
conectați (s, server_addr. server_addrlen)
- Se așteaptă solicitarea de a stabili o conexiune:
asculta (e. backlog)
- Adoptarea cererii de conectare:
snew = accepta (s. client_addr. client_addr1en)
- Trimiterea unui mesaj pe o conexiune existentă:
scrie (s. mesaj, msgjen)
msg_len lungimea mesajelor, stocate într-un mesaj tampon, trimis destinatarului, care este conectat la priza de pre-s.
- Primirea unui mesaj de pe o conexiune existentă:
Mbytes = citit (snew, tampon, cantitate)
Un mesaj care sosesc prin mufa snew care conectat anterior expeditorului este primit la dimensiunea buffer-ului din suma tampon. Dacă nu există mesaje, procesul de primire a blocat.
- Trimiterea de mesaje fără a stabili o conexiune:
sendto (s. mesaj, receiver_address)
- Primirea mesajelor fără a stabili o conexiune:
Suma = recvfrom (s, mesajul, SENDER_ADDRESS)
Luați în considerare utilizarea de apeluri de sistem mecanism soclu pentru organizarea de comunicare între cele două noduri.
Pentru a face schimb de mesaje scurte, care nu necesită livrare de încredere și ordine, este recomandabil să se utilizeze apeluri de sistem care nu necesită o conexiune. Fragment programului Procesul de trimitere ar putea arata astfel:
s = soclu (AF_INET SOCKJJGRAM.0.):
bind (s, sender_addr, sender_addrlen):
sendto (s, mesajul, receiver_addr);
Prin urmare, pentru beneficiarul procesului:
s = soclu (AF_INET, SOCK_DGRAM, 0);
bind (s receiver_addr, receiver_addrlen.):
Suma = recvfrom (s, mesaj, sender_addr):
AF_INET constantă specifică faptul că schimbul se efectuează în comunicarea domeniului de Internet, și SOCK_DGRAM constantă definește regimul de schimb datagramă fără a stabili o conexiune. Alegerea protocolului de transport este lăsată la latitudinea sistemului.
Dacă este necesar să se organizeze schimbul de mesaje cu un mod sigur de a comanda, fragmente ale programelor vor fi după cum urmează.
s = soclu (AF_INET SOCK_STREAM.0.);
conectați (s, server_addr, server_addrlen);
wrlte (s, mesajul, msgjen);
wrlte (s, mesajul, msgjen);
s = soclu (AFJNET SOCKJTREAM.0.):
bind (s, server_addr, server_addrlen);
snew - accepta (e c11ent_addr, cl1ent_addrlen.);
Nbytes = citit (snew, tampon, cantitate);
Nbytes = citit (snew, tampon, cantitate);
Remote Procedure Call
Un alt mecanism convenabil, facilitând interacțiunea sistemelor de operare și a aplicațiilor în rețea, un mecanism de apel de procedură la distanță (Remote Procedure Call, RPC). Acest mecanism este construit pe partea de sus a sistemului de operare de schimb de mesaje, astfel încât, în unele cazuri, permite mai convenabil mod transparent și de a organiza programe de rețea de cooperare, dar utilitatea nu este universală.
Remote Procedure Call Concept
Ideea de la distanță apelul de procedură este de a spori bine-cunoscute și înțelese de cei mecanism de transmitere a datelor și de control în cadrul unui program care rulează pe o mașină, pentru a transfera controlul și date prin intermediul rețelei. Soluții RPC sunt proiectate pentru a facilita organizarea de calcul distribuit. Mecanismul RPC este implementat pentru prima dată compania Sun Microsystems, și el este în bună concordanță cu motto-ul „de rețea - un calculator“, pentru a lua compania în funcțiune cât mai aproape de programare de rețea locală. RPC cea mai mare eficiență se realizează în acele aplicații în care există o comunicare interactivă între componente de la distanță, cu un timp de răspuns mic și o cantitate relativ mică de date transmise. Astfel de aplicații sunt cunoscute ca RPC-orientate.
Caracteristicile sunt apelul de procedură locală:
- asimetrie - o parte a comunicării este de a iniția o colaborare;
- sincronicitate - executarea apelantului este blocat de la solicitarea emiterii și reluată numai după revenirea din procedura numita.
RPC următoarele diferențe de apel local este că utilizează întotdeauna sistemul de mesaje de bază, dar acest lucru nu ar trebui să fie văzut în mod clar în orice definiție a procedurilor sau a procedurilor propriu-zise. Distanța introduce provocări suplimentare. Executarea apelantului și procedura locală numită în aceeași mașină vândută într-un singur proces. Dar, în punerea în aplicare a RPC implică cel puțin două procese - una în fiecare mașină. Dacă unul dintre ei sa prăbușit, pot apărea următoarele situații:
- un accident cauzat de apelant la distanță proceduri devin „orfani“;
- O terminare anormală a procedurilor la distanță sunt „procedura de apel părinților nevoiași, care va fi în zadar să se aștepte un răspuns de la procedura de la distanță.
În plus, există mai multe probleme asociate cu eterogenitatea limbaje de programare și medii de operare: structurile și procedurile de apel de date structură acceptate în orice limbaj de programare una care nu este acceptată în exact același mod ca și în alte limbi.
Luați în considerare modul în care tehnologia RPC care sta la baza multor sisteme de operare distribuite, rezolvă aceste probleme.
Pentru a înțelege activitatea RPC, să ne ia în considerare în primul rând punerea în aplicare a unei proceduri de apel local la un computer independent. Să-l, de exemplu, se va scrie date într-o procedură de fișier:
Aici fd - un descriptor de fișier, un număr întreg, buf - pointer la o serie de caractere, lungime - lungimea de matrice, număr întreg.
Decizia cu privire la care mecanismul este folosit pentru transmiterea parametrilor, dezvoltatorii au adoptat limba. Uneori depinde de tipul de date transmise. În limbajul C, de exemplu, numere întregi, și alte date scalare este întotdeauna trecut prin valoare, și matrice - link-ul.
Figura 9.6 ilustrează parametrii de transmisie ale procedurii numite: stiva înaintea scrierii apelului (a), stiva în timpul procedurii (b), stiva la revenirea la programul apelant (a).
Ideea care stă la baza RPC, este de a apela o procedură la distanță, dacă este posibil privit ca un apel de procedură locală. Cu alte cuvinte, este necesar să se facă mecanism RPC este transparent pentru programator: apelantul nu are nevoie să știe că procedura este numit pe o altă mașină, și vice-versa.
Mecanismul RPC realizează transparența urmează. În cazul în care procedura numită într-adevăr este la distanță, într-o altă versiune a procedurii, numit clientul Stabia (- cioturi cioturi) procedurile pentru punerea în aplicare a bibliotecii locale în locul codului de procedură original este plasat. Pe computerul la distanță, care acționează ca o procedură de server, a pus codul original al procedurii numit, precum și un alt ciot numit server de Stabia. Atribuirea de client și server stub - pentru a organiza transferul parametrilor procedurii numit și returnează valoarea procedurii prin intermediul rețelei, în timp ce codul procedură originală, plasată pe un server trebuie să fie pe deplin menținută. Ciorne utilizate pentru a transmite date prin intermediul rețelei de mesagerie subsistemului, care este disponibil în primitivele OS trimite și primi. Uneori, subsistemul de mesaje a lansat un modul software care organizează ștuțurile de conexiune cu primitivele de mesagerie, numit modulul RPCRimtime.
Această operație se numește de ambalare parametrii de funcționare. După aceea, stub clientul se referă la trimitere primitivă pentru a trimite mesajul la computerul la distanță, care este plasat pe punerea în aplicare a procedurii inițiale. După ce a primit un mesaj de la rețea, computerul la distanță nucleul sistemului de operare solicită stub server care extrage din parametrii de mesaje și solicită procedura inițială în modul obișnuit. Pentru a primi un ciot server de mesaje trebuie să sune mai întâi primi primitiv, nucleul cunoscut pentru care a fost raportat. Stub server de despachetează opțiunile de apel disponibile în raport, și în mod obișnuit este procedura inițială, care trece parametrii de pe stivă. După încheierea procedurii de server cioturi pachete rezultatul funcționării într-un nou mesaj si folosind send primitiv ./ „transmite un mesaj prin rețea către client Stabu, și returnează convențional„Zoom rezultat format și de a controla procedura de asteptare. Procedurile care nu provoacă „numita procedură de ra sau original, nu schimbă faptul că au început să lucreze pe computere diferite.