Remediere: serviciul „Apel de procedură la distanță (RPC)” nu pornește. Apel de procedură la distanță (rpc) Acces de la distanță rpc

Apel de procedură la distanță (RPC) Concept de apel de procedură la distanță

Ideea din spatele apelului de procedură la distanță (RPC) este de a extinde mecanismul bine cunoscut și bine înțeles pentru transferul de control și date într-un program care rulează pe o singură mașină pentru a transfera controlul și datele pe o rețea. Facilitățile de apel de la distanță sunt proiectate pentru a facilita organizarea calculelor distribuite. RPC este cel mai eficient în aplicațiile în care există o comunicare interactivă între componentele de la distanță cu timpi de răspuns rapid și un transfer de date relativ mic. Astfel de aplicații sunt denumite orientate spre RPC.

Apelurile de procedură locală se caracterizează prin:

Asimetria, adică una dintre părțile care interacționează este inițiatorul; Sincronicitatea, adică execuția procedurii de apelare atunci când se oprește din momentul emiterii cererii și reia numai după revenirea din procedura apelată.

Implementarea apelurilor la distanță este semnificativ mai complexă decât implementarea apelurilor de procedură locală. Pentru început, întrucât apelantul și procedura apelată sunt executate pe mașini diferite, acestea au spații de adresă diferite și acest lucru creează probleme la trecerea parametrilor și a rezultatelor, mai ales dacă mașinile nu sunt identice. Deoarece RPC nu poate conta pe memoria partajată, aceasta înseamnă că parametrii RPC nu trebuie să conțină indicatori către locații de memorie care nu sunt stive și că valorile parametrilor trebuie copiate de la un computer la altul. Următoarea diferență RPC dintr-un apel local este că folosește în mod necesar sistemul de comunicație subiacent, dar acest lucru nu trebuie văzut în mod explicit nici în definiția procedurilor, nici în procedurile în sine. Depărtarea introduce probleme suplimentare. Executarea programului apelant și a procedurii locale apelate pe aceeași mașină se face într-un singur proces. Dar există cel puțin două procese implicate în implementarea RPC - unul pe fiecare mașină. Dacă unul dintre aceștia se blochează, pot apărea următoarele situații: dacă procedura de apelare se blochează, procedurile apelate la distanță vor deveni „orfane” și dacă procedurile la distanță se termină anormal, apelanții vor deveni „părinți privați” de apelanți, așteptați degeaba un răspuns de la procedurile la distanță.

În plus, există o serie de probleme asociate cu eterogenitatea limbajelor de programare și a mediilor de operare: structurile de date și structurile de apel de procedură acceptate într-un singur limbaj de programare nu sunt acceptate în același mod în toate celelalte limbaje.

Acestea și alte probleme sunt rezolvate de tehnologia RPC răspândită care stă la baza multor sisteme de operare distribuite.

Operațiuni de bază RPC

Pentru a înțelege cum funcționează RPC, luați în considerare mai întâi executarea unui apel de procedură locală pe o mașină convențională care rulează autonom. De exemplu, să fie un apel de sistem

Count = citit (fd, buf, nbytes);

unde fd este un număr întreg,
buf este o serie de caractere,
nbytes este un număr întreg.

Pentru a efectua apelul, procedura de apelare împinge parametrii în stivă în ordine inversă (Figura 3.1). După terminarea apelului de citit, acesta împinge valoarea de returnare într-un registru, mută adresa de returnare și returnează controlul la procedura de apelare, care scoate parametrii din stivă, revenind la starea inițială... Rețineți că în C, parametrii pot fi numiți fie prin referință (după nume), fie prin valoare (după valoare). În ceea ce privește procedura numită, parametrii valorii sunt variabile locale inițializabile. Procedura apelată le poate modifica fără a afecta valoarea originalelor acestor variabile în procedura de apelare.

Dacă un indicator către o variabilă este trecut la o procedură apelată, atunci o modificare a valorii acestei variabile prin procedura apelată are ca rezultat o modificare a valorii acestei variabile și pentru procedura apelantă. Acest fapt este esențial pentru RPC.

Există, de asemenea, un alt mecanism de trecere a parametrilor, care nu este utilizat în limbajul C. Se numește apel cu copiere / restaurare și constă în necesitatea copierii program de apelare variabile în stivă ca valori și apoi copiate înapoi după efectuarea apelului peste valorile originale ale procedurii de apelare.

Depinde de proiectanții de limbă să decidă ce mecanism de trecere a parametrilor să utilizeze. Uneori, depinde de tipul de date transferate. În C, de exemplu, numărul întreg și alte date scalare sunt întotdeauna trecute prin valoare, iar matricile sunt întotdeauna transmise prin referință.

Orez. 3.1. a) Stiva înainte de efectuarea apelului citit;
b) Stiva în timpul executării procedurii;
c) Stivați după revenirea la programul de apelare

Ideea din spatele RPC este de a face un apel de procedură la distanță să pară cât mai aproape de un apel de procedură locală. Cu alte cuvinte, faceți RPC transparent: apelantul nu trebuie să știe că procedura apelată se află pe o altă mașină și invers.

RPC realizează transparența în felul următor. Când procedura apelată este într-adevăr la distanță, în loc de procedura locală, o altă versiune a procedurii numită stub client (stub) este plasată în bibliotecă. La fel ca procedura originală, stub-ul este invocat utilizând secvența de apelare (ca în Figura 3.1) și apare o întrerupere la accesarea nucleului. Doar spre deosebire de procedura inițială, nu introduce parametri în registre și nu solicită kernel-ului pentru date, ci generează un mesaj pe care să-l trimită la kernel-ul mașinii la distanță.

Pași de execuție RPC

Interacțiunea componentelor software în timpul executării unui apel de procedură la distanță este ilustrată în Figura 3.2. După ce clientul stub a fost apelat de programul client, prima sa sarcină este de a umple tamponul cu mesajul trimis. Pe unele sisteme, stub-ul clientului are un buffer unic, cu lungime fixă, care este umplut de la început de fiecare dată când sosește o nouă solicitare. Pe alte sisteme, un buffer de mesaje este un pool de buffere pentru câmpuri de mesaje individuale, dintre care unele sunt deja pline. Această metodă este adecvată în special atunci când pachetul este într-un format format din un numar mare câmpuri, dar valorile multora dintre aceste câmpuri nu se schimbă de la apel la apel.

Parametrii trebuie apoi convertiți în formatul corespunzător și introduși în bufferul de mesaje. În acest moment, mesajul este gata pentru a fi trimis, astfel încât se efectuează o întrerupere a apelului kernel.

Orez. 3.2. Apel procedură la distanță

Când nucleul câștigă controlul, comută contextul, salvează registrele procesorului și o hartă de memorie (descriptori de pagină) și configurează o nouă hartă de memorie care va fi utilizată pentru a rula în modul nucleu. Deoarece contextul nucleului și al utilizatorului sunt diferite, nucleul trebuie să copieze mesajul exact în propriul spațiu de adresă, astfel încât să îl poată accesa, să rețină adresa de destinație (și, eventual, alte câmpuri de antet) și trebuie să îl transmită și rețelei. interfață. Aceasta finalizează activitatea din partea clientului. Temporizatorul de transmisie este activat, iar nucleul poate fie să sondeze ciclic pentru un răspuns, fie să treacă controlul către planificator, care alege un alt proces de executat. În primul caz, executarea interogării este accelerată, dar nu există multiprogramare.

Pe partea de server, biții de intrare sunt plasați de hardware-ul de recepție, fie într-un buffer încorporat, fie în RAM... Când se primesc toate informațiile, se generează o întrerupere. Handlerul de întrerupere verifică corectitudinea datelor pachetului și determină care stub ar trebui să-i fie transmis. Dacă niciunul dintre butoane nu așteaptă acest pachet, gestionarul trebuie fie să-l tamponeze, fie să îl arunce cu totul. Dacă există un buton în așteptare, mesajul este copiat pe acesta. În cele din urmă, se efectuează un comutator de context, în urma căruia registrele și harta de memorie sunt restaurate, luând valorile pe care le aveau în momentul în care butonul a efectuat apelul de primire.

Acum, butonul de server începe să funcționeze. Acesta despachetează parametrii și îi împinge în mod corespunzător pe teanc. Când totul este gata, se efectuează un apel server. După finalizarea procedurii, serverul trimite rezultatele către client. Pentru aceasta, se efectuează toți pașii descriși mai sus, numai în ordine inversă.

Figura 3.3 arată secvența de comenzi care trebuie executate pentru fiecare apel RPC, iar Figura 3.4 arată cât din timpul total de execuție RPC este petrecut executând fiecare dintre cele 14 etape descrise. Cercetarea a fost efectuată pe o stație de lucru multiprocesor DEC Firefly și, deși prezența a cinci procesoare a afectat în mod necesar rezultatele măsurătorilor, histograma prezentată în figură oferă o imagine de ansamblu asupra procesului de execuție RPC.

Orez. 3.3. Pașii procedurii RPC

Orez. 3.4. Alocarea timpului între 14 etape de execuție RPC

1. Apelați butonul

2. Pregătiți tamponul

3. Parametrii pachetului

4. Completați câmpul de titlu

5. Calculați suma de controlîn mesaj

6. Întrerupeți până la bază

7. Coada de pachete pentru execuție

8. Trimiterea unui mesaj către controler prin intermediul QBUS

9. Timp de transmisie Ethernet

10. Obțineți un pachet de la controler

11. Procedura de manipulare a întreruperii

12. Calcularea sumei de control

13. Comutarea contextului la spațiul utilizatorului

14. Executarea unui stub de server

Conectare dinamică

Luați în considerare întrebarea cu privire la modul în care clientul specifică locația serverului. O metodă pentru rezolvarea acestei probleme este utilizarea directă a adresei de rețea a serverului în programul client. Dezavantajul acestei abordări este inflexibilitatea sa extremă: când serverul este mutat, sau când numărul serverelor este crescut sau când interfața este schimbată, în toate aceste și multe alte cazuri, este necesar să recompilați toate programele care au folosit un alocarea dură a adresei serverului. Pentru a evita toate aceste probleme, unele sisteme distribuite folosesc ceea ce se numește legare dinamică.

Punctul de plecare pentru legarea dinamică este definiția formală (specificația) serverului. Specificația conține numele serverului de fișiere, numărul versiunii și o listă a procedurilor de servicii furnizate de acest server pentru clienți (Figura 3.5). Pentru fiecare procedură, este dată o descriere a parametrilor săi, indicând dacă acest parametru este de intrare sau de ieșire în raport cu serverul. Unii parametri pot fi atât de intrare, cât și de ieșire - de exemplu, o serie care este trimisă de client către server, modificată acolo și apoi returnată clientului (operație de copiere / restaurare).

Orez. 3.5. Specificații server RPC

Specificația formală a serverului este utilizată ca intrare într-un program generator de stub care creează atât stub-uri client, cât și server. Apoi, acestea sunt plasate în bibliotecile corespunzătoare. Când programul utilizator (client) apelează orice procedură definită în specificațiile serverului, se asociază procedura corespunzătoare de stub cod binar programe. La fel, atunci când este compilat un server, stuburile serverului sunt asociate cu acesta.

Când serverul pornește, prima sa acțiune este de a transfera interfața serverului program special denumit liant. Acest proces, cunoscut sub numele de proces de înregistrare a serverului, implică trimiterea de către server a numelui, a numărului de versiune, a identificatorului unic și a unui descriptor pentru locația serverului. Descriptorul este independent de sistem și poate fi IP, Ethernet, X.500 , sau altceva. adresa, și poate conține și alte informații, cum ar fi autentificarea.

Când clientul apelează una dintre procedurile de la distanță pentru prima dată, de exemplu, citește, stub-ul clientului vede că nu este încă conectat la server și trimite un mesaj către programul binder cerând să importe interfața versiunea dorită serverul dorit. Dacă există un astfel de server, atunci liantul trece un mâner și un identificator unic către stubul clientului.

Butonul client utilizează un descriptor ca adresă atunci când trimite un mesaj de solicitare. Mesajul conține parametri și un identificator unic pe care nucleul serverului îl folosește pentru a transmite mesajul primit către serverul corect dacă există mai mulți dintre aceștia pe această mașină.

Această metodă de import / export de interfețe este foarte flexibilă. De exemplu, pot exista mai multe servere care acceptă aceeași interfață, iar clienții sunt distribuiți aleatoriu între servere. În cadrul acestei metode, devine posibilă sondarea periodică a serverelor, analizarea performanței acestora și, în caz de eșec, oprire automată, ceea ce mărește toleranța generală la erori a sistemului. Această metodă poate sprijini, de asemenea, autentificarea clientului. De exemplu, un server ar putea determina că acesta poate fi utilizat numai de clienți dintr-o anumită listă.

Cu toate acestea, legătura dinamică are dezavantaje, cum ar fi cheltuielile suplimentare (timpul) de export și import de interfețe. Amploarea acestor costuri poate fi semnificativă, deoarece multe procese client există pentru o perioadă scurtă de timp, iar la fiecare început al procesului, procedura de import a interfeței trebuie efectuată din nou. În plus, în sistemele mari distribuite, programul binder poate deveni un blocaj, iar crearea de programe multiple cu un scop similar crește, de asemenea, cheltuielile generale de creare și sincronizare a proceselor.

Semantica RPC în caz de eșecuri

În mod ideal, RPC ar trebui să funcționeze corect în caz de eșec. Luați în considerare următoarele clase de eșecuri:

Clientul nu poate determina locația serverului, de exemplu, dacă serverul necesar eșuează sau pentru că programul client a fost compilat cu mult timp în urmă și utilizat versiune veche interfață server. În acest caz, un mesaj care conține un cod de eroare este primit ca răspuns la solicitarea clientului. Cerere pierdută de la client la server. Cea mai simplă soluție este repetarea cererii după un anumit timp. Mesaj de răspuns pierdut de la server la client. Această opțiune este mai complicată decât cea anterioară, deoarece unele proceduri nu sunt idempotente. O procedură idempotentă este o procedură a cărei cerere de execuție poate fi repetată de mai multe ori, iar rezultatul nu se va modifica. Un exemplu de astfel de procedură este citirea unui fișier. Dar procedura pentru retragerea unei anumite sume dintr-un cont bancar nu este idempotentă și, în cazul pierderii unui răspuns, o cerere repetată poate schimba semnificativ starea contului clientului. Una dintre soluțiile posibile este de a aduce toate procedurile într-o formă idempotentă. Cu toate acestea, în practică, acest lucru nu este întotdeauna posibil, deci poate fi utilizată o altă metodă - numerotarea secvențială a tuturor cererilor de către clientul principal. Nucleul serverului își amintește numărul celei mai recente cereri din partea fiecărui client și, la primirea fiecărei cereri, analizează dacă această cerere este primară sau repetată. Serverul s-a blocat după ce a primit solicitarea. Proprietatea idempotenței este, de asemenea, importantă aici, dar, din păcate, abordarea numerotării interogărilor nu poate fi aplicată. În acest caz, contează când a apărut defecțiunea - înainte sau după operație. Dar nucleul client nu poate recunoaște aceste situații, știe doar că răspunsul a expirat. Există trei abordări ale acestei probleme: Așteptați până când serverul repornește și încercați din nou. Această abordare asigură faptul că RPC a fost finalizat cel puțin o dată și, eventual, mai mult. Raportați imediat eroarea către aplicație. Această abordare asigură că RPC a fost executat cel mult o dată. A treia abordare nu garantează nimic. Când serverul eșuează, nu există suport pentru client. RPC poate fi sau nu executat deloc sau de multe ori. În orice caz, această metodă este foarte ușor de implementat.

Niciuna dintre aceste abordări nu este foarte atractivă. Iar opțiunea ideală care ar garanta exact o execuție RPC, în cazul general, nu poate fi implementată din motive de principiu. Să presupunem, de exemplu, că o operație la distanță tipărește un anumit text, care include încărcarea tamponului imprimantei și setarea unui bit într-un anumit registru de control al imprimantei, ca urmare a căruia imprimanta pornește. O blocare a serverului poate avea loc fie cu o microsecundă înainte, fie cu o microsecundă după setarea bitului de control. Momentul eșecului determină în totalitate procedura de recuperare, dar clientul nu poate ști despre momentul eșecului. Pe scurt, posibilitatea unui accident de server schimbă radical natura RPC și reflectă în mod clar diferența dintre un sistem centralizat și un sistem distribuit. În primul caz, o blocare a serverului duce la o blocare a clientului, iar recuperarea este imposibilă. În al doilea caz, pașii pentru restaurarea sistemului sunt atât posibili, cât și necesari.

Clientul sa prăbușit după ce a trimis solicitarea. În acest caz, calculele sunt efectuate pe rezultatele pe care nimeni nu le așteaptă. Astfel de calcule se numesc „orfani”. Prezența orfanilor poate provoca diverse probleme: timpul procesorului, blocarea resurselor, înlocuirea răspunsului la solicitarea curentă cu răspunsul la o cerere care a fost emisă de mașina client chiar înainte de repornirea sistemului.

Ce să faci cu orfanii? Să luăm în considerare 4 soluții posibile.

Distrugere. Înainte ca butonul client să trimită un mesaj RPC, acesta face o notă în jurnal, notificând ce va face acum. Jurnalul este stocat pe disc sau altă memorie tolerantă la erori. După accident, sistemul repornește, jurnalul este analizat și orfanii sunt eliminați. Dezavantajele acestei abordări includ, în primul rând, costurile crescute asociate cu scrierea despre fiecare RPC pe disc și, în al doilea rând, posibila ineficiență datorată apariției orfanilor de a doua generație generați prin apeluri RPC emise de orfani de prima generație. Reîncarnare. În acest caz, toate problemele sunt rezolvate fără a utiliza scrierea pe disc. Metoda constă în împărțirea timpului în perioade numerotate secvențial. Când clientul repornește, acesta transmite către toate mașinile pentru a începe o nouă perioadă. La primirea acestui mesaj, toate calculele la distanță sunt încheiate. Desigur, dacă rețeaua este segmentată, atunci unii orfani pot supraviețui. Reîncarnarea soft este similară cu cazul anterior, cu excepția faptului că nu toate calculele la distanță sunt găsite și distruse, ci doar cele ale clientului de repornire. Data expirării. Fiecărei cereri i se atribuie un interval de timp standard T, timp în care trebuie îndeplinită. Dacă cererea nu este finalizată în timpul alocat, atunci se alocă o cuantă suplimentară. Deși necesită muncă în plus, dar dacă, după un accident de client, serverul așteaptă un interval T înainte de a reporni clientul, atunci toți orfanii sunt neapărat distruși.

În practică, niciuna dintre aceste abordări nu este de dorit; în plus, distrugerea orfanilor poate agrava situația. De exemplu, să presupunem că un orfan a blocat unul sau mai multe fișiere de baze de date. Dacă orfanul este brusc distrus, atunci aceste blocări vor rămâne, în plus, orfanii distruși pot rămâne în picioare în diferite cozi de sistem, în viitor pot provoca executarea de noi procese etc.

Mulți utilizatori de sisteme informatice au auzit de concepte precum proceduri la distanță, apel la procedură la distanță sau RPC. Dar nu toată lumea știe ce sunt aceste tehnologii, cum funcționează și pentru ce sunt necesare. Dar mulți dintre cei care au dezactivat acest serviciu în sistemele Windows pot primi adesea erori legate de eșecuri critice. Acest lucru și multe altele vor fi discutate mai jos.

Apel procedură la distanță: ce este?

Merită să începeți cu câteva informații teoretice. Se crede că procedurile la distanță (apeluri la proceduri la distanță) sunt un mecanism care vă permite să porniți sau să utilizați orice funcții ale sistemelor informatice într-un spațiu de adrese diferit de terminalul utilizat. În termeni simpli, este o modalitate de a accesa un computer la distanță, de exemplu, printr-o rețea locală sau o conexiune la Internet.

