Zavolajte na vzdialené postupy RPC ultrazvukový skener. Mechanizmus vzdialeného volania procedúry - RPC

Veľmi dôležitý mechanizmus pre aplikácie klient-server poskytuje RPC ( Diaľkové volanie procedúry). RPC vyvinula spoločnosť Sun Micrsystems a ide o kolekciu nástrojov a knižničných funkcií. Na RPC fungujú najmä NIS (Network Information System) a NFS (Network File System).

Server RPC pozostáva zo systému takých procedúr, ku ktorým má klient prístup odoslaním požiadavky RPC na server spolu s parametrami procedúry. Server zavolá určenú procedúru a vráti návratovú hodnotu procedúry, ak existuje. Aby boli všetky údaje vymieňané medzi klientom a serverom nezávislé od stroja, konvertujú sa na takzvanú externú reprezentáciu údajov ( Externá reprezentácia údajov, XDR). RPC komunikuje s UDP a TCP socketmi na prenos dát vo formáte XDR. Sun deklaroval RPC ako verejnú doménu a jeho popis je dostupný v sérii dokumentov RFC.

Zmeny v aplikáciách RPC niekedy zavedú nekompatibilitu do procedúry volania rozhrania. Samozrejme, jednoduchá zmena by spôsobila zlyhanie servera všetkých aplikácií, ktoré stále čakajú na rovnaké hovory. Preto majú programy RPC priradené čísla verzií, zvyčajne začínajúce 1. Každý novú verziu RPC sleduje číslo verzie. Server môže často ponúkať niekoľko verzií súčasne. Klienti v tomto prípade špecifikujú číslo verzie, ktorú chcú použiť.

Sieťová komunikácia medzi servermi RPC a klientmi je trochu špeciálna. Server RPC ponúka jednu alebo viac systémových procedúr, pričom každá sada takýchto procedúr sa nazýva program ( program) a je jednoznačne identifikovaný číslom programu ( číslo programu). Zoznam názvov služieb sa zvyčajne uchováva v /etc/rpc, ktorého príklad je uvedený nižšie.

Príklad 12-4. Vzorový súbor /etc/rpc

V sieťach TCP/IP stáli autori RPC pred úlohou namapovať čísla programov na bežné sieťové služby. Každý server poskytuje port TCP a UDP pre každý program a každú verziu. Vo všeobecnosti aplikácie RPC používajú UDP na prenos údajov a vrátia sa späť k TCP, keď sa prenášané údaje nezmestia do jedného datagramu UDP.

Samozrejme, klientske programy musia mať spôsob, ako zistiť, ktorý port zodpovedá číslu programu. Použitie konfiguračného súboru by bolo príliš neflexibilné; Keďže aplikácie RPC nepoužívajú vyhradené porty, nie je zaručené, že port nie je obsadený nejakou aplikáciou a je nám dostupný. Aplikácie RPC si teda vyberú ľubovoľný port, ktorý môžu prijať, a zaregistrujú ho démon portmapper. Klient, ktorý chce kontaktovať službu s daným číslom programu, najprv požiada portmappera o zistenie čísla portu požadovanej služby.

Táto metóda má nevýhodu v tom, že zavádza jediný bod zlyhania, podobne inetd démon Tento prípad je však o niečo horší, pretože pri zlyhaní mapovača portov sa stratia všetky informácie RPC o portoch. Zvyčajne to znamená, že musíte manuálne reštartovať všetky servery RPC alebo reštartovať počítač.

V systéme Linux sa mapovač portov nazýva /sbin/portmap alebo /usr/sbin/rpc.portmap . Okrem toho, že musí byť spustený zo sieťového spúšťacieho skriptu, portmapper nevyžaduje žiadnu konfiguračnú prácu.

Diaľkové volanie procedúry(alebo Volanie vzdialených procedúr) (z angličtiny. Vzdialené volanie procedúry (RPC)) - trieda technológií, ktoré umožňujú počítačovým programom volať funkcie alebo procedúry v inom adresnom priestore (zvyčajne na vzdialených počítačoch). Implementácia technológie RPC zvyčajne zahŕňa dva komponenty: sieťový protokol pre komunikáciu klient-server a jazyk objektovej serializácie (alebo štruktúry 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, keďže HTTP nie je natívne prenosový protokol).

Implementácie

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

• Sun RPC (binárny protokol založený na TCP a UDP a XDR) RFC-1831 druhý názov ONC RPC RFC-1833
• .Net Remoting (binárny protokol založený na TCP, UDP, HTTP)
• SOAP - Simple Object Access Protocol (textový protokol založený na HTTP) pozri špecifikáciu: RFC-4227
• XML RPC (textový protokol založený na HTTP) pozri špecifikáciu: RFC-3529
• Java RMI – Java Remote Method Invocation – pozri špecifikáciu: http://java.sun.com/j2se/1.5.0/docs/guide/rmi/index.html
• JSON-RPC JavaScript Object Notation Vzdialené volania procedúr (textový protokol založený na HTTP) pozri špecifikáciu: RFC-4627
• 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)

Princíp

Myšlienkou vzdialeného volania procedúr (RPC) je rozšíriť dobre známy a pochopený mechanizmus na prenos riadenia a údajov v rámci programu bežiaceho na jednom stroji na prenos riadenia a údajov 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 prebieha interaktívna komunikácia 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.

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 big- 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), čo však 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

Spravujte odchádzajúce a prichádzajúce pripojenia. - 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 informácií cez sieť identifikujúcich volajúceho.

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.

pozri tiež

Vzdialené volanie procedúry (RPC) Koncept vzdialeného volania procedúry

Myšlienkou vzdialeného volania procedúr (RPC) je rozšíriť dobre známy a pochopený mechanizmus na prenos riadenia a údajov v rámci programu bežiaceho na jednom stroji na prenos riadenia a údajov cez sieť. Nástroje vzdialeného volania procedúr sú navrhnuté tak, aby uľahčili organizáciu distribuovaných výpočtov. Najväčšia efektivita využitia RPC sa dosahuje v tých aplikáciách, v ktorých prebieha interaktívna komunikácia 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 volania miestnych postupov 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. Na začiatok, keďže volajúce a volané procedúry sa vykonávajú 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 stroje nie sú identické. 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. Ďalší rozdiel medzi RPC a miestnym hovorom je ten, že nevyhnutne používa základný komunikačný systém, čo by však nemalo byť explicitne viditeľné ani v definícii procedúr, ani v samotných procedúrach. Odľahlosť prináša ďalšie problémy. 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ú „osirotenými rodičmi“ a márne čakajú na odozvy zo vzdialených procedúr.

Okrem toho 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.

Tieto a niektoré ďalšie problémy rieši rozšírená technológia RPC, ktorá je základom mnohých distribuovaných operačných systémov. Základné operácie RPC

Aby sme pochopili, ako RPC funguje, zvážme najskôr uskutočnenie lokálneho volania procedúry na typickom počítači spustenom offline. Nech je to napríklad systémové volanie

count=read(fd, buf, nbytes);

kde fd je celé číslo, buf je pole znakov, nbytes je celé číslo.

Ak chcete uskutočniť hovor, volajúca procedúra vloží parametre do zásobníka v opačnom poradí (obrázok 3.1). Po vykonaní volania čítania umiestni návratovú hodnotu do registra, presunie návratovú adresu a vráti riadenie volajúcej procedúre, ktorá vyberie parametre zo zásobníka a vráti ho do pôvodného stavu. Všimnite si, že v jazyku C môžu byť parametre volané buď odkazom (podľa názvu) alebo hodnotou (podľa hodnoty). Vo vzťahu k volanej procedúre sú parametre hodnoty inicializované lokálne premenné. Volaná procedúra ich môže zmeniť bez ovplyvnenia pôvodných hodnôt týchto premenných vo volajúcej procedúre.

Ak je do volanej procedúry odovzdaný ukazovateľ na premennú, potom zmena hodnoty tejto premennej pomocou volanej procedúry znamená zmenu hodnoty tejto premennej pre volajúcu procedúru. Táto skutočnosť je pre RPC veľmi významná.

Existuje aj ďalší mechanizmus odovzdávania parametrov, ktorý sa v C nepoužíva. Nazýva sa call-by-copy/restore, ktorý vyžaduje, aby volajúci skopíroval premenné do zásobníka ako hodnoty a potom ich skopíroval späť po vykonaní volania cez pôvodné hodnoty volacej procedúry.

O tom, ktorý mechanizmus odovzdávania parametrov použiť, rozhodujú vývojári jazyka. Niekedy to závisí od typu prenášaných údajov. Napríklad v C sú celé čísla a iné skalárne údaje vždy odovzdávané hodnotou a polia sú vždy odovzdávané odkazom.

Aplikácia

Významná časť nástrojov diaľkové ovládanie Operačný systém Windows (prehliadač udalostí, správca servera, správa tlače, zoznamy používateľov) používa DCE RPC ako prostriedok komunikácie cez sieť medzi riadenou službou a aplikáciou na ovládanie používateľského rozhrania. Podpora DCE RPC je vo Windows NT prítomná od úplne prvej verzie 3.1. Klienti DCE RPC boli podporovaní aj v rade light operačné systémy Windows 3.x/95/98/Me.

Systémové knižnice Windows, ktoré poskytujú takéto možnosti riadenia a slúžia ako základná vrstva pre aplikácie na ovládanie používateľského rozhrania (netapi32.dll a čiastočne advapi32.dll), v skutočnosti obsahujú klientsky kód pre rozhrania DCE RPC, ktoré vykonávajú túto kontrolu.

Toto architektonické rozhodnutie bolo predmetom aktívnej kritiky spoločnosti Microsoft. Všeobecné postupy zaraďovania prítomné v DCE RPC sú veľmi zložité a majú obrovský potenciál na využitie defektov v sieti odoslaním zámerne zdeformovaného paketu DCE RPC. Významná časť defektov Zabezpečenie systému Windows, objavené od konca 90-tych rokov do polovice 2000-tych rokov, boli presne chyby v zaraďovacom kóde DCE RPC.

Okrem DCE RPC Windows aktívne používa technológiu DCOM. Používa sa napríklad ako prostriedok komunikácie medzi nástrojmi na správu webového servera IIS a samotným spravovaným serverom. Na DCOM je založené aj plne funkčné rozhranie pre komunikáciu s poštovým systémom MS Exchange Server - MAPI.

Myšlienka volania vzdialených procedúr (Vzdialené volanie procedúry – RPC) 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.

Najväčšia efektívnosť používania RPC sa dosahuje v tých aplikáciách, v ktorých existuje interaktívna komunikácia medzi vzdialenými komponentmi s krátky čas odozvy A relatívne malé množstvo prenášaných dát.Takéto aplikácie sa nazývajú orientované na RPC.

Charakteristické črty volania miestnych postupov sú:

asymetria, to znamená, že jedna zo zúčastnených strán je iniciátorom;

synchronizácia, to znamená, že vykonávanie volajúcej procedúry je pozastavené od momentu vydania požiadavky a pokračuje sa až po návrate volanej procedúry.

Implementácia vzdialených volaní je oveľa komplikovanejšia ako implementácia miestnych volaní procedúr.

1. Začnime tým, že keďže sa volajúce a volané procedúry vykonávajú na rôznych strojoch, tak oni majú rôzne adresné priestory a toto vytvára problémy pri prenose parametrov a výsledkov, najmä ak stroje nie sú identické.

Keďže RPC sa nemôže spoliehať na zdieľanú pamäť, znamená to Parametre RPC nesmú obsahovať ukazovatele na miesta v pamäti bez zásobníka No a čo hodnoty parametrov musia byť skopírované z jedného počítača do druhého.

2. Ďalší rozdiel medzi RPC a miestnym hovorom je ten nevyhnutne používa základný komunikačný systém, však toto by nemali byť jasne viditeľné ani v definícii postupov, ani v samotných postupoch .

Odľahlosť prináša ďalšie problémy. Spustenie volajúceho programu a volanej lokálnej procedúry na rovnakom počítači implementované v rámcislobodný proces. ale podieľajú na implementácii RPCaspoň dva procesy - jeden v každom aute. Ak jeden z nich zlyhá, môžu nastať nasledujúce situácie:

Ak sa volajúca procedúra zrúti, vzdialene volané procedúry „osirejú“ a

Ak sa vzdialené procedúry ukončia nenormálne, volajúce procedúry sa stanú „chudobnými rodičmi“ a budú čakať na odpoveď od vzdialených procedúr bezvýsledne.

Okrem toho 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.

Tieto a niektoré ďalšie problémy rieši rozšírená technológia RPC, ktorá je základom mnohých distribuovaných operačných systémov.

Myšlienkou RPC je dosiahnuť, aby vzdialené volanie procedúry vyzeralo čo najviac podobne ako volanie lokálnej procedúry. Inými slovami, urobte RPC transparentným: volajúca procedúra nemusí vedieť, že volaná procedúra je na inom počítači a naopak.

RPC dosahuje transparentnosť nasledujúcim spôsobom. Keď je volaná procedúra skutočne vzdialená, do knižnice sa namiesto lokálnej procedúry umiestni iná verzia procedúry, nazývaná klientsky stub. Rovnako ako pôvodná procedúra sa stub volá pomocou volacej sekvencie (ako na obrázku 3.1) a pri prístupe k jadru nastane prerušenie. Iba na rozdiel od pôvodnej procedúry neumiestňuje parametre do registrov a nepožaduje údaje z jadra, namiesto toho vygeneruje správu, ktorá sa odošle do jadra vzdialeného počítača..

Ryža. 3.2. 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ď 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 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 požadovaný výsledok. 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 explicitne 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, otvorené okná sa nezobrazujú na paneli úloh atď. atď. 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 iba 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 počítača alebo z distribúcie Windows (ako som to urobil 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šetky 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 náhradou nesprávne verzie správne. V konzole spustite:

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

Po reštarte začal počítač fungovať základné služby začala. 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:

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: