Ohjelmat, jotka kommunikoivat verkon kautta, tarvitsevat viestintämekanismin. Alemmalla tasolla pakettien saapuessa verkon signaalinkäsittelyohjelma käsittelee signaalin. Ylimmällä tasolla toimii tapaamismekanismi (tapaaminen), joka on hyväksytty adakielellä. NFS käyttää etäproseduurikutsumekanismia (RPC), jossa asiakas kommunikoi palvelimen kanssa (katso kuva 1). Tämän prosessin mukaisesti asiakas käyttää ensin menettelyä, joka lähettää pyynnön palvelimelle. Kun paketti saapuu pyynnöllä, palvelin kutsuu sen avaamismenettelyn, suorittaa pyydetyn palvelun, lähettää vastauksen ja ohjaus palautetaan asiakkaalle.
RPC -käyttöliittymässä voidaan ajatella olevan kolme kerrosta:
Ylempi taso on täysin läpinäkyvä. Tämän tason ohjelma voi esimerkiksi soittaa rnusers (), joka palauttaa etäkoneen käyttäjien määrän. Sinun ei tarvitse tietää RPC -mekanismin käytöstä, koska soitat ohjelmassa.
Keskitaso on yleisimmille sovelluksille. Tämän tason RPC-kutsuja käsittelevät registerrpc ()-ja callrpc () -rutiinit: registerrpc () vastaanottaa koko järjestelmän kattavan tumman koodin ja callrpc () suorittaa etäproseduurikutsun. Rnusers () -puhelu toteutetaan käyttämällä näitä kahta rutiinia.
Alempaa tasoa käytetään monimutkaisempiin tehtäviin, jolloin oletusasetukset muutetaan menettelyparametrien arvoiksi. Tällä tasolla voit nimenomaisesti manipuloida RPC -sanomien lähettämiseen käytettäviä pistorasioita.
Pääsääntöisesti sinun tulee käyttää ylempää kerrosta ja välttää alempien kerrosten tarpeetonta käyttöä.
Huolimatta siitä, että tässä opetusohjelmassa otamme huomioon vain C -käyttöliittymän, etäproseduureja voidaan soittaa mistä tahansa kielestä. RPC -mekanismin työ prosessien välisen viestinnän järjestämiseksi eri koneilla ei eroa sen työstä samalla koneella.
RPC (Remote Procedure Call) on rajapinta etäkäyttäjien ja tiettyjen isäntäohjelmien välillä, joita nämä käyttäjät käyttävät. Isännän RPC -palvelu tarjoaa tyypillisesti asiakkaille joukon ohjelmia. Jokainen näistä ohjelmista koostuu vuorostaan yhdestä tai useammasta etäproseduurista. Esimerkiksi RPC-puheluihin perustuva NFS-etätiedostojärjestelmäpalvelu voi koostua vain kahdesta ohjelmasta: esimerkiksi yksi ohjelma on vuorovaikutuksessa korkean tason käyttöliittymien kanssa ja toinen matalan tason I / O-toimintojen kanssa.
Jokaisessa RPC -kutsussa on kaksi osapuolta: aktiivinen asiakas, joka lähettää menettelykutsupyynnön palvelimelle, ja palvelin, joka lähettää vastauksen asiakkaalle.
Huomautus. On pidettävä mielessä, että termit "asiakas" ja "palvelin" viittaavat tässä tapauksessa tiettyyn tapahtumakohtaiseen isäntään tai ohjelmisto(prosessi tai ohjelma) voi toimia asiakkaana tai palvelimena. Esimerkiksi etäproseduuripalvelua tarjoava ohjelma voi samanaikaisesti olla verkkotiedostojärjestelmän asiakas.
RPC perustuu etämenettelykutsumalliin, joka on samanlainen kuin paikalliset proseduurikutsut. Kun kutsut paikallisen menettelyn, työnnät argumentteja tiettyyn muistipaikkaan, pinoon tai ympäristömuuttujiin ja siirrät prosessin hallinnan tiettyyn osoitteeseen. Kun olet suorittanut työn, luet tulokset tiettyyn osoitteeseen ja jatkat prosessia.
Etäproseduurin tapauksessa tärkein ero on se, että etätoimintokutsua palvelee kaksi prosessia: asiakasprosessi ja palvelinprosessi.
Asiakasprosessi lähettää palvelimelle viestin, joka sisältää kutsutun menettelyn parametrit, ja odottaa vastaussanomaa työnsä tulosten kanssa. Kun vastaus vastaanotetaan, tulos luetaan ja prosessi jatkuu. Palvelinpuolella puhelunkäsittelyprosessi on odotustilassa, ja kun viesti saapuu, se lukee toimenpideparametrit, suorittaa sen, lähettää vastauksen ja siirtyy seuraavan puhelun odotustilaan.
RPC-protokolla ei aseta mitään vaatimuksia prosessien välisille lisäyhteyksille eikä vaadi suoritettujen toimintojen synkronointia, toisin sanoen puhelut voivat olla asynkronisia ja ei-riippumattomia, jotta asiakas voi suorittaa muita toimenpiteitä odottaessaan vastausta. RPC -palvelin voi varata kullekin toiminnolle erillisen prosessin tai virtuaalikoneen, joten odottamatta aikaisempien pyyntöjen suorittamista se voi heti hyväksyä seuraavan.
Paikallisten ja etäproseduurikutsujen välillä on kuitenkin useita tärkeitä eroja:
1. Virhe käsittelyssä. Asiakkaalle tulee joka tapauksessa ilmoittaa virheistä, joita ilmenee, kun palvelimen tai verkon etämenettelyjä kutsutaan.
2. Globaalit muuttujat. Koska palvelimella ei ole pääsyä asiakkaan osoitetilaan, et voi käyttää piilotettuja parametreja globaalimuuttujien muodossa etäproseduuripuheluissa.
3. Esitys. Etäproseduurien suoritusnopeus on pääsääntöisesti yksi tai kaksi suuruusluokkaa pienempi kuin vastaavien paikallisten toimenpiteiden suoritusnopeus.
4. Todentaminen. Koska etäproseduurikutsut tapahtuvat verkon kautta, on käytettävä asiakkaan todennusmekanismeja.
Protokollan rakentamisen periaatteet.
RPC -protokolla voi käyttää useita erilaisia siirtoprotokollia. RPC -protokollan ainoat velvollisuudet ovat standardien noudattaminen ja sanomansiirron tulkinta. Sanomien lähetyksen luotettavuus ja luotettavuus varmistetaan kokonaan siirtokerroksella.
RPC voi kuitenkin hallita siirtoprotokollan valintaa ja joitakin toimintoja. Esimerkkinä RPC: n ja siirtoprotokollan välisestä vuorovaikutuksesta harkitse menettelyä sovellusprosessin RPC -portin määrittämiseksi RPC: n kautta - Portmapper.
Tämä toiminto määrittää dynaamisesti (pyynnöstä) tietyn portin RPC -yhteydelle. Toiminto Portmapper käytetään melko usein, koska RPC: lle varattujen kuljetusporttien joukko on rajallinen ja samanaikaisesti mahdollisesti suoritettavien prosessien määrä on erittäin suuri. Portmapper esimerkiksi soitetaan, kun NFS -asiakas / palvelin -tietoliikenneportit on valittu.
Palvelu Portmapper käyttää RPC -lähetysmekanismia tiettyyn porttiin - III. Tässä portissa asiakas lähettää pyynnön tietyn RPC -palvelun portille. Palvelu Portmapper käsittelee verosanoman, määrittää paikallisen RPC -palvelun osoitteen ja lähettää vastauksen asiakkaalle. RPC -palvelu Portmapper voi toimia sekä TCP- että UDP -protokollien kanssa.
RPC voi toimia erilaisten siirtoprotokollien kanssa, mutta se ei koskaan kopioi niiden toimintoja, eli jos RPC toimii TCP: n päällä, RPC jättää kaikki huolet TCP -yhteyden luotettavuudesta. Jos RPC on kuitenkin asennettu UDP: n päälle, se voi tarjota lisäominaisuuksia viestin toimittamisen varmistamiseksi.
Huomautus. Sovellukset voivat tarkastella RPC -protokollaa määriteltynä toimintokutsumenettelynä JSR (Jump Subroutine Instruction) -verkon kautta.
Jotta RPC -protokolla toimisi, seuraavien ehtojen on täytyttävä:
1. Ainutlaatuinen tunnistus kaikista etäkutsuista menettelyistä tietyssä isännässä. RPC -pyynnöt sisältävät kolme tunnistekenttää - etäohjelman (palvelun) numeron, etäohjelman versionumeron ja määritetyn ohjelman etäproseduurin numeron. Ohjelmanumeron antaa palvelun valmistaja, toimenpiteen numero osoittaa tämän palvelun nimenomaisen toiminnon
2. RPC -protokollan version tunnistaminen. RPC -viestit sisältävät RPC -protokollan versiokentän. Sitä käytetään vastaamaan lähetettyjen parametrien muotoja, kun asiakas työskentelee eri RPC -versioiden kanssa.
3. Järjestelmän tarjoaminen asiakkaan todentamiseksi palvelimelle. RPC -protokolla tarjoaa menettelyn asiakkaan todentamiseksi palvelussa ja tarvittaessa jokaiseen pyyntöön tai vastauksen lähettämiseen asiakkaalle. Lisäksi RPC mahdollistaa useita muita turvamekanismeja.
RPC voi käyttää neljää erilaista todennusmekanismia:
AUTH_NULL - todennusta ei ole käytetty
AUTH_UNIX - UNIX -vakiotodennus
AUTH_SHORT - UNIX -todennus omalla koodausrakenteellaan
AUTH_DES - DES -todennus
4. Vastaavien pyyntöjen vastausviestien tunnistaminen. RPC -vastausviestit sisältävät sen pyynnön tunnuksen, johon ne perustuivat. Tätä tunnistetta voidaan kutsua RPC -puhelun tapahtumatunnisteeksi. Tämä mekanismi on erityisen hyödyllinen työskenneltäessä asynkronisessa tilassa ja suoritettaessa useita RPC -puheluja.
5. Protokollavirheiden tunnistaminen. Kaikilla verkko- tai palvelinvirheillä on yksilölliset tunnisteet, joiden avulla kukin yhteyshenkilö voi määrittää vian syyn.
Protokollan sanomarakenteet
Kun RPC -viestejä siirretään kuljetusprotokollan kautta, useita RPC -viestejä voi sijaita yhdessä kuljetuspaketissa. Yhden viestin erottamiseksi toisesta käytetään tietueiden merkintää (RM - Record Marker). Jokainen RPC -viesti on "merkitty" täsmälleen yhdellä RM: llä.
RPC -viesti voi koostua useista osista. Jokainen osa koostuu neljästä tavusta otsikkoa ja (0-2 ** 31-1) dataa. Otsikon ensimmäinen bitti osoittaa, onko pala viimeinen, ja loput 31 bittiä osoittavat datapaketin pituuden.
RPC -rakenne kuvataan muodollisesti kuvausformaatin kuvaus- ja esityskielellä - XDR, jossa on lisäyksiä menettelyjen kuvaukseen. Voit jopa sanoa, että RPC -merkintäkieli on XDR: n laajennus, jota täydennetään toimenpiteillä.
RPC -paketin rakenne näyttää tältä:
structure rpc_msg (
allekirjoittamaton int xid;
liitinkytkin (msg_type mtype) (
call_body cbody;
vastaus body rbody;
jossa xid on nykyisen tapahtuman tunniste, call_body on pyyntöpaketti, vastaus_body on vastauspaketti. Pyyntörakenne näyttää tältä:
strukture call body (
allekirjoittamattomat int rpcvers;
allekirjoittamaton int -ohjelma;
allekirjoittamaton int vers;
allekirjoittamaton int proc;
läpinäkymätön_auth cred;
opaque_auth verf;
/ * menettelyn parametrit * /
Vastaus_rakenne -rakenne voi sisältää joko virheen sattuessa välitetyn rakenteen (jolloin se sisältää virhekoodin) tai rakenteen pyynnön onnistuneelle käsittelylle (jolloin se sisältää palautetut tiedot).
Korkean tason ohjelmointirajapinta.
Aliohjelmien käyttäminen ohjelmassa on perinteinen tapa rakentaa tehtävä selkeämmäksi. Useimmin käytetyt aliohjelmat kerätään kirjastoihin, joissa niitä voidaan käyttää eri ohjelmissa. Tässä tapauksessa puhumme paikallisesta (paikallisesta) puhelusta, eli sekä soittaja että kutsutut objektit toimivat samassa ohjelmassa samassa tietokoneessa.
Jos kyseessä on etäkutsu, yhdellä tietokoneella käynnissä oleva prosessi käynnistää prosessin etätietokoneella (eli se todella suorittaa menettelykoodin etätietokoneessa). On selvää, että etäproseduurikutsu eroaa merkittävästi perinteisestä paikallisesta, mutta ohjelmoijan näkökulmasta tällaisia eroja ei käytännössä ole, toisin sanoen etäproseduurikutsun arkkitehtuurin avulla voit simuloida paikallista puhelua.
Kuitenkin, jos ohjelma lähettää paikallisen puhelun tapauksessa parametrit kutsutulle menettelylle ja vastaanottaa työnsä tuloksen pinon tai jaetun muistialueen kautta, niin etäpuhelun tapauksessa parametrien siirto muuttuu lähetetään pyyntö verkon kautta, ja työn tulos on vastaanotetussa vastauksessa.
Tämä lähestymistapa on mahdollinen perusta hajautettujen sovellusten luomiseen, ja vaikka monet nykyaikaiset järjestelmät eivät käytä tätä mekanismia, peruskäsitteet ja termit jäävät monissa tapauksissa. RPC -mekanismia kuvattaessa viitataan perinteisesti kutsuprosessiin asiakkaana ja etäprosessiksi, joka toteuttaa menettelyn palvelimena.
Etämenettelykutsu sisältää seuraavat vaiheet:
1. Asiakasohjelma soittaa paikallisesti kutsuun, jota kutsutaan tynkäksi. Tässä tapauksessa asiakas "näyttää" siltä, että soittamalla tynkään se itse asiassa soittaa palvelimen menettelyyn. Itse asiassa asiakas välittää vaaditut parametrit tynkään ja palauttaa tuloksen. Asiakas ei kuitenkaan ajattele sitä näin. Tynkän tehtävä on hyväksyä argumentit etäproseduuria varten, mahdollisesti muuntaa ne johonkin vakiomuotoon ja muodostaa verkkopyyntö. Argumenttien pakkaamista ja verkkopyynnön tekemistä kutsutaan järjestelyksi.
2. Verkkopyyntö lähetetään verkon kautta etäjärjestelmään. Tätä varten tynkä käyttää sopivia puheluita, esimerkiksi niitä, joita on käsitelty edellisissä osissa. Huomaa, että tässä tapauksessa voidaan käyttää erilaisia siirtoprotokollia eikä vain TCP / IP -perhettä.
3. Etäisännässä kaikki tapahtuu päinvastaisessa järjestyksessä. Palvelinyksikkö odottaa pyyntöä ja vastaanottaa vastaanotettuaan parametrit - menettelykutsun argumentit. Purkaminen (purkaminen) voi sisältää tarvittavia muunnoksia (esimerkiksi tavujen järjestyksen muuttaminen).
4. Tynkä soittaa todelliselle palvelinmenettelylle, johon asiakkaan pyyntö on osoitettu, välittäen sille verkon kautta vastaanotetut argumentit.
5. Kun toimenpide on suoritettu, ohjaus palaa palvelimen tynkälle ja välittää sille tarvittavat parametrit. Kuten asiakkaan tynkä; palvelimen tynkä muuntaa menettelyn palauttamat arvot muodostamaan verkon vastaussanoman, joka lähetetään verkon kautta järjestelmään, josta pyyntö tuli.
6. Käyttöjärjestelmä välittää vastaanotetun viestin asiakkaan tynkälle, joka tarvittavan muunnoksen jälkeen välittää arvot (jotka ovat etäproseduurin palauttamia arvoja) asiakkaalle, joka tulkitsee tämän normaaliksi palautukseksi menettelystä.
Näin ollen se soittaa asiakkaan näkökulmasta etäproseduurikutsun kuten paikallisellekin. Samaa voidaan sanoa palvelimesta: proseduuri kutsutaan normaalilla tavalla, objekti (palvelimen tynkä) kutsuu paikallisen menettelyn ja vastaanottaa sen palauttamat arvot. Asiakas käsittelee tynkää kutsuttavana palvelinmenettelynä ja palvelin tulkitsee oman tynkänsä asiakkaaksi.
Näin ollen tynkät muodostavat RPC -järjestelmän ytimen, joka vastaa kaikesta viestin luomisesta ja lähettämisestä asiakkaan ja etäpalvelimen välillä (menettely), vaikka sekä asiakas että palvelin olettavat, että puhelut soitetaan paikallisesti. Tämä on RPC: n peruskäsite - piilottaa viestinnän hajautettu (verkko) luonne kokonaan tynkäkoodiin. Tämän lähestymistavan edut ovat ilmeisiä: sekä asiakas että palvelin ovat riippumattomia verkon toteutuksesta, molemmat toimivat jonkinlaisen hajautetun kehyksen puitteissa virtuaalikone, ja menettelykutsuilla on vakiorajapinta.
Parametrien välittäminen
Arvoarvojen siirtäminen on yksinkertaista. Tässä tapauksessa asiakastynkki asettaa parametrin arvon verkkopyyntöön ja mahdollisesti suorittaa muunnoksia vakiolomakkeeseen (esimerkiksi muuttaa tavujärjestystä). Tilanne ohitusosoittimien kanssa on paljon monimutkaisempi, kun parametri on tietojen osoite eikä niiden arvo. Osoitteen välittäminen pyynnössä on merkityksetöntä, koska etäproseduuri suoritetaan täysin eri osoitetilassa. Yksinkertaisin RPC -ratkaisu on estää asiakkaita välittämästä parametreja muutoin kuin arvon mukaan, vaikka tämä asettaa varmasti vakavia rajoituksia.
Sidonta
Ennen kuin asiakas voi kutsua etäproseduurin, sen on muodostettava yhteys etäjärjestelmään, joka isännöi vaadittua palvelinta. Siten linkittämisen tehtävä on jaettu kahteen:
Etäisännän etsiminen tarvittavalla palvelimella
Tarvittavan palvelinprosessin löytäminen tietystä isännästä
Isännän löytämiseen voidaan käyttää erilaisia lähestymistapoja. Mahdollinen vaihtoehto on luoda jonkinlainen keskitetty hakemisto, jossa isännät ilmoittavat palvelimistaan ja jossa asiakas voi halutessaan valita itselleen sopivan isännän ja toimenpideosoitteen.
Jokainen RPC -menettely tunnistetaan yksilöllisesti ohjelman ja toimenpiteen numerolla. Ohjelmanumero määrittää ryhmän etäproseduureja, joista jokaisella on oma numero. Jokaiselle ohjelmalle annetaan myös versionumero, joten kun ohjelmaan tehdään pieniä muutoksia (esimerkiksi lisättäessä menettelyä), sen numeroa ei tarvitse muuttaa. Yleensä yhdessä ohjelmamoduulissa toteutetaan useita toiminnallisesti samankaltaisia proseduureja, joista käynnistettäessä tulee näiden menettelyjen palvelin ja jotka tunnistetaan ohjelmanumerolla.
Kun asiakas haluaa soittaa etäproseduuriin, hänen on siis tiedettävä vaaditun palvelun tarjoava ohjelma, versio ja menettelynumerot.
Pyynnön välittämiseksi asiakkaan on myös tiedettävä isännän verkko -osoite ja portin numero, jotka liittyvät vaadittuja menettelyjä tarjoavaan palvelinohjelmaan. Tämä tehdään käyttämällä portmap (IM) -demonia (jota kutsutaan joissakin järjestelmissä rpcbind (IM)). Daemon toimii isäntänä, joka tarjoaa etäproseduuripalvelun, ja käyttää tunnettua porttinumeroa. Kun palvelinprosessi käynnistyy, se rekisteröi rutiinit ja porttinumerot porttikarttaan (IM). Nyt kun asiakkaan on tiedettävä portin numero soittaakseen tiettyyn menettelyyn, se lähettää pyynnön porttikartta (IM) -palvelimelle, joka puolestaan joko palauttaa portin numeron tai ohjaa pyynnön suoraan RPC -palvelimelle ja palauttaa vastaus asiakkaalle sen suorittamisen jälkeen. Joka tapauksessa, jos vaadittu menettely on olemassa, asiakas saa menettelyn porttinumeron porttikarttapalvelimelta (IM) ja lisäpyynnöt voidaan tehdä suoraan tälle portille.
Poikkeusten käsittely
Poikkeusten käsittely paikallisia menettelyjä kutsuttaessa ei ole erityisen ongelmallista. UNIX käsittelee prosessivirheet, kuten jaon nollalla, virheelliset muistikäytöt jne. Etämenettelyn kutsuminen lisää virhetilanteiden todennäköisyyttä. Palvelimeen ja tynkävirheisiin lisätään virheitä, jotka liittyvät esimerkiksi virheellisen verkkoviestin vastaanottamiseen.
Esimerkiksi kun UDP: tä käytetään siirtoprotokollana, viestit lähetetään uudelleen tietyn aikakatkaisun jälkeen. Virhe palautetaan asiakkaalle, jos palvelimelta ei ole saatu vastausta tietyn määrän yritysten jälkeen. Jos käytetään TCP -protokollaa, asiakas palauttaa virheen, jos palvelin katkaisee TCP -yhteyden.
Kutsu semantiikkaa
Paikallisen menettelyn kutsuminen johtaa yksiselitteisesti sen suorittamiseen, minkä jälkeen ohjaus palaa pääohjelmaan. Tilanne on toinen, kun soitetaan etämenettelyyn. On mahdotonta määrittää, milloin toimenpide suoritetaan tarkasti, suoritetaanko se ollenkaan ja jos on, kuinka monta kertaa? Jos esimerkiksi etäjärjestelmä vastaanottaa pyynnön sen jälkeen, kun palvelinohjelma päättyy epänormaalisti, toimenpidettä ei suoriteta lainkaan. Jos asiakas, kun se ei saa vastausta tietyn ajan (aikakatkaisun) jälkeen, lähettää pyynnön uudelleen, voi syntyä tilanne, jossa vastaus lähetetään jo verkon kautta ja toistuva pyyntö hyväksytään uudelleen käsiteltäväksi etätoimenpiteellä. Tässä tapauksessa toimenpide suoritetaan useita kertoja.
Siten etäproseduurin suorittamista voidaan luonnehtia seuraavalla semantiikalla:
- Yksi ja ainoa kerta. Tätä käyttäytymistä (joissakin tapauksissa halutuinta) on vaikea valvoa mahdollisten palvelimen kaatumisten vuoksi.
- Enimmäisajat. Tämä tarkoittaa, että toimenpidettä ei suoritettu lainkaan tai se suoritettiin vain kerran. Samanlainen lausunto voidaan tehdä, kun normaalin vastauksen sijasta saadaan virhe.
- Ainakin kerran. Menettely suoritettiin luultavasti kerran, mutta enemmän on mahdollista. Normaalikäyttöön tällaisessa tilanteessa etäproseduurilla on oltava idempotenssi (englanninkielisestä idemponentista). Tällä ominaisuudella on menettely, jonka toistuva suorittaminen ei aiheuta kumulatiivisia muutoksia. Esimerkiksi tiedoston lukeminen on idempotentti, mutta tekstin lisääminen tiedostoon ei ole.
Tietojen esittely
Kun asiakas ja palvelin toimivat samassa järjestelmässä samassa tietokoneessa, tietojen yhteensopimattomuusongelmia ei ole. Binääridata on sekä asiakkaalle että palvelimelle sama. Etäpuhelun tapauksessa asiaa monimutkaistaa se, että asiakas ja palvelin voivat käyttää järjestelmiä, joiden arkkitehtuuri on erilainen ja joilla on erilaiset datan esitykset (esimerkiksi liukulukuesitys, tavujärjestys jne.)
Useimmat RPC -toteutukset määrittävät tietyn vakiomuotoisen esityksen tiedoista, joihin kaikki pyyntöissä ja vastauksissa välitetyt arvot on muunnettava.
Esimerkiksi Sun Microsystemsin RPC -muodossa olevien tietojen esitystapa on seuraava:
Tavujärjestys - merkittävin - viimeinen
Liukulukuesitys - IEEE
Merkkien esitys - ASCII
Toiminnallisesti RPC -järjestelmä on sovelluskerroksen ja siirtokerroksen välissä. OSI -mallin mukaan tämä säännös vastaa esitys- ja istuntotasoja. Näin ollen RPC on teoriassa riippumaton verkon toteutuksesta, erityisesti siirtokerroksen verkkoprotokollista.
Järjestelmän ohjelmistototeutukset tukevat pääsääntöisesti yhtä tai kahta protokollaa. Esimerkiksi Sun Microsystemsin RPC -järjestelmä tukee viestejä TCP- ja UDP -protokollien avulla. Yhden tai toisen protokollan valinta riippuu sovelluksen vaatimuksista. UDP on perusteltu sovelluksille, joilla on seuraavat ominaisuudet:
Kutsutut menettelyt ovat idempotentteja
Lähetettyjen argumenttien ja palautustuloksen koko on pienempi kuin UDP -paketin koko - 8 kt.
Palvelin tarjoaa työtä useiden satojen asiakkaiden kanssa. Koska palvelin joutuu TCP -protokollien kanssa työskennellessään ylläpitämään yhteyttä jokaisen aktiivisen asiakkaan kanssa, tämä vie merkittävän osan sen resursseista. UDP on tässä suhteessa vähemmän resursseja kuluttava.
Toisaalta TCP tarjoaa tehokkaan toiminnan sovelluksille, joilla on seuraavat ominaisuudet:
Sovellus vaatii luotettavan siirtoprotokollan
Kutsutut menettelyt eivät ole identtisiä
Argumentit tai palautettu tulos on suurempi kuin 8 kt
Protokollan valinta jää yleensä asiakkaan tehtäväksi, ja järjestelmä järjestää viestien muodostamisen ja lähettämisen eri tavoilla. Joten kun käytetään TCP -protokollaa, jolle lähetetty data on tavuvirta, viestit on erotettava toisistaan. Tätä varten käytetään esimerkiksi asiakirjassa RFC1057 "RPC: Remote procedure Call Protocol specification version 2" kuvattua tietueenmerkintäprotokollaa, joka edeltää jokaista viestiä 32-bittisellä kokonaisluvulla, joka määrittää viestin koon tavuina.
Tilanne on erilainen puhelun semantiikan kanssa. Jos esimerkiksi RPC suoritetaan epäluotettavan siirtoprotokollan (UDP) avulla, järjestelmä lähettää viestin uudelleen lyhyin väliajoin (aikakatkaisut). Jos asiakassovellus ei saa vastausta, voidaan sanoa, että toimenpide on suoritettu nolla tai useampia kertoja. Jos vastaus on saatu, sovellus voi päätellä, että menettely on suoritettu vähintään kerran. Jos käytetään luotettavaa siirtoprotokollaa (TCP), jos vastaus vastaanotetaan, voidaan sanoa, että toimenpide suoritettiin kerran. Jos vastausta ei saada, on mahdotonta sanoa varmasti, ettei toimenpidettä suoritettu3.
Kuinka se toimii?
Pohjimmiltaan todellinen RPC -järjestelmä on rakennettu asiakasohjelmaan ja palvelinohjelmaan. On ilahduttavaa, että hajautettuja sovelluksia kehitettäessä sinun ei tarvitse syventyä RPC -protokollan tai ohjelmaviestien käsittelyn yksityiskohtiin. Järjestelmä olettaa asianmukaisen kehitysympäristön olemassaolon, mikä helpottaa suuresti sovellusohjelmistojen luojan elämää. Yksi RPC: n keskeisistä kohdista on, että hajautetun sovelluksen kehittäminen alkaa objektirajapinnan määrittelyllä - palvelinkäyttötoimintojen muodollisella kuvauksella, joka on tehty erityisellä kielellä. Asiakkaan ja palvelimen tynkät luodaan automaattisesti tästä käyttöliittymästä. Ainoa asia, joka on tehtävä tämän jälkeen, on kirjoittaa todellinen menettelykoodi.
Tarkastellaan esimerkiksi Sun Microsystemsin RPC: tä. Järjestelmä koostuu kolmesta pääosasta:
Rpcgen (1) on RPC -kääntäjä, joka luo asiakas- ja palvelinkäyrät C -ohjelmiksi etäproseduuriliittymän kuvauksen perusteella.
Kirjasto XDR (eXternal Data representation), joka sisältää toimintoja erityyppisten tietojen muuntamiseksi koneesta riippumattomaan muotoon ja mahdollistaa tietojen vaihdon heterogeenisten järjestelmien välillä.
Kirjasto moduuleista, jotka varmistavat koko järjestelmän toiminnan.
Katsotaanpa esimerkkiä hajautettujen tapahtumien kirjaussovelluksesta. Asiakas kutsuu käynnistyksen yhteydessä etäproseduuria kirjoittaakseen viestin etätietokoneen lokitiedostoon.
Tätä varten sinun on luotava vähintään kolme tiedostoa: log.x -etäkäytäntöjen rajapintojen määritykset (käyttöliittymän kuvauskielellä), log.c -etäkäytäntöjen varsinainen teksti ja asiakkaan pääohjelma main () - client.c (C -kielellä).
Rpcgen (l) -kääntäjä luo kolme tiedostoa log.x -spesifikaation perusteella: C -asiakas- ja palvelimen tynkät (log clnt.c ja log svc.c) ja molempien osien käyttämä log.h -määritystiedosto.
Katsotaanpa siis ohjelmien lähdekoodia.
Tämä tiedosto määrittää etäproseduurin rekisteröintiparametrit - ohjelman, version ja toimenpiteen numerot - ja määrittelee kutsuvan käyttöliittymän - syöttöargumentit ja palautusarvot. Siten määritetään RLOG -menettely, joka ottaa merkkijonon argumentiksi (joka kirjoitetaan lokiin) ja palautusarvo oletusarvoisesti osoittaa tilatun operaation onnistumisen tai epäonnistumisen.
ohjelma LOG_PROG (
versio LOG_VER (
int RLOG (merkkijono) = 1;
) = 0x31234567;
Rpcgen (l) -kääntäjä luo otsikkotiedoston loki. H, jossa erityisesti määritellään menettelyt:
log.h
* Älä muokkaa tätä tiedostoa.
* Se luotiin käyttäen rpcgen.
#ifndef _LOG_H_RPCGEN
#define _LOG_H_RPCGEN
#sisältää
/ * Ohjelman numero * /
#define LOG_PROG ((allekirjoittamaton pitkä) (0x31234567))
#define LOG_VER ((unsigned long) (1)) / * Version numero * /
#define RLOG ((allekirjoittamaton pitkä) (1)) / * Rutiiniluku * /
extern int * rlog_l ();
/ * Sisäinen menettely - meidän ei tarvitse käyttää sitä * / extern int log_prog_l_freeresult ();
#endif / *! _LOG_H_RPCGEN * /
Katsotaanpa tätä tiedostoa tarkemmin. Kääntäjä kääntää käyttöliittymäkuvaajan määrittämän RLOG -nimen rlog_1: ksi, korvaa isot kirjaimet pienillä kirjaimilla ja lisää ohjelman versionumeron alaviivalla. Palautustyyppi on muuttunut int: stä int *: ksi. Tämä on sääntö - RPC: n avulla voit lähettää ja vastaanottaa vain käyttöliittymää kuvattaessa ilmoitettujen parametrien osoitteet. Sama sääntö koskee argumenttina välitettyä merkkijonoa. Vaikka tämä ei seuraa print.h -tiedostosta, itse asiassa rivin osoite välitetään myös argumenttina rlog_l () -funktiolle.
Otsikkotiedoston lisäksi rpcgen (l) -kääntäjä luo asiakas- ja palvelinväylämoduuleja. Pohjimmiltaan näiden tiedostojen teksti sisältää kaiken etäkutsukoodin.
Palvelimen tynkä on pääohjelma, joka hoitaa kaikki verkkoyhteydet asiakkaan kanssa (tarkemmin sanottuna sen tynkän kanssa). Toiminnon suorittamiseksi palvelimen tynkä soittaa paikallispuhelun funktiolle, jonka teksti on kirjoitettava:
log.c
#sisältää
#sisältää
#sisältää
#include "log.h"
int * rlog_1 (char ** arg)
/ * Palautusarvo on määritettävä staattiseksi * /
staattinen int -tulos;
int fd; / * Lokitiedoston kuvaaja * /
/ * 0 avaa lokitiedosto (luo se, jos sitä ei ole), palauta virhekoodin tulos == 1. * /
if ((fd = auki ("./ palvelin .log",
O_CREAT | O_RDWR | O_APPEND))< 0) return (&result);
len = strlen (* arg);
jos (kirjoittaa (fd, * arg, strlen ( * arg))! = len)
paluu (& tulos); / * Palauta tulos - osoitteen tulos * /
Asiakkaan tynkä ottaa etäproseduurille välitetyn argumentin, tekee tarvittavat muunnokset, lähettää pyynnön porttikartta (1M) -palvelimelle, kommunikoi etäproseduuripalvelimen kanssa ja välittää lopuksi palautusarvon asiakkaalle. Asiakkaalle etäproseduuripuhelu on tynkäpuhelu, eikä se eroa tavallisesta paikallispuhelusta.
asiakas. c
#sisältää
#include "log.h"
pää (int argc, char * argv)
char * palvelin, * mystring, * clnttime;
jos (argc! = 2) (
fprintf (stderr, "Puhelun muoto:% s Host_address \ n",
/ * Hanki asiakaskuvaaja. Vian sattuessa ilmoitamme sinulle
Mahdollisuus muodostaa yhteys palvelimeen * /
if ((с1 = clnt_create (palvelin,
LOG_PROG, LOG_VER, "udp")) == NULL) (
clnt_pcreateerror (palvelin);
/ * Varaa puskuri merkkijonolle * /
mystring = (char *) malloc (100);
/ * Määritä tapahtuman aika * /
bintime = aika ((aika_t *) NULL);
clnttime = ctime (& bintime);
sprintf (mystring, "% s - Asiakas aloitettu", clnttime);
/ * Lähetämme lokille viestin - ajan, jolloin asiakas aloitti työskentelyn. Jos vika ilmenee, ilmoitamme virheestä * /
if ((tulos = rlog_l (& mystring, cl)) == NULL) (
fprintf (stderr, "error2 \ n");
clnt_perror (cl, palvelin);
/ * Jos etätietokoneessa ilmenee vika, ilmoitamme virheestä * /
jos (* tulos! = 0)
fprintf (stderr, "Virhe kirjoitettaessa lokiin \ n");
/ * 0 vapauta kuvaaja * /
cint tuhota (cl);
Asiakastyyppi log_clnt.c kootaan asiakkaan.c -moduulin kanssa saadakseen suoritettavan ohjelman.
cc -o rlog client.c log_clnt.c -Insl
Log_svc.c -palvelimen tynkä ja log.c -rutiini kootaan palvelimen suoritettavaksi.
cc -o logger log_svc.c log.c -Insl
Nyt joissakin isäntäpalvelimissa.nowhere.ru sinun on käynnistettävä palvelinprosessi:
Kun rlog -asiakas käynnistetään toisella koneella, palvelin lisää vastaavan merkinnän lokitiedostoon.
RPC -toimintamalli tässä tapauksessa on esitetty kuviossa. 1. Moduulit ovat vuorovaikutuksessa seuraavasti:
1. Kun palvelinprosessi käynnistyy, se luo UDP -pistorasian ja sitoo kaikki paikalliset portit kyseiseen pistorasiaan. Palvelin kutsuu sitten svc_register (3N) -kirjastotoiminnon rekisteröidäkseen ohjelmanumerot ja versionumerot. Tätä varten toiminto kutsuu portmap (IM) -prosessin ja välittää vaaditut arvot. Porttikartta (IM) -palvelin käynnistetään yleensä järjestelmän alustuksen yhteydessä ja se sitoo johonkin tunnettuun porttiin. Portmap (3N) tietää nyt ohjelmamme ja version portin numeron. Palvelin odottaa pyynnön vastaanottamista. Huomaa, että kaikki kuvatut toiminnot suorittaa rpcgen (IM) -kääntäjän luoma palvelinkanta.
2. Kun rlog käynnistyy, se kutsuu ensimmäisenä kirjastotoiminnon clnt_create (3N) antamalla sille etäjärjestelmän osoitteen, ohjelman ja versionumerot sekä siirtoprotokollan. Toiminto pyytää pyynnön etäjärjestelmäpalvelimen porttikartan (IM) palvelimelle. Nowhere.m ja hakee lokipalvelimen etäportin numeron.
3. Asiakas kutsuu rlog_1 () -rutiinia, joka on määritetty asiakaskannassa, ja siirtää ohjauksen tynkään. Tämä vuorostaan muodostaa pyynnön (muuntaa argumentit XDR -muotoon) UDP -paketin muodossa ja välittää sen porttikarttapalvelimelta vastaanotetulle etäportille. Sitten se odottaa vastausta jonkin aikaa ja jos sitä ei vastaanoteta, se lähettää pyynnön uudelleen. Suotuisissa olosuhteissa kirjauspalvelin (palvelimen tynkämoduuli) hyväksyy pyynnön. Tynkä tunnistaa, mitä toimintoa kutsuttiin (toimenpiteen numerolla), ja kutsuu log.c -moduulin rlog_1 () -funktion. Kun ohjaus palaa takaisin tynkään, tynkä muuntaa rlog_1 () -funktion palauttaman arvon XDR -muotoon ja muodostaa vastauksen myös UDP -paketin muodossa. Saatuaan vastauksen asiakastynkki purkaa palautetun arvon, muuntaa sen ja palauttaa sen asiakaskoneelle.
Etämenettelykutsu - RPC Etämenettelykutsun - RPC käsitteenä on laajentaa tunnettu ja ymmärretty mekanismi ohjauksen ja tietojen siirtämiseksi samalla koneella käynnissä olevan ohjelman sisällä ohjauksen ja datan siirtämiseksi verkon kautta. RPC -työkalut on suunniteltu helpottamaan hajautettua tietojenkäsittelyä. RPC on tehokkain sovelluksissa, joissa on vuorovaikutteista kommunikaatiota etäkomponenttien välillä, joilla on nopea vasteaika ja suhteellisen vähän tiedonsiirtoa.
Tällaisia sovelluksia kutsutaan RPC-suuntautuneiksi. Paikallisten proseduurikutsujen ominaispiirteitä ovat epäsymmetria, toisin sanoen yksi vuorovaikutuksessa olevista osapuolista aloittaa synkroniteetin eli soittotoimenpiteen suorittamisen, kun se pysähtyy pyynnön lähettämishetkestä ja jatkuu vasta kutsutusta menettelystä palattuaan. Etäpuheluiden toteuttaminen on paljon monimutkaisempaa kuin paikallisten menettelyjen kutsujen toteuttaminen.
Ensinnäkin, koska soittaja ja kutsuttu menettely suoritetaan eri koneilla, niillä on eri osoiteavaruudet, mikä aiheuttaa ongelmia parametrien ja tulosten välittämisessä, varsinkin jos koneet eivät ole identtisiä. Koska RPC ei voi luottaa jaettuun muistiin, tämä tarkoittaa, että RPC-parametrit eivät saa sisältää osoittimia muille kuin pino-muistipaikoille ja että parametriarvot on kopioitava tietokoneesta toiseen.
Seuraava ero RPC: n ja paikallisen puhelun välillä on, että se käyttää välttämättä taustalla olevaa viestintäjärjestelmää, mutta tämän ei pitäisi näkyä nimenomaisesti menettelyjen määrittelyssä tai itse menettelyissä. Etäisyys tuo lisäongelmia. Soittajan ja kutsutun paikallisen menettelyn suorittaminen samalla koneella suoritetaan yhtenä prosessina, mutta RPC: n käyttöönottoon kuuluu vähintään kaksi prosessia, yksi jokaisessa koneessa.
Jos yksi niistä kaatuu, seuraavat tilanteet voivat ilmetä, jos kutsumismenettely kaatuu, etäkutsutut menettelyt jäävät orvoiksi ja jos etäproseduurit päättyvät epänormaalisti, soittajista tulee epäedullisessa asemassa olevia vanhempia, jotka odottavat vastausta kaukosäätimeltä ohjelmointikielten ja toimintaympäristöjen, tietorakenteiden ja yhdellä ohjelmointikielellä tuettujen menettelyjen kutsurakenteiden epäyhtenäisyyteen liittyviä ongelmia ei tueta samalla tavalla kaikilla muilla kielillä.
Nämä ja eräät muut ongelmat ratkaistaan laajalla RPC -tekniikalla, joka on monien hajautettujen käyttöjärjestelmien taustalla. RPC: n perustoiminnot Ymmärtääksesi RPC: n toiminnan, harkitse ensin paikallisen proseduurikutsun suorittamista normaalilla offline -tilassa toimivalla koneella, kuten count read fd, buf, nbytes system call jossa fd on kokonaisluku, buf on merkkijono ja nbytes on kokonaisluku ....
Puhelun soittamiseksi kutsumismenettely työntää parametrit pinoon päinvastaisessa järjestyksessä. Kun lukukutsu on suoritettu, se sijoittaa palautusarvon rekisteriin, siirtää palautusosoitteen ja palauttaa ohjauksen soittomenettelyyn, joka nostaa parametrit pinosta ja palauttaa sen alkuperäiseen tilaansa. Huomaa, että C: ssä parametreja voidaan kutsua joko nimellä tai arvolla. Kutsutun menettelyn osalta arvoparametrit ovat alustettavia paikallisia muuttujia.
Kutsuttu menettely voi muuttaa niitä vaikuttamatta näiden muuttujien alkuperäisten arvoon kutsumismenettelyssä. Jos muuttujan osoitin siirretään kutsutulle menettelylle, muutetun arvon muutos kutsutulla menettelyllä muuttaa kyseisen muuttujan arvoa myös kutsumenettelyssä.Tämä tosiasia on erittäin tärkeä RPC: lle. Parametrien välittämiseen on myös toinen mekanismi, jota ei käytetä C-kielellä. Sitä kutsutaan call by by copy -palautukseksi, ja kutsuvan ohjelman on kopioitava muuttujat pinoon arvoina ja kopioitava sitten takaisin kun puhelu on soitettu proseduurin alkuperäisten arvojen yli.
Kielisuunnittelijoiden on päätettävä, mitä parametrien välitysmekanismia käytetään. Joskus se riippuu välitettävän datan tyypistä, esimerkiksi C: ssä kokonaisluku- ja muut skalaaritiedot välitetään aina arvon mukaan ja matriisit aina viittauksella.
Riisi. 3.1. a Pino ennen lukukutsua b Toisin sanoen, jotta RPC olisi läpinäkyvä, soittajan ei tarvitse tietää, että kutsuttu menettely on eri koneessa, ja päinvastoin. RPC saavuttaa läpinäkyvyyden seuraavalla tavalla.
Kun kutsuttu proseduuri on todellakin etäkäyttöinen, paikallisen menettelyn sijasta kirjastossa on toinen prosessin versio, jota kutsutaan asiakkaan tynkäksi. Alkuperäisen menettelyn tapaan tynkä kutsutaan kuviossa 3.1 kutsuvan sekvenssin avulla ja ydin keskeytetään. Vain toisin kuin alkuperäinen menettely, se ei laita parametreja rekistereihin eikä pyydä ytimeltä tietoja, vaan luo viestin, joka lähetetään etäkoneen ytimeen. RPC -suoritusvaiheet Kuva 3.2 havainnollistaa ohjelmistokomponenttien vuorovaikutusta etäproseduurikutsussa. Kun asiakasohjelma on kutsunut asiakastyön, sen ensimmäinen tehtävä on täyttää puskuri lähetettävällä viestillä.
Joissakin järjestelmissä asiakaskannassa on yksi kiinteäpituinen puskuri, joka täytetään alusta alkaen aina, kun uusi pyyntö saapuu. Muissa järjestelmissä sanomapuskuri on yksittäisten viestikenttien puskureita, joista osa on jo täynnä.
Tämä menetelmä sopii erityisesti silloin, kun paketti on muotoiltu suurella määrällä kenttiä, mutta monien näiden kenttien arvot eivät muutu puhelusta puheluun. Parametrit on sitten muunnettava sopivaan muotoon ja lisättävä sanomapuskuriin, jolloin viesti on valmis lähetettäväksi, joten keskeytys suoritetaan ytimen puhelulle. Riisi. 3.2. Etämenettelykutsu Kun ydin saa hallinnan, se vaihtaa konteksteja, tallentaa prosessorirekisterit ja muistikarttasivun kuvaajat, asentaa uuden muistikartan, jota käytetään ytimessä. Koska ytimen ja käyttäjäyhteydet ovat erilaiset, ytimen on kopioitava viesti täsmälleen omaan osoitetilaansa, jotta se voi käyttää sitä, muistaa kohdeosoitteen ja mahdollisesti muut otsikkokentät, ja sen on myös siirrettävä se verkkoliitännälle .
Tämä päättää työn asiakaspuolella.
Lähetysajastin on kytketty päälle, ja ydin voi joko kysyä vastausta tai siirtää ohjauksen ajoitukselle, joka valitsee jonkin muun suoritettavan prosessin. Ensimmäisessä tapauksessa kyselyn suorittamista nopeutetaan, mutta moniohjelmointia ei ole. Palvelinpuolella vastaanottavat laitteet sijoittavat saapuvat bitit joko sisäänrakennettuun puskuriin tai sisään RAM. Kun kaikki tiedot on vastaanotettu, syntyy keskeytys.
Keskeytyksen käsittelijä tarkistaa pakettidatan oikeellisuuden ja päättää, mikä tynkä tulee välittää.Jos yksikään tynkistä ei odota tätä pakettia, käsittelijän tulee joko laittaa se puskuriin tai hylätä se kokonaan. Jos odottava tynkä on, viesti kopioidaan siihen. Lopuksi suoritetaan kontekstikytkin, jonka seurauksena rekisterit ja muistikartta palautetaan ottaen arvot, jotka niillä oli sillä hetkellä, kun tynkä soitti vastaanottopuhelun.
Nyt palvelimen tynkä alkaa toimia. Se purkaa parametrit pakkauksesta ja työntää ne sopivasti pinolle. Kun kaikki on valmista, soitetaan palvelinkutsu. Menettelyn päätyttyä palvelin lähettää tulokset asiakkaalle noudattamalla kaikkia yllä kuvattuja vaiheita vain päinvastaisessa järjestyksessä. Kuva 3.3 esittää komentojen järjestyksen, joka on suoritettava kullekin RPC -kutsulle, ja kuva 3.4 osoittaa, kuinka suuri osa RPC: n kokonaisajasta kuluu kunkin kuvatun 14 vaiheen suorittamiseen.
Tutkimus tehtiin DEC Firefly -moniprosessorityöasemalla, ja vaikka viiden prosessorin läsnäolo vaikutti välttämättä mittaustuloksiin, kuvassa näkyvä histogrammi antaa yleiskuvan RPC -suoritusprosessista. Riisi. 3.3. RPC -menettelyn vaiheet Kuva. 3.4. Ajan jakautuminen 14 RPC -suoritusvaiheen välillä 1. Puhelu tynkä 2. Valmista puskuri 3. Paketin parametrit 4. Täytä otsikkokenttä 5. Laske viestin tarkistussumma 6. Keskeytä ytimeen 7. Pakettijono suoritettavaksi 8. Lähetä viesti ohjaimelle QBUS: n kautta 9. Ethernet -lähetysaika 10. Vastaanota paketti ohjaimelta 11. Keskeytysrutiini 12. Tarkistussumman laskeminen 13. Kontekstin vaihtaminen käyttäjätilaan 14. Palvelimen tynkän suoritus Dynaaminen sidonta Harkitse, miten asiakas määrittää palvelimen sijainnin.
Yksi tapa ratkaista tämä ongelma on käyttää suoraan palvelimen verkko -osoitetta asiakasohjelmassa.
Tämän lähestymistavan haittana on sen äärimmäinen joustamattomuus palvelinta siirrettäessä tai palvelimien lukumäärän kasvaessa tai kun käyttöliittymää muutetaan kaikissa näissä ja monissa muissa tapauksissa, on välttämätöntä kääntää uudelleen kaikki ohjelmat, jotka käyttivät Jotkut hajautetut järjestelmät käyttävät niin sanottua dynaamista linkitystä.
Dynaamisen sidonnan lähtökohta on palvelimen määrityksen virallinen määrittäminen. Tekniset tiedot sisältävät tiedostopalvelimen nimen, versionumeron ja luettelon palvelimen asiakkaille tarjoamista palvelutoiminnoista Kuva 3.5. Jokaiselle toimenpiteelle annetaan sen parametrien kuvaus, joka osoittaa, onko tämä parametri tulo vai lähtö suhteessa palvelimeen. Jotkut parametrit voidaan syöttää ja tulostaa samanaikaisesti - esimerkiksi jotakin asiakkaan palvelimelle lähettämää taulukkoa muutetaan siellä, ja sitten toiminto palautetaan takaisin asiakaskopion palauttamiseen. Riisi. 3.5. RPC -palvelimen määritys Muodollista palvelinmäärittelyä käytetään syötteenä tynkägeneraattoriohjelmaan, joka luo sekä asiakas- että palvelinväylät.
Sitten ne sijoitetaan asianmukaisiin kirjastoihin. Kun käyttäjäasiakasohjelma kutsuu mitä tahansa palvelimen määrityksissä määriteltyä menettelyä, vastaava tynkäproseduuri liittyy ohjelman binaariin.
Samoin, kun palvelin käännetään, palvelimen tynkät liittyvät siihen. Kun palvelin käynnistyy, sen ensimmäinen toiminto on siirtää palvelimen käyttöliittymä erityinen ohjelma kutsutaan sideaineeksi. Tämä prosessi, joka tunnetaan palvelimen rekisteröintiprosessina, edellyttää, että palvelin lähettää nimensä, versionumeronsa, yksilöllisen tunnuksensa ja palvelimen sijainninkuvaajan Kirjoittaja on järjestelmästä riippumaton ja voi olla IP, Ethernet, X.500 tai jokin muu osoite.
Lisäksi se voi sisältää muita tietoja, esimerkiksi todentamiseen liittyviä. Kun asiakas soittaa yhdelle etäproseduurista ensimmäistä kertaa, esimerkiksi lukee, asiakastuki näkee, että sitä ei ole vielä yhdistetty palvelimeen, ja lähettää viestin sideohjelmalle, jossa pyydetään tuomaan vaaditun version käyttöliittymä Jos tällainen palvelin on olemassa, sideaine lähettää kahvan ja yksilöllisen tunnisteen asiakaskannalle.
Asiakkaan tynkä käyttää kuvaajaa osoitteena lähettäessään pyyntöviestin. Viesti sisältää parametreja ja yksilöllisen tunnisteen, jota palvelimen ydin käyttää välittääkseen saapuvan viestin oikealle palvelimelle, jos niitä on useita tällä koneella. Tämä käyttöliittymien tuonti- ja vientimenetelmä on erittäin joustava. Esimerkiksi samaa käyttöliittymää voi olla useita palvelimia ja asiakkaat jaetaan satunnaisesti palvelimien kesken.
Tämän menetelmän puitteissa on mahdollista ajoittain kysyä palvelimia, analysoida niiden suorituskykyä ja vian sattuessa automaattinen sammutus, mikä lisää järjestelmän yleistä vikasietoisuutta. Tämä menetelmä voi myös tukea asiakkaan todennusta. Palvelin voi esimerkiksi määrittää, että sitä voivat käyttää vain tietyn luettelon asiakkaat, mutta dynaamisella sidonnalla on haittoja, kuten ylimääräiset yleiskulut ja käyttöliittymien vientiin ja tuontiin kuluva aika.
Näiden kustannusten suuruus voi olla merkittävä, koska monet asiakasprosessit ovat olemassa lyhyen aikaa, ja jokaisen prosessin alussa käyttöliittymän tuontimenettely on suoritettava uudelleen. Lisäksi suurissa hajautetuissa järjestelmissä sideaineesta voi tulla pullonkaula, ja useiden samankaltaisten ohjelmien luominen lisää myös prosessien luomisen ja synkronoinnin yleiskustannuksia.
Harkitse seuraavia vikaluokkia 1. Asiakas ei voi löytää palvelinta, esimerkiksi jos oikea palvelin epäonnistuu tai koska asiakasohjelma on koottu kauan sitten ja se on käyttänyt vanhaa palvelinliittymän versiota. Tässä tapauksessa virhekoodin sisältävä viesti vastaanotetaan vastauksena asiakkaan pyyntöön. 2. Yksinkertaisin ratkaisu on toistaa pyyntö tietyn ajan kuluttua. 3. Kadonnut vastausviesti palvelimelta asiakkaalle.
Tämä vaihtoehto on monimutkaisempi kuin edellinen, koska jotkut menettelyt eivät ole idempotentteja. Idempotent -menettely on menettely, jonka suorituspyyntö voidaan toistaa useita kertoja, eikä tulos muutu. Esimerkki tällaisesta menettelystä on tiedoston lukeminen, mutta menettely tietyn summan nostamiseksi pankkitililtä ei ole järjetön, ja jos vastaus häviää, toistuva pyyntö voi muuttaa merkittävästi asiakkaan tilin tilaa.
Yksi mahdolliset ratkaisut on kaikkien menettelyjen vähentäminen idempotenttiin muotoon. Käytännössä tämä ei kuitenkaan aina ole mahdollista, joten voidaan käyttää toista menetelmää - kaikkien ydinpyyntöjen järjestysnumerointia. Palvelinydin muistaa kunkin asiakkaan viimeisimmän pyynnön numeron, ja jokaisen pyynnön saatuaan se analysoi, onko tämä pyyntö ensisijainen vai toistuva. 4. Palvelin kaatui pyynnön vastaanottamisen jälkeen. Idempotenssin ominaisuus on myös tärkeä tässä, mutta valitettavasti pyyntöjen numerointimenetelmää ei voida soveltaa.
Tässä tapauksessa on väliä, milloin vika tapahtui - ennen tai jälkeen toimenpiteen. Mutta asiakasydin ei voi tunnistaa näitä tilanteita, se tietää vain, että vastaus aikakatkaistiin. Tähän ongelmaan on kolme tapaa. Odota, kunnes palvelin käynnistyy uudelleen ja yritä uudelleen. Tämä lähestymistapa varmistaa, että RPC on suoritettu vähintään kerran ja mahdollisesti useammin. Ilmoita virheestä välittömästi sovellukselle.
Tämä lähestymistapa varmistaa, että RPC on suoritettu korkeintaan kerran. Kolmas lähestymistapa ei takaa mitään. Kun palvelin epäonnistuu, asiakas ei tue. RPC voidaan suorittaa tai olla suorittamatta ollenkaan tai monta kertaa. Tämä menetelmä on joka tapauksessa erittäin helppo toteuttaa. Mikään näistä lähestymistavoista ei ole kovin houkutteleva, eikä ihanteellista vaihtoehtoa, joka takaa täsmälleen yhden RPC -suorituksen, ei periaatteessa voida toteuttaa.
Oletetaan esimerkiksi, että etäkäyttö tulostaa tekstiä, johon kuuluu tulostinpuskurin lataaminen ja yhden bitin asettaminen tulostimen johonkin ohjausrekisteriin, minkä seurauksena tulostin käynnistyy. Palvelimen kaatuminen voi tapahtua sekä mikrosekunnin ennen että mikrosekunnin kuluttua ohjausbitin asettamisesta. Epäonnistumisen hetki määrää kokonaan palautusmenettelyn, mutta asiakas ei voi tietää vikahetkestä.
Lyhyesti sanottuna palvelimen kaatumisen mahdollisuus muuttaa radikaalisti RPC: n luonnetta ja heijastaa selvästi keskitetyn järjestelmän ja hajautetun järjestelmän välistä eroa. Ensimmäisessä tapauksessa palvelimen kaatuminen johtaa asiakkaan kaatumiseen, eikä palautuminen ole mahdollista. Toisessa tapauksessa järjestelmän palauttamisvaiheet ovat sekä mahdollisia että tarpeellisia. 1. Asiakas joutui onnettomuuteen pyynnön lähettämisen jälkeen. Tässä tapauksessa laskelmat suoritetaan tuloksille, joita kukaan ei odota; tällaisia laskelmia kutsutaan orvoiksi. Orpojen läsnäolo voi aiheuttaa erilaisia ongelmia, suorittimen yleiskustannuksia, resurssien estämistä, nykyisen pyynnön vastauksen korvaamisen vastauksella pyyntöön, jonka asiakaskone antoi jo ennen järjestelmän uudelleenkäynnistystä.
Mitä tehdä orvoille? Tarkastellaan 4 mahdollista ratkaisua. Tuhoaminen. Ennen kuin asiakastuki lähettää RPC -viestin, se tekee lokiin muistiinpanon, joka ilmoittaa, mitä se tekee nyt Loki tallennetaan levylle tai muuhun vikasietoiseen muistiin.
Onnettomuuden jälkeen järjestelmä käynnistyy uudelleen, loki analysoidaan ja orvot poistetaan. Tämän lähestymistavan haittoja ovat ensinnäkin kussakin RPC: stä levylle kirjoittamisesta aiheutuvat lisäkustannukset ja toiseksi mahdollinen tehottomuus, joka johtuu toisen sukupolven orpojen ilmestymisestä ensimmäisen sukupolven orpojen soittamien RPC -puheluiden avulla. Reinkarnaatio: Tässä tapauksessa kaikki ongelmat ratkaistaan ilman levylle kirjoittamista. Menetelmä koostuu ajan jakamisesta jaksoittaisiin jaksoihin. Kun asiakas käynnistyy uudelleen, se lähettää kaikille koneille uuden ajanjakson.
Tämän viestin vastaanottamisen jälkeen kaikki etälaskutoiminnot lopetetaan. Tietenkin, jos verkko on segmentoitu, jotkut orvot voivat selviytyä. Pehmeä reinkarnaatio on samanlainen kuin edellinen tapaus, paitsi että kaikkia etälaskutoimituksia ei löydy ja tuhota, vaan vain uudelleenkäynnistävän asiakkaan. Vanheneminen: Jokaiselle pyynnölle annetaan vakiopituus T, jonka aikana se on suoritettava.
Jos pyyntöä ei suoriteta annetussa ajassa, varataan lisäkvantti. Vaikka tämä vaatii lisätyötä, jos palvelin odottaa asiakaskaatumisen jälkeen välin T ennen kuin asiakas käynnistyy uudelleen, kaikki orvot tuhoutuvat välttämättä. Käytännössä mikään näistä tavoista ei ole toivottava, ja lisäksi orpojen tuhoaminen voi pahentaa tilannetta. tilanne. Oletetaan esimerkiksi, että orpo on lukinnut yhden tai useamman tietokantatiedoston.
Jos orpo tuhoutuu yhtäkkiä, nämä lukot pysyvät, lisäksi tuhoutuneet orvot voivat jäädä seisomaan erilaisiin järjestelmäjonoihin, tulevaisuudessa ne voivat aiheuttaa uusien prosessien suorittamisen jne.
Jos tämä materiaali osoittautui hyödylliseksi sinulle, voit tallentaa sen sivullesi sosiaalisissa verkostoissa:
Tämän artikkelin tarkoituksena on keskustella terminologiasta. Artikkeli ei koske miten ja miksi, vaan vain terminologian käytöstä. Artikkeli heijastaa kirjoittajan mielipidettä eikä väitä olevansa tieteellinen.
Jos työskentelet ohjelmoinnin parissa hajautetut järjestelmät tai sisään järjestelmien integrointi, suurin osa täällä olevista tiedoista ei ole sinulle uutta.
Ongelma syntyy, kun eri tekniikoita käyttävät ihmiset tapaavat ja kun nämä ihmiset aloittavat teknisiä keskusteluja. Tässä tapauksessa terminologiasta johtuu usein keskinäinen väärinkäsitys. Tässä yritän koota yhteen eri yhteyksissä käytetyt terminologiat.
Tällä alalla ei ole selkeää terminologiaa ja luokittelua. Alla käytetty terminologia heijastaa tekijän mallia, eli se on ehdottomasti subjektiivinen. Kaikki kritiikki ja keskustelu ovat tervetulleita.
Olen jakanut terminologian kolmeen osaan: RPC (Remote Procedure Call), Messaging ja REST. Näillä alueilla on historialliset juuret.
RPC tekniikka on vanhin tekniikka. RPC: n kirkkaimmat edustajat ovat - CORBA ja DCOM.
Siihen aikaan oli pääasiassa tarpeen yhdistää järjestelmät nopeisiin ja suhteellisen luotettaviin lähiverkkoihin. RPC: n pääidea oli tehdä kutsuvista etäjärjestelmistä hyvin samankaltaisia kuin ohjelman kutsutoiminnot. Kaikki etäkutsujen mekaniikka piilotettiin ohjelmoijalta. Ainakin he yrittivät piilottaa sen. Ohjelmoijat joutuivat monissa tapauksissa työskentelemään syvemmällä tasolla, jossa termit marshaling ( järjestely) ja epäselvä(miten se on venäjäksi?), joka lähinnä tarkoitti sarjoittamista. Normaalitoimintojen kutsut prosessien sisällä käsiteltiin soittajalla Välityspalvelin, ja toimintoa suorittavan järjestelmän puolella, sisään Lähettäjä... Ihannetapauksessa soittojärjestelmä tai käsittelyjärjestelmä eivät olleet kiinnostuneita tietojen siirtämisen monimutkaisuudesta järjestelmien välillä. Kaikki nämä hienovaraisuudet keskitettiin Proxy - Dispatcher -pakettiin, jonka koodi luotiin automaattisesti.
Siksi et huomaa, sinun ei pitäisi huomata mitään eroa paikalliseen toimintoon ja etätoimintoon kutsumisen välillä.
Nyt on olemassa eräänlainen RPC -renessanssi, jonka näkyvimmät edustajat ovat: Google ProtoBuf, Thrift, Avro.
Ajan myötä kävi ilmi, että yritys suojella ohjelmoijaa siitä, että kutsuttu toiminto on edelleen erilainen kuin paikallinen, ei johtanut haluttuun tulokseen. Toteutustiedot ja perustavanlaatuiset erot hajautettujen järjestelmien välillä olivat liian suuria, jotta niitä voitaisiin ratkaista automaattisesti luodulla välityspalvelinkoodilla. Vähitellen kävi selväksi, että se, että järjestelmät on liitetty epäluotettavaan, hitaaseen ja hitaaseen ympäristöön, on otettava nimenomaisesti huomioon ohjelmakoodissa.
Tekniikat ilmestyivät Web palvelut... Aloimme puhua ABC: Osoite, sitova, sopimus... Ei ole täysin selvää, miksi sopimukset ilmestyivät, ja ne ovat lähinnä kirjekuoria syöttöargumenteille. Sopimukset usein monimutkaistavat koko mallia eivätkä yksinkertaista sitä. Mutta ... ei haittaa.
Nyt ohjelmoija loi nimenomaisesti palvelu(Palvelu) tai asiakas(Asiakas) soittamalla palveluun. Palvelu oli kokonaisuus toimintaa (Operaatio), joista jokainen otettiin syötteessä tiedustelu(Pyyntö) ja antoi vastaus(Vastaus). Asiakas nimenomaisesti lähetetty(Lähetetty), palvelu on nimenomaisesti vastaanotettu ( Vastaanottaa) ja vastasi (Lähetetty) lähettämällä vastauksen. Asiakas sai (Vastaanota) vastauksen ja puhelu päättyi.
Aivan kuten RPC: ssä, välityspalvelin ja lähettäjä työskentelivät jossain täällä. Ja kuten ennen, heidän koodinsa luotiin automaattisesti, eikä ohjelmoijan tarvinnut ymmärtää sitä. Ellei juuri nyt, asiakas käytti nimenomaisesti välityspalvelimen luokkia.
Pyynnöt ja vastaukset muunnetaan nimenomaisesti langalliseen muotoon. Useimmiten tämä on tavuryhmä. Muutosta kutsutaan Serialisointi ja Deserialisointi ja joskus piiloutuu välityspalvelimen koodiin.
Viestien huipentuma oli paradigman syntyminen ESB (Enterprise Service Bus)... Kukaan ei voi sanoa, mitä se on, mutta kaikki ovat samaa mieltä siitä, että tiedot ESB: stä liikkuvat viestien muodossa.
Jatkuvassa kamppailussa koodin monimutkaisuuden kanssa ohjelmoijat ottivat seuraavan askeleen ja loivat LEVÄTÄ.
RESTin perusperiaate on, että toimintooperaatiot ovat jyrkästi rajoitettuja ja vain joukko toimintoja on jäljellä. CRUD: Luo - Lue - Päivitä - Poista... Tässä mallissa kaikkia toimintoja sovelletaan aina joihinkin tietoihin. CRUD -toiminnot ovat käytettävissä useimmissa sovelluksissa. Koska REST -tekniikat edellyttävät useimmissa tapauksissa HTTP -protokollan käyttöä, CRUD -komennot vaikuttivat komentoihin HTTP (Lähettää - Saada - Laittaa - Poistaa) ... Väitetään jatkuvasti, että REST ei välttämättä ole sidottu HTTP: hen. Mutta käytännössä operaatioiden allekirjoitusten heijastusta HTTP -komentojen syntaksiin käytetään laajalti. Esimerkiksi funktion kutsuminen
EntityAddress ReadEntityAddress (string param1, string param2)
Se ilmaistaan seuraavasti:
GET: entityAddress? Param1 = arvo1 ja param2 = arvo2
Ennen kuin aloitat keskustelun hajautetuista järjestelmistä tai integraatiosta, määrittele joitakin terminologioita. Jos välityspalvelin tarkoittaa aina samaa asiaa eri yhteyksissä, esimerkiksi pyyntö ei merkitse juurikaan RPC -termejä, ja järjestely aiheuttaa hämmennystä keskusteltaessa REST -tekniikoista.
) Etäproseduurikutsun käsite
Etäkäytännön kutsun (RPC) ajatuksena on laajentaa tunnettu ja ymmärretty mekanismi ohjauksen ja datan siirtämiseksi yhdessä koneessa käynnissä olevan ohjelman sisällä ohjauksen ja datan siirtämiseksi verkon kautta. Etämenettelykutsut on suunniteltu helpottamaan hajautetun tietojenkäsittelyn järjestämistä. RPC on tehokkain sovelluksissa, joissa on vuorovaikutteista viestintää etäkomponenttien välillä, nopeat vasteajat ja suhteellisen vähän tiedonsiirtoa. Tällaisia sovelluksia kutsutaan RPC-suuntautuneiksi.
Paikallisille menettelykutsuille on ominaista:
Epäsymmetria eli yksi vuorovaikutuksessa olevista osapuolista on aloittaja; Synkronisuus eli soittotoimenpiteen suorittaminen, kun se pysähtyy pyynnön lähettämishetkestä ja jatkuu vasta kutsutusta menettelystä palattuaan.
Etäpuheluiden toteuttaminen on huomattavasti monimutkaisempaa kuin paikallisten proseduurikutsujen toteuttaminen. Ensinnäkin, koska soittaja ja kutsuttu suoritetaan eri koneilla, niillä on eri osoiteavaruudet, mikä aiheuttaa ongelmia parametrien ja tulosten välittämisessä, varsinkin jos koneet eivät ole identtisiä. Koska RPC ei voi luottaa jaettuun muistiin, tämä tarkoittaa, että RPC-parametrit eivät saa sisältää osoittimia muille kuin pino-muistipaikoille ja että parametriarvot on kopioitava tietokoneesta toiseen. Seuraava ero RPC: n ja paikallisen puhelun välillä on, että se käyttää välttämättä taustalla olevaa viestintäjärjestelmää, mutta tämän ei pitäisi näkyä nimenomaisesti menettelyjen määrittelyssä tai itse menettelyissä. Etäisyys tuo lisäongelmia. Kutsuvan ohjelman ja kutsutun paikallisen menettelyn suorittaminen samalla koneella suoritetaan yhdessä prosessissa. Mutta RPC -toteutukseen liittyy ainakin kaksi prosessia - yksi jokaisessa koneessa. Jos yksi niistä kaatuu, seuraavia tilanteita voi ilmetä: jos kutsumismenettely kaatuu, etäkutsutut menettelyt jäävät orvoiksi ja jos etäproseduurit päättyvät epänormaalisti, soittajista tulee soittajien "riistettyjä vanhempia", jotka odota turhaan vastausta etämenettelyistä.
Lisäksi ohjelmointikielien ja käyttöympäristöjen heterogeenisuuteen liittyy useita ongelmia: yhdellä ohjelmointikielellä tuettuja tietorakenteita ja menettelykutsurakenteita ei tueta samalla tavalla kaikilla muilla kielillä.
Nämä ja eräät muut ongelmat ratkaistaan laajalla RPC -tekniikalla, joka on monien hajautettujen käyttöjärjestelmien taustalla.
RPC -perustoiminnot
Ymmärtääksesi RPC: n toiminnan harkitse ensin paikallisen proseduurikutsun suorittamista perinteisellä koneella, joka toimii itsenäisesti. Olkoon se esimerkiksi järjestelmäpuhelu
Count = luku (fd, buf, nbytes);
missä fd on kokonaisluku,
buf on joukko merkkejä,
nbytes on kokonaisluku.
Puhelun soittamiseksi kutsumismenettely työntää parametrit pinoon päinvastaisessa järjestyksessä (kuva 3.1). Kun lukukutsu on suoritettu, se sijoittaa palautusarvon rekisteriin, siirtää palautusosoitteen ja palauttaa ohjauksen soittomenettelyyn, joka nostaa parametrit pinosta ja palauttaa sen alkuperäiseen tilaansa. Huomaa, että C: ssä parametreja voidaan kutsua joko viitteellä (nimellä) tai arvolla (arvon mukaan). Kutsutun menettelyn osalta arvoparametrit ovat alustettavia paikallisia muuttujia. Kutsuttu menettely voi muuttaa niitä vaikuttamatta näiden muuttujien alkuperäisten arvoon kutsumismenettelyssä.
Jos osoitin muuttujaan välitetään kutsutulle proseduurille, tämän muuttujan arvon muutos kutsutulla menettelyllä johtaa muuttujan arvon muutokseen myös kutsutusmenettelyssä. Tämä tosiasia on olennainen RPC: lle.
Parametrien välittämiseen on myös toinen mekanismi, jota ei käytetä C-kielellä. Sitä kutsutaan kutsutuskopioksi / palautukseksi, ja kutsuvan ohjelman on kopioitava muuttujat pinoon arvoina ja kopioitava sitten takaisin sen jälkeen, kun puhelu on soitettu alkuperäisten arvojen yli.
Kielisuunnittelijoiden on päätettävä, mitä parametrien välitysmekanismia käytetään. Joskus se riippuu siirrettävien tietojen tyypistä. Esimerkiksi C: ssä kokonaisluku- ja muut skalaaritiedot välitetään aina arvon mukaan ja matriisit aina viittauksella.
Riisi. 3.1. a) pino ennen lukukutsua;
b) pino menettelyn suorittamisen aikana;
c) Pino soittopalveluun palaamisen jälkeen
RPC: n ajatuksena on saada etäproseduurikutsu näyttämään mahdollisimman läheltä paikallista menettelykutsua. Toisin sanoen, tee RPC läpinäkyväksi: soittajan ei tarvitse tietää, että kutsuttu menettely on eri koneessa, ja päinvastoin.
RPC saavuttaa läpinäkyvyyden seuraavalla tavalla. Kun kutsuttu proseduuri on todellakin etäkäyttöinen, paikallisen proseduurin sijasta kirjastossa on toinen prosessin versio, jota kutsutaan asiakkaan tynkäksi (tynkä). Kuten alkuperäinen menettely, tynkä kutsutaan kutsusekvenssin avulla (kuten kuvassa 3.1) ja ydin keskeytetään. Vain toisin kuin alkuperäinen menettely, se ei laita parametreja rekistereihin eikä pyydä ytimeltä tietoja, vaan luo viestin, joka lähetetään etäkoneen ytimeen.
RPC -suoritusvaiheet
Ohjelmistokomponenttien vuorovaikutus etäproseduurikutsun suorittamisen aikana on esitetty kuvassa 3.2. Kun asiakasohjelma on kutsunut asiakastyön, sen ensimmäinen tehtävä on täyttää puskuri lähetettävällä viestillä. Joissakin järjestelmissä asiakaskannassa on yksi kiinteäpituinen puskuri, joka täytetään alusta alkaen aina, kun uusi pyyntö saapuu. Muissa järjestelmissä sanomapuskuri on yksittäisten viestikenttien puskureita, joista osa on jo täynnä. Tämä menetelmä sopii erityisesti silloin, kun paketti on muotoiltu suurella määrällä kenttiä, mutta monien näiden kenttien arvot eivät muutu puhelusta puheluun.
Parametrit on sitten muunnettava sopivaan muotoon ja lisättävä sanomapuskuriin. Tässä vaiheessa viesti on valmis lähetettäväksi, joten ydinpuhelu keskeytetään.
Kun ydin saa hallinnan, se vaihtaa konteksteja, tallentaa prosessorirekisterit ja muistikartan (sivunkuvaajat) ja määrittää uuden muistikartan, jota käytetään ytintilassa. Koska ytimen ja käyttäjäyhteydet ovat erilaisia, ytimen on kopioitava viesti täsmälleen omaan osoitetilaansa, jotta se voi käyttää sitä, muistaa kohdeosoite (ja mahdollisesti muut otsikkokentät), ja sen on myös välitettävä se verkolle käyttöliittymä. Tämä päättää työn asiakaspuolella. Lähetysajastin on kytketty päälle, ja ydin voi joko kysyä vastausta tai siirtää ohjauksen ajoitukselle, joka valitsee jonkin muun suoritettavan prosessin. Ensimmäisessä tapauksessa kyselyn suorittamista nopeutetaan, mutta moniohjelmointia ei ole.
Palvelinpuolella vastaanottavat laitteet sijoittavat saapuvat bitit joko sisäänrakennettuun puskuriin tai RAM-muistiin. Kun kaikki tiedot on vastaanotettu, syntyy keskeytys. Keskeytyksen käsittelijä tarkistaa pakettidatan oikeellisuuden ja päättää, mikä tynkä sen pitäisi välittää. Jos yksikään tynkistä ei odota tätä pakettia, käsittelijän on joko puskuroitava se tai hävitettävä se kokonaan. Jos odottava tynkä on, viesti kopioidaan siihen. Lopuksi suoritetaan kontekstikytkin, jonka seurauksena rekisterit ja muistikartta palautetaan ottaen arvot, jotka niillä oli sillä hetkellä, kun tynkä soitti vastaanottopuhelun.
Nyt palvelimen tynkä alkaa toimia. Se purkaa parametrit pakkauksesta ja työntää ne sopivasti pinolle. Kun kaikki on valmista, soitetaan palvelinkutsu. Menettelyn päätyttyä palvelin lähettää tulokset asiakkaalle. Tätä varten kaikki edellä kuvatut vaiheet suoritetaan vain päinvastaisessa järjestyksessä.
Kuva 3.3 esittää komentojen järjestyksen, joka on suoritettava kullekin RPC -kutsulle, ja kuva 3.4 osoittaa, kuinka suuri osa RPC: n kokonaisajasta kuluu kunkin kuvatun 14 vaiheen suorittamiseen. Tutkimus tehtiin DEC Firefly -moniprosessorityöasemalla, ja vaikka viiden prosessorin läsnäolo vaikutti välttämättä mittaustuloksiin, kuvassa näkyvä histogrammi antaa yleiskuvan RPC -suoritusprosessista.
1. Soita tynkään
2. Valmista puskuri
3. Pakkauksen parametrit
4. Täytä otsikkokenttä
5. Laske viestin tarkistussumma
6. Keskeytä ytimeen
7. Pakettijono suoritettavaksi
8. Viestin lähettäminen ohjaimelle QBUS -väylän kautta
9. Ethernet -lähetysaika
10. Hanki paketti ohjaimesta
11. Keskeytä käsittely
12. Tarkistussumman laskeminen
13. Kontekstin vaihtaminen käyttäjätilaan
14. Palvelimen tynkän suorittaminen
Dynaaminen linkitys
Harkitse kysymystä siitä, miten asiakas määrittää palvelimen sijainnin. Yksi tapa ratkaista tämä ongelma on käyttää suoraan palvelimen verkko -osoitetta asiakasohjelmassa. Tämän lähestymistavan haittana on sen äärimmäinen joustamattomuus: kun palvelinta siirretään tai palvelimien määrää lisätään tai käyttöliittymää muutetaan, kaikissa näissä ja monissa muissa tapauksissa on tarpeen kääntää uudelleen kaikki ohjelmat, jotka käyttivät palvelimen osoitteen kova antaminen. Kaikkien näiden ongelmien välttämiseksi jotkut hajautetut järjestelmät käyttävät niin sanottua dynaamista linkitystä.
Dynaamisen sidonnan lähtökohta on palvelimen muodollinen määritelmä (spesifikaatio). Tekniset tiedot sisältävät tiedostopalvelimen nimen, versionumeron ja luettelon palvelimen asiakkaille tarjoamista palvelutoimenpiteistä (Kuva 3.5). Jokaiselle toimenpiteelle annetaan sen parametrien kuvaus, joka osoittaa, onko tämä parametri syötetty vai tulostettu suhteessa palvelimeen. Jotkin parametrit voivat olla sekä syöttö- että tulostus - esimerkiksi jotkut asiakasohjelman palvelimelle lähettämät taulukot, joita muutetaan siellä ja palautetaan sitten takaisin asiakkaalle (kopiointi- / palautustoiminto).
Muodollista palvelinmäärittelyä käytetään syötteenä tynkägeneraattoriohjelmaan, joka luo sekä asiakas- että palvelimen tynkät. Sitten ne sijoitetaan asianmukaisiin kirjastoihin. Kun käyttäjä (asiakas) -ohjelma kutsuu mitä tahansa palvelimen määrityksissä määriteltyä menettelyä, vastaava tynkäproseduuri liittyy ohjelman binaariin. Samoin, kun palvelin käännetään, palvelimen tynkät liittyvät siihen.
Kun palvelin käynnistyy, ensimmäinen asia, jonka se tekee, on välittää palvelinkäyttöliittymä erityiselle ohjelmalle nimeltä sideaine. Tämä prosessi, joka tunnetaan palvelimen rekisteröintiprosessina, edellyttää, että palvelin lähettää nimen, versionumeron, yksilöllisen tunnisteen ja Kuvaaja on järjestelmästä riippumaton ja voi olla IP-, Ethernet-, X.500- tai jokin muu osoite, ja se voi sisältää muita tietoja, kuten todennuksen.
Kun asiakas soittaa jollekin etäproseduurista ensimmäistä kertaa, esimerkiksi lukee, asiakastuki näkee, että se ei ole vielä yhteydessä palvelimeen, ja lähettää viestin sideohjelmalle, jossa se pyytää tuomaan oikean version käyttöliittymän vaaditusta palvelimesta. Jos tällainen palvelin on olemassa, sideaine välittää kahvan ja yksilöllisen tunnisteen asiakkaan tynkälle.
Asiakkaan tynkä käyttää kuvaajaa osoitteena lähettäessään pyyntöviestin. Viesti sisältää parametreja ja yksilöllisen tunnisteen, jota palvelimen ydin käyttää välittääkseen saapuvan viestin oikealle palvelimelle, jos niitä on useita tällä koneella.
Tämä tapa tuoda / viedä rajapintoja on erittäin joustava. Esimerkiksi samaa käyttöliittymää voi olla useita palvelimia, ja asiakkaat jaetaan satunnaisesti palvelimien kesken. Tämän menetelmän puitteissa on mahdollista ajoittain kysyä palvelimia, analysoida niiden suorituskykyä ja vian sattuessa automaattinen sammutus, mikä lisää järjestelmän yleistä vikasietoisuutta. Tämä menetelmä voi myös tukea asiakkaan todennusta. Palvelin voi esimerkiksi määrittää, että sitä voivat käyttää vain tietyn luettelon asiakkaat.
Dynaamisella linkittämisellä on kuitenkin haittoja, kuten lisäkustannukset (aika) rajapintojen viennissä ja tuonnissa. Näiden kustannusten suuruus voi olla merkittävä, koska monet asiakasprosessit ovat olemassa lyhyen aikaa, ja jokaisen prosessin alussa käyttöliittymän tuontimenettely on suoritettava uudelleen. Lisäksi suurissa hajautetuissa järjestelmissä sideaineohjelmasta voi tulla pullonkaula, ja useiden samankaltaisten ohjelmien luominen lisää myös prosessien luomisen ja synkronoinnin yleiskustannuksia.
RPC -semantiikka vikatapauksissa
Ihannetapauksessa RPC: n pitäisi toimia oikein vian sattuessa. Harkitse seuraavia vikaluokkia:
Asiakas ei voi määrittää palvelimen sijaintia, esimerkiksi jos vaadittu palvelin epäonnistuu tai asiakasohjelma on koottu kauan sitten ja se on käyttänyt palvelinliittymän vanhaa versiota. Tässä tapauksessa virhekoodin sisältävä viesti vastaanotetaan vastauksena asiakkaan pyyntöön. Kadonnut asiakas-palvelin-pyyntö. Yksinkertaisin ratkaisu on toistaa pyyntö tietyn ajan kuluttua. Kadonnut vastausviesti palvelimelta asiakkaalle. Tämä vaihtoehto on monimutkaisempi kuin edellinen, koska jotkut menettelyt eivät ole idempotentteja. Idempotent -menettely on menettely, jonka suorituspyyntö voidaan toistaa useita kertoja, eikä tulos muutu. Esimerkki tällaisesta menettelystä on tiedoston lukeminen. Menettely tietyn summan kotiuttamiseksi pankkitililtä ei kuitenkaan ole järkevä, ja jos vastaus häviää, toistuva pyyntö voi muuttaa merkittävästi asiakkaan tilin tilaa. Yksi mahdollisista ratkaisuista on saada kaikki menettelyt idempotenttiin muotoon. Käytännössä tämä ei kuitenkaan aina ole mahdollista, joten voidaan käyttää toista menetelmää - kaikkien ydinpyyntöjen järjestysnumerointia. Palvelinydin muistaa kunkin asiakkaan viimeisimmän pyynnön numeron, ja jokaisen pyynnön saatuaan se analysoi, onko tämä pyyntö ensisijainen vai toistuva. Palvelin kaatui pyynnön vastaanottamisen jälkeen. Idempotenssin ominaisuus on myös tärkeä tässä, mutta valitettavasti kyselyn numerointimenetelmää ei voida soveltaa. Tässä tapauksessa sillä on merkitystä
Java RMI eräänä etäproseduurikutsuna, riippumatta verkosta, sen kanssa työskentelyn päävaiheista ja tarkoituksesta. Jaettujen ja jakamattomien Java-ohjelmien vertailu. Java RMI -arkkitehtuuri, tynkä ja luuranko, etäviitteet ja siirtokerrokset.
Esikokoelma SQL -kyselyistä suorituspaikassa. PrepaStatement -lauseen käyttäminen. Käytä puhelun määrityksen syntaksia saadaksesi menettelyn tai funktion palautusarvon. Luo näytteenotto -ohjeita tarvittaessa.
Työn tarkoitus ja suunnitelma. Koostumus ja asennus. Paketin http menettelyjen määrittely.
Toimenpiteet ja toiminnot voidaan määritellä suljetuiksi ohjelmistoyksiköiksi, jotka toteuttavat jonkin algoritmin. Itse asiassa menettely tai toiminto on melkein ohjelma.
Automaattinen TCP / IP -määritys, dynaaminen määritys BOOTP: n avulla. Pyynnön / vastauksen IP -osoitteet, menetys- ja viestimuoto, BOOTP -vaiheet. DHCP -protokolla BOOTP -protokollan jatkeena. IP -osoitteiden jakaminen ja osoittaminen.
Olemme jo tavanneet rekursion käsitteen: toistumissuhteet ovat melko yleisiä matemaattisissa ilmaisuissa. Määritelmän rekursio koostuu siitä, että määritelty käsite määritellään käsitteen kautta.
1. Johdanto 2 2. Katsaus COM -tekniikkaan 2 2.1. KOM -objektin koostumus 3 2.2. Liitännät 4 2.3. COM -objektien ominaisuudet 6 2.4. COM -palvelimet 6 2.5. Järjestysmekanismi 7
Tutkimus etätietokantojen olemuksesta, toimintaperiaatteesta ja päätarkoituksesta. Tietojen etähallintamalli (tiedostopalvelinmalli). Rinnakkaistyypit. Trigger on mekanismi tietokannan tilaan liittyvien erityistapahtumien seurantaan.
Metamalli-, fakta- ja turvallisuusmallipaketit. Käsitteellinen malli asiakkaasta. Esimerkki hajautetun arkkitehtuurin toiminnasta. Toteutuksen monimutkaisuus.
Dll käsite. Muistetaan DOS -ohjelmointiprosessi. Lähdekoodin muuntaminen konekoodiksi sisälsi kaksi prosessia: kokoaminen ja linkittäminen. Linkittämisen aikana ohjelmakoodiin sijoitettiin paitsi toimintojen ja menettelyjen ilmoitukset, myös niiden täydellinen koodi.
Toiminnot TCP / IP -protokollan, Socket, Bind, kuuntele ja hyväksy. Tiedoston kuvaaja. Viestintäprosessit. Tietojen vastaanottaminen. Lukeminen pistorasiasta. Kirjoittaminen pistorasiaan. Pistorasian sulkeminen. Ohjelman teksti, joka luo Web -palvelimen QNX -käyttöjärjestelmään.
Netizenien pääsy sähköpostit tallennettu palvelimelle. Ohjelman kuvaus, todennus on yksinkertainen, APOP ja AUTH-todennus. Toimintojen toteutus, käyttöopas, ohjelman toiminnan algoritmit, graafinen käyttöliittymä.
Turbo-Paskal-ohjelmointikielen pääoperaattoreiden toimintaperiaate: tehtäväoperaattori, tapauksen valinta, ehdoton hyppy, silmukka, tarttuva, yhdistelmä. Toimintojen ja menettelyjen virallinen kuvaus ja kutsu. Todellisten parametrien luetteloa koskevat vaatimukset.
Java -servlettien toimintaperiaate ja tarkoitus, niiden merkitys verkkopalvelimien toimivuuden lisäämisessä ja ohjelmoinnin parantamisessa, käytön edut ja haitat. Tapoja soittaa servleteille selaimesta ja sivulta. Kirjoittaminen ja istunnon määritteiden lukeminen.
Windows NT OS -arkkitehtuuri. Mikrokernelipohjainen käyttöjärjestelmärakenne. Windows NT: n suojatut osajärjestelmät.
Perusviestien välitys primitiivit hajautetuissa järjestelmissä. Osoittamismenetelmät. Estävät ja estävät primitiivit. Puskuroidut ja puskuroimattomat primitiivit.
Sovelluspalvelin. Asiakasosa.
Kaksi vuotta sitten AJAX oli uutuus (eikä sanaa AJAX itse keksitty silloin). Nyt verkkosovellukset, joiden sivut päivitettiin lennossa, ovat arkipäivää. Päinvastoin: on vaikea kuvitella joitakin palveluita ilman AJAXia.
Prosessin kuvaamisen ja kutsumisen syntaksi. Asetukset. Esimerkki menettelyn kuvaamisesta ja kutsumisesta. Parametrien tyypit. Ohjelmoida.
Monet tietokoneen käyttäjät ovat kuulleet käsitteistä, kuten etämenettelyistä, etämenettelykutsusta tai RPC: stä. Kaikki eivät kuitenkaan tiedä, mitä nämä tekniikat ovat, miten ne toimivat ja mihin niitä tarvitaan. Mutta monet niistä, jotka ovat poistaneet tämän palvelun käytöstä Windows -järjestelmissä, voivat usein saada kriittisiin virheisiin liittyviä virheitä. Tätä ja paljon muuta käsitellään alla.
Kannattaa aloittaa teoreettisista tiedoista. Uskotaan, että etäproseduurit (etämenettelykutsut) ovat mekanismi, jonka avulla voit käynnistää tai käyttää tietokonejärjestelmien toimintoja eri osoitetilassa kuin käytetty päätelaite. Yksinkertaisesti sanottuna tämä on tapa päästä etätietokoneeseen esimerkiksi kautta paikallisverkko tai Internet -yhteys.
Etämenettelyt (etämenettelykutsut), joita kutsutaan RPC: ksi (lyhenne sanoista Remote Procedure Call), eivät kuitenkaan rajoitu etätietokoneisiin. Paikallisella tasolla tällaisia tekniikoita käytetään myös. Yksinkertaisin esimerkki on kutsua jonkin ohjelman tietty toiminto toisesta sovelluksesta vuorovaikutuksen kautta erityisten kirjastojen kautta.
Lisäksi ehdottomasti kaikissa Windows -versioissa on tällainen palvelu, ja jos se on poistettu käytöstä tai epäonnistuu, XP -muutos ei toimi ollenkaan.
RPC-palvelu edellyttää pääsääntöisesti vähintään kahta pääkomponenttia toimimaan asiakas-palvelin-tilassa: verkkoprotokolla tiedonvaihtoa varten ja sarjoituskieli (prosessin tai informaatiorakenteen kääntäminen bittisekvenssiksi).
Arkkitehtuurit voivat olla täysin erilaisia ja kyvyiltään erilaisia. Mutta tiedonsiirtoon ns. Siirtokerroksessa käytetään useimmiten UDP: tä ja TCP: tä, harvemmin HTTP: tä.
Jotta teknisiin näkökohtiin ei mennä, seuraava esimerkki voi olla yksinkertaisin selitys tällaisten tekniikoiden toimintaperiaatteelle: asiakasprosessi luo palvelimelle pyynnön, jossa on kuvaus valitusta menettelystä määritetyillä parametreilla, ja lähettää sen, jonka jälkeen palvelin suorittaa vaaditun direktiivin ja lähettää asiakkaalle vastauksen, joka näkyy asiakasautossa. Palvelimen käsittelijä on kuitenkin niin sanotusti valmiustilassa ja aktivoituu vasta, kun asiakaspyyntöjä vastaanotetaan. Tässä tapauksessa ei ole ollenkaan välttämätöntä, että pyyntö-vastaus-järjestelmä suoritetaan välittömästi.
Samaan aikaan maksimaalinen suorituskyky saavutetaan, kun vaihdetaan suhteellisen pieniä tietomääriä ja lyhyt vasteaika komponenteille, joiden välillä vuorovaikutteinen viestintä on muodostettu.
Näiden tekniikoiden kaksi pääominaisuutta voidaan siis erottaa:
Toteutusten kannalta etäproseduurit (etämenettelykutsut) käyttävät nykyään useita perustekniikoita, joista yleisimmin käytettyjä ovat seuraavat:
Nyt muutama sana haitoista. Tärkein ongelma ja vastaavasti toteutustehtävä on, että sama toimenpide, joka koskee etäproseduurin kutsumista palvelun "Etämenettelykutsu" solmun kautta, on suoritettava samanaikaisesti eri koneilla ja usein eri käyttöjärjestelmillä, osoitepaikat ja arkkitehtuuri ... Prosessissa parametritiedot on kopioitava päätelaitteesta toiseen. Tätä varten ei käytetä pelkästään siirtoprotokollaa, vaan myös serialisointia, joka mahdollistaa eri tietotyyppien muuntamisen tavusekvenssiksi.
Toinen kohta liittyy siihen, että etäproseduurit (etämenettelykutsut) eivät käytä yhtä prosessia, kuten paikallisella tasolla, vaan kahta (asiakaskoneella ja palvelimella). Siksi ohjelman epänormaali lopettaminen toisella päätelaitteella voi aiheuttaa saman reaktion toisella.
Lopuksi yksi suurimmista ongelmista on nimeltään yhteensopivuus, joka johtuu joidenkin ohjelmointikielten heterogeenisyydestä huolimatta vakiintuneista yhtenäisistä standardeista.
Etäproseduurikutsu Windows 10: lle tai jollekin muulle luokan alle jäävälle järjestelmälle edellyttää erityisten alijärjestelmien käyttöä:
Jos puhumme siitä, mitkä käyttöjärjestelmien ohjelmistomoduulit edellyttävät RPC -palvelun pitämistä käytössä, on yksinkertaisesti mahdotonta luetella niitä kaikkia.
Mutta kaikkien Windows-järjestelmien tunnettujen komponenttien joukossa voimme mainita faksipalvelun, salauspalvelut, virheiden kirjaamisen, ohjeen ja tuen, pääsyn HID-laitteisiin, viestintäpalvelun (Messenger), levyjen ja loogisten osioiden hallinnan, irrotettavien laitteiden hallinnan asemat, äänijärjestelmä, Windows Installer ja paljon muuta. Jumala tietää mitä.
Näyttää siltä, että tämä luettelo riittää ymmärtämään, kuinka monet järjestelmän komponentit ja käyttäjä itse ovat riippuvaisia tästä palvelusta.
Yleensä edellisen kuvauksen perusteella voit arvioida RPC: n vaikutuksen. Joten esimerkiksi on monia tapauksia, joissa kun tämä palvelu sammutettiin, ääni katosi kokonaan, järjestelmää ei voitu palauttaa kriittisten vikojen jälkeen tai käyttäjän aloittamana, langattoman verkon asetukset "vilkkuvat".
Surullisinta on kuitenkin se, että jos poistat RPC -etäproseduurikutsun käytöstä, joskus on jopa mahdotonta päästä käsiksi järjestelmän perusasetuksiin, olipa käyttäjä vähintään kolme kertaa oman päätelaitteen järjestelmänvalvoja.
Yleensä monet ovat yrittäneet (ja yrittävät) poistaa RPC -palvelun käytöstä. Tämän tekeminen on ehdottomasti kielletty. Yleensä itse järjestelmä ei yrittäessään tehdä tällaista ilmoitusta.
Mutta kaikki eivät tiedä, että palveluosassa (services.msc) on myös sellainen asia kuin "RPC -paikannin". Se on vain jotain, joka voidaan sammuttaa järjestelmästä kivuttomasti. Sovellukset, jotka voivat käyttää sitä työssään, soittavat tarvittaessa palveluun itsenäisesti.
Katsotaan lopuksi, mitä voit tehdä, jos etäproseduurikutsun aikana ilmaantuu virhe. Yksinkertaisimmassa tapauksessa voit yrittää ottaa palvelun uudelleen käyttöön (jos se tietysti toimii).
Voit tehdä tämän kaksoisnapsauttamalla parametrien muokkausvalikkoa vastaavassa osiossa, jossa haluttu palvelu sijaitsee, painamalla käyttöpainiketta ja itse sisällytystyypiksi on asetettu automaattinen. Jos tätä toimenpidettä ei voi suorittaa järjestelmän vakiokäynnistyksen aikana, voit yrittää suorittaa samanlaisia toimintoja vikasietotilassa. Jotkut asiantuntijat suosittelevat, että virustentorjuntaohjelmisto sammutetaan samanaikaisesti toimenpiteen ajaksi.
Jos tämä ei auta, mutta sinulla on järjestelmän asennus- tai palautuslevy käsillä, voit käynnistää komentokonsolin järjestelmänvalvojan oikeuksilla (sinun ei tarvitse käynnistää levyltä) ja kirjoittaa siihen seuraavat komennot:
Käynnistä sen jälkeen "Tehtävienhallinta" (Ctrl + Del + Alt tai taskmgr "Suorita" -valikossa) ja lopeta Explorer.exe -prosessi.
Lopetamme "lähettäjässä" kaikki svhost.exe -prosessit, ja sitten 60 sekunnin kuluessa sinulla on oltava aikaa syöttää komentoriville kopio% TEMP% \ svchost.exe% systemroot% \ system32 / y.
Lopuksi, jos olet palauttanut pääsyn rekisterieditoriin (regedit), sinun on käytävä HKCC -haara läpi SYSTEM- ja CurrentControlSet -osioiden kautta ja päästävä CSConfigFlags -parametriin muuttamalla sen arvo nollaksi.
Nämä ovat vain joitain menetelmiä RPC: hen liittyvien virheiden korjaamiseen. Tosiasia on, että jos tämä palvelu aiheutti häiriöitä muiden palvelujen toiminnassa, sinun on ehkä ensin korjattava niiden suorituskykyongelmat ja vasta sitten ryhdyttävä toimiin RPC: n suhteen. Ja et aina voi saada täyden pääsyn yllä oleviin parametreihin ja asetuksiin. Jos mitään ei tapahdu lainkaan, vaikka se kuulostaakin valitettavalta, sinun on asennettava käyttöjärjestelmä kokonaan uudelleen, vaikka toivoisin, että tämä ei tule tähän.
Siinä kaikki pähkinänkuoressa RPC -tekniikasta ja -palvelusta. Itse asiassa kaikki tämä näyttää paljon monimutkaisemmalta kuin mitä tässä kuvauksessa esitettiin, ja jotta ymmärrät ongelman täysin, sinulla on oltava vähintään perustiedot. Mutta saadakseen yleisen käsityksen RPC: stä tämä riittää toistaiseksi.
Mitä tulee sammutukseen, älä yritä tehdä sellaisia asioita, muuten koko järjestelmä epäonnistuu. Kaatumisten korjaamiseen annetut ratkaisut auttavat yleensä, mutta et voi silti antaa täydellistä takuuta, koska palvelun poistaminen käytöstä voi aiheuttaa vikoja muissa osissa.
