REMOTE PROCEDURE CALL (RPC) I OPERATIVSYSTEMET

Remote Procedure Call (RPC) er en kraftfuld teknik til at bygge distribuerede, klient-server baserede applikationer . Den er baseret på at udvide den konventionelle lokale procedurekald, således at den kaldede procedure behøver ikke at eksistere i det samme adresserum som den kaldende procedure . De to processer kan være på det samme system, eller de kan være på forskellige systemer med et netværk, der forbinder dem.

Når du foretager et fjernprocedureopkald:

1. Det kaldende miljø suspenderes, procedureparametre overføres på tværs af netværket til det miljø, hvor proceduren skal udføres, og proceduren udføres der.

hvordan man henter skjulte apps

2. Når proceduren afsluttes og producerer sine resultater, overføres dens resultater tilbage til det kaldende miljø, hvor udførelsen genoptages, som om den vender tilbage fra et almindeligt procedurekald.

BEMÆRK: RPC er især velegnet til klient-server (f.eks. forespørgsel-svar) interaktion, hvor strømmen af kontrol skifter mellem den, der ringer og den, der ringer . Konceptuelt kører klienten og serveren ikke begge på samme tid. I stedet springer udførelsestråden fra den, der ringer til den, der kalder, og derefter tilbage igen.

Arbejde med RPC

Følgende trin finder sted under en RPC:

En klient påberåber sig en klient stub procedure , passerer parametre på den sædvanlige måde. Klientstubben ligger i klientens eget adresseområde.
Klientstumpen marshalls (pakke) parametrene i en besked. Marshalling omfatter konvertering af repræsentationen af parametrene til et standardformat og kopiering af hver parameter ind i meddelelsen.
Klientstubben sender beskeden til transportlaget, som sender den til den eksterne servermaskine.
På serveren sender transportlaget beskeden videre til en serverstub, som demarshalls (pakke ud) parametrene og kalder den ønskede serverrutine ved hjælp af den almindelige procedurekaldsmekanisme.
Når serverproceduren er fuldført, vender den tilbage til serverstubben (f.eks. via en normal procedure tilbagekald) , som samler returværdierne til en besked. Serverstubben sender derefter beskeden til transportlaget.
Transportlaget sender resultatmeddelelsen tilbage til klienttransportlaget, som sender meddelelsen tilbage til klientstubben.
Klientstubben afgrænser returparametrene, og udførelsen returnerer til den, der ringer.

Nøgleovervejelser for design og implementering af RPC-systemer er:

Sikkerhed: Da RPC involverer kommunikation over netværket, er sikkerhed et stort problem. Foranstaltninger som autentificering, kryptering og autorisation skal implementeres for at forhindre uautoriseret adgang og beskytte følsomme data. Skalerbarhed: Efterhånden som antallet af klienter og servere stiger, må ydeevnen af RPC-systemet ikke forringes. Belastningsbalanceringsteknikker og effektiv ressourceudnyttelse er vigtige for skalerbarheden. Fejltolerance: RPC-systemet bør være modstandsdygtigt over for netværksfejl, servernedbrud og andre uventede hændelser. Foranstaltninger som redundans, failover og yndefuld nedbrydning kan hjælpe med at sikre fejltolerance. Standardisering: Der er flere tilgængelige RPC-rammer og protokoller, og det er vigtigt at vælge en standardiseret og bredt accepteret for at sikre interoperabilitet og kompatibilitet på tværs af forskellige platforme og programmeringssprog. Ydeevneindstilling: Det er vigtigt at finjustere RPC-systemet for optimal ydeevne. Dette kan involvere optimering af netværksprotokollen, minimering af de data, der overføres over netværket, og reduktion af latens og overhead forbundet med RPC-opkald.

RPC-problemer :
Problemer, der skal løses:

side ned tastatur

1. RPC Runtime:
RPC run-time system er et bibliotek af rutiner og et sæt tjenester, der håndterer den netværkskommunikation, der ligger til grund for RPC-mekanismen. I løbet af et RPC-opkald håndterer køretidssystemers kode på klient- og serversiden binding, etablere kommunikation over en passende protokol, videregive opkaldsdata mellem klienten og serveren og håndtere kommunikationsfejl.

2. Stub:
Stubbens funktion er at give gennemsigtighed til den programmørskrevne applikationskode .

java operatør forrang

På klientsiden håndterer stubben grænsefladen mellem klientens lokale procedurekald og runtime-systemet, rangerer og unmarshalling data, påkalder RPC runtime-protokollen og udfører, hvis det anmodes om det, nogle af bindingstrinnene. På serversiden giver stubben en lignende grænseflade mellem køretidssystemet og de lokale administratorprocedurer, der udføres af serveren.

3. Binding: Hvordan ved kunden, hvem han skal ringe til, og hvor tjenesten er bosat?
Den mest fleksible løsning er at bruge dynamisk binding og finde serveren på køretid, når RPC'en først laves. Første gang klientstubben kaldes, kontakter den en navneserver for at bestemme transportadressen, hvor serveren ligger.

Indbinding består af to dele:

Vi:
Placering:

En server, der har en tjeneste at tilbyde, eksporterer en grænseflade til den. Eksport af en grænseflade registrerer den i systemet, så klienter kan bruge den. En klient skal importere en (eksporteret) grænseflade, før kommunikationen kan begynde.

4. Opkaldssemantikken forbundet med RPC:
Det er hovedsageligt klassificeret i følgende valg-

FORDELE:

RPC giver ABSTRAKTION det vil sige, at meddelelsesoverførende karakter af netværkskommunikation er skjult for brugeren.
RPC udelader ofte mange af protokollagene for at forbedre ydeevnen. Selv en lille forbedring af ydeevnen er vigtig, fordi et program ofte kalder RPC'er.
RPC muliggør brugen af applikationerne i det distribuerede miljø, ikke kun i det lokale miljø.
Med RPC-kode minimeres indsatsen for omskrivning/genudvikling.
Procesorienterede og trådorienterede modeller understøttet af RPC.

Referencer:

TechCodeview