logo

TechCodeview

Remote Procedure Call (RPC) i operativsystemet

Remote Procedure Call (RPC) är en kraftfull teknik för att bygga distribuerade, klient-serverbaserade applikationer . Den bygger på att utöka det konventionella lokala förfarandet så att anropad procedur behöver inte finnas i samma adressutrymme som anropsproceduren . De två processerna kan vara på samma system, eller så kan de finnas på olika system med ett nätverk som ansluter dem.

När du ringer ett fjärranrop:



1. Den anropande miljön avbryts, procedurparametrar överförs över nätverket till miljön där proceduren ska utföras, och proceduren utförs där.

vad är en stack i java

2. När proceduren är klar och ger sina resultat, överförs dess resultat tillbaka till den anropande miljön, där exekveringen återupptas som om den återvände från ett vanligt proceduranrop.



OBS: RPC är särskilt väl lämpad för klient-server (t.ex. fråga-svar) interaktion där flödet av kontroll växlar mellan den som ringer och den som ringer . Konceptuellt körs inte både klienten och servern samtidigt. Istället hoppar utförandetråden från den som ringer till den som ringer och sedan tillbaka igen.

RPC fungerar



Följande steg sker under en RPC:

  1. En klient åberopar en klientstubbsprocedur , passerar parametrar på vanligt sätt. Klientstubben finns i klientens eget adressutrymme.
  2. Klientstubben marshalls (pack) parametrarna till ett meddelande. Marshalling inkluderar att konvertera representationen av parametrarna till ett standardformat och kopiera varje parameter till meddelandet.
  3. Klientstubben skickar meddelandet till transportlagret, som skickar det till fjärrservermaskinen.
  4. På servern skickar transportlagret meddelandet till en serverstub, som demarshalls (packa upp) parametrarna och anropar den önskade serverrutinen med användning av den vanliga procedurenropsmekanismen.
  5. När serverproceduren är klar återgår den till serverstubben (t.ex. via ett normalt förfarande samtalsretur) , som samlar returvärdena till ett meddelande. Serverstubben lämnar sedan meddelandet till transportlagret.
  6. Transportlagret skickar resultatmeddelandet tillbaka till klienttransportlagret, som lämnar tillbaka meddelandet till klientstubben.
  7. Klientstubben demarskallar returparametrarna och exekveringen returnerar till anroparen.

Viktiga överväganden för att designa och implementera RPC-system är:

    Säkerhet: Eftersom RPC involverar kommunikation över nätverket är säkerheten ett stort problem. Åtgärder som autentisering, kryptering och auktorisering måste implementeras för att förhindra obehörig åtkomst och skydda känslig data. Skalbarhet: När antalet klienter och servrar ökar, får RPC-systemets prestanda inte försämras. Lastbalanseringstekniker och effektivt resursutnyttjande är viktiga för skalbarheten. Feltolerans: RPC-systemet bör vara motståndskraftigt mot nätverksfel, serverkrascher och andra oväntade händelser. Åtgärder som redundans, failover och graciös degradering kan hjälpa till att säkerställa feltolerans. Standardisering: Det finns flera RPC-ramverk och protokoll tillgängliga, och det är viktigt att välja ett standardiserat och allmänt accepterat för att säkerställa interoperabilitet och kompatibilitet mellan olika plattformar och programmeringsspråk. Prestandajustering: Det är viktigt att finjustera RPC-systemet för optimal prestanda. Detta kan innebära att optimera nätverksprotokollet, minimera data som överförs över nätverket och minska latensen och overheaden som är förknippade med RPC-samtal.

RPC-FRÅGOR :
Frågor som måste åtgärdas:

nackdelar med internetbank

1. RPC-körtid:
RPC runtime system är ett bibliotek av rutiner och en uppsättning tjänster som hanterar nätverkskommunikationen som ligger till grund för RPC-mekanismen. Under ett RPC-samtal hanterar körtidssystemens kod på klientsidan och serversidan bindning, upprätta kommunikation över ett lämpligt protokoll, skicka samtalsdata mellan klienten och servern och hantera kommunikationsfel.

2. Stubb:
Stubbens funktion är att ge insyn i den programmerarskrivna applikationskoden .

strängfunktioner java
    På klientsidan hanterar stubben gränssnittet mellan klientens lokala proceduranrop och körtidssystemet, rangerar och tar bort data, anropar RPC-körtidsprotokollet och, om så begärs, utför några av bindningsstegen. På serversidan tillhandahåller stubben ett liknande gränssnitt mellan körtidssystemet och de lokala hanterarprocedurerna som exekveras av servern.

3. Bindande: Hur vet kunden vem han ska ringa och var tjänsten finns?
Den mest flexibla lösningen är att använda dynamisk bindning och hitta servern vid körning när RPC:n först görs. Första gången klientstubben anropas kontaktar den en namnserver för att fastställa transportadressen där servern finns.

Bindningen består av två delar:

  • Vi:
  • Plats:
    En server som har en tjänst att erbjuda exporterar ett gränssnitt för den. Export av ett gränssnitt registrerar det i systemet så att klienter kan använda det. En klient måste importera ett (exporterat) gränssnitt innan kommunikation kan påbörjas.

4. Samtalets semantik förknippad med RPC:
Det är främst klassificerat i följande val-

    Försök begära meddelande igen –
    Om du ska försöka skicka ett begäranmeddelande igen när en server har misslyckats eller mottagaren inte tagit emot meddelandet. Duplicerad filtrering –
    Ta bort dubblettserverförfrågningarna. Återsändning av resultat –
    Att återsända förlorade meddelanden utan att återutföra operationerna på serversidan.

FÖRDELAR:

  1. RPC tillhandahåller ABSTRAKTION d.v.s. meddelandeförmedlande karaktär av nätverkskommunikation är dold för användaren.
  2. RPC utelämnar ofta många av protokolllagren för att förbättra prestandan. Även en liten prestandaförbättring är viktig eftersom ett program kan anropa RPC:er ofta.
  3. RPC möjliggör användningen av applikationerna i den distribuerade miljön, inte bara i den lokala miljön.
  4. Med RPC-kod minimeras omskrivning / omutveckling.
  5. Processorienterade och trådorienterade modeller som stöds av RPC.

Referenser: