Apel de procedură de la distanță

În calculul distribuit , apelul de procedură de la distanță (în engleză , Remote Procedure Call , RPC ) este un program pe care un computer îl folosește pentru a executa cod pe o altă mașină la distanță fără a fi nevoit să-și facă griji cu privire la comunicațiile dintre cele două, astfel încât să pară executat la sediu . Protocolul care este utilizat pentru acest apel este un mare avans față de prizele de internet folosite până acum. În acest fel, programatorul nu trebuia să fie conștient de comunicații, deoarece acestea erau încapsulate în RPC-uri.

Un apel de procedură este foarte asemănător cu o invocare a unei metode la distanță în care un program client apelează o procedură într-un alt program care rulează într-un proces server. Serverele pot fi clienți ai altor servere pentru a permite lanțurile RPC. Un proces server definește în interfața sa de serviciu procedurile disponibile pentru a fi apelate de la distanță. RPC este de obicei implementat prin protocolul cerere-răspuns, care este simplificat prin omiterea referințelor la obiecte de la distanță în partea mesajului de cerere.

RPC-urile sunt utilizate pe scară largă în comunicarea client-server . Fiind clientul cel care inițiază procesul solicitând serverului să execute o anumită procedură sau funcție și trimițând rezultatul acestei operațiuni înapoi către client.

Clientul care accesează un serviciu include o procedură stub pentru fiecare procedură din interfața de serviciu. Rolul unei proceduri de rezervă este similar cu cel al unui proxy. Se comportă ca o procedură client local, dar în loc să execute apelul, împachetează identificatorul procedurii și argumentele într-un mesaj de solicitare care este trimis prin modulul său de comunicare către server; când sosește mesajul de răspuns, despachetează rezultatele.

Conceptul de RPC a fost introdus pentru prima dată de Birrell și Nelson în 1984 și a pus bazele dezvoltării sistemelor distribuite care este folosit astăzi. ]

Probleme de design

Există probleme asociate cu implementarea sistemelor RPC care sunt programarea cu interfețe și transparență, ambele rezumate în cartea „Distributed Systems: Concepts and Design”. ]

Interfețe

Majoritatea programelor moderne au o structură modulară, în care o funcție poate fi utilizată printr-o interfață, care maschează procedura respectivă, iar funcționalitatea acesteia poate fi modificată fără a afecta modul în care este numită. Aceste module pot comunica între ele prin RPC în așa fel încât interacțiunile să fie controlate prin interfețele modulelor, chiar dacă implementarea lor internă variază.

Într-un program distribuit, de exemplu, cu o arhitectură client-server, serverul oferă clienților o listă a modulelor care sunt disponibile pentru utilizare, precum și argumentele necesare pentru a efectua un apel corect către acestea. În acest fel clientul trebuie să-și facă griji doar de interfață, nu trebuie să cunoască detalii despre implementarea modulului, cum ar fi limbajul de programare, sau platforma în care a fost implementat serviciul, în acest fel problema eterogenitatea sistemelor distribuite curente.

Pe de altă parte, dacă un modul care rulează într-un proces trebuie să acceseze variabile dintr-un alt modul care rulează într-un alt proces, nu le poate accesa, deoarece transmiterea argumentelor prin referință nu este permisă. Ca o consecință a acestuia din urmă, parametrii de ieșire trec într-un mesaj de răspuns. O excepție este CORBA care poate accesa variabile dintr-un modul situat într-un alt proces folosind metodele getter și setter .

Transparență

Creatorii RPC, Birrell și Nelson, au încercat să facă apeluri de procedură la distanță cât mai asemănătoare cu cele locale, astfel încât să nu existe distincție între un apel local și un apel la distanță. Transformările reprezentării datelor într-un format adecvat, așa-numita marshalling , precum și alte proceduri de transmitere a mesajelor sunt ascunse de programator. RPC se concentrează pe asigurarea transparenței locației și accesului prin ascunderea locației fizice a metodelor.

Cu toate acestea, apelurile de procedură de la distanță sunt mai vulnerabile la eșec decât cele locale, deoarece implică o conexiune la rețea și un alt computer cu alt proces. Acest lucru face mai dificilă determinarea a ceea ce ar fi putut cauza un eșec.

De asemenea, rețineți că apelurile RPC au o latență mai mare. Acest lucru trebuie luat în considerare reducând cât mai puțin acest tip de apeluri sau făcând procedura care face apelul RPC capabil să îl anuleze dacă durează prea mult. Dacă aceasta din urmă este făcută, este important ca serverul să restabilească informațiile la modul în care erau înainte de apel.

Există o discuție între programatori despre cât de transparent trebuie să fie un apel RPC. De exemplu, creatorii limbajului de programare Argus ( Liskov și Scheifler ) au susținut că apelurile RPC ar trebui să fie diferite de cele locale și, în consecință, Argus a făcut apeluri de la distanță explicite programatorului. Concluzia generală la care sa ajuns este că sintaxa dintre un apel local și un apel la distanță ar trebui să fie aceeași, iar diferența dintre unul și celălalt ar trebui explicată în interfețele lor.

Tipuri de semantică

Există diferite moduri care garantează livrarea mesajelor în RPC:

• Mesaj de solicitare de reîncercare: controlează retransmiterea cererii până când serverul o primește sau presupune că a eșuat

• Filtru duplicat: controlează utilizarea retransmisiilor și dacă serverul elimină cererile duplicate

• Retransmiterea rezultatelor: controlează dacă se păstrează un istoric al rezultatelor mesajelor, permițând retransmiterea rezultatelor pierdute fără a reexecuta operațiunile pe server.

Combinația acestor opțiuni conduce la trei tipuri posibile de semantică: „poate”, „cel puțin-o dată” și „cel mult-o dată” ]

Măsuri de toleranță la erori ]			Semantica apelurilor
Reîncercați mesajul de solicitare	Filtru duplicat	Retransmiterea rezultatelor
nu	Nu se aplică	Nu se aplică	poate
da	nu	Reluați procedura	cel puțin o dată
da	da	Transmite răspunsul	cel mult o dată

Semantica „Poate”

• Procedura de la distanță poate fi executată o dată sau deloc.
• Clientul poate primi sau nu un răspuns.

Functionare

1. Clientul trimite o cerere și așteaptă un anumit timp.
2. Dacă răspunsul nu sosește în timpul expirării, acesta își continuă execuția.
3. Clientul nu are feedback în caz de eșec (nu știe ce s-a întâmplat).

Admisibil numai în aplicațiile în care sunt tolerate pierderea cererilor și primirea de răspunsuri întârziate (în afara ordinii).

Semantică „cel puțin o dată”

• Procedura de la distanță este executată o dată sau de mai multe ori.
• Clientul poate primi unul sau mai multe răspunsuri.

Functionare

1. Clientul trimite o cerere și așteaptă un timp.
2. Dacă nu sosește niciun răspuns sau ACK în timpul expirării, repetați solicitarea.
3. Serverul nu filtrează cererile duplicate (procedura de la distanță poate fi executată în mod repetat).
4. Clientul poate primi mai multe răspunsuri.

Este aplicabil numai atunci când sunt utilizate exclusiv operații idempotente (repetabile). Notă: O operație este idempotentă dacă poate fi executată de mai multe ori cu același efect ca și când ar fi fost executată o singură dată. Uneori, o operație non-idempotentă poate fi implementată ca o secvență de operații idempotente. Admisibil în aplicațiile în care este tolerat ca invocările să poată fi repetate fără a afecta funcționarea acestuia.

semantică „cel mult-o dată”

• Procedura de la distanță este executată exact o dată sau deloc.
• Clientul primește un răspuns sau o indicație că procedura de la distanță nu a fost executată.

Functionare

1. Clientul trimite cererea și așteaptă un timp.
2. Dacă nu sosește niciun răspuns sau ACK în timpul expirării, repetați solicitarea.
3. Serverul filtrează cererile duplicate și păstrează un istoric al răspunsurilor trimise (server cu memorie). Procedura de la distanță este executată o singură dată.
4. Clientul primește un răspuns doar dacă cererea a sosit și procedura a fost executată, în caz contrar primește un raport de eroare.

Rezumatul semanticii RPC

Semantică	Functionare
poate	Clientul nu își retransmite cererile (nu folosește ACK )
	Serverul nu filtrează cererile duplicate
cel puțin o dată	Clientul își retransmite cererile (folosește ACK + timer)
	Serverul nu filtrează cererile duplicate
	Confruntat cu solicitări repetate, serverul repetă execuția
cel mult unul	Clientul își retransmite cererile (folosește ACK + timer)
	Serverul filtrează cererile duplicate
	În fața solicitărilor repetate, serverul retransmite răspunsurile din trecut

Implementări

Implementarea unui apel de procedură la distanță necesită o serie de componente software, care pot fi observate în următoarea figură tradusă din cea găsită în cartea „Sisteme distribuite: Concepte și design”. ]

Schema de implementare a RPC

În interiorul procesului client se află programul principal (programul client). Acesta comunică printr-o procedură stub care este responsabilă pentru realizarea funcției de marshaling , pentru a transforma datele în formatul corespunzător și a le trimite ca mesaj de solicitare prin modulul de comunicare. Odată ce sosește răspunsul, stub-ul anulează transformarea pentru a obține rezultatele.

Modulul de comunicare al procesului client comunică cu cel al procesului server, de la care transmite datele unui distribuitor (dispecer) care trimite datele la procedura stub corespunzătoare, care va îndeplini funcția de marshaling cu procedura de service. Întrucât există mai multe stub-uri, câte unul pentru fiecare procedură de service, distribuitorul este responsabil pentru alegerea celui care corespunde fiecărei solicitări.

Modulele de comunicare nu sunt responsabile doar de adresarea mesajelor, ci și de alte aspecte legate de comunicare, cum ar fi mesaje duplicate, timeout-uri sau retransmisii. ]

În general, RPC implementează un protocol cerere-răspuns.

Apelurile de proceduri de la distanță sunt implementate prin diferite tipuri de protocoale, multe dintre ele standardizate, cum ar fi RPC-ul Sun numit ONC RPC ( RFC 1057 ), RPC Open Software Foundation (OSF) numit DCE/RPC și „Modelul Microsoft Distributed Component Object Model ( DCOM ), deși niciuna dintre acestea nu este compatibilă între ele. Cele mai multe dintre ele folosesc un limbaj de descriere a interfeței ( Interface description language sau IDL) care definește metodele exportate de server.

Astăzi , XML este folosit ca limbaj pentru a defini IDL și HTTP ca protocol de aplicație, dând naștere a ceea ce este cunoscut sub numele de servicii web. Exemple de acestea ar putea fi SOAP sau XML-RPC .

Vezi și

• Apel de procedură la distanță ONC RPC de la Sun.
• Apel de procedură la distanță DCE/RPC de la Open Software Foundation.
• Modelul obiectelor componente distribuite (DCOM), modelul obiectelor componentelor distribuite de la Microsoft.
• Java Remote Method Invocation (RMI), Invocarea metodelor de la distanță pentru Java.
• CORBA .
• XML-RPC .
• SAPUN .
• Calcul distribuit .

Link- uri externe

• www.sun.com Sun Microsystems (în engleză).
• www.w3.org/TR/soap/Soap .
• www.faqs.org/rfcs/rfc1057.html RFC 1057 (în engleză).
• www.jmasters.info:8443/jres/ JRES - Serviciul de execuție la distanță Java este un protocol RPC care utilizează un mecanism de codificare în stil SSL pentru a-și codifica apelurile și HTTP pur ca mecanism de transport .