Cu toate acestea, procedurile la distanță (apeluri de procedură la distanță), denumite RPC (prescurtare pentru Apel de procedură la distanță), nu se limitează la computerele la distanță. La nivel local, sunt folosite și astfel de tehnologii. Cel mai simplu exemplu este apelarea unei anumite funcții a unui program dintr-o altă aplicație prin interacțiune prin biblioteci speciale.

În plus, absolut în toate Versiuni Windows există un astfel de serviciu și, dacă este dezactivat sau funcționează defectuos, modificarea XP nu funcționează deloc.

Principiul de funcționare

De obicei, serviciul RPC necesită cel puțin două componente principale pentru a funcționa în modul client-server: un protocol de rețea pentru schimbul de date și un limbaj de serializare (traducerea unui proces sau a unei structuri de date informaționale într-o secvență de biți).

Arhitecturile pot fi complet diferite și pot diferi în ceea ce privește capacitățile lor. Dar pentru schimbul de date la așa-numitul strat de transport, cel mai adesea sunt utilizate protocoalele UDP și TCP, mai rar HTTP.

Pentru a nu intra în aspecte tehnice, următorul exemplu poate deveni cea mai simplă explicație a principiului de funcționare a unor astfel de tehnologii: procesul client generează o cerere către server cu o descriere a procedurii selectate cu parametrii specificați și o trimite, după care serverul execută directiva cerută și trimite un răspuns către client, care este afișat pe mașina clientului. Cu toate acestea, gestionarul de server în sine este, ca să spunem așa, într-un mod de așteptare și este activat numai atunci când sunt primite cererile clientului. În acest caz, nu este deloc necesar ca executarea schemei cerere-răspuns să fie efectuată imediat.

În același timp, efectul maxim de performanță este atins atunci când se schimbă cantități relativ mici de date și un timp de răspuns scurt al componentelor între care se stabilește comunicarea interactivă.

Proceduri la distanță (apeluri la proceduri la distanță): caracteristici și implementări

Astfel, se pot distinge două caracteristici principale ale acestor tehnologii:

• asimetrie (inițierea unei execuții a procedurii la distanță de către doar una dintre părți);
• sincronicitate (suspendarea procedurii de apelare din momentul inițierii cererii și reluarea după trimiterea răspunsului).

În ceea ce privește implementările, procedurile la distanță (apeluri la proceduri la distanță) utilizează astăzi mai multe tehnologii de bază, printre care următoarele sunt cele mai utilizate:

• DCE / RPC - protocol binar bazat pe TCP / IP, SMB / SIFC etc;
• DCOM - un supliment orientat pe obiecte cu capacitatea de a transmite referințe la obiecte și de a apela la metode pentru procesarea lor;
• JSON-RPC este un protocol text bazat pe HTTP;
• .NET Remoting - un protocol binar bazat pe UDP, TCP și HTTP;
• JAVA RMI;
• SĂPUN;
• XML RPC;
• SUN RPC;
• ZeroC ICE;
• Routix.RPC etc.

Provocări și provocări

Acum câteva cuvinte despre dezavantaje. Cea mai importantă problemă și, în consecință, sarcina de implementare este că aceeași operație de apelare a unei proceduri la distanță printr-un nod al serviciului „Apel de procedură la distanță” trebuie executată simultan pe diferite mașini, adesea cu sisteme de operare diferite, adresă spații și arhitecturi ... În acest proces, datele parametrilor trebuie copiate de la un terminal la altul. Pentru aceasta, nu se utilizează doar protocolul de transport, ci și serializarea, care permite conversia diferitelor tipuri de date într-o secvență de octeți.

Al doilea punct este legat de faptul că procedurile la distanță (apeluri la proceduri la distanță) utilizează nu un proces, ca la nivel local, ci două (pe computerul client și pe server). Prin urmare, terminarea anormală a programului pe unul dintre terminale poate provoca aceeași reacție pe cealaltă.

În cele din urmă, una dintre problemele principale se numește compatibilitate datorită eterogenității unor limbaje de programare, în ciuda standardelor uniforme stabilite.

Tipuri de bază de subsisteme

Apelarea la distanță a Windows 10 sau orice alt sistem sub rang implică utilizarea unor subsisteme speciale:

• subsistem de transport conceput pentru a gestiona conexiunile de ieșire și de intrare cu livrarea garantată a pachetelor de date;
• pool-protocols - conceptul de executare a unei proceduri pe un terminal numit;
• serializare (marshaling) - convertirea fluxurilor de date în coduri standard de octeți, independent de arhitectură;
• criptarea pachetelor trimise și primite cu impunerea unei semnături digitale asupra acestora;
• sistemul de autentificare și autorizare.

Ce tipuri de programe necesită RPC pentru a rula?

Dacă vorbim despre ce module software sistemele de operare necesită păstrarea serviciului RPC activat, este pur și simplu imposibil să le enumerați pe toate.

Dar, printre toate componentele bine-cunoscute ale sistemelor Windows, putem menționa serviciul de fax, serviciile de criptografie, înregistrarea erorilor, ajutor și asistență, accesul la dispozitive HID, serviciul de mesagerie (Messenger), administrarea de discuri și partiții logice, gestionarea dispozitivelor amovibile. unități, sistem audio, instalator Windowsși Dumnezeu mai știe ce altceva.

Se pare că această listă este suficientă pentru a înțelege câte componente ale sistemului și utilizatorul însuși depind de acest serviciu.

Ce afectează RPC

În general, pe baza descrierii anterioare, puteți evalua impactul RPC. De exemplu, există multe cazuri în care când acest serviciu a fost oprit, sunetul a dispărut complet, a fost imposibil să se restabilească sistemul după eșecuri critice sau inițiat de utilizator, setările rețelei wireless „au clipit”.

Dar cel mai trist lucru este că, dacă dezactivați apelul de procedură la distanță RPC, uneori este imposibil chiar să obțineți acces la setările de bază ale sistemului, indiferent dacă utilizatorul este de cel puțin trei ori administrator pe propriul terminal.

Este posibil să dezactivați acest serviciu

În general, mulți au încercat (și încearcă) să dezactiveze serviciul RPC. A face acest lucru este strict interzis. În general, sistemul în sine, atunci când face o astfel de încercare de a face acest lucru, nu va da o notificare corespunzătoare.

Dar nu toată lumea știe că în secțiunea de servicii (services.msc) există și un astfel de lucru ca „localizator RPC”. Doar că poate fi oprit nedureros pentru sistem. Aplicațiile care îl pot folosi în munca lor vor apela în mod independent serviciul, dacă este necesar.

Depanarea blocărilor și erorilor

În cele din urmă, să vedem ce puteți face dacă se produce o eroare în timpul unui apel la procedură la distanță. În cel mai simplu caz, puteți încerca să reactivați serviciul (dacă, desigur, funcționează).

Pentru a face acest lucru, în secțiunea corespunzătoare în care se află serviciul dorit, faceți dublu clic pe meniul pentru editarea parametrilor, apăsați butonul de activare și tipul de includere în sine este setat la automat. Dacă nu este posibil să efectuați această procedură cu o pornire standard a sistemului, puteți încerca să efectuați acțiuni similare în modul sigur... Unii experți sfătuiesc în același timp să oprească software-ul antivirus în momentul acțiunii, pentru orice eventualitate.

Dacă acest lucru nu ajută, dar aveți la îndemână discul de instalare sau de recuperare al sistemului, puteți porni consola de comandă cu drepturi de administrator (nu trebuie să porniți de pe disc) și să scrieți următoarele comenzi:

• cd z: \ i386 (Z este litera unității optice);
• extindeți explorer.ex_% TEMP% \ explorer.exe;
• extindeți svchost.ex_% TEMP% \ svchost.exe.

După aceea, lansați „Task Manager” (Ctrl + Del + Alt sau taskmgr în meniul „Run”) și încheiați procesul Explorer.exe.

În „Dispatcher” oprim toate procesele svhost.exe și apoi în 60 de secunde trebuie să aveți timp pentru a introduce linia de copiere% TEMP% \ svchost.exe% systemroot% \ system32 / y în linia de comandă.

În cele din urmă, dacă aveți acces la editor registru de sistem(regedit) este restaurat, trebuie să mergeți de-a lungul ramurii HKCC prin secțiunile SYSTEM și CurrentControlSet și să ajungeți la parametrul CSConfigFlags, schimbându-i valoarea la zero.

Acestea sunt doar câteva dintre metodele de remediere a erorilor legate de RPC. Faptul este că, dacă acest serviciu a implicat întreruperi în activitatea altor servicii, este posibil să fie necesar mai întâi să remediați problemele cu performanța lor și abia apoi să luați măsuri în legătură cu RPC. Și nu este întotdeauna posibil să ajungeți la parametrii și setările de mai sus acces complet... Dacă nu se întâmplă nimic, oricât de deplorabil ar suna, va trebui să reinstalați complet sistemul de operare, deși sper că acest lucru nu va ajunge la acest lucru.

Concluzie

Asta este totul pe scurt despre tehnologia și serviciul RPC. De fapt, toate acestea arată mult mai complicat decât a fost prezentat în această descriere și, pentru a înțelege pe deplin problema, trebuie să aveți cel puțin cunoștințe de bază. Dar pentru a avea o înțelegere generală a RPC, acest lucru este suficient pentru moment.

În ceea ce privește oprirea, nu încercați să faceți astfel de lucruri, altfel întregul sistem va eșua. Soluțiile date pentru remedierea blocărilor ajută de obicei, dar tot nu puteți oferi o garanție deplină, deoarece dezactivarea serviciului ar putea provoca defecțiuni la alte componente.

