Čo je vzdialené volanie procedúry rpc. Diaľkové volanie procedúry

Účelom tohto článku je diskutovať o terminológii. Článok nie je o tom ako a prečo, ale len o používaní terminológie. Článok odráža názor autora a nepredstiera, že je vedecký.

Úvod

Ak pracujete v programovaní distribuované systémy alebo v systémová integrácia, potom väčšina z toho, čo je tu prezentované, nie je pre vás novinkou.

Problém nastáva, keď existujú ľudia, ktorí používajú rôzne technológie a keď títo ľudia začnú technické rozhovory. V tomto prípade často vznikajú vzájomné nedorozumenia kvôli terminológii. Tu sa pokúsim spojiť terminológie používané v rôznych kontextoch.

Terminológia

V tejto oblasti neexistuje jasná terminológia a klasifikácia. Nižšie použitá terminológia je odrazom autorovho modelu, to znamená, že je prísne subjektívna. Akákoľvek kritika a diskusia sú vítané.

Terminológiu som rozdelil do troch oblastí: RPC (Remote Procedure Call), Správy a REST. Tieto oblasti majú historické korene.

RPC

RPC technológie - najstaršie technológie. Najvýznamnejšími predstaviteľmi RPC sú - CORBA A DCOM.

V tých časoch bolo potrebné hlavne prepojiť systémy rýchlo a relatívne spoľahlivo lokálnych sietí. Hlavnou myšlienkou RPC bolo urobiť volanie vzdialených systémov podobne ako volanie funkcií v rámci programu. Celá mechanika vzdialených hovorov bola pred programátorom skrytá. Aspoň sa to snažili skryť. Programátori boli v mnohých prípadoch nútení pracovať na hlbšej úrovni, kde sa objavili pojmy marshaling ( zoraďovanie) A demaršovanie(ako je to v ruštine?), čo v podstate znamenalo serializáciu. Normálne volania funkcií v rámci procesov boli spracované na konci volajúceho Proxy, a na strane systému vykonávajúceho funkciu, v Dispečer. V ideálnom prípade by sa ani volací systém, ani systém spracovania nezaoberali zložitosťou prenosu údajov medzi systémami. Všetky tieto jemnosti boli sústredené v balíku Proxy - Dispečer, ktorého kód bol generovaný automaticky.

Takže si nevšimnete, nemali by ste si všimnúť, žiadny rozdiel medzi volaním lokálnej funkcie a volaním vzdialenej funkcie.
Teraz nastáva akási renesancia RPC, ktorej najvýznamnejšími predstaviteľmi sú: Google ProtoBuf, Thrift, Avro.

Správy

Postupom času sa ukázalo, že pokus ochrániť programátora pred tým, že volaná funkcia sa predsa len líši od lokálnej, neviedla k želanému výsledku. Podrobnosti implementácie a zásadné rozdiely medzi distribuovanými systémami boli príliš veľké na to, aby sa dali vyriešiť pomocou automaticky generovaného Proxy kódu. Postupne prišlo pochopenie, že skutočnosť, že systémy sú prepojené nespoľahlivým, pomalým a nízkorýchlostným prostredím, sa musí explicitne prejaviť v programovom kóde.

Objavili sa technológie webové služby. Začali sme sa rozprávať ABC: Adresa, Väzba, Zmluva. Nie je celkom jasné, prečo sa objavili zmluvy, ktoré sú v podstate obálkami pre vstupné argumenty. Zmluvy často celkový model skôr skomplikujú, než zjednodušia. Ale... to je jedno.

Teraz programátor výslovne vytvoril služby(servis) alebo zákazník(Zákazník) zavolajte do servisu. Služba pozostávala zo súpravy operácií (Prevádzka), z ktorých každý prijal na vstupe žiadosť(Žiadosť) a vydané odpoveď(odpoveď). Klient výslovne odoslaná(Odoslané) žiadosť, služba výslovne dostala ( Prijať) a odpovedal mu (Odoslané), pričom odpoveď poslal. Klient dostal odpoveď a hovor sa skončil.

Rovnako ako v RPC, aj tu niekde bežal Proxy a Dispečer. A ako predtým, ich kód bol generovaný automaticky a programátor mu nemusel rozumieť. Pokiaľ klient výslovne nepoužíval triedy z Proxy.

Požiadavky a odpovede sú výslovne prevedené do formátu určeného na prenos po drôte. Najčastejšie ide o bajtové pole. Transformácia sa nazýva Serializácia A Deserializácia a niekedy sa skrýva v kóde proxy.
Vyvrcholenie zasielania správ sa prejavilo vznikom paradigmy ESB (Enterprise Service Bus). Nikto nemôže skutočne formulovať, čo to je, ale každý súhlasí s tým, že údaje sa pohybujú cez ESB vo forme správ.

ODPOČINOK

V neustálom boji so zložitosťou kódu urobili programátori ďalší krok a vytvorili ODPOČINOK.

Hlavným princípom REST je, že funkčné operácie sú výrazne obmedzené a ponechajú len súbor operácií CRUD: Vytvoriť - Čítať - Aktualizovať - ​​Vymazať. V tomto modeli sú všetky operácie vždy aplikované na nejaké dáta. Operácie dostupné v CRUD sú dostatočné pre väčšinu aplikácií. Keďže technológie REST vo väčšine prípadov zahŕňajú použitie protokolu HTTP, príkazy CRUD sa odrazili v príkazoch HTTP (Príspevok - Získajte - Dajte - Odstrániť) . Neustále sa uvádza, že REST nie je nevyhnutne viazaný na HTTP. V praxi sa však široko používa odraz podpisov operácií na syntax príkazov HTTP. Napríklad volanie funkcie

EntityAddress ReadEntityAddress(reťazec param1, string param2)

Vyjadrené takto:

GET: adresa entity?param1=hodnota1¶m2=hodnota2

Záver

Pred začatím diskusie o distribuovaných systémoch alebo integrácii definujte terminológiu. Ak Proxy bude vždy znamenať to isté v rôznych kontextoch, potom napríklad požiadavka bude znamenať málo z hľadiska RPC a zaraďovanie spôsobí zmätok pri diskusii o technológiách REST.

Po reštarte počítača sa služba nespustila" Vzdialené volanie procedúry (RPC)". Veľa závisí od tejto služby. V dôsledku toho nefunguje obnovenie systému, sieťové prostredie, zvuk, Inštalátor systému Windows, konzola na správu (MMC) takmer nefunguje, nezobrazujú sa na paneli úloh otvorené okná atď. a tak ďalej. Pokus o manuálne spustenie vedie k chybe " Nedá sa spustiť...(RPC) na xxxComp. Chyba 5: Prístup odmietnutý„Antivírus nič nenašiel. Dva dni kopania a počítač sa vrátil k životu.

Podľa odporúčania Microsoftu som sa ako prvé pokúsil nájsť a odstrániť kľúč databázy Registry . Nemal som to, možno v dôsledku niektorých nainštalovaných aktualizácií.

Ďalej pokus o obnovenie parametrov služby v registri. Keďže regedit.exe bol len na čítanie/vymazanie (ďalší vedľajší efekt), nebolo možné vykonať zmeny. Áno, neboli potrebné, pretože... všetko bolo správne. Malo by to vyzerať takto:

Editor databázy Registry systému Windows, verzia 5.00 "Description"="Poskytuje mapovanie koncových bodov a iných služieb RPC." "DisplayName"="Vzdialené volanie procedúry (RPC)" "ErrorControl"=dword:00000001 "Group"="Infraštruktúra COM" "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" "Štart"=dword:00000002 "Typ"=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 "Zabezpečenie"=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"="Root\\LEGACY_RPCSS\\0000" "Count"=dword:00000001 "NextInstance"=dword:00000001

Hodnota parametra začať môže sa líšiť. Stále môžete zmeniť register, ale musíte zaviesť systém veliteľ MS ERD.

Ďalšie kroky jednoducho opíšem bod po bode. Všeobecnou myšlienkou je, že musíte nahradiť súbory súbormi, o ktorých je známe, že fungujú. Môžu byť prevzaté z iného stroja alebo z Distribúcia Windows(ako ja).

  • Spustite konzolu (Štart > Spustiť: cmd)
  • cd z:\i386(tam je distribúcia Windows)
  • rozbaliť explorer.ex_ %TEMP%\explorer.exe
  • rozbaliť svchost.ex_ %TEMP%\svchost.exe
  • Spustite Správcu úloh (Ctrl+Shift+Esc)
  • Zastavte proces exlporer.exe
  • skopírujte %TEMP%\explorer.exe %SYSTEMROOT% /y
  • Zastavte všetko procesy svchost.exe. Pozor! Potom budete mať 60 sekúnd, kým sa počítač reštartuje.
  • skopírujte %TEMP%\svchost.exe %systemroot%\system32 /y

Táto finta tiež nepriniesla výsledky. Ďalšia možnosť: spustiť kontrolu všetkých chránených systémové súbory s nahradením nesprávnych verzií správnymi. V konzole spustite:

sfc /PURGECACHE- Vymažte vyrovnávaciu pamäť súborov a okamžite skontrolujte súbory
sfc /SCANONCE- Jednorazová kontrola pri ďalšom spustení

Nepomohlo to.. Potom je úplne brutálnym krokom obnovenie nastavení zabezpečenia. Opäť v konzole:

secedit /configure /cfg %windir%\repair\secsetup.inf /db secsetup.sdb /verbose

Po reštarte začal počítač fungovať a spustili sa základné služby. Objavil sa nový problém (alebo možno bol od samého začiatku): pod mojím účtom sa nespustil aspoň Správca diskov a Inštalátor systému Windows. Prístup zamietnutý. Prístupové práva na systémový disk môžete obnoviť na „predvolené“ prostredníctvom konzoly:

secedit /configure /db %TEMP%\temp.mdb /Cfg %WINDIR%\inf\defltwk.inf /areas filestore

Potom musíte manuálne definovať práva pre každý účet. alebo ich vytvorte znova, podľa toho, čo je jednoduchšie.

V mojom prípade som jednoducho pridelil rovnaké práva celému systémovému disku pomocou prístupu k súboru . Doménový účet som pridal do štandardu s plnými právami na disk. Možno je to nesprávne z hľadiska bezpečnosti, ale nemám čas ponoriť sa do každého adresára samostatne.

Čo iné sa dalo robiť

Kým bol počítač chorý, toto nebolo v registri:

"ActiveService"="RpcSs"

Možno by ručné pridávanie nejako zmenilo situáciu.

Pokusy o manuálne spustenie služby, napríklad pomocou príkazu " čistý štart rcpss"skončil chybne" Chyba 5: prístup odmietnutý". Predpokladám, že prístup je odmietnutý, pretože služba musí byť spustená pod systémovým účtom - "NT AUTHORITY". V registri je nasledujúci parameter:

"ObjectName"="NT AUTHORITY\\NetworkService"

Skúsil by som sem zadať účet správcu a znova spustiť službu. Ale to je len nápad, ktorý sa nedočkal realizácie.

Ďalšia možnosť: na získanie konzoly so systémovými právami použite exploit KiTrap0D. O tomto exploite sa písalo v . Vlastne binárne. Mám však aktualizácie systému Windows, takže sa zdá, že tento exploit už nefunguje.

Súvisiace materiály:

Zahrnuté v operačnom systéme Windows ľubovoľný modifikácie, počnúc verziou XP, obsahujú servisný komponent označený ako RPC. Väčšina bežných používateľov nevie, čo to je, a ešte menej tušia, na čo táto služba slúži a ako funguje. V tejto súvislosti sa navrhuje zvážiť niektoré základné aspekty súvisiace so samotným komponentom, jeho prevádzkovými princípmi a rozsahom použitia bez opisu zbytočných a zložitých technických výrazov. Zostaňme oddelene možné chyby služby a metódy na ich rýchle odstránenie.

Diaľkové procedúry (vzdialené volania procedúr): čo to je?

Zdá sa, že mnohí používatelia už na základe názvu tohto komponentu služby dospeli k záveru, čo to je. Vzdialené procedúry (vzdialené volania procedúr) skutočne zahŕňajú niektoré akcie, keď sa nevykonávajú lokálny počítač, ale vzdialene (najčastejšie na serveri).

To znamená, že požiadavka sa vygeneruje na jednom termináli, potom sa prenesie na druhý, kde sa vykoná, po čom sa odpoveď (správa) o vykonaní vráti prvému počítaču. Ale to je len primitívne vysvetlenie. V skutočnosti je všetko oveľa komplikovanejšie, pretože je potrebné vziať do úvahy protokoly prenosu údajov (UDP, TCP, HTTP) a mnoho ďalších mechanizmov.

Na čo slúži táto služba?

Napriek svojmu hlavnému účelu sa vzdialené volanie procedúr RPC nesmie používať rôzne počítače, ale na jednom. Ako najviac jednoduchý príklad Niektoré funkcie jedného programu môžete volať z inej aplikácie. Mnoho hudobníkov, ktorí pracujú s virtuálnymi štúdiami a sekvencermi, vie, že každá takáto aplikácia má vlastný modul na úpravu alebo spracovanie zvuku, ktorý nie vždy spĺňa požiadavky používateľa. A každé štúdio vám namiesto toho umožňuje pripojiť akýkoľvek iný externý program.

Napríklad v nastaveniach sekvencera FL Studio môžete zadať inú aplikáciu (napríklad Adobe Audition), ktorú chcete upraviť zvukové súbory(vzorky) v hlavnom prostredí programu budú použité štandardne. V tomto prípade sa pripojenie Adobe Audition k FL Studio nevykoná prostredníctvom virtuálnych hostiteľov ako VST, RTAS alebo DX, ale priamo pomocou služby vzdialeného volania procedúr. Je samozrejmé, že tento príklad nie je jediný, pretože rozsah použitia opísaného komponentu je oveľa širší.

Často túto službu je tiež spojená s rozložením výpočtovej záťaže na termináloch, medzi ktorými je nadviazaná interaktívna komunikácia. Zároveň, ak je záťaž rovnomerne rozložená na výpočtové zdroje viacerých počítačov, maximálny výkon je možné dosiahnuť len pri výmene malého množstva dát a rýchlej odozve medzi komponentmi.

Zlyhanie vzdialeného volania procedúry: aký je dôvod?

Bohužiaľ, kvôli takémuto dopytu je výskyt porúch a chýb spojených s touto službou pomerne častým javom.

V dôsledku toho sa stáva nemožné nielen použitie samotného komponentu. Niekedy sa k niektorým ani nedostanete systémové nastavenia a Windows XP úplne zlyhá, po ktorom môže byť dosť problematické obnoviť ho do normálneho pracovného stavu. Ďalším problémom je online nástroj na obnovu DISM, ktorý je súčasťou operačného systému.

S porušením jej fungovania je spojený výskyt chyby 1726, ktorá priamo ovplyvňuje fungovanie komponentov služby RPC.

Hlavnými príčinami takýchto zlyhaní sú volanie nástrojov na skenovanie alebo obnovu systému, keď je proces DISM aktívny alebo sa nedá správne vypnúť (napríklad keď sú nástroje DISM a SFC spustené súčasne z dvoch príkazových konzol); keď služba beží súbežne so servisom komponentov RPC; keď je služba zablokovaná antivírusovým softvérom.

Ak teda zaznamenáte zlyhanie RPC v systéme Windows 7 a novšom, prvá vec, ktorú musíte urobiť, je ukončiť DISM, reštartovať počítač a znova spustiť službu. Ak to nepomôže, môžete sa pokúsiť prepnúť do núdzového režimu a počas procesu obnovy ho úplne zakázať. antivírusová ochrana. Samostatne sa budeme zaoberať dodatočnými opatreniami, ktoré pomáhajú opraviť akékoľvek zlyhanie počas vzdialeného volania procedúry a pri akejkoľvek úprave systému Windows. Zatiaľ sa pozrime na problémy súvisiace s deaktiváciou tohto systémového komponentu (žiaľ, mnohí používatelia, ktorí nepoznajú podstatu problému, sa snažia robiť práve takéto veci).

Je možné zakázať službu RPC?

Pozrime sa teda, aké reálne je deaktivovať vzdialené volania procedúr. Vzdialené procedúry, založené na odporúčaniach vývojárov, by nemali byť za žiadnych okolností zakázané. To je dôležité! V zásade vám to nedovolí urobiť sami. Samozrejme, existuje niekoľko riešení, ktoré zahŕňajú použitie ďalších softvér, ale z pochopiteľných dôvodov sa názvy takýchto aplikácií neuvádzajú, pretože pri ich nesprávnom použití sa celý systém môže stať nepoužiteľným.

Dôsledky zakázania procesov RPC

Aj keď sa používateľovi podarí nejakým spôsobom zakázať vzdialené procedúry (vzdialené volania procedúr), následky, žiaľ, môžu byť veľmi nepredvídateľné. Ako už bolo spomenuté, systém Windows XP môže úplne prestať fungovať a v operačnom systéme vyššej úrovne sa v dôsledku toho môže objaviť veľké množstvo systémových zlyhaní, ktoré sa nedajú odstrániť, už len z dôvodu nedostatočného prístupu k kritickým nastaveniam a Nastavenia systému Windows, a dokonca aj v bezpečnostný mód alebo pri spustení z vymeniteľného média. Vzdialené volania procedúr však zlyhajú v systéme Windows 10 alebo novšom staršie verzie operačný systém je možné opraviť. Metóda nie je najjednoduchšia, takže pri jej používaní musíte byť veľmi opatrní.

Vypnutie lokátora vzdialeného prístupu

Hlavnú službu RPC teda nemožno zakázať. Ale možno má zmysel deaktivovať niektoré z jeho sprievodných komponentov? Áno, skutočne, ak prejdete do sekcie systémových služieb a ich komponentov (services.msc), nájdete tam takzvaný RPC lokátor.

Dá sa však deaktivovať bez obáv z katastrofálnych následkov. Po vstupe do úpravy jeho parametrov je potrebné zastaviť činnosť komponentu a nastaviť typ spúšťania na vypnutý. Programy, ktoré môžu používať vzdialené procedúry, budú aj tak volať vzdialené procedúry (bez ich pomoci).

Ak z nejakého dôvodu nastaviť parametre nebude fungovať, môžete použiť inštalačný nástroj Disk Windows, pri načítaní z neho zavolajte na príkazový riadok a zadajte nasledovné:

  • cd X:\i386 (X je písmeno pre vymeniteľnú jednotku);
  • expand explorer.ex_ %TEMP%\explorer.exe;
  • rozbaliť svchost.ex_ %TEMP%\svchost.exe.

Po reštarte sa vyvolá „Správca úloh“ a je dokončený, potom sa na príkazový riadok zapíše kombinovaná kópia %TEMP%\explorer.exe %SYSTEMROOT% /y, po ktorej sa ukončia úplne všetky procesy svchost v „Správca úloh“. Teraz by ste mali byť obzvlášť opatrní, pretože po dokončení procesov musíte mať čas do šesťdesiatich sekúnd zadať príkaz copy %TEMP%\svchost.exe %systemroot%\system32 /y do príkazovej konzoly.

Ak má používateľ napríklad v normálnom alebo bezpečnom režime prístup k systémový register, v editore (regedit) vo vetve HKCC je potrebné nájsť parameter CSConfigFlags a priradiť mu hodnotu nula.

Riešenie problémov pri zlyhaní 1726

Nakoniec, riešenie chyby 1726 sa vykonáva aj prostredníctvom registra. V tomto prípade však musíte vo vetve HKLM nájsť adresár RpcSs a vpravo upraviť hodnotu parametra Štart.

Je potrebné ho zmeniť zo štyroch, ktoré sú zvyčajne predvolene nastavené, na dva a potom reštartovať systém.

Doslov

To je v skutočnosti všetko, čo sa týka volania vzdialených procedúr. Diaľkové postupy a princípy fungovania tohto komponentu v rozšírenej verzii je možné opísať veľmi dlho, ale dôraz v prezentovanom materiáli bol kladený na všeobecné oboznámenie sa so službou a niektorými metódami na odstraňovanie chýb a porúch, ktoré dokáže spôsobiť v počítačový systém. Bežní používatelia budú musieť byť trpezliví a byť veľmi opatrní, pretože jedna nesprávna akcia v registri môže viesť k úplnému zlyhaniu operačného systému.

Upozorňujeme, že poruchy tohto typu nemožno dosiahnuť žiadnymi inými prostriedkami, ako sú optimalizačné programy a nastavovače parametrov. operačné systémy Okná nie sú opravené. So všetkou túžbou príkazový riadok, ani navyše zásahy do registra na úrovni úpravy kľúčov v napr softvérové ​​balíky neboli poskytnuté.

V inom adresnom priestore (zvyčajne na vzdialených počítačoch). Implementácia technológie RPC zvyčajne obsahuje dva komponenty: sieťový protokol na výmenu v režime klient-server a jazyk na serializáciu objektov (alebo štruktúr pre neobjektové RPC). Rôzne implementácie RPC majú veľmi odlišné architektúry a líšia sa svojimi schopnosťami: niektoré implementujú architektúru SOA, iné CORBA alebo DCOM. Na transportnej vrstve RPC primárne používajú protokoly TCP a UDP, avšak niektoré sú postavené na HTTP (čo porušuje architektúru ISO/OSI, pretože HTTP nie je podľa návrhu transportný protokol).

Encyklopedický YouTube

    1 / 2

    Vzdialené volanie procedúry zlyhalo. Riešenie

    REST API v Yii2 časť 1. Teória. XML-RPC, JSON-RPC, SOAP.

titulky

Implementácie

Existuje mnoho technológií, ktoré poskytujú RPC:

  • DCE/RPC – Distributed Computing Environment / Remote Procedure Calls (binárny protokol založený na rôznych transportných protokoloch vrátane TCP/IP a Named Pipes z protokolu SMB/CIFS)
  • DCOM – Distributed Component Object Model známy ako MSRPC Microsoft Remote Procedure Call alebo „Network OLE“ (objektovo orientované rozšírenie DCE RPC, ktoré vám umožňuje odovzdávať odkazy na objekty a volať objektové metódy prostredníctvom takýchto odkazov)
  • JSON-RPC - Objekt JavaScript Notation Remote Procedure Calls (textový protokol založený na HTTP) pozri špecifikáciu: RFC-4627
  • .NET Remoting (binárny protokol založený na TCP, UDP, HTTP)
  • Java RMI – Java Remote Method Invocation – pozri špecifikáciu: http://java.sun.com/j2se/1.5.0/docs/guide/rmi/index.html
  • SOAP - Simple Object Access Protocol (textový protokol založený na HTTP) pozri špecifikáciu: RFC-4227
  • Sun RPC (binárny protokol založený na TCP a UDP a XDR) Druhé meno RFC-1831 ONC RPC RFC-1833
  • XML RPC (textový protokol založený na HTTP) pozri špecifikáciu: RFC-3529

Princíp

Nápad na výzvu vzdialené procedúry pozostáva z rozšírenia dobre známeho a pochopeného mechanizmu na prenos riadenia a dát v rámci programu bežiaceho na jednom stroji na prenos riadenia a dát cez sieť. Nástroje vzdialeného volania procedúr sú navrhnuté tak, aby uľahčili organizáciu distribuovaných výpočtov a vytváranie distribuovaných klient-server informačné systémy. Najväčšia efektivita využitia RPC sa dosahuje v tých aplikáciách, v ktorých dochádza k interaktívnej komunikácii medzi vzdialenými komponentmi s rýchlou odozvou a relatívne malým množstvom prenášaných dát. Takéto aplikácie sa nazývajú orientované na RPC.

Charakteristické črty vzdialených volaní procedúr sú:

  • Asymetria, to znamená, že jedna zo spolupôsobiacich strán je iniciátorom;
  • Synchronicita, to znamená, že vykonávanie volajúcej procedúry je pozastavené od momentu zadania požiadavky a je obnovené až po návrate volanej procedúry.

Implementácia vzdialených volaní je oveľa komplikovanejšia ako implementácia miestnych volaní procedúr. Môžeme identifikovať nasledujúce problémy a úlohy, ktoré je potrebné vyriešiť pri implementácii RPC:

  • Pretože volajúce a volané procedúry bežia na rôznych počítačoch, majú rôzne adresné priestory, čo spôsobuje problémy pri odovzdávaní parametrov a výsledkov, najmä ak na počítačoch bežia rôzne operačné systémy alebo majú rôzne architektúry (napríklad little-endian alebo little- endian). Keďže RPC sa nemôže spoliehať na zdieľanú pamäť, znamená to, že parametre RPC nesmú obsahovať ukazovatele na pamäťové miesta bez zásobníka a že hodnoty parametrov sa musia skopírovať z jedného počítača do druhého. Na kopírovanie parametrov procedúry a výsledkov vykonania cez sieť sú tieto serializované.
  • Na rozdiel od lokálneho volania, vzdialené volanie procedúry nevyhnutne využíva transportnú vrstvu sieťovej architektúry (napríklad TCP), ale to zostáva vývojárom skryté.
  • Spustenie volajúceho programu a volanej lokálnej procedúry na tom istom počítači je implementované v rámci jedného procesu. Implementácia RPC však zahŕňa minimálne dva procesy – jeden na každom stroji. Ak jedna z nich zlyhá, môžu nastať nasledujúce situácie: ak zlyhá volacia procedúra, vzdialene volané procedúry „osirejú“ a ak vzdialené procedúry zlyhajú, volajúce procedúry sa stanú „chudobnými rodičmi“, ktorí budú márne čakať. pre odpoveď zo vzdialených procedúr.
  • Existuje množstvo problémov spojených s heterogenitou programovacích jazykov a operačných prostredí: dátové štruktúry a štruktúry volania procedúr podporované v jednom programovacom jazyku nie sú podporované rovnakým spôsobom vo všetkých ostatných jazykoch. Existuje teda problém s kompatibilitou, ktorý zatiaľ nebol vyriešený ani zavedením jedného všeobecne akceptovaného štandardu, ani implementáciou niekoľkých konkurenčných štandardov na všetky architektúry a vo všetkých jazykoch.

Subsystémy

  • Dopravný subsystém
- riadenie odchádzajúcich a prichádzajúcich spojení. - podpora koncepcie „hranice správy“ pre transportné protokoly, ktoré ju priamo nepodporujú (TCP). - podpora garantovaného doručenia pre transportné protokoly, ktoré to priamo nepodporujú (UDP).
  • Zásobník nití (iba callee). Poskytuje kontext spustenia pre kód vyvolaný cez sieť.
  • Marshalling (nazývaný aj „serializácia“). Balenie parametrov volania do bajtového toku štandardným spôsobom, nezávisle od architektúry (najmä poradie bajtov v slove). Môže to ovplyvniť najmä polia, reťazce a štruktúry, na ktoré ukazujú parametre ukazovateľa.
  • Šifrovanie balíkov a používanie digitálneho podpisu na ne.
  • Autentifikácia a autorizácia. Prenos cez sieť informácií identifikujúcich volajúcu entitu.

V niektorých implementáciách RPC (.NET Remoting) sú hranice subsystémov otvorené polymorfné rozhrania a je možné napísať vlastnú implementáciu takmer všetkých uvedených subsystémov. V iných implementáciách (DCE RPC v systéme Windows) to tak nie je.

Účelom tohto článku je diskutovať o terminológii. Článok nie je o tom ako a prečo, ale len o používaní terminológie. Článok odráža názor autora a nepredstiera, že je vedecký.

Úvod

Ak pracujete v programovaní distribuované systémy alebo v systémová integrácia, potom väčšina z toho, čo je tu prezentované, nie je pre vás novinkou.

Problém nastáva, keď sa stretnú ľudia, ktorí používajú rôzne technológie, a keď títo ľudia začnú viesť technické rozhovory. V tomto prípade často vznikajú vzájomné nedorozumenia kvôli terminológii. Tu sa pokúsim spojiť terminológie používané v rôznych kontextoch.

Terminológia

V tejto oblasti neexistuje jasná terminológia a klasifikácia. Nižšie použitá terminológia je odrazom autorovho modelu, to znamená, že je prísne subjektívna. Akákoľvek kritika a diskusia sú vítané.

Terminológiu som rozdelil do troch oblastí: RPC (Remote Procedure Call), Správy a REST. Tieto oblasti majú historické korene.

RPC

RPC technológie - najstaršie technológie. Najvýznamnejšími predstaviteľmi RPC sú - CORBA A DCOM.

V tých časoch museli byť systémy väčšinou pripojené na rýchle a relatívne spoľahlivé lokálne siete. Hlavnou myšlienkou RPC bolo urobiť volanie vzdialených systémov podobne ako volanie funkcií v rámci programu. Celá mechanika vzdialených hovorov bola pred programátorom skrytá. Aspoň sa to snažili skryť. Programátori boli v mnohých prípadoch nútení pracovať na hlbšej úrovni, kde sa objavili pojmy marshaling ( zoraďovanie) A demaršovanie(ako je to v ruštine?), čo v podstate znamenalo serializáciu. Normálne volania funkcií v rámci procesov boli spracované na konci volajúceho Proxy, a na strane systému vykonávajúceho funkciu, v Dispečer. V ideálnom prípade by sa ani volací systém, ani systém spracovania nezaoberali zložitosťou prenosu údajov medzi systémami. Všetky tieto jemnosti boli sústredené v balíku Proxy - Dispečer, ktorého kód bol generovaný automaticky.

Takže si nevšimnete, nemali by ste si všimnúť, žiadny rozdiel medzi volaním lokálnej funkcie a volaním vzdialenej funkcie.
Teraz nastáva akási renesancia RPC, ktorej najvýznamnejšími predstaviteľmi sú: Google ProtoBuf, Thrift, Avro.

Správy

Postupom času sa ukázalo, že pokus ochrániť programátora pred tým, že volaná funkcia sa predsa len líši od lokálnej, neviedla k želanému výsledku. Podrobnosti implementácie a zásadné rozdiely medzi distribuovanými systémami boli príliš veľké na to, aby sa dali vyriešiť pomocou automaticky generovaného Proxy kódu. Postupne prišlo pochopenie, že skutočnosť, že systémy sú prepojené nespoľahlivým, pomalým a nízkorýchlostným prostredím, sa musí explicitne prejaviť v programovom kóde.

Objavili sa technológie webové služby. Začali sme sa rozprávať ABC: Adresa, Väzba, Zmluva. Nie je celkom jasné, prečo sa objavili zmluvy, ktoré sú v podstate obálkami pre vstupné argumenty. Zmluvy často celkový model skôr skomplikujú, než zjednodušia. Ale... to je jedno.

Teraz programátor výslovne vytvoril služby(servis) alebo zákazník(Zákazník) zavolajte do servisu. Služba pozostávala zo súpravy operácií (Prevádzka), z ktorých každý prijal na vstupe žiadosť(Žiadosť) a vydané odpoveď(odpoveď). Klient výslovne odoslaná(Odoslané) žiadosť, služba výslovne dostala ( Prijať) a odpovedal mu (Odoslané), pričom odpoveď poslal. Klient dostal odpoveď a hovor sa skončil.

Rovnako ako v RPC, aj tu niekde bežal Proxy a Dispečer. A ako predtým, ich kód bol generovaný automaticky a programátor mu nemusel rozumieť. Pokiaľ klient výslovne nepoužíval triedy z Proxy.

Požiadavky a odpovede sú výslovne prevedené do formátu určeného na prenos po drôte. Najčastejšie ide o bajtové pole. Transformácia sa nazýva Serializácia A Deserializácia a niekedy sa skrýva v kóde proxy.
Vyvrcholenie zasielania správ sa prejavilo vznikom paradigmy ESB (Enterprise Service Bus). Nikto nemôže skutočne formulovať, čo to je, ale každý súhlasí s tým, že údaje sa pohybujú cez ESB vo forme správ.

ODPOČINOK

V neustálom boji so zložitosťou kódu urobili programátori ďalší krok a vytvorili ODPOČINOK.

Hlavným princípom REST je, že funkčné operácie sú výrazne obmedzené a ponechajú len súbor operácií CRUD: Vytvoriť - Čítať - Aktualizovať - ​​Vymazať. V tomto modeli sú všetky operácie vždy aplikované na nejaké dáta. Operácie dostupné v CRUD sú dostatočné pre väčšinu aplikácií. Keďže technológie REST vo väčšine prípadov zahŕňajú použitie protokolu HTTP, príkazy CRUD sa odrazili v príkazoch HTTP (Príspevok - Získajte - Dajte - Odstrániť) . Neustále sa uvádza, že REST nie je nevyhnutne viazaný na HTTP. V praxi sa však široko používa odraz podpisov operácií na syntax príkazov HTTP. Napríklad volanie funkcie

EntityAddress ReadEntityAddress(reťazec param1, string param2)

Vyjadrené takto:

GET: adresa entity?param1=hodnota1¶m2=hodnota2

Záver

Pred začatím diskusie o distribuovaných systémoch alebo integrácii definujte terminológiu. Ak Proxy bude vždy znamenať to isté v rôznych kontextoch, potom napríklad požiadavka bude znamenať málo z hľadiska RPC a zaraďovanie spôsobí zmätok pri diskusii o technológiách REST.