logo

Remote Procedure Call (RPC) käyttöjärjestelmässä

Remote Procedure Call (RPC) on tehokas rakennustekniikka hajautetut, asiakaspalvelinpohjaiset sovellukset . Se perustuu tavanomaisen paikallisen kutsun laajentamiseen niin, että kutsutun proseduurin ei tarvitse olla samassa osoiteavaruudessa kuin kutsuvan proseduurin . Nämä kaksi prosessia voivat olla samassa järjestelmässä tai ne voivat olla eri järjestelmissä, joissa verkko yhdistää ne.

Kun soitat etämenettelypuhelun:



1. Kutsuva ympäristö keskeytetään, proseduuriparametrit siirretään verkon yli ympäristöön, jossa proseduuri suoritetaan, ja proseduuri suoritetaan siellä.

seleeni opetusohjelma java

2. Kun proseduuri on valmis ja tuottaa tulokset, sen tulokset siirretään takaisin kutsuvaan ympäristöön, jossa suoritus jatkuu ikään kuin palaisi normaalista proseduurikutsusta.



HUOMAA: RPC sopii erityisen hyvin asiakas-palvelimelle (esim. kyselyvastaus) vuorovaikutus, jossa virtaus ohjaus vuorotellen soittajan ja soitetun välillä . Käsitteellisesti asiakas ja palvelin eivät suorita molemmat samaan aikaan. Sen sijaan suorituksen lanka hyppää soittajalta kutsuttavalle ja sitten takaisin.

RPC:n toiminta



Seuraavat vaiheet tapahtuvat RPC:n aikana:

  1. Asiakas pyytää a asiakkaan tynkämenettely , välittää parametrit tavalliseen tapaan. Asiakkaan tynkä sijaitsee asiakkaan omassa osoiteavaruudessa.
  2. Asiakas tynkä marsallit (pakkaus) parametrit viestiin. Marshalling sisältää parametrien esityksen muuntamisen vakiomuotoon ja kunkin parametrin kopioimisen viestiin.
  3. Asiakkaan tynkä välittää viestin siirtokerrokselle, joka lähettää sen etäpalvelinkoneelle.
  4. Palvelimella siirtokerros välittää viestin palvelimen tynkälle, joka demarshall (purkaa pakkauksesta) parametrit ja kutsuu halutun palvelinrutiinin tavallisella proseduurikutsumekanismilla.
  5. Kun palvelintoiminto on valmis, se palaa palvelimen tyngään (esim. normaalin menettelyn puhelun paluu kautta) , joka järjestää palautusarvot viestiksi. Palvelimen tynkä luovuttaa sitten viestin siirtokerrokselle.
  6. Kuljetuskerros lähettää tulosviestin takaisin asiakkaan siirtokerrokseen, joka luovuttaa viestin takaisin asiakkaan tynkälle.
  7. Asiakkaan tynkä demarshall palautusparametrit ja suoritus palaa soittajalle.

Tärkeimmät näkökohdat RPC-järjestelmien suunnittelussa ja toteutuksessa ovat:

    Suojaus: Koska RPC sisältää tiedonsiirron verkon kautta, turvallisuus on suuri huolenaihe. Todentamisen, salauksen ja valtuutuksen kaltaisia ​​toimenpiteitä on toteutettava luvattoman käytön estämiseksi ja arkaluonteisten tietojen suojaamiseksi. Skaalautuvuus: Asiakkaiden ja palvelimien määrän kasvaessa RPC-järjestelmän suorituskyky ei saa heikentyä. Kuormantasaustekniikat ja tehokas resurssien käyttö ovat tärkeitä skaalautuvuuden kannalta. Vikasietokyky: RPC-järjestelmän tulee kestää verkkovikoja, palvelinkaatumisia ja muita odottamattomia tapahtumia. Toimenpiteet, kuten redundanssi, vikasietoisuus ja sulava heikkeneminen, voivat auttaa varmistamaan vikasietoisuuden. Standardointi: Saatavilla on useita RPC-kehyksiä ja protokollia, ja on tärkeää valita standardisoitu ja laajalti hyväksytty, jotta voidaan varmistaa yhteentoimivuus ja yhteensopivuus eri alustojen ja ohjelmointikielien välillä. Suorituskyvyn viritys: RPC-järjestelmän hienosäätö optimaalisen suorituskyvyn saavuttamiseksi on tärkeää. Tämä voi sisältää verkkoprotokollan optimoinnin, verkon kautta siirrettävien tietojen minimoimisen ja RPC-puheluihin liittyvän viiveen ja ylikuormituksen vähentämisen.

