Soita etätoimenpiteisiin rpc-ultraääniskanneri. Etämenettelyn kutsumekanismi - RPC

Erittäin tärkeän mekanismin asiakas-palvelinsovelluksille tarjoaa RPC ( Etämenettelyn kutsu). RPC:n on kehittänyt Sun Micrsystems, ja se on kokoelma työkaluja ja kirjastotoimintoja. Erityisesti NIS (Network Information System) ja NFS (Network File System) toimivat RPC:ssä.

RPC-palvelin koostuu tällaisten proseduurien järjestelmästä, johon asiakas pääsee käsiksi lähettämällä palvelimelle RPC-pyynnön proseduuriparametrien kanssa. Palvelin kutsuu määritettyä proseduuria ja palauttaa sen mahdollisen palautusarvon. Koneesta riippumattomana kaikki asiakkaan ja palvelimen välillä vaihdettu data muunnetaan niin sanotuksi ulkopuoliseksi dataesitykseksi ( Ulkoinen tietojen edustus, XDR). RPC kommunikoi UDP- ja TCP-vastakkeiden kanssa tiedon siirtämiseksi XDR-muodossa. Sun on julistanut RPC:n julkiseksi, ja sen kuvaus on saatavilla useissa RFC-asiakirjoissa.

Joskus muutokset RPC-sovelluksissa aiheuttavat yhteensopimattomuutta liitäntäkutsumenettelyyn. Tietenkin yksinkertainen muutos saattaisi palvelimen kaatamaan kaikki sovellukset, jotka odottavat edelleen samoja kutsuja. Siksi RPC-ohjelmille on määritetty versionumerot, jotka yleensä alkavat numerolla 1. Jokainen uusi versio RPC pitää kirjaa versionumerosta. Usein palvelin voi tarjota useita versioita samanaikaisesti. Asiakkaat määrittelevät tässä tapauksessa versionumeron, jota he haluavat käyttää.

RPC-palvelimien ja asiakkaiden välinen verkkoliikenne on hieman erikoista. RPC-palvelin tarjoaa yhden tai useamman järjestelmäproseduurin, joista jokaista kutsutaan ohjelmaksi ( ohjelmoida) ja se tunnistetaan yksiselitteisesti ohjelmanumerolla ( ohjelman numero). Palvelunimien luettelo säilytetään yleensä tiedostossa /etc/rpc, josta on esimerkki alla.

Esimerkki 12-4. Esimerkki /etc/rpc-tiedostosta

TCP/IP-verkoissa RPC:n tekijöiden tehtävänä oli kartoittaa ohjelmanumerot yleisiin verkkopalveluihin. Jokainen palvelin tarjoaa TCP- ja UDP-portin jokaiselle ohjelmalle ja jokaiselle versiolle. Yleensä RPC-sovellukset käyttävät UDP:tä tiedon lähettämiseen ja palaavat TCP:hen, kun lähetettävä data ei mahdu yhteen UDP-datagrammiin.

Tietenkin asiakasohjelmilla on oltava tapa selvittää, mikä portti vastaa ohjelman numeroa. Asetustiedoston käyttäminen tähän olisi liian joustamatonta; Koska RPC-sovellukset eivät käytä varattuja portteja, ei ole takeita siitä, että portti ei ole jonkin sovelluksen käytössä ja että se on käytettävissämme. Siksi RPC-sovellukset valitsevat minkä tahansa portin, jonka ne voivat vastaanottaa, ja rekisteröivät sen portmapper-daemon. Asiakas, joka haluaa ottaa yhteyttä palveluun tietyllä ohjelmanumerolla, tekee ensin pyynnön portmapperille saadakseen selville halutun palvelun porttinumeron.

Tällä menetelmällä on se haittapuoli, että se tuo esiin yhden vikapisteen, aivan kuten inetd demoni Tämä tapaus on kuitenkin hieman huonompi, koska portmapperin epäonnistuessa kaikki porttien RPC-tiedot menetetään. Tämä tarkoittaa yleensä sitä, että sinun on käynnistettävä kaikki RPC-palvelimet manuaalisesti tai käynnistettävä kone uudelleen.

Linuxissa portmapperin nimi on /sbin/portmap tai /usr/sbin/rpc.portmap . Sen lisäksi, että portmapper on käynnistettävä verkon käynnistyskomentosarjasta, se ei vaadi konfigurointityötä.