Programele care comunică printr-o rețea au nevoie de un mecanism de comunicare. La nivelul inferior, la sosirea pachetelor, un semnal este procesat de programul de procesare a semnalului de rețea. La nivelul superior, funcționează mecanismul de întâlnire (rendezvous), adoptat în limba Ada. NFS utilizează un mecanism de apel la procedură la distanță (RPC) în care clientul comunică cu serverul (vezi Figura 1). În conformitate cu acest proces, clientul accesează mai întâi o procedură care trimite o cerere către server. La sosirea unui pachet cu o cerere, serverul apelează procedura de deschidere, efectuează serviciul solicitat, trimite un răspuns și controlul este returnat clientului.

Interfața RPC poate fi considerată ca având trei straturi:

1. Nivelul superior este complet transparent. Un program la acest nivel ar putea, de exemplu, să apeleze rnusers (), care returnează numărul de utilizatori de pe aparatul de la distanță. Nu trebuie să știți despre utilizarea mecanismului RPC, deoarece efectuați apelul în program.
2. Nivel mediu conceput pentru cei mai mulți aplicații comune... Apelurile RPC la acest nivel sunt gestionate de rutinele registerrpc () și callrpc (): registerrpc () primește cod întunecat la nivel de sistem, iar callrpc () execută un apel de procedură la distanță. Apelul rnusers () este implementat folosind aceste două rutine.
3. Nivelul inferior este utilizat pentru sarcini mai complexe, schimbând valorile implicite la valorile parametrilor procedurii. La acest nivel, puteți manipula în mod explicit soclurile utilizate pentru transmiterea mesajelor RPC.

Ca regulă generală, ar trebui să utilizați stratul superior și să evitați utilizarea straturilor inferioare inutil.

În ciuda faptului că în acest tutorial luăm în considerare doar interfața din C, apelurile la proceduri la distanță pot fi efectuate din orice limbă. Activitatea mecanismului RPC pentru organizarea comunicării între procese pe diferite mașini nu diferă de activitatea sa pe aceeași mașină.

RPC (Remote Procedure Call) este o interfață între utilizatorii la distanță și anumite programe gazdă care sunt rulate atunci când sunt solicitați de acei utilizatori. Un serviciu RPC pentru o gazdă oferă de obicei clienților o suită de programe. Fiecare dintre aceste programe, la rândul său, constă din una sau mai multe proceduri la distanță. De exemplu, un serviciu la distanță Sistemul de fișiere NFS, care este construit pe apeluri RPC, poate consta doar din două programe: de exemplu, un program interacționează cu interfețe de utilizator de nivel înalt, iar celălalt cu funcții de I / O de nivel scăzut.

Fiecare apel RPC implică două părți: clientul activ, care trimite cererea de apel de procedură către server și serverul, care trimite răspunsul către client.

Notă. Rețineți că termenii „client” și „server” în acest caz se referă la o anumită tranzacție. O anumită gazdă sau software (proces sau program) poate acționa fie ca client, fie ca server. De exemplu, un program care oferă un serviciu de procedură la distanță poate fi în același timp client pentru un sistem de fișiere de rețea.

RPC este construit pe un model de apel de procedură la distanță similar cu apelurile de procedură locală. Când apelați o procedură locală, împingeți argumentele către o anumită locație de memorie, stivă sau variabile de mediu și transferați controlul procesului la o anumită adresă. După finalizarea lucrării, citiți rezultatele la o anumită adresă și vă continuați procesul.

În cazul unei proceduri la distanță, diferența principală este că apelul funcției la distanță este deservit de două procese: procesul client și procesul server.

Procesul client trimite un mesaj către server, care include parametrii procedurii apelate și așteaptă un mesaj de răspuns cu rezultatele muncii sale. Când se primește un răspuns, rezultatul este citit și procesul continuă. Pe partea de server, procesul de gestionare a apelurilor se află în starea de așteptare și, atunci când ajunge un mesaj, citește parametrii procedurii, îl execută, trimite un răspuns și devine în starea de așteptare pentru următorul apel.

Protocolul RPC nu impune nicio cerință conexiuni suplimentareîntre procese și nu necesită sincronizarea funcțiilor efectuate, adică apelurile pot fi asincrone și neindependente, astfel încât clientul să poată executa alte proceduri în timp ce așteaptă un răspuns. Serverul RPC poate aloca un proces separat sau o mașină virtuală pentru fiecare funcție, prin urmare, fără a aștepta finalizarea solicitărilor anterioare, poate accepta imediat următoarea.

Cu toate acestea, există câteva diferențe importante între apelurile de procedură locală și la distanță:

1. Eroare la procesare. În orice caz, clientul ar trebui să fie notificat cu privire la erorile care apar atunci când apelează proceduri la distanță pe server sau în rețea.
2. Variabile globale. Deoarece serverul nu are acces la spațiul de adresă al clientului, nu puteți utiliza parametri ascunși sub formă de variabile globale în apelurile de procedură la distanță.
3. Performanţă. Viteza de execuție a procedurilor la distanță, de regulă, este cu una sau două ordine de mărime mai mică decât viteza de execuție a procedurilor locale similare.
4. Autentificare. Deoarece apelurile de procedură la distanță apar prin rețea, trebuie utilizate mecanisme de autentificare a clientului.

Principiile construirii protocolului.

Protocolul RPC poate utiliza mai multe protocoale de transport diferite. Singurele responsabilități ale protocolului RPC sunt aplicarea standardelor și interpretarea transferului de mesaje. Fiabilitatea și fiabilitatea transmiterii mesajelor sunt asigurate în întregime de stratul de transport.

Cu toate acestea, RPC poate controla alegerea și unele funcții ale protocolului de transport. Ca exemplu al interacțiunii dintre RPC și protocolul de transport, luați în considerare procedura de atribuire a unui port RPC pentru un proces de aplicație prin RPC - Portmapper.

Această funcție atribuie dinamic (la cerere) un port specific unei conexiuni RPC. Funcția Portmapper este utilizată destul de des deoarece setul de porturi de transport rezervate pentru RPC este limitat și numărul de procese care pot rula simultan este foarte mare. Portmapper, de exemplu, este invocat atunci când selectați porturile de comunicații ale unui client și server de sistem NFS.

Serviciul Portmapper utilizează mecanismul de transmitere a mesajelor RPC către un port specific - III. Pe acest port, clientul transmite o cerere pentru portul unui anumit serviciu RPC. Serviciul Portmapper procesează mesajul fiscal, determină adresa serviciului RPC local și trimite un răspuns clientului. Serviciul RPC Portmapper poate funcționa atât cu protocoalele TCP, cât și cu cele UDP.

RPC poate funcționa cu diverse protocoale de transport, dar nu își dublează niciodată funcțiile, adică, dacă RPC rulează pe TCP, toate preocupările legate de fiabilitatea și validitatea conexiunii RPC sunt plasate pe TCP. Cu toate acestea, dacă RPC este instalat peste UDP, acesta poate oferi funcționalități native suplimentare pentru a asigura livrarea mesajelor este garantată.

Notă.

Aplicațiile se pot gândi la protocolul RPC ca la o procedură de apel funcție definită pe o rețea JSR (Jump Subroutine Instruction).

Pentru ca protocolul RPC să funcționeze, trebuie îndeplinite următoarele condiții:

1. Identificarea unică a tuturor procedurilor apelate de la distanță pe o anumită gazdă. Cererile RPC conțin trei câmpuri de identificatori - numărul programului la distanță (serviciu), numărul versiunii programului la distanță și numărul procedurii la distanță a programului specificat. Numărul programului este atribuit de producătorul serviciului, numărul procedurii indică o funcție specifică acest serviciu
2. Identificarea versiunii protocolului RPC. Mesajele RPC conțin un câmp de versiune a protocolului RPC. Se folosește pentru a conveni asupra formatelor parametrilor transmiși când clientul lucrează diferite versiuni RPC.
3. Furnizarea de mecanisme pentru autentificarea clientului pe server. Protocolul RPC oferă o procedură pentru autentificarea clientului în serviciu și, dacă este necesar, pentru fiecare cerere sau trimiterea unui răspuns către client. În plus, RPC permite diverse mecanisme de securitate suplimentare.

RPC poate utiliza patru tipuri de mecanisme de autentificare:

• AUTH_NULL - nu a fost utilizată nicio autentificare
• AUTH_UNIX - autentificare de către Standard UNIX
• AUTH_SHORT - autentificare UNIX cu propria structură de codificare
• Autentificare AUTH_DES - DES

1. Identificarea mesajelor de răspuns la solicitările corespunzătoare. Mesajele de răspuns RPC conțin ID-ul cererii pe care s-au bazat. Acest identificator poate fi numit identificatorul de tranzacție al apelului RPC. Acest mecanism este util mai ales atunci când se lucrează în mod asincron și când se execută o secvență de mai multe apeluri RPC.
2. Identificarea erorilor de protocol. Toate erorile de rețea sau de server au identificatori unici prin care fiecare dintre participanții la conexiune poate determina cauza eșecului.

Structuri de mesaje protocol

Când transferați mesaje RPC printr-un protocol de transport, mai multe mesaje RPC pot fi localizate într-un pachet de transport. Pentru a distinge un mesaj de altul, se folosește un marker de înregistrare (RM - Record Marker). Fiecare mesaj RPC este „marcat” cu exact un RM.

Un mesaj RPC poate fi compus din mai multe fragmente. Fiecare bucată este formată din patru octeți de antet și (de la 0 la 2 ** 31-1) date. Primul bit al antetului indică dacă fragmentul este ultimul, iar restul de 31 de biți indică lungimea pachetului de date.

Structura RPC este descrisă formal în limbajul descrierii și reprezentării formatelor de date - XDR cu adăugiri referitoare la descrierea procedurilor. Puteți spune chiar că limbajul de marcare RPC este o extensie a XDR, completată de lucrul cu proceduri.

Structura pachetului RPC arată astfel:

Structura reply_body poate conține fie o structură transmisă în cazul unei erori (caz în care conține codul de eroare), fie o structură pentru procesarea cu succes a cererii (caz în care conține datele returnate).

Interfață de programare la nivel înalt.

Utilizarea subrutinelor într-un program este modalitatea tradițională de a structura o sarcină, de a o clarifica. Cele mai frecvent utilizate subrutine sunt colectate în biblioteci, unde pot fi utilizate de diferite programe. În acest caz, vorbim despre un apel local (local), adică atât apelantul, cât și obiectele apelate funcționează în același program pe același computer.

În cazul unei invocații la distanță, un proces care rulează pe un computer pornește procesul pe computerul de la distanță (adică rulează de fapt codul de procedură pe computerul de la distanță). Evident, un apel de procedură la distanță diferă semnificativ de un apel local tradițional, dar din punctul de vedere al programatorului, practic nu există astfel de diferențe, adică arhitectura unui apel de procedură la distanță vă permite să simulați un apel local.

Cu toate acestea, dacă, în cazul unui apel local, programul trece parametrii la procedura apelată și primește rezultatul muncii prin stivă sau zone de memorie partajată, atunci în cazul unui apel la distanță, transferul parametrilor se transformă într-un transmiterea unei cereri prin rețea, iar rezultatul muncii este în răspunsul primit.

Această abordare este o bază posibilă pentru crearea de aplicații distribuite și, deși multe sisteme moderne nu folosesc acest mecanism, conceptele și termenii de bază rămân în multe cazuri. Când descriem mecanismul RPC, în mod tradițional ne vom referi la procesul de apelare ca la client și la procesul de la distanță care implementează procedura ca server.

Un apel de procedură la distanță include următorii pași:

1. Programul client efectuează un apel local către o procedură numită stub. În acest caz, clientul „pare” că, apelând stub-ul, efectiv face un apel către procedura serverului. Într-adevăr, clientul transmite parametrii necesari către stub și acesta returnează rezultatul. Cu toate acestea, acesta nu este exact modul în care clientul îl prevede. Sarcina stub-ului este de a accepta argumente pentru procedura de la distanță, eventual de a le converti într-un fel format standardși să formeze o cerere de rețea. Ambalarea argumentelor și efectuarea unei cereri de rețea se numește marshalling.
2. Solicitarea de rețea este trimisă prin rețea către sistemul de la distanță. Pentru a face acest lucru, butonul utilizează apelurile corespunzătoare, de exemplu, cele discutate în secțiunile anterioare. Rețineți că, în acest caz, pot fi utilizate diverse protocoale de transport și nu numai familia TCP / IP.
3. Pe gazda la distanță, totul se întâmplă în ordine inversă. Stubul serverului așteaptă o cerere și, la primire, preia parametrii - argumentele apelului de procedură. Extragerea (unmarshalling) poate implica conversii necesare (de exemplu, schimbarea ordinii octeților).
4. Stubul face un apel către procedura serverului real la care este adresată solicitarea clientului, transmițându-i argumentele primite prin rețea.
5. După finalizarea procedurii, controlul revine la stub-ul serverului, trecându-i parametrii necesari. Ca un client client; butonul de server convertește valorile returnate de procedură pentru a forma un mesaj de răspuns de rețea care este trimis prin rețea la sistemul din care a venit solicitarea.
6. Sistemul de operare transmite mesajul primit către clientul stub, care, după transformarea necesară, transmite valorile (care sunt valorile returnate de procedura la distanță) către client, care interpretează acest lucru ca o revenire normală de la procedură.

Astfel, din punctul de vedere al clientului, efectuează un apel de procedură la distanță, așa cum ar face pentru unul local. Același lucru se poate spune despre server: procedura este apelată în mod standard, un obiect (server stub) apelează procedura locală și primește valorile returnate de acesta. Clientul tratează stub-ul ca pe o procedură de server apelabilă, iar serverul își interpretează propriul stub ca fiind clientul.

Astfel, butoanele constituie nucleul sistemului RPC, responsabil pentru toate aspectele generării și transmiterii mesajelor între client și serverul la distanță (procedură), deși atât clientul, cât și serverul presupun că apelurile sunt efectuate local. Acesta este conceptul de bază al RPC - pentru a ascunde complet natura distribuită (rețea) a comunicării în codul stub. Avantajele acestei abordări sunt evidente: atât clientul, cât și serverul sunt independente de implementarea rețelei, ambele funcționând în cadrul unui tip de distribuire mașină virtuală, și apelurile de procedură au o interfață standard.

Trecerea parametrilor

Trecerea parametrilor valorii este simplă. În acest caz, stub-ul clientului plasează valoarea parametrului în solicitarea de rețea, realizând eventual conversii la formularul standard (de exemplu, schimbarea ordinii de octeți). Situația cu indicatorii de trecere este mult mai complicată, atunci când parametrul este adresa datelor și nu valoarea acestora. Trecerea unei adrese într-o cerere nu are sens, deoarece procedura de la distanță este executată într-un spațiu de adrese complet diferit. Cel mai soluție simplă ceea ce folosește RPC este de a interzice clienților să transmită parametri altfel decât după valoare, deși acest lucru impune cu siguranță restricții serioase.

Legare

Înainte ca un client să poată apela o procedură la distanță, acesta trebuie să se lege de sistemul la distanță care găzduiește serverul solicitat. Astfel, sarcina de legare este împărțită în două:

1. Găsirea gazdei la distanță cu serverul necesar
2. Găsirea procesului de server necesar pe o anumită gazdă

Diverse abordări pot fi folosite pentru a găsi o gazdă. O posibilă opțiune este crearea unui fel de director centralizat în care gazdele își anunță serverele și unde clientul, dacă se dorește, poate alege o gazdă și o adresă de procedură potrivită pentru el.

Fiecare procedură RPC este identificată în mod unic printr-un număr de program și procedură. Numărul programului definește un grup de proceduri la distanță, fiecare dintre ele având propriul număr. Fiecărui program i se atribuie și un număr de versiune, astfel încât atunci când se fac modificări minore programului (de exemplu, când se adaugă o procedură), nu este nevoie să-i schimbați numărul. De obicei, mai multe proceduri similare funcțional sunt implementate într-un singur modul de program, care, atunci când este lansat, devine serverul acestor proceduri și care este identificat prin numărul programului.

Astfel, atunci când un client dorește să apeleze o procedură la distanță, trebuie să cunoască programul, versiunea și numerele de procedură care furnizează serviciul necesar.

Pentru a transmite cererea, clientul trebuie să cunoască, de asemenea, adresa de rețea a gazdei și numărul de port asociat programului de server care furnizează procedurile necesare. Acest lucru se face folosind demonul portmap (IM) (numit rpcbind (IM) pe unele sisteme). Demonul rulează pe gazda care furnizează serviciul de procedură la distanță și folosește un număr de port bine cunoscut. Când se inițializează un proces server, acesta își înregistrează rutinele și numerele de port în portmap (IM). Acum, atunci când clientul trebuie să cunoască numărul portului pentru a apela o anumită procedură, acesta trimite o cerere către serverul portmap (IM), care la rândul său fie returnează numărul portului, fie transmite cererea direct la serverul RPC și returnează un răspuns către client după executarea acestuia. În orice caz, dacă există procedura necesară, clientul primește numărul de port al procedurii de la serverul portmap (IM) și se pot face cereri suplimentare direct la acest port.

Tratarea excepțiilor

Gestionarea excepțiilor la apelarea procedurilor locale nu este deosebit de problematică. UNIX gestionează erorile de proces, cum ar fi împărțirea la zero, accesurile de memorie nevalide și așa mai departe. Apelarea unei proceduri la distanță crește probabilitatea apariției unor situații de eroare. Adăugate la erori de server și stub sunt erori legate de, de exemplu, primirea unui mesaj de rețea eronat.

De exemplu, când se utilizează UDP ca protocol de transport, mesajele sunt retransmise după un timeout specificat. O eroare este returnată clientului dacă, după un anumit număr de încercări, nu a fost primit un răspuns de la server. În cazul în care este utilizat protocolul TCP, o eroare este returnată clientului dacă serverul a terminat conexiunea TCP.

Apelați la semantică

Apelarea unei proceduri locale duce fără echivoc la executarea acesteia, după care controlul revine la programul principal. Situația este diferită atunci când se apelează o procedură la distanță. Este imposibil să se stabilească când se va executa exact procedura, dacă se va efectua deloc și, dacă da, de câte ori? De exemplu, dacă cererea este primită de sistemul la distanță după ce programul server se termină anormal, procedura nu va fi deloc executată. Dacă clientul, după ce nu a primit un răspuns după o anumită perioadă de timp (timeout), retrimite cererea, atunci poate apărea o situație când răspunsul este deja transmis prin rețea, iar cererea repetată este din nou acceptată pentru procesare de către procedură la distanță. În acest caz, procedura va fi efectuată de mai multe ori.

Astfel, executarea unei proceduri la distanță poate fi caracterizată prin următoarea semantică:

• O singură dată. Acest comportament (în unele cazuri cel mai de dorit) este dificil de aplicat din cauza posibilelor blocări ale serverului.
• Timpi maximi. Aceasta înseamnă că procedura fie nu a fost efectuată deloc, fie a fost efectuată o singură dată. O declarație similară poate fi făcută atunci când se primește o eroare în locul unui răspuns normal.
• Cel puțin o dată. Procedura a fost efectuată probabil o singură dată, dar este posibil mai mult. Pentru funcționarea normală într-o astfel de situație, procedura la distanță trebuie să aibă proprietatea idempotenței (din engleza idemponent). Această proprietate este posedată de o procedură, a cărei executare repetată nu provoacă modificări cumulative. De exemplu, citirea unui fișier este idempotentă, dar adăugarea de text la un fișier nu este.

Prezentarea datelor

Când clientul și serverul rulează pe același sistem pe același computer, nu există probleme de incompatibilitate a datelor. Datele binare sunt reprezentate la fel atât pentru client, cât și pentru server. În cazul unui apel la distanță, problema este complicată de faptul că clientul și serverul pot rula pe sisteme cu arhitecturi diferite cu reprezentări de date diferite (de exemplu, reprezentare în virgulă mobilă, ordinea de octeți etc.)