RPC-ONGMAT :
Asiat, jotka on ratkaistava:

aseta java

1. RPC-ajoaika:
RPC-ajonaikainen järjestelmä on kirjasto rutiineja ja palveluita, jotka käsittelevät RPC-mekanismin taustalla olevaa verkkoviestintää. RPC-puhelun aikana asiakas- ja palvelinpuolen ajonaikaisten järjestelmien koodinkäsittely sitoa, muodostaa viestintää sopivan protokollan kautta, siirtää puhelutiedot asiakkaan ja palvelimen välillä ja käsitellä viestintävirheitä.

2. Kansi:
Kannen tehtävänä on antaa ohjelmoijan kirjoittaman sovelluskoodin läpinäkyvyyden .

    Asiakaspuolella tynkä käsittelee asiakkaan paikallisen proseduurikutsun ja ajonaikaisen järjestelmän välistä rajapintaa, ryhmittelee ja purkaa tiedot, vetoaa RPC-ajonaikaiseen protokollaan ja suorittaa pyydettäessä joitain sidontavaiheita. Palvelinpuolella tynkä tarjoaa samanlaisen rajapinnan ajonaikaisen järjestelmän ja palvelimen suorittamien paikallisten hallintatoimintojen välillä.

3. Sitoutuminen: Mistä asiakas tietää, kenelle soittaa ja missä palvelu sijaitsee?
Joustavin ratkaisu on käyttää dynaamista sidontaa ja etsiä palvelin ajon aikana, kun RPC tehdään ensimmäisen kerran. Ensimmäistä kertaa asiakkaan tynkä kutsua, se ottaa yhteyttä nimipalvelimeen määrittääkseen siirtoosoitteen, jossa palvelin sijaitsee.

Sidonta koostuu kahdesta osasta:

  • Me:
  • Sijainti:
    Palvelin, jolla on tarjota palvelu, vie sille käyttöliittymän. Liittymän vienti rekisteröi sen järjestelmään, jotta asiakkaat voivat käyttää sitä. Asiakkaan on tuotava (viety) käyttöliittymä ennen kuin viestintä voi alkaa.

4. RPC:hen liittyvä kutsun semantiikka:
Se luokitellaan pääasiassa seuraaviin valintoihin:

    Yritä uudelleen pyyntöviesti –
    Yritetäänkö pyyntöviestin lähettäminen uudelleen, kun palvelin on epäonnistunut tai vastaanottaja ei saanut viestiä. Kaksoissuodatus –
    Poista päällekkäiset palvelinpyynnöt. Tulosten uudelleenlähetys –
    Kadonneiden viestien lähettäminen uudelleen suorittamatta toimintoja uudelleen palvelinpuolella.

EDUT:

bourne-ain -kuori
  1. RPC tarjoaa ABSTRAKTIO eli verkkoviestinnän viestinvälitysluonne on piilotettu käyttäjältä.
  2. RPC jättää usein pois monia protokollakerroksia suorituskyvyn parantamiseksi. Pienikin suorituskyvyn parannus on tärkeä, koska ohjelma voi usein kutsua RPC:itä.
  3. RPC mahdollistaa sovellusten käytön hajautetussa ympäristössä, ei vain paikallisessa ympäristössä.
  4. RPC-koodin avulla uudelleenkirjoitus/uudelleenkehitystyö on minimoitu.
  5. RPC:n tukemat prosessisuuntaiset ja säiesuuntaiset mallit.

Viitteet: