Remote Procedure Call (RPC) er en kraftig teknikk for å bygge distribuerte, klient-serverbaserte applikasjoner . Den er basert på å utvide den konvensjonelle lokale prosedyrekallingen slik at kalt prosedyre trenger ikke eksistere i samme adresserom som anropsprosedyren . De to prosessene kan være på samme system, eller de kan være på forskjellige systemer med et nettverk som forbinder dem.
Når du foretar et eksternt prosedyreanrop:
1. Det anropende miljøet suspenderes, prosedyreparametere overføres over nettverket til miljøet der prosedyren skal utføres, og prosedyren utføres der.
dvaledialekt
2. Når prosedyren er ferdig og produserer resultatene, blir resultatene overført tilbake til anropsmiljøet, hvor kjøringen fortsetter som om den kom tilbake fra et vanlig prosedyrekall.
MERK: RPC er spesielt godt egnet for klient-server (f.eks. spørring-svar) interaksjon der flyten av kontroll veksler mellom den som ringer og den som ringer . Konseptuelt kjører ikke klienten og serveren begge samtidig. I stedet hopper utførelsestråden fra den som ringer til den som ringer og deretter tilbake igjen.
Arbeid av RPC
Følgende trinn finner sted under en RPC:
- En klient påberoper seg en klient stubb prosedyre , passerer parametere på vanlig måte. Klientstubben ligger innenfor klientens eget adresseområde.
- Klientstubben marshalls (pakke) parametrene i en melding. Marshalling inkluderer å konvertere representasjonen av parameterne til et standardformat, og kopiere hver parameter inn i meldingen.
- Klientstubben sender meldingen til transportlaget, som sender den til den eksterne servermaskinen.
- På serveren sender transportlaget meldingen til en serverstubb, som demarshalls (pakke ut) parametrene og kaller den ønskede serverrutinen ved å bruke den vanlige prosedyrekallingsmekanismen.
- Når serverprosedyren er fullført, går den tilbake til serverstubben (f.eks. via en normal prosedyre anropsretur) , som samler returverdiene til en melding. Serverstubben sender deretter meldingen til transportlaget.
- Transportlaget sender resultatmeldingen tilbake til klienttransportlaget, som leverer meldingen tilbake til klientstubben.
- Klientstubben demarshaller returparameterne og utførelsen returnerer til den som ringer.
Viktige hensyn for å designe og implementere RPC-systemer er:
- Sikkerhet: Siden RPC involverer kommunikasjon over nettverket, er sikkerhet en stor bekymring. Tiltak som autentisering, kryptering og autorisasjon må implementeres for å forhindre uautorisert tilgang og beskytte sensitive data. Skalerbarhet: Ettersom antallet klienter og servere øker, må ikke ytelsen til RPC-systemet forringes. Lastbalanseringsteknikker og effektiv ressursutnyttelse er viktig for skalerbarhet. Feiltoleranse: RPC-systemet bør være motstandsdyktig mot nettverksfeil, serverkrasj og andre uventede hendelser. Tiltak som redundans, failover og grasiøs degradering kan bidra til å sikre feiltoleranse. Standardisering: Det er flere RPC-rammeverk og protokoller tilgjengelig, og det er viktig å velge en standardisert og allment akseptert for å sikre interoperabilitet og kompatibilitet på tvers av forskjellige plattformer og programmeringsspråk. Ytelsesinnstilling: Finjustering av RPC-systemet for optimal ytelse er viktig. Dette kan innebære å optimalisere nettverksprotokollen, minimere dataene som overføres over nettverket, og redusere ventetiden og overhead knyttet til RPC-anrop.
RPC-PROBLEM :
Problemer som må løses:
'murerens formel'
1. RPC kjøretid:
RPC run-time system er et bibliotek med rutiner og et sett med tjenester som håndterer nettverkskommunikasjonen som ligger til grunn for RPC-mekanismen. I løpet av et RPC-anrop håndterer kjøretidssystemene på klientsiden og serversiden binding, etablere kommunikasjon over en passende protokoll, sende samtaledata mellom klienten og serveren og håndtere kommunikasjonsfeil.
2. Stubb:
Stubbens funksjon er å gi åpenhet til den programmerer-skrevne applikasjonskoden .
java-operatørprioritet
- På klientsiden håndterer stubben grensesnittet mellom klientens lokale prosedyrekall og kjøretidssystemet, rangerer og unmarshaller data, påkaller RPC-kjøretidsprotokollen og utfører noen av bindingstrinnene hvis det blir bedt om det. På serversiden gir stubben et lignende grensesnitt mellom kjøretidssystemet og de lokale administratorprosedyrene som utføres av serveren.
3. Binding: Hvordan vet klienten hvem han skal ringe, og hvor tjenesten holder til?
Den mest fleksible løsningen er å bruke dynamisk binding og finne serveren på kjøretid når RPC først lages. Første gang klientstubben påkalles, kontakter den en navneserver for å fastslå transportadressen serveren befinner seg på.
Innbinding består av to deler:
- Vi:
- Plassering:
- En server som har en tjeneste å tilby, eksporterer et grensesnitt for den. Ved å eksportere et grensesnitt registreres det i systemet slik at klienter kan bruke det. En klient må importere et (eksportert) grensesnitt før kommunikasjon kan begynne.
4. Samtalesemantikken knyttet til RPC:
Det er hovedsakelig klassifisert i følgende valg-
- Forespørselsmelding på nytt –
Om du skal prøve å sende en forespørselsmelding på nytt når en server har sviktet eller mottakeren ikke mottok meldingen. Duplikatfiltrering –
Fjern dupliserte serverforespørsler. Videresending av resultater –
Å sende tapte meldinger på nytt uten å utføre operasjonene på nytt på serversiden.
FORDELER :
- RPC gir ABSTRAKSJON dvs. nettverkskommunikasjon er skjult for brukeren.
- RPC utelater ofte mange av protokolllagene for å forbedre ytelsen. Selv en liten ytelsesforbedring er viktig fordi et program kan påkalle RPCer ofte.
- RPC muliggjør bruk av applikasjonene i det distribuerte miljøet, ikke bare i det lokale miljøet.
- Med RPC-kode minimeres omskriving / re-utvikling innsats.
- Prosessorienterte og trådorienterte modeller støttet av RPC.
Referanser:
- https://web.cs.wpi.edu/~cs4514/b98/week8-rpc/week8-rpc.html
- https://users.cs.cf.ac.uk/Dave.Marshall/C/node33.html
- Datanettverk: A Top – Down Approach av FOROUZAN