Proseduuripuhelu etänä(tai Etämenettelyjen soittaminen) (englannista. Remote Procedure Call (RPC)) - tekniikkaluokka, jonka avulla tietokoneohjelmat voivat kutsua toimintoja tai proseduureja toisessa osoiteavaruudessa (yleensä etätietokoneissa). Tyypillisesti RPC-tekniikan toteutus sisältää kaksi komponenttia: verkkoprotokollan asiakas-palvelin-viestintää varten ja objektien serialointikielen (tai rakenteet, ei-objekti-RPC:lle). Eri RPC-toteutuksissa on hyvin erilaiset arkkitehtuurit ja niiden ominaisuudet vaihtelevat: toiset toteuttavat SOA-arkkitehtuuria, toiset CORBA- tai DCOM-arkkitehtuuria. Kuljetuskerroksessa RPC:t käyttävät ensisijaisesti TCP- ja UDP-protokollia, mutta osa niistä on rakennettu HTTP:n päälle (joka rikkoo ISO/OSI-arkkitehtuuria, koska HTTP ei ole alkuperäisesti siirtoprotokolla).

Toteutukset

On monia tekniikoita, jotka tarjoavat RPC:tä:

• Sun RPC (binääriprotokolla, joka perustuu TCP:hen ja UDP:hen ja XDR:ään) RFC-1831 toinen nimi ONC RPC RFC-1833
• .Net Remoting (binääriprotokolla, joka perustuu TCP:hen, UDP:hen, HTTP:hen)
• SOAP - Simple Object Access Protocol (HTTP-pohjainen tekstiprotokolla) katso erittely: RFC-4227
• XML RPC (HTTP-pohjainen tekstiprotokolla) katso erittely: RFC-3529
• Java RMI - Java Remote Method Invocation - katso erittely: http://java.sun.com/j2se/1.5.0/docs/guide/rmi/index.html
• JSON-RPC JavaScript Object Notation Remote Procedure Calls (HTTP-pohjainen tekstiprotokolla) katso erittely: RFC-4627
• DCE/RPC – Distributed Computing Environment / Remote Procedure Calls (binääriprotokolla, joka perustuu useisiin siirtoprotokolliin, mukaan lukien TCP/IP ja nimetyt putket SMB/CIFS-protokollasta)
• DCOM – Distributed Component Object Model, joka tunnetaan nimellä MSRPC Microsoft Remote Procedure Call tai "Network OLE" (oliosuuntautunut laajennus DCE RPC:lle, jonka avulla voit välittää viittauksia objekteihin ja kutsua objektimenetelmiä tällaisten viitteiden kautta)

Periaate

Remote Procedure Callin (RPC) ideana on laajentaa tunnettua ja ymmärrettyä mekanismia ohjauksen ja tiedon siirtämiseksi yhdessä koneessa käynnissä olevan ohjelman sisällä ohjauksen ja tiedon siirtämiseksi verkon yli. Etämenettelyn kutsutyökalut on suunniteltu helpottamaan hajautetun laskennan organisointia ja hajautetun asiakaspalvelimen luomista. tietojärjestelmä. RPC:n käytön suurin tehokkuus saavutetaan niissä sovelluksissa, joissa etäkomponenttien välillä on vuorovaikutteista viestintää nopealla vasteajalla ja suhteellisen pienellä siirrettävällä määrällä. Tällaisia ​​sovelluksia kutsutaan RPC-suuntautuneiksi.

Etäpuheluiden toteuttaminen on paljon monimutkaisempaa kuin paikallisten proseduurikutsujen toteuttaminen. Voimme tunnistaa seuraavat ongelmat ja tehtävät, jotka on ratkaistava RPC:tä toteutettaessa:

• Koska kutsuvat ja kutsutut proseduurit toimivat eri koneissa, 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 erilaiset arkkitehtuurit (esim. endian). ). 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. Proseduuriparametrien ja suoritustulosten kopioimiseksi verkon yli ne sarjoidaan.
• Toisin kuin paikallinen puhelu, etäproseduurikutsu käyttää välttämättä verkkoarkkitehtuurin siirtokerrosta (esimerkiksi TCP:tä), mutta tämä jää kehittäjältä piiloon.
• Kutsuvan ohjelman ja kutsutun paikallisproseduurin suorittaminen samalla koneella toteutetaan yhdessä prosessissa. Mutta RPC:n käyttöönotto sisältää vähintään kaksi prosessia - yksi jokaisessa koneessa. Jos jokin niistä kaatuu, voi syntyä seuraavia tilanteita: jos soittotoiminto kaatuu, etäkutsutut toiminnot jäävät "orvoiksi" ja jos etätoimenpiteet kaatuvat, kutsuvista proseduureista tulee "köyhäisiä vanhempia", jotka odottavat turhaan. saadaksesi vastauksen etätoimenpiteistä.
• Ohjelmointikielten ja toimintaympäristöjen heterogeenisyyteen liittyy 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ä.

