Fjernprocedurekald

Den aktuelle version af siden er endnu ikke blevet gennemgået af erfarne bidragydere og kan afvige væsentligt fra den version , der blev gennemgået den 22. marts 2021; checks kræver 3 redigeringer .

Fjernprocedurekald (nogle gange fjernprocedurekald ; RPC fra engelsk  remote procedure call ) er en klasse af teknologier, der tillader programmer at kalde funktioner eller procedurer i et andet adresserum (på fjernknudepunkter eller i et uafhængigt tredjepartssystem på samme node). Typisk omfatter en implementering af RPC-teknologi to komponenter: en netværksprotokol til klient-server-kommunikation og et objektserialiseringssprog (eller strukturer til ikke-objektive RPC'er). Forskellige implementeringer har forskellige arkitekturer og forskellige i kapaciteter: nogle implementerer SOA -arkitekturen , andre - CORBAeller DCOM . På transportlaget bruger RPC'er hovedsageligt TCP- og UDP-protokollerne , dog er nogle bygget oven på HTTP (hvilket krænker ISO/OSI -arkitekturen , da HTTP ikke oprindeligt er en transportprotokol).

Der er mange teknologier, der giver RPC, blandt dem:

Princip

Ideen med at kalde fjernprocedurer er at udvide mekanismen til overførsel af kontrol og data i et program, der kører på den samme node, til at overføre kontrol og data over netværket. Remote procedure call-værktøjer er designet til at lette organiseringen af ​​distribueret computing og skabelsen af ​​distribuerede klient-server informationssystemer. Den mest effektive brug af RPC opnås i de applikationer, hvor der er en interaktiv kommunikation mellem fjernkomponenter med en lille responstid og en relativt lille mængde overført data. Sådanne applikationer kaldes RPC-orienterede.

De fremtrædende træk ved et fjernprocedurekald er:

Implementeringen af ​​fjernopkald er meget mere kompliceret end implementeringen af ​​lokale procedureopkald.

Da procedurerne for opkald og opkald kører på forskellige noder, har de forskellige adresserum, og dette skaber problemer, når parametre og resultater overføres, især hvis maskinerne kører forskellige operativsystemer eller har forskellige arkitekturer (f.eks. lille endian eller lille endian er brugt ) . Da RPC ikke kan stole på delt hukommelse, betyder det, at RPC-parametre ikke må indeholde pointere til ikke-stablede hukommelsesplaceringer, og at parameterværdier skal kopieres fra en computer til en anden. For at kopiere parametrene for proceduren og resultatet af udførelse gennem netværket serialiseres de .

I modsætning til et lokalt opkald bruger et fjernprocedurekald nødvendigvis netværksarkitekturens transportlag (f.eks . TCP ), men dette forbliver skjult for udvikleren. Derudover deltager mindst to processer i implementeringen af ​​RPC - en på hver node, og hvis en af ​​dem går ned, kan følgende situationer opstå: hvis opkaldsproceduren går ned, bliver de eksternt kaldte procedurer forældreløse, og hvis fjernprocedurer vil blive "fattige forældre" til opkaldsprocedurer, som vil vente på et svar fra fjerntliggende procedurer til ingen nytte.

Der er også en række problemer forbundet med heterogeniteten af ​​programmeringssprog og driftsmiljøer: datastrukturer og procedurekaldsstrukturer, der understøttes i et hvilket som helst programmeringssprog, understøttes ikke på samme måde på alle andre sprog. Der er således et kompatibilitetsproblem, som endnu ikke er løst, enten ved at indføre én almindeligt accepteret standard eller ved at implementere flere konkurrerende standarder på alle arkitekturer og på alle sprog.

Komponenter

Centralt for RPC-implementeringer er transportundersystemet, som er ansvarligt for at styre udgående og indgående forbindelser. Dens funktioner omfatter understøttelse af konceptet "meddelelsesgrænse" for transportprotokoller, der ikke direkte understøtter det (TCP) og understøttelse af garanteret levering for transportprotokoller, der ikke understøtter det (UDP).

Trådpooling-komponent (kun Callee) - Giver en eksekveringskontekst for kode kaldet over netværket.

Marshaling -komponenten (analog med " serialisering ") sikrer, at opkaldsparametre pakkes ind i en bytestrøm på en standard måde, der er uafhængig af arkitekturen (især rækkefølgen af ​​bytes i et ord) . Det kan især påvirke arrays, strenge og strukturer, der peges på af pointerparametre.

En separat komponent kan være ansvarlig for kryptering af pakker og digital signering af dem .

En separat blok af funktioner er autentificering og autorisation, som sikrer transmission af information over netværket, der identificerer emnet, der foretager opkaldet.

I nogle implementeringer af RPC (.NET Remoting) er undersystemgrænser åbne polymorfe grænseflader, og det er muligt at skrive din egen implementering af næsten alle de listede undersystemer. I andre implementeringer (DCE RPC på Windows) er dette ikke tilfældet.

Noter

  1. RFC-4627 . Hentet 13. november 2008. Arkiveret fra originalen 1. januar 2016.
  2. JDK 5.0 Remote Method Invocation (RMI)-relaterede API'er og udviklervejledninger - fra Sun Microsystems . Hentet 13. november 2008. Arkiveret fra originalen 19. december 2008.
  3. RFC-4227
  4. RFC-1831 . Hentet 13. november 2008. Arkiveret fra originalen 6. november 2008.
  5. RFC-1833 . Hentet 13. november 2008. Arkiveret fra originalen 25. oktober 2008.
  6. RFC-3529 . Hentet 13. november 2008. Arkiveret fra originalen 10. oktober 2008.

Links