Majoritatea implementărilor RPC definesc o reprezentare standard a datelor la care trebuie convertite toate valorile transmise în cereri și răspunsuri.

De exemplu, formatul pentru reprezentarea datelor în RPC de la Sun Microsystems este următorul:

1. Ordin de octeți - Cel mai semnificativ - Ultimul
2. Reprezentare în virgulă mobilă - IEEE
3. Reprezentarea personajelor - ASCII

Reţea

În ceea ce privește funcționalitatea, sistemul RPC este intermediar între stratul de aplicație și stratul de transport. Conform modelului OSI, această prevedere corespunde straturilor de prezentare și sesiune. Astfel, RPC este teoretic independent de implementarea rețelei, în special a protocoalelor de rețea ale stratului de transport.

Implementările software ale sistemului, de regulă, acceptă unul sau două protocoale. De exemplu, sistemul RPC al Sun Microsystems acceptă mesageria utilizând protocoalele TCP și UDP. Alegerea unuia sau a altui protocol depinde de cerințele aplicației. Alegerea UDP este justificată pentru aplicațiile cu următoarele caracteristici:

• Procedurile apelate sunt idempotente
• Dimensiunea argumentelor transmise și rezultatul returnat este mai mică decât dimensiunea pachetului UDP - 8 KB.
• Serverul asigură funcționarea cu câteva sute de clienți. Deoarece, atunci când lucrează cu protocoale TCP, serverul este obligat să mențină o conexiune cu fiecare dintre clienții activi, acest lucru ocupă o parte semnificativă din resursele sale. UDP utilizează mai puține resurse în acest sens.

Pe de altă parte, TCP oferă muncă eficientă aplicații cu următoarele caracteristici:

• Aplicația necesită un protocol de transfer fiabil
• Procedurile numite nu sunt identice
• Argumentele sau rezultatul returnat sunt mai mari de 8 KB

Alegerea protocolului rămâne de obicei în sarcina clientului, iar sistemul organizează formarea și transmiterea mesajelor în moduri diferite. Deci, atunci când utilizați protocolul TCP, pentru care datele transmise sunt un flux de octeți, este necesar să separați mesajele unul de celălalt. Pentru aceasta, de exemplu, se utilizează protocolul de etichetare a înregistrărilor descris în RFC1057 „RPC: specificație protocol de apel la procedură la distanță versiunea 2”, care prefixează fiecare mesaj cu un număr întreg de 32 de biți care specifică dimensiunea mesajului în octeți.

Situația este diferită cu semantica apelului. De exemplu, dacă RPC se efectuează utilizând un protocol de transport nesigur (UDP), sistemul retransmite mesajul la intervale scurte (timeouts). Dacă aplicația client nu primește un răspuns, atunci este sigur să spunem că procedura a fost executată de zero sau de mai multe ori. Dacă a fost primit un răspuns, cererea poate concluziona că procedura a fost executată cel puțin o dată. Când se utilizează protocolul de transport fiabil (TCP), dacă se primește un răspuns, se poate spune că procedura a fost executată o singură dată. Dacă nu se primește niciun răspuns, este imposibil să spunem cu certitudine că procedura nu a fost efectuată3.

Cum functioneaza?

În esență, sistemul RPC real este încorporat în programul client și în programul server. Este îmbucurător faptul că atunci când dezvoltați aplicații distribuite, nu trebuie să vă adânciți în detaliile protocolului RPC sau procesării mesajelor de program. Sistemul presupune existența unui mediu de dezvoltare adecvat, care facilitează foarte mult viața creatorilor aplicației software... Unul dintre punctele cheie din RPC este că dezvoltarea unei aplicații distribuite începe cu definirea unei interfețe obiect - o descriere formală a funcțiilor serverului, realizată într-un limbaj special. Stuburile client și server sunt apoi generate automat din această interfață. Singurul lucru care trebuie făcut după aceasta este să scrieți codul de procedură propriu-zis.

De exemplu, luați în considerare RPC de la Sun Microsystems. Sistemul este format din trei părți principale:

• rpcgen (1) este un compilator RPC care generează stub-uri client și server ca programe C pe baza descrierii interfeței procedurii la distanță.
• Biblioteca XDR (eXternal Data Representation), care conține funcții pentru conversia diferitelor tipuri de date într-o formă independentă de mașină, permițând schimbul de informații între sistemele eterogene.
• O bibliotecă de module care asigură funcționarea sistemului în ansamblu.

Să vedem un exemplu de aplicație de înregistrare de evenimente distribuită de bază. Clientul, la pornire, apelează procedura la distanță pentru a scrie un mesaj în fișierul jurnal al computerului la distanță.

Pentru a face acest lucru, va trebui să creați cel puțin trei fișiere: specificația interfețelor procedurilor la distanță log.x (în limbajul descrierii interfeței), textul real al procedurilor la distanță log.c și textul programul principal al clientului main () - client.c (în limbajul C).

Compilatorul rpcgen (l) generează trei fișiere pe baza specificației log.x: stuburile clientului și serverului C (log clnt.c și log svc.c) și fișierul de definiție log.h utilizat de ambele stub-uri.

Deci, să ne uităm la codul sursă al programelor.

Acest fișier specifică parametrii de înregistrare a procedurii de la distanță - program, versiune și numere de procedură - și definește interfața apelantă - argumente de intrare și valori returnate. Astfel, este definită procedura RLOG, care ia un șir ca argument (care va fi scris în jurnal), iar valoarea returnată, în mod implicit, indică succesul sau eșecul operației comandate.

program LOG_PROG ( versiune LOG_VER ( int RLOG (șir) = 1; ) = 1; ) = 0x31234567;

Compilatorul rpcgen (l) generează un fișier header log.h unde, în special, sunt definite procedurile:

Să aruncăm o privire mai atentă la acest fișier. Compilatorul traduce numele RLOG definit în descriptorul interfeței în rlog_1, înlocuind caracterele majuscule cu cele minuscule și adăugând numărul versiunii programului cu un subliniat. Tipul de returnare s-a schimbat de la int la int *. Aceasta este regula - RPC vă permite să trimiteți și să primiți doar adresele parametrilor declarați atunci când descrieți interfața. Aceeași regulă se aplică șirului trecut ca argument. Deși acest lucru nu rezultă din fișierul print.h, de fapt, adresa liniei este, de asemenea, transmisă ca argument funcției rlog_l ().

În plus față de fișierul antet, compilatorul rpcgen (l) generează module stub client și module stub server. În esență, textul acestor fișiere conține tot codul de apel la distanță.

Stubul de server este programul principal care gestionează toate interacțiunile de rețea cu clientul (mai precis, cu stubul său). Pentru a efectua operația, stub-ul serverului efectuează un apel local către funcție, al cărui text trebuie scris:

Stubul clientului ia un argument transmis procedurii la distanță, efectuează transformările necesare, emite o cerere către serverul portmap (1M), comunică cu serverul de procedură la distanță și, în cele din urmă, transmite clientului valoarea de returnare. Pentru client, un apel de procedură la distanță este un apel de tip stub și nu diferă de un apel local obișnuit.

client.c

#include #include„jurnal.h” principal(int argc, char* argv) (CLIENT * cl; char* server, * mystring, * clnttime; time_t bintime; int* rezultat; dacă(argc! = 2) (fprintf (stderr, "Format apel:% s Host_address \ n", argv); exit (1);) server = argv; / * Obțineți descriptorul clientului. În caz de eșec, vă vom informa despre imposibilitatea stabilirii unei conexiuni cu serverul * / dacă((c1 = clnt_create (server, LOG_PROG, LOG_VER, "udp")) == NULL) (clnt_pcreateerror (server); exit (2);) / * Alocați un buffer pentru șir * / șirul meu = ( char*) malloc (100); / * Determinați ora evenimentului * / bintime = time ((time_t *) NULL); clnttime = ctime (& bintime); sprintf (mystring, "% s - Clientul a început", clnttime); / * Să trimitem un mesaj pentru jurnal - momentul în care clientul a început să lucreze. În caz de eșec, vom raporta o eroare * / dacă((result = rlog_l (& mystring, cl)) == NUL) (fprintf (stderr, "error2 \ n"); clnt_perror (cl, server); exit (3);) / * În caz de defecțiune pe computerul de la distanță, vom raporta o eroare * / dacă(* rezultat! = 0) fprintf (stderr, "Eroare la scrierea în jurnal \ n"); / * 0 liber descriptorul * / cint destroy (cl); ieșire (0); )

Clientul stub log_clnt.c este compilat cu modulul client.c pentru a obține executabilul clientului.

Acum, pe un server.nowhere.ru gazdă, trebuie să porniți procesul serverului:

$ logger

Apoi, când clientul rlog este pornit pe o altă mașină, serverul va adăuga o intrare corespunzătoare în fișierul jurnal.

Schema de funcționare RPC în acest caz este prezentată în Fig. 1. Modulele interacționează după cum urmează:

1. Când începe procesul de server, acesta creează un socket UDP și leagă orice port local de acel socket. Serverul apelează apoi funcția de bibliotecă svc_register (3N) pentru a înregistra numerele de program și numerele de versiune. Pentru a face acest lucru, funcția apelează procesul portmap (IM) și transmite valorile necesare. Serverul portmap (IM) este de obicei pornit la inițializarea sistemului și se leagă de un port bine cunoscut. Portmap (3N) cunoaște acum numărul de port pentru programul și versiunea noastră. Serverul așteaptă să primească solicitarea. Rețineți că toate acțiunile descrise sunt efectuate de un stub de server creat de compilatorul rpcgen (IM).
2. Când pornește programul rlog, primul lucru pe care îl face este să apele funcția de bibliotecă clnt_create (3N), oferindu-i adresa sistemului de la distanță, numerele de program și versiune și protocolul de transport. Funcția face o cerere către serverul portmap (IM) al sistemului de la distanță server.nowhere.m și obține numărul de port la distanță pentru serverul de jurnal.
3. Clientul apelează rutina rlog_1 () definită în stubul clientului și transferă controlul către stub. Acesta, la rândul său, formează cererea (convertind argumentele în format XDR) sub forma unui pachet UDP și o redirecționează către portul la distanță primit de la serverul portmap (IM). Apoi așteaptă un răspuns pentru o perioadă de timp și, dacă nu este primit, trimite din nou cererea. În circumstanțe favorabile, cererea este acceptată de serverul de înregistrare (modulul stub de server). Butonul identifică funcția care a fost apelată (după numărul procedurii) și apelează funcția rlog_1 () a modulului log.c. După ce controlul revine la stub, stub convertește valoarea returnată de funcția rlog_1 () în format XDR și formează răspunsul și sub forma unui pachet UDP. După primirea răspunsului, butonul client extrage valoarea returnată, o convertește și o întoarce la gazda clientului

) Conceptul de apel procedură la distanță

Ideea din spatele apelului de procedură la distanță (RPC) este de a extinde mecanismul bine cunoscut și bine înțeles pentru transferul de control și date într-un program care rulează pe o singură mașină pentru a transfera controlul și datele pe o rețea. Facilitățile de apel de la distanță sunt proiectate pentru a facilita organizarea calculelor distribuite. RPC este cel mai eficient în aplicațiile în care există o comunicare interactivă între componentele de la distanță cu timpi de răspuns rapid și un transfer de date relativ mic. Astfel de aplicații sunt denumite orientate spre RPC.

Apelurile de procedură locală se caracterizează prin:

Asimetria, adică una dintre părțile care interacționează este inițiatorul; Sincronicitatea, adică execuția procedurii de apelare atunci când se oprește din momentul emiterii cererii și reia numai după revenirea din procedura apelată.

Implementarea apelurilor la distanță este semnificativ mai complexă decât implementarea apelurilor de procedură locală. Pentru început, întrucât apelantul și procedura apelată sunt executate pe mașini diferite, acestea au spații de adresă diferite și acest lucru creează probleme la trecerea parametrilor și a rezultatelor, mai ales dacă mașinile nu sunt identice. Deoarece RPC nu poate conta pe memoria partajată, aceasta înseamnă că parametrii RPC nu trebuie să conțină indicatori către locații de memorie care nu sunt stive și că valorile parametrilor trebuie copiate de la un computer la altul. Următoarea diferență între RPC și un apel local este că folosește în mod necesar sistemul de comunicație subiacent, dar acest lucru nu trebuie văzut în mod explicit nici în definiția procedurilor, nici în procedurile în sine. Depărtarea introduce probleme suplimentare. Executarea programului apelant și a procedurii locale apelate pe aceeași mașină se face într-un singur proces. Dar există cel puțin două procese implicate în implementarea RPC - unul pe fiecare mașină. Dacă unul dintre aceștia se blochează, pot apărea următoarele situații: dacă procedura de apelare se blochează, procedurile apelate la distanță vor deveni „orfane” și dacă procedurile la distanță se termină anormal, apelanții vor deveni „părinți privați” de apelanți, așteptați degeaba un răspuns de la procedurile la distanță.

În plus, există o serie de probleme asociate cu eterogenitatea limbajelor de programare și a mediilor de operare: structurile de date și structurile de apel de procedură acceptate într-un singur limbaj de programare nu sunt acceptate în același mod în toate celelalte limbaje.

Acestea și alte probleme sunt rezolvate de tehnologia RPC răspândită care stă la baza multor sisteme de operare distribuite.

Operațiuni de bază RPC

Pentru a înțelege cum funcționează RPC, luați în considerare mai întâi executarea unui apel de procedură locală pe o mașină convențională care rulează autonom. De exemplu, să fie un apel de sistem

Count = citit (fd, buf, nbytes);

unde fd este un număr întreg,
buf este o serie de caractere,
nbytes este un număr întreg.

Pentru a efectua apelul, procedura de apelare împinge parametrii în stivă în ordine inversă (Figura 3.1). După executarea apelului de citit, acesta plasează valoarea de returnare într-un registru, avansează adresa de returnare și returnează controlul la procedura de apelare, care scoate parametrii din stivă, revenind la starea inițială. Rețineți că în C, parametrii pot fi numiți fie prin referință (după nume), fie prin valoare (după valoare). În ceea ce privește procedura numită, parametrii valorii sunt variabile locale inițializabile. Procedura apelată le poate modifica fără a afecta valoarea originalelor acestor variabile în procedura de apelare.

Dacă un indicator către o variabilă este trecut la o procedură apelată, atunci o modificare a valorii acestei variabile prin procedura apelată are ca rezultat o modificare a valorii acestei variabile și pentru procedura apelantă. Acest fapt este esențial pentru RPC.

Există, de asemenea, un alt mecanism de trecere a parametrilor, care nu este utilizat în limbajul C. Se numește apel-prin-copiere / restaurare și constă în necesitatea ca programul apelant să copieze variabilele în stivă ca valori și apoi să le copieze înapoi după efectuarea apelului peste valorile inițiale ale procedurii de apelare.

Depinde de proiectanții de limbă să decidă ce mecanism de trecere a parametrilor să utilizeze. Uneori, depinde de tipul de date transferate. În C, de exemplu, numărul întreg și alte date scalare sunt întotdeauna trecute prin valoare, iar matricile sunt întotdeauna transmise prin referință.

Orez. 3.1. a) Stiva înainte de efectuarea apelului citit;
b) Stiva în timpul executării procedurii;
c) Stivați după revenirea la programul de apelare

Ideea din spatele RPC este de a face un apel de procedură la distanță să pară cât mai aproape de un apel de procedură locală. Cu alte cuvinte, faceți RPC transparent: apelantul nu trebuie să știe că procedura apelată se află pe o altă mașină și invers.

RPC realizează transparența în felul următor. Când procedura apelată este într-adevăr la distanță, în loc de procedura locală, o altă versiune a procedurii numită stub client (stub) este plasată în bibliotecă. La fel ca procedura originală, stub-ul este invocat utilizând secvența de apelare (ca în Figura 3.1) și apare o întrerupere la accesarea nucleului. Doar spre deosebire de procedura inițială, nu introduce parametri în registre și nu solicită kernel-ului pentru date, ci generează un mesaj pe care să-l trimită la kernel-ul mașinii la distanță.

Pași de execuție RPC

Interacțiunea componentelor software în timpul executării unui apel de procedură la distanță este ilustrată în Figura 3.2. După ce clientul stub a fost apelat de programul client, prima sa sarcină este de a umple tamponul cu mesajul trimis. Pe unele sisteme, stub-ul clientului are un buffer unic, cu lungime fixă, care este umplut de la început de fiecare dată când sosește o nouă solicitare. Pe alte sisteme, un buffer de mesaje este un pool de buffere pentru câmpuri de mesaje individuale, dintre care unele sunt deja pline. Această metodă este potrivită în special atunci când pachetul este formatat cu un număr mare de câmpuri, dar valorile multor dintre aceste câmpuri nu se schimbă de la apel la apel.

Parametrii trebuie apoi convertiți în formatul corespunzător și introduși în bufferul de mesaje. În acest moment, mesajul este gata pentru a fi trimis, astfel încât se efectuează o întrerupere a apelului kernel.

Orez. 3.2. Apel procedură la distanță

Când nucleul câștigă controlul, comută contextul, salvează registrele procesorului și o hartă de memorie (descriptori de pagină) și configurează o nouă hartă de memorie care va fi utilizată pentru a rula în modul nucleu. Deoarece contextul nucleului și al utilizatorului sunt diferite, nucleul trebuie să copieze mesajul exact în propriul spațiu de adresă, astfel încât să îl poată accesa, să rețină adresa de destinație (și, eventual, alte câmpuri de antet) și trebuie să îl transmită și rețelei. interfață. Aceasta finalizează activitatea din partea clientului. Temporizatorul de transmisie este activat, iar nucleul poate fie să sondeze ciclic pentru un răspuns, fie să treacă controlul către planificator, care alege un alt proces de executat. În primul caz, executarea interogării este accelerată, dar nu există multiprogramare.

Pe partea de server, biții de intrare sunt plasați de hardware-ul de recepție fie într-un buffer încorporat, fie în RAM. Când se primesc toate informațiile, se generează o întrerupere. Handlerul de întrerupere verifică corectitudinea datelor pachetului și determină care stub ar trebui să-i fie transmis. Dacă niciunul dintre butoane nu așteaptă acest pachet, gestionarul trebuie fie să-l tamponeze, fie să îl arunce cu totul. Dacă există un buton în așteptare, mesajul este copiat pe acesta. În cele din urmă, se efectuează un comutator de context, în urma căruia registrele și harta de memorie sunt restaurate, luând valorile pe care le aveau în momentul în care butonul a efectuat apelul de primire.

Acum, butonul de server începe să funcționeze. Acesta despachetează parametrii și îi împinge în mod corespunzător pe teanc. Când totul este gata, se efectuează un apel server. După finalizarea procedurii, serverul trimite rezultatele către client. Pentru aceasta, se efectuează toți pașii descriși mai sus, numai în ordine inversă.

Figura 3.3 arată secvența de comenzi care trebuie executate pentru fiecare apel RPC, iar Figura 3.4 arată cât din timpul total de execuție RPC este petrecut executând fiecare dintre cele 14 etape descrise. Cercetarea a fost efectuată pe o stație de lucru multiprocesor DEC Firefly și, deși prezența a cinci procesoare a afectat în mod necesar rezultatele măsurătorilor, histograma prezentată în figură oferă o imagine de ansamblu asupra procesului de execuție RPC.

Orez. 3.3. Pașii procedurii RPC

Orez. 3.4. Alocarea timpului între 14 etape de execuție RPC

1. Apelați butonul

2. Pregătiți tamponul

3. Parametrii pachetului

4. Completați câmpul de titlu

5. Calculați suma de verificare din mesaj

6. Întrerupeți până la bază

7. Coada de pachete pentru execuție

8. Trimiterea unui mesaj către controler prin intermediul QBUS

9. Timp de transmisie Ethernet

10. Obțineți un pachet de la controler

11. Procedura de manipulare a întreruperii

12. Calcularea sumei de control

13. Comutarea contextului la spațiul utilizatorului

14. Executarea unui stub de server

Conectare dinamică

Luați în considerare întrebarea cu privire la modul în care clientul specifică locația serverului. O metodă pentru rezolvarea acestei probleme este utilizarea directă a adresei de rețea a serverului în programul client. Dezavantajul acestei abordări este inflexibilitatea sa extremă: când serverul este mutat, sau când numărul serverelor este crescut sau când interfața este schimbată, în toate aceste și multe alte cazuri, este necesar să recompilați toate programele care au folosit un alocarea dură a adresei serverului. Pentru a evita toate aceste probleme, unele sisteme distribuite folosesc ceea ce se numește legare dinamică.

Punctul de plecare pentru legarea dinamică este definiția formală (specificația) serverului. Specificația conține numele serverului de fișiere, numărul versiunii și o listă a procedurilor de servicii furnizate de acest server pentru clienți (Figura 3.5). Pentru fiecare procedură, este dată o descriere a parametrilor săi, indicând dacă acest parametru este de intrare sau de ieșire în raport cu serverul. Unii parametri pot fi atât de intrare, cât și de ieșire - de exemplu, o serie care este trimisă de client către server, modificată acolo și apoi returnată clientului (operație de copiere / restaurare).

Orez. 3.5. Specificații server RPC

Specificația formală a serverului este utilizată ca intrare într-un program generator de stub care creează atât stub-uri client, cât și server. Apoi, acestea sunt plasate în bibliotecile corespunzătoare. Când programul utilizator (client) apelează orice procedură definită în specificațiile serverului, procedura corespunzătoare stub este asociată cu programul binar. La fel, atunci când este compilat un server, stuburile serverului sunt asociate cu acesta.

Când pornește serverul, primul lucru pe care îl face este să treacă interfața serverului către un program special numit binder. Acest proces, cunoscut sub numele de procesul de înregistrare a serverului, implică trimiterea de către server a numelui, numărul versiunii, identificatorul unic și descriptorul locația serverului. Descriptorul este independent de sistem și poate fi un IP, Ethernet, X.500 sau o altă adresă și poate conține și alte informații, cum ar fi autentificarea.

Când clientul apelează una dintre procedurile de la distanță pentru prima dată, de exemplu, citește, stub-ul clientului vede că nu este încă conectat la server și trimite un mesaj către programul binder cerându-i să importe interfața versiunii corecte a serverului necesar. Dacă există un astfel de server, atunci liantul trece un mâner și un identificator unic către stubul clientului.

Butonul client utilizează un descriptor ca adresă atunci când trimite un mesaj de solicitare. Mesajul conține parametri și un identificator unic pe care nucleul serverului îl folosește pentru a transmite mesajul primit către serverul corect dacă există mai mulți dintre aceștia pe această mașină.

Această metodă de import / export de interfețe este foarte flexibilă. De exemplu, pot exista mai multe servere care acceptă aceeași interfață, iar clienții sunt distribuiți aleatoriu între servere. Ca parte a acestei metode, devine posibilă interogarea periodică a serverelor, analizarea performanței acestora și, în caz de defecțiune, oprirea automată, ceea ce crește toleranța generală la erori a sistemului. Această metodă poate sprijini, de asemenea, autentificarea clientului. De exemplu, un server ar putea determina că acesta poate fi utilizat numai de clienți dintr-o anumită listă.

Cu toate acestea, legătura dinamică are dezavantaje, cum ar fi cheltuielile suplimentare (timpul) de export și import de interfețe. Amploarea acestor costuri poate fi semnificativă, deoarece multe procese client există pentru o perioadă scurtă de timp, iar la fiecare început al procesului, procedura de import a interfeței trebuie efectuată din nou. În plus, în sistemele mari distribuite, programul binder poate deveni un blocaj, iar crearea de programe multiple cu un scop similar crește, de asemenea, cheltuielile generale de creare și sincronizare a proceselor.

Semantica RPC în caz de eșecuri

În mod ideal, RPC ar trebui să funcționeze corect în caz de eșec. Luați în considerare următoarele clase de eșecuri:

Clientul nu poate determina locația serverului, de exemplu, dacă serverul necesar eșuează sau pentru că programul client a fost compilat cu mult timp în urmă și a folosit o versiune veche a interfeței serverului. În acest caz, un mesaj care conține un cod de eroare este primit ca răspuns la solicitarea clientului. Cerere pierdută de la client la server. Cea mai simplă soluție este repetarea cererii după un anumit timp. Mesaj de răspuns pierdut de la server la client. Această opțiune este mai complicată decât cea anterioară, deoarece unele proceduri nu sunt idempotente. O procedură idempotentă este o procedură a cărei cerere de execuție poate fi repetată de mai multe ori, iar rezultatul nu se va modifica. Un exemplu de astfel de procedură este citirea unui fișier. Dar procedura pentru retragerea unei anumite sume dintr-un cont bancar nu este idempotentă și, în cazul pierderii unui răspuns, o cerere repetată poate schimba semnificativ starea contului clientului. Una dintre soluțiile posibile este de a aduce toate procedurile într-o formă idempotentă. Cu toate acestea, în practică, acest lucru nu este întotdeauna posibil, deci poate fi utilizată o altă metodă - numerotarea secvențială a tuturor cererilor de către clientul principal. Nucleul serverului își amintește numărul celei mai recente cereri din partea fiecărui client și, la primirea fiecărei cereri, analizează dacă această cerere este primară sau repetată. Serverul s-a blocat după ce a primit solicitarea. Proprietatea idempotenței este, de asemenea, importantă aici, dar, din păcate, abordarea numerotării interogărilor nu poate fi aplicată. În acest caz, contează

Java RMI ca tip de apel de procedură la distanță, independent de rețea, de pașii principali de lucru cu acesta și de scopul. Comparație dintre distribuite și nealocate Programe Java... Arhitectura Java RMI, stub și schelet, referințe la distanță și straturi de transport.

Precompilarea interogărilor SQL la locul de execuție. Folosind declarația prepareStatement. Utilizați sintaxa definiției apelurilor pentru a obține valoarea returnată a unei proceduri sau funcții. Generați instrucțiuni de eșantionare la cerere.

Scopul și schema de lucru. Compoziție și instalare. Specificarea procedurilor pentru pachetul http.

Procedurile și funcțiile pot fi definite ca unități software închise care implementează un algoritm. De fapt, o procedură sau o funcție este aproape un program.

Configurare TCP / IP automată, setare dinamică configurații folosind BOOTP. Adresele IP de cerere / răspuns, formatul de pierdere și mesaj, fazele BOOTP. DHCP ca o extensie a protocolului BOOTP. Alocarea și atribuirea adreselor IP.

Am întâlnit deja conceptul de recursivitate: relațiile de recurență sunt destul de frecvente în expresiile matematice. Recursivitatea în definiție constă în faptul că conceptul definit este definit prin acest concept însuși.

1. Introducere 2 2. Prezentare generală a tehnologiei COM 2 2.1. Compoziția obiectului COM 3 2.2. Interfețe 4 2.3. Proprietățile obiectelor COM 6 2.4. Servere COM 6 2.5. Mecanism de separare 7

Studiul esenței, principiului de funcționare și scopul principal al bazelor de date la distanță. Model telecomandă modelul de date server de fișiere). Tipuri de concurență. Trigger este un mecanism de urmărire a evenimentelor speciale care sunt legate de starea bazei de date.

Pachete de metamodel, fapte și model de securitate. Modelul conceptual al clientului. Un exemplu de funcționare a unei arhitecturi distribuite. Complexitatea implementării.

Conceptul Dll. Să ne amintim procesul de programare în DOS. Conversia codului sursă în codul mașinii a implicat 2 procese: compilare și conectare. În timpul conectării, nu numai declarațiile de funcții și proceduri, ci și codul complet al acestora au fost plasate în codul programului.

Funcții pentru lucrul cu protocolul TCP / IP, Socket, Bind, ascultați și acceptați. Descriptor de fișiere. Procese de comunicare. Primirea datelor. Citind dintr-o priză. Scrierea pe o priză. Închiderea unei prize. Textul programului care creează serverul Web în sistem de operare QNX.

Accesul internauților la e-mailuri stocate pe server. Descrierea programului, autentificarea este simplă, autentificarea APOP și AUTH. Implementarea funcțiilor, manualul de utilizare, algoritmi pentru funcționarea programului, interfață grafică.

Principiul de funcționare al operatorilor principali ai limbajului de programare Turbo-Paskal: operator de atribuire, selectarea cazurilor, salt necondiționat, buclă, captivant, compus. Descrierea formală și apelarea funcțiilor și procedurilor. Cerințe pentru lista parametrilor reali.

Principiul de funcționare și scopul servleturilor Java, importanța lor în creșterea funcționalității serverelor Web și îmbunătățirea programării acestora, avantajele și dezavantajele utilizării. Moduri de apelare a servleturilor din browser și pagină. Atributele sesiunii de scriere și citire.

Arhitectura sistemului de operare Windows NT. Structura sistemului de operare bazat pe microkernel. Subsisteme protejate din Windows NT.

Primitive de bază de transmitere a mesajelor în sisteme distribuite. Metode de adresare. Primitive de blocare și non-blocare. Primitive tamponate și non-tamponate.

Server de aplicații. Partea clientului.

Acum doi ani, AJAX era o noutate (iar cuvântul AJAX în sine nu a fost inventat atunci). Acum aplicațiile web, ale căror pagini au fost reîmprospătate din mers, sunt obișnuite. Dimpotrivă, este dificil să ne imaginăm unele servicii fără AJAX.

Sintaxa pentru descrierea și apelarea unei proceduri. Opțiuni. Un exemplu de descriere și apelare a unei proceduri. Tipuri de parametri. Program.