Alijärjestelmät

• Kuljetuksen osajärjestelmä

Hallitse lähteviä ja saapuvia yhteyksiä. - "viestirajan" käsitteen tuki siirtoprotokollille, joka ei suoraan tue sitä (TCP). - tuki taatulle toimitukselle siirtoprotokolleille, jotka eivät tue sitä suoraan (UDP).

• Lankaallas (vain callee). Tarjoaa suorituskontekstin verkon kautta kutsutulle koodille.

• Järjestäminen (kutsutaan myös "sarjaksi"). Puheluparametrien pakkaaminen tavuvirtaan tavallisella tavalla arkkitehtuurista (erityisesti sanan tavujärjestyksestä) riippumatta. Erityisesti se voi vaikuttaa taulukoihin, merkkijonoihin ja rakenteisiin, joihin osoitinparametrit osoittavat.

• Pakettien salaus ja digitaalisen allekirjoituksen lisääminen niihin.

• Todennus ja valtuutus. Tietojen siirto verkon kautta, joka tunnistaa puhelun soittavan kohteen.

Joissakin RPC (.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.

Katso myös

Remote Procedure Call (RPC) Remote Procedure Call -konsepti

Remote Procedure Callin (RPC) ideana on laajentaa tunnettua ja ymmärrettyä mekanismia ohjauksen ja tiedon siirtämiseksi yhdessä koneessa käynnissä olevan ohjelman sisällä ohjauksen ja tiedon siirtämiseksi verkon yli. Etäproseduurikutsutyökalut on suunniteltu helpottamaan hajautetun laskennan järjestämistä. RPC:n käytön suurin tehokkuus saavutetaan niissä sovelluksissa, joissa etäkomponenttien välillä on vuorovaikutteista viestintää nopealla vasteajalla ja suhteellisen pienellä siirrettävällä määrällä. Tällaisia ​​sovelluksia kutsutaan RPC-suuntautuneiksi.

Paikallisiin menettelyihin soittamisen ominaispiirteet ovat:

• Epäsymmetria, eli yksi vuorovaikutuksessa olevista osapuolista on aloitteentekijä;
• Synkronisuus, eli kutsuproseduurin suorittaminen keskeytetään pyynnön lähettämishetkestä ja sitä jatketaan vasta kun kutsuttu proseduuri on palannut.

Etäpuheluiden toteuttaminen on paljon monimutkaisempaa kuin paikallisten proseduurikutsujen toteuttaminen. Aluksi, koska kutsuvat ja kutsutut proseduurit 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 ei-pinomuistipaikkoihin ja että parametrien arvot on kopioitava tietokoneesta toiseen. Seuraava ero RPC:n ja paikallispuhelun välillä on, että se käyttää välttämättä taustalla olevaa viestintäjärjestelmää, mutta tämän ei pitäisi olla selkeästi näkyvissä toimenpiteiden määrittelyssä tai itse proseduureissa. Etäisyys aiheuttaa lisäongelmia. Kutsuvan ohjelman ja kutsutun paikallisproseduurin suorittaminen samalla koneella toteutetaan yhdessä prosessissa. Mutta RPC:n käyttöönotto sisältää vähintään kaksi prosessia - yksi jokaisessa koneessa. Jos jokin niistä kaatuu, voi syntyä seuraavia tilanteita: jos soittotoiminto kaatuu, etäkutsutut toiminnot jäävät "orvoiksi" ja jos etätoimenpiteet kaatuvat, kutsuvista toimenpiteistä tulee "orpovanhempia", jotka odottavat turhaan vastaus etätoimenpiteistä.

Lisäksi ohjelmointikielten ja toimintaympäristöjen heterogeenisuuteen liittyy useita ongelmia: missä tahansa ohjelmointikielessä tuettuja tietorakenteita ja proseduurikutsurakenteita ei tueta samalla tavalla kaikissa muissa kielissä.

Nämä ja jotkut muut ongelmat ratkaistaan ​​laajalle levinneellä RPC-tekniikalla, joka on monien hajautettujen käyttöjärjestelmien taustalla. Perustoiminnot RPC

Ymmärtääksemme, miten RPC toimii, harkitsemme ensin paikallisen proseduurikutsun tekemistä tavallisessa offline-tilassa toimivassa koneessa. Olkoon tämä esimerkiksi järjestelmäkutsu

count=read(fd, buf, nbytes);

missä fd on kokonaisluku, buf on merkkijono, nbytes on kokonaisluku.

Kutsua varten kutsuprosessi työntää parametrit pinoon käänteisessä järjestyksessä (kuva 3.1). Kun lukukutsu on suoritettu, se asettaa palautusarvon rekisteriin, siirtää paluuosoitteen ja palauttaa ohjauksen kutsuproseduuriin, joka ponnahtaa parametrit pinosta palauttaen sen alkuperäiseen tilaan. Huomaa, että C-kielessä parametreja voidaan kutsua joko viittauksella (nimellä) tai arvolla (arvon mukaan). Kutsutun proseduurin suhteen arvoparametrit ovat alustettuja paikallismuuttujia. Kutsuttu proseduuri voi muuttaa niitä vaikuttamatta näiden muuttujien alkuperäisiin arvoihin kutsumenettelyssä.

Jos osoitin muuttujaan välitetään kutsutulle proseduurille, tämän muuttujan arvon muuttaminen kutsutulla proseduurilla edellyttää tämän muuttujan arvon muuttamista kutsuvalle proseduurille. Tämä tosiasia on erittäin tärkeä RPC:lle.

On myös toinen parametrien välitysmekanismi, jota ei käytetä C:ssä. Sitä kutsutaan call-by-copy/restore, joka vaatii soittajan kopioimaan muuttujat pinoon arvoina ja sitten kopioimaan ne takaisin, kun kutsu on tehty kutsumenettelyn alkuperäiset arvot.

Kielenkehittäjät tekevät päätöksen siitä, mitä parametrien siirtomekanismia käytetään. Joskus se riippuu siirrettävien tietojen tyypistä. Esimerkiksi C:ssä kokonaisluvut ja muut skalaaritiedot välitetään aina arvon mukaan ja taulukot aina viitteellä.

Sovellus

Merkittävä osa soittimista kaukosäädin Windows-käyttöjärjestelmä (Event Viewer, Server Manager, tulostushallinta, käyttäjäluettelot) käyttää DCE RPC:tä viestintävälineenä verkon yli hallitun palvelun ja käyttöliittymän ohjaussovelluksen välillä. DCE RPC -tuki on ollut Windows NT:ssä ensimmäisestä versiosta 3.1 lähtien. DCE RPC -asiakkaita tuettiin myös kevyessä linjassa käyttöjärjestelmät Windows 3.x/95/98/Me.

Windows-järjestelmäkirjastot, jotka tarjoavat tällaisia ​​ohjausominaisuuksia ja toimivat peruskerroksena käyttöliittymän ohjaussovelluksille (netapi32.dll ja osittain advapi32.dll), sisältävät itse asiassa asiakaskoodin tämän ohjauksen suorittaville DCE RPC -liittymille.

Tätä arkkitehtonista päätöstä kritisoitiin aktiivisesti Microsoftia vastaan. DCE RPC:ssä olevat yleiset järjestysmenettelyt ovat erittäin monimutkaisia ​​ja niillä on valtava mahdollisuus hyödyntää vikoja verkossa lähettämällä tarkoituksella väärin muotoiltu DCE RPC -paketti. Merkittävä osa vioista Windowsin suojaus 90-luvun lopulta 2000-luvun puoliväliin löydetyt olivat juuri virheitä DCE RPC -järjestelykoodissa.

DCE RPC:n lisäksi Windows käyttää aktiivisesti DCOM-tekniikkaa. Sitä käytetään esimerkiksi viestintävälineenä IIS-verkkopalvelimen hallintatyökalujen ja itse hallittavan palvelimen välillä. Täysin toimiva käyttöliittymä MS Exchange Server -sähköpostijärjestelmän kanssa viestimiseen - MAPI - perustuu myös DCOM:iin.

Ajatus soittaa etätoimenpiteisiin (Etämenettelykutsu - RPC) koostuu hyvin tunnetun ja ymmärrettävän mekanismin laajentamisesta ohjauksen ja tiedon siirtämiseksi yhdessä koneessa käynnissä olevan ohjelman sisällä ohjauksen ja tiedon siirtämiseen verkon kautta. Etäproseduurikutsutyökalut on suunniteltu helpottamaan hajautetun laskennan järjestämistä.

RPC:n käytön suurin tehokkuus saavutetaan niissä sovelluksissa, joissa sitä on interaktiivinen viestintä etäkomponenttien välillä Kanssa lyhyt vasteaika Ja suhteellisen pieni määrä siirrettyä dataa.Tällaisia ​​sovelluksia kutsutaan RPC-suuntautuneiksi.

Paikallisiin menettelyihin soittamisen ominaispiirteet ovat:

epäsymmetria, toisin sanoen yksi vuorovaikutuksessa olevista osapuolista on aloitteentekijä;

Synkronisuus, eli kutsuproseduurin suorittaminen keskeytetään pyynnön lähettämishetkestä ja sitä jatketaan vasta kun kutsuttu proseduuri palaa.

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

1. Aloitetaan siitä, että koska kutsuvat ja kutsutut proseduurit suoritetaan eri koneissa, ne niillä on erilaiset osoiteavaruudet, ja tämä luo ongelmia parametrien ja tulosten siirrossa, varsinkin jos koneet eivät ole identtisiä.

Koska RPC ei voi luottaa jaettuun muistiin, tämä tarkoittaa sitä RPC-parametrit eivät saa sisältää osoittimia ei-pinollisiin muistipaikkoihin Mitä sitten parametriarvot on kopioitava tietokoneelta toiselle.

2. Seuraava ero RPC:n ja paikallispuhelun välillä on se käyttää välttämättä taustalla olevaa viestintäjärjestelmää kuitenkin tämä ei saa olla selvästi näkyvissä menettelyjen määrittelyssä tai itse menettelyissä .

Etäisyys aiheuttaa lisäongelmia. Kutsuvan ohjelman ja kutsutun paikallisproseduurin suorittaminen samalla koneella sisälläyksittäinen käsitellä asiaa. Mutta mukana RPC:n täytäntöönpanossavähintään kaksi prosessia - yksi jokaisessa autossa. Jos jokin niistä epäonnistuu, voi esiintyä seuraavia tilanteita:

Jos kutsumenettely kaatuu, etäkutsutut toiminnot muuttuvat "orvoiksi" ja

Jos etätoimenpiteet päättyvät epänormaalisti, soittoproseduureista tulee "puutotuneita vanhempia" ja ne odottavat vastausta etätoimenpiteistä turhaan.

Lisäksi on useita ohjelmointikielten ja käyttöympäristöjen heterogeenisuuteen liittyviä ongelmia : Missä tahansa ohjelmointikielessä tuettuja tietorakenteita ja proseduurikutsurakenteita ei tueta samalla tavalla kaikissa muissa kielissä.

Nämä ja jotkut muut ongelmat ratkaistaan ​​laajalle levinneellä RPC-tekniikalla, joka on monien hajautettujen käyttöjärjestelmien taustalla.

RPC:n ideana on saada etäproseduurikutsu näyttämään mahdollisimman samanlaiselta kuin paikallinen proseduurikutsu. Toisin sanoen tee RPC:stä läpinäkyvä: kutsuvan proseduurin ei tarvitse tietää, että kutsuttu proseduuri on toisessa koneessa ja päinvastoin.

RPC saavuttaa läpinäkyvyyden seuraavalla tavalla. Kun kutsuttu proseduuri on todella etäinen, kirjastoon sijoitetaan toimintosarjan toinen versio, jota kutsutaan asiakastyypiksi. Kuten alkuperäinen menettely, tynkä kutsutaan käyttämällä kutsusekvenssiä (kuten kuvassa 3.1), ja keskeytys tapahtuu, kun käytetään ydintä. Vain toisin kuin alkuperäinen menettely, se ei sijoita parametreja rekistereihin eikä pyydä tietoja ytimestä, vaan se luo viestin lähetettäväksi etäkoneen ytimeen.

Riisi. 3.2. Etämenettelyn kutsu

Tämän artikkelin tarkoituksena on keskustella terminologiasta. Artikkeli ei kerro miten ja miksi, vaan ainoastaan ​​terminologian käytöstä. Artikkeli heijastaa kirjoittajan mielipidettä eikä väitä olevansa tieteellinen.

Johdanto

Jos työskentelet ohjelmoinnin parissa hajautetut järjestelmät tai sisään järjestelmien integrointi, suurin osa tässä esitetystä ei ole sinulle uutta.

Ongelma syntyy, kun eri tekniikoita käyttävät ihmiset tapaavat ja kun nämä ihmiset alkavat käydä teknisiä keskusteluja. Tällöin terminologian takia syntyy usein molemminpuolisia väärinkäsityksiä. Tässä yritän koota yhteen eri yhteyksissä käytetyt terminologiat.

Terminologia

Tällä alalla ei ole selkeää terminologiaa ja luokitusta. Alla käytetty terminologia heijastaa kirjoittajan mallia, eli se on ehdottoman subjektiivinen. Kaikenlainen kritiikki ja keskustelu ovat tervetulleita.

Olen jakanut terminologian kolmeen osa-alueeseen: RPC (Remote Procedure Call), Messaging ja REST. Näillä alueilla on historialliset juuret.

RPC

RPC teknologiat - vanhimmat tekniikat. RPC:n näkyvimmät edustajat ovat - CORBA Ja DCOM.

Tuohon aikaan järjestelmien liittäminen oli pääasiassa välttämätöntä nopeilla ja suhteellisen luotettavilla paikalliset verkot. RPC:n pääideana oli tehdä etäjärjestelmiin soittamisesta samanlaista kuin ohjelman sisällä. Koko etäpuhelujen mekaniikka piilotettiin ohjelmoijalta. Ainakin he yrittivät piilottaa sen. Ohjelmoijat joutuivat monissa tapauksissa työskentelemään syvemmällä tasolla, missä termit marshaling esiintyivät ( järjestys) Ja järjetöntä(miten se on venäjäksi?), mikä tarkoitti pohjimmiltaan serialisointia. Normaalit toimintokutsut prosessien sisällä käsiteltiin soittajan lopussa Välityspalvelin, ja toiminnon suorittavan järjestelmän puolella, sisään Lähettäjä. Ihannetapauksessa kutsujärjestelmä tai käsittelyjärjestelmä eivät selviäisi järjestelmien välisen tiedonsiirron monimutkaisuudesta. Kaikki nämä hienovaraisuudet keskitettiin Proxy - Dispatcher -pakettiin, jonka koodi luotiin automaattisesti.

Joten et huomaa, sinun ei pitäisi huomata, mitään eroa paikallisen toiminnon ja etätoiminnon kutsumisen välillä.
Nyt on eräänlainen RPC-renessanssi, jonka näkyvimmät edustajat ovat: Google ProtoBuf, Thrift, Avro.

Viestit

Ajan myötä kävi ilmi, että yritys suojella ohjelmoijaa siltä, ​​että kutsuttu toiminto eroaa edelleen paikallisesta, ei johtanut haluttu lopputulos. Toteutuksen yksityiskohdat ja perustavanlaatuiset erot hajautettujen järjestelmien välillä olivat liian suuria ratkaistaviksi automaattisesti luodun välityspalvelimen avulla. Pikkuhiljaa ymmärrys siitä, että se tosiasia, että järjestelmiä yhdistää epäluotettava, hidas, hidas ympäristö, täytyy näkyä selkeästi ohjelmakoodissa.

Tekniikat ovat ilmestyneet Web palvelut. Aloimme puhua ABC: Osoite, sitominen, sopimus. Ei ole täysin selvää, miksi sopimukset ilmestyivät, jotka ovat pääasiassa kirjekuoria syöttöargumenteille. Sopimukset usein monimutkaistavat kokonaismallia eivätkä yksinkertaista sitä. Mutta... sillä ei ole väliä.

Nyt ohjelmoija loi nimenomaisesti palvelua(Palvelu) tai asiakas(Asiakas) soittamalla palveluun. Palvelu koostui setistä toiminnot (Operaatio), joista jokainen käytti sisääntuloa pyyntö(Pyyntö) ja myönnetty vastaus(Vastaus). Asiakas nimenomaisesti lähetetty(Lähetetty) pyyntö, palvelu on nimenomaisesti vastaanottanut ( Vastaanottaa) ja vastasi hänelle (Lähetetty) ja lähetti vastauksen. Asiakas sai vastauksen ja puhelu loppui.

Aivan kuten RPC:ssä, jossain oli käynnissä välityspalvelin ja Dispatcher. Ja kuten ennenkin, heidän koodinsa luotiin automaattisesti, eikä ohjelmoijan tarvinnut ymmärtää sitä. Ellei asiakas ole nimenomaisesti käyttänyt välityspalvelimen luokkia.

Pyynnöt ja vastaukset muunnetaan nimenomaisesti muotoon, joka on tarkoitettu lähetettäväksi langan välityksellä. Useimmiten tämä on tavutaulukko. Transformaatiota kutsutaan Sarjoittaminen Ja Deserialisointi ja joskus piiloutuu välityspalvelimen koodiin.
Viestinnän huipentuma ilmeni paradigman syntymisessä ESB (Enterprise Service Bus). Kukaan ei voi oikein ilmaista, mitä se on, mutta kaikki ovat yhtä mieltä siitä, että tiedot liikkuvat ESB:n läpi viestien muodossa.

LEVÄTÄ

Jatkuvassa taistelussa koodin monimutkaisuuden kanssa ohjelmoijat ottivat seuraavan askeleen ja loivat LEVÄTÄ.

RESTin pääperiaate on, että toimintooperaatiot ovat jyrkästi rajoitettuja ja jättävät vain joukon operaatioita CRUD: Luo - Lue - Päivitä - Poista. Tässä mallissa kaikkia operaatioita sovelletaan aina joihinkin tietoihin. CRUD:ssa käytettävissä olevat toiminnot riittävät useimpiin sovelluksiin. Koska REST-tekniikat edellyttävät useimmissa tapauksissa HTTP-protokollan käyttöä, CRUD-komennot heijastuivat komentoihin HTTP (Lähettää - Saada - Laittaa - Poistaa) . Jatkuvasti sanotaan, että REST ei välttämättä ole sidottu HTTP:hen. Mutta käytännössä operaatioiden allekirjoitusten heijastamista HTTP-komentojen syntaksiin käytetään laajalti. Esimerkiksi funktion kutsuminen

EntityAddress ReadentityAddress(merkkijono param1, merkkijono param2)

Ilmaistuna näin:

GET: entityAddress?param1=arvo1¶m2=arvo2

Johtopäätös

Ennen kuin aloitat keskustelun hajautetuista järjestelmistä tai integraatiosta, määrittele terminologia. Jos Proxy tarkoittaa aina samaa asiaa eri yhteyksissä, niin esimerkiksi pyyntö merkitsee vähän RPC-termeissä ja järjestys aiheuttaa sekaannusta REST-tekniikoista puhuttaessa.

Palvelu ei käynnistynyt tietokoneen uudelleenkäynnistyksen jälkeen" Remote Procedure Call (RPC)". Paljon riippuu tästä palvelusta. Tämän seurauksena järjestelmän palautus, verkkoympäristö, ääni, Windows Installer eivät toimi, hallintakonsoli (MMC) ei melkein toimi, avoimia ikkunoita ei näytetä tehtäväpalkissa jne., jne. Yritys käynnistää manuaalisesti johtaa virheeseen " Ei voi käynnistää...(RPC) laitteella xxxComp. Virhe 5: Pääsy estetty"Virustorjunta ei löytänyt mitään. Kaksi päivää kaivettua ja tietokone heräsi henkiin.

Microsoftin suosituksen mukaan yritin ensimmäisenä löytää ja poistaa rekisteriavaimen . Minulla ei ollut sitä, ehkä joidenkin asennettujen päivitysten seurauksena.

Seuraavaksi yritetään palauttaa palveluparametrit rekisterissä. Koska regedit.exe oli vain luku/poisto (toinen sivuvaikutus), muutoksia ei voitu tehdä. Kyllä, niitä ei tarvittu, koska... kaikki oli oikein. Sen pitäisi näyttää tältä:

Windowsin rekisterieditorin versio 5.00 "Description"="Tarjoaa päätepisteiden ja muiden RPC-palvelujen yhdistämisen." "DisplayName"="Remote Procedure Call (RPC)" "ErrorControl"=dword:00000001 "Group"="COM-infrastruktuuri" "ImagePath"=hex(2):25,00,53,00,79,00,73, 00,74,00,65,00,6d,00,52,00,6f,00,6f,00,\ 74,00,25,00,5c,00,73,00,79,00,73,00 ,74,00,65,00,6d,00,33,00,32,00,5c,00,73,\ 00,76,00,63,00,68,00,6f,00,73,00, 74,00,20,00,2d,00,6b,00,20,00,72,00,70,00,\ 63,00,73,00,73,00,00,00 "ObjectName"="NT AUTHORITY\\NetworkService" "Start"=dword:00000002 "Type"=dword:00000010 "FailureActions"=hex:00,00,00,00,00,00,00,00,00,00,00,00,01 ,00,00,00,00,00,00,\ 00,02,00,00,00,60,ea,00,00 "ServiceSidType"=dword:00000001 "ServiceDll"=hex(2):25.00 ,53 ,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,\ 00,74,00,25,00,5c,00, 73, 00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,\ 72,00,70,00,63,00,73 ,00 ,73,00,2e,00,64,00,6c,00,6c,00,00,00 "Turvallisuus"=hex:01,00,14,80,a8,00,00,00,b4, 00, 00,00,14,00,00,00,30,00,00,00,02,\ 00,1c,00,01,00,00,00,02,80,14,00,ff,01 ,0f ,00,01,01,00,00,00,00,00,01,00,00,\ 00,00,02,00,78,00,05,00,00,00,00,00, 14, 00,8d,00,02,00,01,01,00,00,00,00,00,\ 05,0b,00,00,00,00,00,18,00,ff,01,0f ,00 ,01,02,00,00,00,00,00,05,20,00,00,00,\ 20,02,00,00,00,00,18,00,8d,00,02, 00, 01,02,00,00,00,00,00,05,20,00,00,00,23,\ 02,00,00,00,00,14,00,9d,00,00,00 ,01 ,01,00,00,00,00,00,05,04,00,00,00,00,00,\ 18,00,9d,00,00,00,01,02,00,00, 00, 00,00,05,20,00,00,00,21,02,00,00,01,01,00,\ 00,00,00,00,05,12,00,00,00,01 ,01 ,00,00,00,00,00,05,12,00,00,00 "0"="Juuri\\LEGACY_RPCSS\\0000" "Count"=dword:00000001 "NextInstance"=dword:00000001

Parametrin arvo alkaa voi vaihdella. Voit silti muuttaa rekisteriä, mutta sinun on käynnistettävä MS ERD:n komentaja.

Kuvaan yksinkertaisesti seuraavat vaiheet kohta kohdalta. Yleinen ajatus on, että sinun on korvattava tiedostot sellaisilla, joiden tiedetään toimivan. Ne voidaan ottaa toisesta koneesta tai Windows-jakelusta (kuten tein).

• Käynnistä konsoli (Käynnistä > Suorita: cmd)
• cd z:\i386(Windows-jakelu siellä)
• laajenna explorer.ex_ %TEMP%\explorer.exe
• laajenna svchost.ex_ %TEMP%\svchost.exe
• Käynnistä Task Manager (Ctrl+Shift+Esc)
• Pysäytä exlporer.exe-prosessi
• kopioi %TEMP%\explorer.exe %SYSTEMROOT% /y
• Pysäytä kaikki svchost.exe-prosessit. Huomio! Tämän jälkeen sinulla on 60 sekuntia aikaa ennen kuin kone käynnistyy uudelleen.
• kopioi %TEMP%\svchost.exe %systemroot%\system32 /y

Tämäkin teko ei tuottanut tulosta. Toinen vaihtoehto: suorita kaikkien suojattujen kohteiden tarkistus järjestelmätiedostot vaihdon kanssa vääriä versioita oikea. Konsoliajon aikana:

Se ei auttanut.. Sitten täysin brutaali toimenpide on palauttaa suojausasetukset. Jälleen konsolissa:

Uudelleenkäynnistyksen jälkeen tietokone alkoi toimia peruspalvelut alkoi. Uusi ongelma ilmaantui (tai ehkä se oli siellä alusta asti): ainakaan Disk Management Manager ja Windows Installer eivät käynnistyneet tililläni. Pääsy evätty. Voit palauttaa käyttöoikeudet järjestelmälevyyn "oletusasetuksiin" konsolin kautta:

Sitten sinun on määritettävä kunkin tilin oikeudet manuaalisesti. tai luoda ne uudelleen sen mukaan, kumpi on helpompaa.

Minun tapauksessani yksinkertaisesti määritin samat oikeudet koko järjestelmälevylle käyttämällä pääsyä . Lisäsin verkkotunnukseni standardiin täydellä oikeuksilla levyyn. Ehkä tämä on väärin tietoturvan kannalta, mutta minulla ei ole aikaa syventyä jokaiseen hakemistoon erikseen.

Mitä muuta voisi tehdä

Kun tietokone oli sairas, tämä ei ollut rekisterissä:

"ActiveService"="RpcSs"

Ehkä manuaalinen lisäys jotenkin muuttaisi tilannetta.

Yrittää käynnistää palvelun manuaalisesti esimerkiksi komennolla " net start rcpss"päättyi virheeseen" Virhe 5: pääsy estetty". Oletan, että pääsy on estetty, koska palvelu on käynnistettävä järjestelmätilillä - "NT AUTHORITY". Rekisterissä on seuraava parametri:

"ObjectName"="NT AUTHORITY\\NetworkService"

Yrittäisin syöttää järjestelmänvalvojan tilin tähän ja käynnistää palvelun uudelleen. Mutta tämä on vain idea, joka ei kestänyt toteutusta.

Toinen vaihtoehto: hanki konsoli järjestelmäoikeuksilla käyttämällä KiTrap0D-hyötyä. Tästä hyväksikäytöstä kirjoitettiin vuonna . Itse asiassa binääri. Mutta minulla on Windows-päivityksiä, joten näyttää siltä, ​​​​että tämä hyväksikäyttö ei enää toimi.

Aiheeseen liittyvät materiaalit: