Proseduuripuhelu etänä

Kokeneet kirjoittajat eivät ole vielä tarkistaneet sivun nykyistä versiota, ja se voi poiketa merkittävästi 22. maaliskuuta 2021 tarkistetusta versiosta . tarkastukset vaativat 3 muokkausta .

Etämenettelykutsu ( joskus etäproseduurikutsu _ _ _ _  _ _ _ _ _ _ _ solmu). Tyypillisesti RPC-tekniikan toteutus sisältää kaksi komponenttia: verkkoprotokollan asiakas-palvelin-viestintää varten ja objektien serialointikielen (tai rakenteet ei-objektiivisille RPC:ille). Eri toteutuksilla on erilaiset arkkitehtuurit ja erilaiset ominaisuudet: toiset toteuttavat SOA -arkkitehtuuria , toiset - CORBAtai DCOM . Kuljetuskerroksessa RPC:t käyttävät pääasiassa TCP- ja UDP-protokollia , mutta osa niistä on rakennettu HTTP :n päälle (joka rikkoo ISO/OSI -arkkitehtuuria , koska HTTP ei ole alun perin siirtoprotokolla).

On monia tekniikoita, jotka tarjoavat RPC:tä, muun muassa:

Periaate

Etäproseduurien kutsumisen ideana on laajentaa ohjauksen ja datan siirtomekanismi samassa solmussa käynnissä olevan ohjelman sisällä ohjauksen ja datan siirtoon verkon yli. Etäproseduurikutsutyökalut on suunniteltu helpottamaan hajautetun laskennan organisointia ja hajautettujen asiakas-palvelin-tietojärjestelmien luomista. RPC:n tehokkain käyttö saavutetaan niissä sovelluksissa, joissa etäkomponenttien välillä on vuorovaikutteista viestintää pienellä vasteajalla ja suhteellisen pienellä siirrettävällä määrällä. Tällaisia ​​sovelluksia kutsutaan RPC-suuntautuneiksi.

Etämenettelypuhelun tärkeimmät ominaisuudet ovat:

Etäpuheluiden toteuttaminen on paljon monimutkaisempaa kuin paikallisten proseduuripuheluiden toteuttaminen.

Koska kutsuvat ja kutsutut proseduurit toimivat eri solmuissa, niillä on erilaiset osoiteavaruudet, mikä aiheuttaa ongelmia parametrien ja tulosten välittämisessä, varsinkin jos koneissa on eri käyttöjärjestelmät tai niillä on eri arkkitehtuuri (esim. little endian tai little endian on käytetty ). ). Koska RPC ei voi luottaa jaettuun muistiin, tämä tarkoittaa, että RPC-parametrit eivät saa sisältää osoittimia ei-pinomuistipaikkoihin ja että parametrien arvot on kopioitava tietokoneesta toiseen. Proseduurin parametrien ja suorituksen tuloksen kopioimiseksi verkon kautta ne sarjotetaan .

Toisin kuin paikallinen puhelu, etäproseduurikutsu käyttää välttämättä verkkoarkkitehtuurin siirtokerrosta (esimerkiksi TCP ), mutta tämä pysyy piilossa kehittäjältä. Lisäksi RPC:n toteutukseen osallistuu vähintään kaksi prosessia - yksi kussakin solmussa, ja jos yksi niistä kaatuu, voi syntyä seuraavia tilanteita: jos kutsuprosessi kaatuu, etäkutsutut prosessit jäävät orvoiksi ja jos etäproseduurit tulee soittomenettelyjen "köyhät vanhemmat", jotka odottavat vastausta etätoimenpiteistä turhaan.

Ohjelmointikielten ja toimintaympäristöjen heterogeenisyyteen liittyy myös useita ongelmia: missä tahansa ohjelmointikielessä tuettuja tietorakenteita ja proseduurikutsurakenteita ei tueta samalla tavalla kaikissa muissa kielissä. Siten on olemassa yhteensopivuusongelma, jota ei ole vielä ratkaistu ottamalla käyttöön yksi yleisesti hyväksytty standardi tai ottamalla käyttöön useita kilpailevia standardeja kaikissa arkkitehtuureissa ja kaikilla kielillä.

Komponentit

Keskeistä RPC-toteutuksissa on kuljetusalijärjestelmä, joka vastaa lähtevien ja saapuvien yhteyksien hallinnasta. Sen toimintoihin kuuluu tuki "viestirajan" käsitteelle siirtoprotokollille, jotka eivät tue sitä suoraan (TCP) ja tuki taatulle toimitukselle siirtoprotokollille, jotka eivät tue sitä (UDP).

Thread Pooling Component (vain Calle) - Tarjoaa suorituskontekstin verkon kautta kutsutulle koodille.

Järjestyskomponentti (analogisesti " serialisoinnin " kanssa ) varmistaa, että puheluparametrit pakataan tavuvirtaan tavallisella tavalla, joka on riippumaton arkkitehtuurista (erityisesti tavujen järjestyksestä sanassa). Erityisesti se voi vaikuttaa taulukoihin, merkkijonoihin ja rakenteisiin, joihin osoitinparametrit osoittavat.

Pakettien salaamisesta ja digitaalisesta allekirjoittamisesta voi vastata erillinen komponentti .

Erillinen toimintolohko on autentikointi ja valtuutus, jotka varmistavat puhelun soittajan tunnistavan tiedon siirron verkon yli.

Joissakin RPC:n (.NET Remoting) toteutuksissa alijärjestelmän rajat ovat avoimia polymorfisia rajapintoja, ja lähes kaikista luetelluista alijärjestelmistä on mahdollista kirjoittaa oma toteutus. Muissa toteutuksissa (DCE RPC Windowsissa) näin ei ole.

Muistiinpanot

  1. RFC-4627 . Haettu 13. marraskuuta 2008. Arkistoitu alkuperäisestä 1. tammikuuta 2016.
  2. JDK 5.0 Remote Method Invocation (RMI) -sovellusliittymät ja kehittäjäoppaat - Sun Microsystemsiltä . Haettu 13. marraskuuta 2008. Arkistoitu alkuperäisestä 19. joulukuuta 2008.
  3. RFC-4227
  4. RFC-1831 . Haettu 13. marraskuuta 2008. Arkistoitu alkuperäisestä 6. marraskuuta 2008.
  5. RFC-1833 . Haettu 13. marraskuuta 2008. Arkistoitu alkuperäisestä 25. lokakuuta 2008.
  6. RFC-3529 . Haettu 13. marraskuuta 2008. Arkistoitu alkuperäisestä 10. lokakuuta 2008.

Linkit