Úč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. Riadne volania funkcií v rámci procesov boli obsluhované spoločnosťou volajúca strana V 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 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 HTTP protokol, potom sa príkazy CRUD premietli do príkazov 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.

Programy komunikujúce cez sieť potrebujú komunikačný mechanizmus. Na nižšej úrovni je po príchode paketov signál odoslaný a spracovaný sieťovým programom na spracovanie signálu. Na najvyššej úrovni funguje mechanizmus stretnutia, prijatý v jazyku Ada. NFS používa mechanizmus vzdialeného volania procedúr (RPC), v ktorom klient komunikuje so serverom (pozri obrázok 1). Podľa tohto procesu klient najskôr zavolá procedúru, ktorá odošle požiadavku na server. Po príchode paketu požiadavky server zavolá procedúru otvorenia paketu, vykoná požadovanú službu, odošle odpoveď a riadenie sa vráti klientovi.

Rozhranie RPC možno považovať za pozostávajúce z troch vrstiev:

1. Najvyššia úroveň je úplne priehľadná. Program na tejto úrovni môže napríklad obsahovať volanie procedúry rnusers(), ktorá vráti počet používateľov na vzdialenom počítači. Nemusíte vedieť o používaní mechanizmu RPC, pretože hovor uskutočňujete v programe.
2. Stredná vrstva je určená pre najbežnejšie aplikácie. Volania RPC na tejto úrovni sú spracovávané podprogramami registerrpc() a callrpc(): registerrpc() prijíma celosystémový kód a callrpc() vykonáva vzdialené volanie procedúry. Volanie rnusers() je implementované pomocou týchto dvoch rutín.
3. Nižšia úroveň sa používa pre zložitejšie úlohy, ktoré menia predvolené hodnoty parametrov procedúry. Na tejto úrovni môžete explicitne manipulovať so zásuvkami používanými na prenos správ RPC.

Vo všeobecnosti by ste mali používať najvyššiu úroveň a vyhýbať sa používaniu nižších úrovní, pokiaľ to nie je absolútne nevyhnutné.

Aj keď v tomto návode uvažujeme iba o rozhraní C, volania na vzdialené procedúry je možné uskutočniť z akéhokoľvek jazyka. Fungovanie mechanizmu RPC na organizovanie komunikácie medzi procesmi na rôznych strojoch sa nelíši od jeho fungovania na jednom stroji.

RPC (Remote Procedure Call) je rozhranie medzi vzdialených používateľov A určité programy hostiteľa, ktoré sa spúšťajú na základe požiadaviek týchto používateľov. Služba RPC akéhokoľvek hostiteľa spravidla poskytuje klientom súbor programov. Každý z týchto programov pozostáva z jednej alebo viacerých vzdialených procedúr. Napríklad vzdialená služba systém súborov NFS, ktorý je postavený na volaniach RPC, môže pozostávať iba z dvoch programov: napríklad jeden program spolupracuje s používateľskými rozhraniami na vysokej úrovni a druhý s funkciami I/O na nízkej úrovni.

Každé vzdialené volanie procedúry zahŕňa dve strany: aktívneho klienta, ktorý odošle požiadavku na volanie procedúry na server, a server, ktorý odošle odpoveď klientovi.

Poznámka. Treba mať na pamäti, že výrazy "klient" a "server" sa v tomto prípade vzťahujú na konkrétnu transakciu. Konkrétny hostiteľ alebo softvér (proces alebo program) môže pôsobiť ako klient aj server. Napríklad program, ktorý poskytuje službu vzdialenej procedúry, môže byť súčasne klientom pre prácu so sieťovým súborovým systémom.

Protokol RPC je postavený na modeli volania vzdialenej procedúry, podobne ako mechanizmus volania lokálnej procedúry. Keď voláte lokálnu procedúru, posúvate argumenty na konkrétne miesto v pamäti, zásobníka, resp premenné prostredia a preniesť riadenie procesu na konkrétnu adresu. Po dokončení úlohy si prečítate výsledky na konkrétnej adrese a pokračujete vo svojom procese.

Pri práci so vzdialenou procedúrou je hlavný rozdiel v tom, že vzdialené volanie funkcie obsluhujú dva procesy: klientsky proces a serverový proces.

Klientsky proces odošle na server správu, ktorá obsahuje parametre volanej procedúry a čaká na odpoveď s výsledkami svojej práce. Po prijatí odpovede sa prečíta výsledok a proces pokračuje. Na strane servera je proces obsluhy hovoru v stave čakania a keď príde správa, prečíta parametre procedúry, vykoná ju, odošle odpoveď a dostane sa do stavu čakania na ďalší hovor.

Protokol RPC nekladie žiadne požiadavky na ďalšiu komunikáciu medzi procesmi a nevyžaduje synchronizáciu vykonávaných funkcií, to znamená, že volania môžu byť asynchrónne a vzájomne nezávislé, takže klient môže počas čakania na odpoveď vykonávať ďalšie procedúry. Server RPC môže pre každú funkciu prideliť samostatný proces alebo virtuálny stroj, takže bez čakania na dokončenie predchádzajúcich požiadaviek môže okamžite prijať ďalšie.

Existuje však niekoľko dôležitých rozdielov medzi lokálnymi a vzdialenými volaniami procedúr:

1. Chyba pri spracovaní. V každom prípade by mal klient dostať upozornenie na chyby, ktoré sa vyskytnú pri volaní vzdialených procedúr na serveri alebo v sieti.
2. Globálne premenné. Pretože server nemá prístup k adresnému priestoru klienta, vzdialené volania procedúr nemôžu používať skryté parametre vo forme globálnych premenných.
3. Výkon. Rýchlosť vykonávania vzdialených procedúr je zvyčajne o jeden alebo dva rády nižšia ako rýchlosť vykonávania podobných lokálnych procedúr.
4. Overenie. Pretože volania vzdialených procedúr prebiehajú cez sieť, musia sa použiť mechanizmy autentifikácie klienta.

Princípy konštrukcie protokolu.

Protokol RPC môže používať niekoľko rôznych transportných protokolov. Zodpovednosťou protokolu RPC je len poskytovať štandardy a interpretovať prenos správ. Spoľahlivosť a spoľahlivosť prenosu správ je plne zabezpečená transportnou vrstvou.

RPC však môže riadiť výber a niektoré funkcie transportného protokolu. Ako príklad interakcie medzi RPC a transportným protokolom zvážte postup na priradenie portu RPC pre aplikačný proces, ktorý bude fungovať cez RPC - Portmapper.

Táto funkcia dynamicky (na požiadanie) priraďuje pripojenie RPC ku konkrétnemu portu. Funkcia Portmapper sa používa pomerne často, pretože množina transportných portov vyhradených pre RPC je obmedzená a počet procesov, ktoré môžu potenciálne bežať súčasne, je veľmi vysoký. Portmapper sa napríklad volá pri výbere portov na interakciu medzi klientom a serverom systému NFS.

Služba Portmapper využíva mechanizmus vysielania RPC správ na konkrétny port - III. Klient odošle na tento port vysielaciu správu s požiadavkou na port konkrétnu službu RPC. Služba Portmapper spracuje daňovú správu, určí adresu lokálnej služby RPC a odošle odpoveď klientovi. Služba RPC Portmapper môže pracovať s protokolmi TCP aj UDP.

RPC môže pracovať s rôznymi transportnými protokolmi, ale nikdy neduplikuje ich funkcie, t.j. ak RPC beží nad TCP, všetky obavy o spoľahlivosť a platnosť pripojenia RPC sú priradené TCP. Ak je však protokol RPC nainštalovaný nad protokolom UDP, môže poskytnúť ďalšie vlastné funkcie, aby bolo zaručené doručenie správ.

Poznámka.

Aplikačné úlohy môžu považovať protokol RPC za špecifickú procedúru na volanie funkcie cez sieť JSR (Jump Subroutine Instruction).

Aby protokol RPC fungoval, musia byť splnené nasledujúce podmienky:

1. Jedinečná identifikácia všetkých vzdialene volaných procedúr na danom hostiteľovi. Požiadavky RPC obsahujú tri polia identifikátorov - číslo vzdialeného programu (služby), číslo verzie vzdialeného programu a číslo vzdialenej procedúry určený program. Číslo programu prideľuje výrobca služby, číslo procedúry označuje konkrétnu funkciu tejto služby
2. Identifikácia verzie protokolu RPC. Správy RPC obsahujú pole verzie protokolu RPC. Používa sa na koordináciu formátov odovzdávaných parametrov, keď klient pracuje s rôznymi verziami RPC.
3. Poskytovanie mechanizmov autentifikácie klienta pre server. Protokol RPC poskytuje postup na autentifikáciu klienta pre službu a v prípade potreby vždy, keď je klientovi zaslaná požiadavka alebo odoslaná odpoveď. Okrem toho RPC umožňuje použitie rôznych dodatočných bezpečnostných mechanizmov.

RPC môže používať štyri typy autentifikačných mechanizmov:

• AUTH_NULL – nevyžaduje sa žiadne overenie
• AUTH_UNIX - autentifikácia podľa štandardu UNIX
• AUTH_SHORT - štandardná autentifikácia UNIX s vlastnou štruktúrou kódovania
• AUTH_DES - autentifikácia podľa štandardu DES

1. Identifikácia správ s odpoveďou na zodpovedajúce požiadavky. Správy s odpoveďou RPC obsahujú identifikátor požiadavky, z ktorej boli skonštruované. Tento identifikátor možno nazvať identifikátor transakcie volania RPC. Tento mechanizmus je potrebný najmä pri práci v asynchrónnom režime a pri vykonávaní sekvencie niekoľkých RPC volaní.
2. Identifikácia chýb protokolu. Všetky chyby siete alebo servera majú jedinečné identifikátory, pomocou ktorých môže každý z účastníkov pripojenia určiť príčinu zlyhania.

Štruktúry protokolových správ

Pri odosielaní správ RPC cez prenosový protokol sa v rámci jedného prenosového paketu môže nachádzať viacero správ RPC. Na oddelenie jednej správy od druhej sa používa značka záznamu (RM - Record Marker). Každá správa RPC je „označená“ presne jedným RM.

Správa RPC môže pozostávať z niekoľkých fragmentov. Každý fragment pozostáva zo štyroch bajtov hlavičky a (0 až 2**31-1) údajov. Prvý bit hlavičky označuje, či je fragment posledný, a zvyšných 31 bitov označuje dĺžku dátového paketu.

Štruktúra RPC je formálne opísaná v jazyku pre popis a reprezentáciu dátových formátov - XDR s doplnkami ohľadom popisu procedúr. Dalo by sa dokonca povedať, že popisný jazyk RPC je nadstavbou XDR, doplnenou o prácu s procedúrami.

Štruktúra RPC paketu vyzerá takto:

Štruktúra odpovede (reply_body) môže obsahovať buď chybovú štruktúru (v takom prípade obsahuje kód chyby) alebo štruktúru úspešného spracovania požiadavky (v takom prípade obsahuje návratové dáta).

Softvérové ​​rozhranie na vysokej úrovni.

Používanie podprogramov v programe - tradičným spôsobomštruktúrovať úlohu a urobiť ju jasnejšou. Najčastejšie používané rutiny sa zhromažďujú v knižniciach, kde ich môžu používať rôzne programy. V tomto prípade hovoríme o lokálnom (lokálnom) hovore, teda volajúci aj volaný objekt fungujú v rámci toho istého programu na tom istom počítači.

V prípade vzdialeného hovoru proces spustený na jednom počítači spustí proces na vzdialený počítač(t. j. v skutočnosti spúšťa kód procedúry na vzdialenom počítači). Je zrejmé, že vzdialené volanie procedúry sa výrazne líši od tradičného lokálneho, ale z pohľadu programátora takéto rozdiely prakticky chýbajú, t. j. architektúra vzdialeného volania procedúry vám umožňuje simulovať lokálne volanie procedúry.

Ak však v prípade lokálneho volania program odovzdá parametre volanej procedúre a dostane výsledok práce cez zásobník alebo oblasti zdieľanej pamäte, potom v prípade vzdialeného volania sa prenos parametrov zmení na prenos žiadosť cez sieť a výsledok práce je v prijatej odpovedi.

Tento prístup je možným základom pre vytváranie distribuovaných aplikácií a hoci mnohé moderné systémy tento mechanizmus nevyužívajú, základné pojmy a termíny sú v mnohých prípadoch zachované. Pri popise mechanizmu RPC budeme volajúci proces tradične nazývať klient, a vzdialený proces, implementujúci postup, je server.

Vzdialené volanie procedúry zahŕňa nasledujúce kroky:

1. Klientsky program vykoná lokálne volanie procedúry nazývanej stub. V tomto prípade sa klientovi „zdá“, že volaním stub v skutočnosti volá procedúru servera. Klient skutočne odovzdá potrebné parametre stub a ten vráti výsledok. Veci však nie sú celkom tak, ako si klient predstavuje. Úlohou stub je prijať argumenty určené pre vzdialenú procedúru, prípadne ich konvertovať do nejakého štandardného formátu a formulovať sieťovú požiadavku. Zbalenie argumentov a vytvorenie sieťovej požiadavky sa nazýva zoraďovanie.
2. Sieťová požiadavka sa prepošle cez sieť do vzdialeného systému. Na tento účel stub používa vhodné volania, napríklad tie, o ktorých sme hovorili v predchádzajúcich častiach. Všimnite si, že možno použiť rôzne transportné protokoly, nielen rodinu TCP/IP.
3. Na vzdialenom hostiteľovi sa všetko deje v opačné poradie. Server stub počúva požiadavku a po prijatí získa parametre - argumenty pre volanie procedúry. Zrušenie môže zahŕňať potrebné transformácie (napríklad zmeny poradia bajtov).
4. Stub zavolá procedúru skutočného servera, ktorej je adresovaná požiadavka klienta, a odovzdá jej argumenty prijaté cez sieť.
5. Po dokončení procedúry sa riadenie vráti do stub servera a odovzdá mu požadované parametre. Ako klientský útržok; Útržok servera skonvertuje hodnoty vrátené procedúrou a vygeneruje správu s odpoveďou siete, ktorá sa prenáša cez sieť do systému, z ktorého prišla požiadavka.
6. Operačný systém odovzdá prijatú správu klientskemu stub, ktorý po nevyhnutnej transformácii odovzdá hodnoty (čo sú hodnoty vrátené vzdialenou procedúrou) klientovi, ktorý to považuje za normálny návrat zo servera. postup.

Z pohľadu klienta teda zavolá vzdialenú procedúru, ako by to bolo v prípade lokálnej procedúry. To isté sa dá povedať o serveri: procedúra sa volá štandardným spôsobom, určitý objekt (stub servera) volá lokálnu procedúru a prijíma hodnoty, ktoré vracia. Klient považuje stub za volaciu serverovú procedúru a server považuje svoj vlastný stub za klienta.

Útržky teda tvoria jadro systému RPC, zodpovedné za všetky aspekty generovania správ a prenosu medzi klientom a vzdialeným serverom (postup), hoci klient aj server veria, že hovory prebiehajú lokálne. Toto je základný koncept RPC – úplne skryť distribuovaný (sieťový) charakter interakcie v stub kóde. Výhody tohto prístupu sú zrejmé: klient aj server sú nezávislé od sieťovej implementácie, oba fungujú v rámci určitej distribuovanej siete. virtuálny prístroj a volania procedúr majú štandardné rozhranie.

Odovzdávanie parametrov

Odovzdávanie parametrov hodnoty nespôsobuje žiadne zvláštne ťažkosti. V tomto prípade klient stub umiestni hodnotu parametra do sieťovej požiadavky, prípadne vykoná konverzie do štandardnej formy (napríklad obrátenie poradia bajtov). Oveľa zložitejšia situácia je pri odovzdávaní ukazovateľov, kedy parameter predstavuje adresu údajov a nie ich hodnotu. Odovzdanie adresy v požiadavke nemá význam, pretože vzdialená procedúra sa vykonáva v úplne inom adresnom priestore. Najviac jednoduché riešenie, ktorý sa používa v RPC, je zakázať klientom odovzdávať parametre iné ako podľa hodnoty, hoci to, samozrejme, prináša vážne obmedzenia.

Väzba

Skôr ako môže klient zavolať vzdialenú procedúru, musí byť priradená k vzdialenému systému, ktorý je hostiteľom požadovaného servera. Záväzná úloha sa teda delí na dve časti:

1. Hľadanie vzdialený hostiteľ s požadovaným serverom
2. Nájdenie požadovaného serverového procesu na danom hostiteľovi

Na nájdenie hostiteľa možno použiť rôzne prístupy. Možnou možnosťou je vytvorenie nejakého centralizovaného adresára, v ktorom hostitelia inzerujú svoje servery a kde si klient môže v prípade potreby vybrať hostiteľa a adresu procedúry, ktoré sú pre neho vhodné.

Každá procedúra RPC je jednoznačne identifikovaná programom a číslom procedúry. Číslo programu identifikuje skupinu vzdialených procedúr, z ktorých každá má svoje vlastné číslo. Každému programu je priradené aj číslo verzie, takže ak v programe vykonáte menšie zmeny (napríklad pridáte procedúru), nie je potrebné meniť jeho číslo. Typicky je niekoľko funkčne podobných procedúr implementovaných v jednom softvérovom module, ktorý sa po spustení stáva serverom týchto procedúr a ktorý je identifikovaný číslom programu.

Preto, keď chce klient zavolať vzdialenú procedúru, potrebuje poznať program, verziu a čísla procedúr, ktoré poskytujú požadovanú službu.

Na odoslanie požiadavky musí klient poznať aj sieťovú adresu hostiteľa a číslo portu spojené s programom servera, ktorý poskytuje požadované postupy. Používa sa na to démon portmap(IM) (na niektorých systémoch nazývaný rpcbind(IM). Démon beží na hostiteľovi, ktorý poskytuje službu vzdialenej procedúry a používa dobre známe číslo portu. Keď je proces servera inicializovaný, zaregistruje svoje procedúry a čísla portov v mape portov (IM). Teraz, keď klient potrebuje poznať číslo portu na zavolanie konkrétnej procedúry, odošle požiadavku na portmap(IM) server, ktorý obratom buď vráti číslo portu alebo prepošle požiadavku priamo na vzdialený server procedúry a potom pri jej vykonaní vráti klientovi odpoveď. V každom prípade, ak požadovaná procedúra existuje, klient dostane číslo portu procedúry zo servera portmap(IM) a ďalšie požiadavky môžu byť zadané priamo na tento port.

Liečba špeciálne situácie(výnimka)

Vybavovanie výnimiek pri volaní miestnych postupov nie je zvlášť problematické. UNIX poskytuje spracovanie chýb procesov, ako je delenie nulou, prístup k neplatnej oblasti pamäte atď. V prípade vzdialeného volania procedúry sa zvyšuje pravdepodobnosť chybových situácií. Okrem chýb servera a stub sa pridávajú chyby spojené napríklad s prijatím chybnej sieťovej správy.

Napríklad pri použití UDP ako transportného protokolu sa správy po určitom časovom limite znova prenesú. Klientovi sa vráti chyba, ak po určitom počte pokusov nedostane odpoveď zo servera. V prípade, že sa používa protokol TCP, vráti sa klientovi chyba, ak server uzavrel TCP spojenie.

Sémantika hovoru

Volanie lokálnej procedúry vedie jednoznačne k jej vykonaniu, po ktorom sa riadenie vráti do hlavného programu. Iná situácia je pri volaní vzdialenej procedúry. Nedá sa určiť, kedy presne bude zákrok vykonaný, či vôbec, a ak áno, koľkokrát? Napríklad, ak vzdialený systém prijme požiadavku po zlyhaní serverového programu, procedúra sa vôbec nevykoná. Ak klient, keď po určitom čase (timeout) nedostane odpoveď, odošle požiadavku znova, potom môže nastať situácia, keď je odpoveď už prenesená cez sieť a opakovaná požiadavka je opäť prijatá na spracovanie diaľkovým ovládačom. postup. V tomto prípade sa postup vykoná niekoľkokrát.

Vykonanie vzdialenej procedúry teda možno charakterizovať nasledujúcou sémantikou:

• Raz a len raz. Toto správanie (v niektorých prípadoch najžiadanejšie) je ťažké vyžadovať kvôli možným zlyhaniam servera.
• Maximálne časy. To znamená, že postup buď nebol vykonaný vôbec, alebo bol vykonaný iba raz. Podobné vyhlásenie možno urobiť pri prijatí chyby namiesto normálnej odpovede.
• Aspoň raz. Zákrok bol pravdepodobne vykonaný raz, ale je možné aj viac. Pre normálna operácia v takejto situácii musí mať postup na diaľku vlastnosť idempotencie (z anglického idemponent). Túto vlastnosť má postup, ktorého opakované vykonávanie nespôsobuje kumulatívne zmeny. Napríklad čítanie súboru je idempotentné, ale pridávanie textu do súboru nie.

Prezentácia údajov

Keď klient a server bežia na rovnakom systéme na rovnakom počítači, nevyskytujú sa žiadne problémy s nekompatibilitou údajov. Pre klienta aj server sú dáta v binárnej forme reprezentované rovnakým spôsobom. V prípade vzdialeného hovoru je záležitosť komplikovaná skutočnosťou, že klient a server môžu bežať na systémoch s rôznymi architektúrami, ktoré majú rôzne reprezentácie údajov (napríklad reprezentácia s pohyblivou rádovou čiarkou, poradie bajtov atď.)

Väčšina implementácií systému RPC definuje niektoré štandardné reprezentácie údajov, na ktoré sa musia previesť všetky hodnoty odovzdané v požiadavkách a odpovediach.

Napríklad formát na prezentáciu údajov v RPC od Sun Microsystems je nasledujúci:

1. Poradie bajtov - Najdôležitejšie - posledné
2. Reprezentácia s pohyblivou rádovou čiarkou - IEEE
3. Reprezentácia znakov - ASCII

Net

Z hľadiska funkčnosti zaujíma RPC systém medziľahlé miesto medzi aplikačnou vrstvou a transportnou vrstvou. V súlade s OSI model Táto pozícia zodpovedá úrovni prezentácie a relácie. RPC je teda teoreticky nezávislý od implementácie siete, najmä od sieťových protokolov transportnej vrstvy.

Softvérové ​​implementácie systému spravidla podporujú jeden alebo dva protokoly. Napríklad systém RPC vyvinutý spoločnosťou Sun Microsystems podporuje prenos správ pomocou protokolov TCP a UDP. Výber jedného alebo druhého protokolu závisí od požiadaviek aplikácie. Výber protokolu UDP je opodstatnený pre aplikácie, ktoré majú nasledujúce vlastnosti:

• Volané procedúry sú idempotentné
• Veľkosť prenášaných argumentov a vráteného výsledku je menšia ako veľkosť paketu UDP – 8 KB.
• Server poskytuje prácu niekoľkým stovkám klientov. Keďže pri práci s protokolmi TCP je server nútený udržiavať spojenie s každým z aktívnych klientov, zaberá to značnú časť jeho zdrojov. Protokol UDP je v tomto smere menej náročný na zdroje

Na druhej strane TCP poskytuje efektívnu prácu aplikácie s nasledujúcimi vlastnosťami:

• Aplikácia vyžaduje spoľahlivý prenosový protokol
• Volané postupy sú neidentické
• Veľkosť argumentov alebo vráteného výsledku presahuje 8 kB

Voľba protokolu je zvyčajne ponechaná na klientovi a systém organizuje generovanie a prenos správ rôznymi spôsobmi. Pri použití protokolu TCP, pre ktorý sú prenášané dáta prúdom bajtov, je teda potrebné správy od seba oddeliť. Na tento účel sa používa napríklad protokol označovania záznamov opísaný v RFC1057 „RPC: Remote Procedure Call Protocol Specification version 2“, v ktorom je na začiatok každej správy umiestnené 32-bitové celé číslo, ktoré definuje veľkosť správy. v bajtoch.

Iná situácia je so sémantikou hovoru. Napríklad, ak sa RPC vykonáva pomocou nespoľahlivého transportného protokolu (UDP), systém znova odošle správu v krátkych intervaloch (časové limity). Ak klientska aplikácia nedostane odpoveď, potom je bezpečné povedať, že procedúra bola vykonaná nula alebo viackrát. Ak dostane odpoveď, aplikácia môže dospieť k záveru, že postup bol vykonaný aspoň raz. Keď sa používa spoľahlivý transportný protokol (TCP), ak je prijatá odpoveď, postup možno považovať za vykonaný raz. Ak nedostanete odpoveď, nie je možné s určitosťou povedať, že postup nebol dokončený3.

Ako to funguje?

Samotný RPC systém je v podstate zabudovaný do klientskeho programu a serverového programu. Je fajn, že pri vývoji distribuovaných aplikácií sa nemusíte vŕtať v detailoch RPC protokolu či spracovania programových správ. Systém predpokladá existenciu vhodného vývojového prostredia, čo výrazne uľahčuje život tvorcom aplikácie. softvér. Jedným z kľúčových bodov RPC je, že vývoj distribuovanej aplikácie začína definíciou objektového rozhrania - formálneho popisu funkcií servera napísaného v špeciálnom jazyku. Na základe tohto rozhrania sa potom automaticky generujú klientske a serverové stuby. Jediné, čo potom musíte urobiť, je napísať skutočný kód procedúry.

Ako príklad si predstavte RPC od Sun Microsystems. Systém sa skladá z troch hlavných častí:

• rpcgen(1) je RPC kompilátor, ktorý na základe popisu rozhrania vzdialenej procedúry generuje klientske a serverové stuby vo forme C programov.
• Knižnica XDR (eXternal Data Representation), ktorá obsahuje funkcie na transformáciu rôzne druhy dáta do strojovo nezávislej formy, čo umožňuje výmenu informácií medzi heterogénnymi systémami.
• Knižnica modulov, ktoré zabezpečujú chod systému ako celku.

Pozrime sa na príklad jednoduchej aplikácie na zaznamenávanie distribuovaných udalostí. Keď sa klient spustí, zavolá vzdialenú procedúru na zapísanie správy do súboru denníka vzdialeného počítača.

Aby ste to dosiahli, budete musieť vytvoriť aspoň tri súbory: špecifikáciu rozhraní vzdialených procedúr log.x (v jazyku popisu rozhrania), skutočný text vzdialených procedúr log.c a text hlavného klientsky program main () - client.c (v jazyku C).

Kompilátor rpcgen(l) vytvorí tri súbory na základe špecifikácie log.x: text klientskych a serverových stubov v C (log clnt.c a log svc.c) a popisný súbor log.h, ktorý používajú oba stuby. .

Poďme sa teda pozrieť na zdrojové kódy programov.

Tento súbor špecifikuje registračné parametre vzdialená procedúra - program, číslo verzie a procedúry a tiež definuje rozhranie volania - vstupné argumenty a návratové hodnoty. Je teda definovaná procedúra RLOG, ktorá berie ako argument reťazec (ktorý sa zapíše do protokolu) a návratová hodnota štandardne indikuje úspech alebo neúspech objednanej operácie.

Kompilátor rpcgen(l) vytvorí hlavičkový súbor log.h, kde sú definované najmä procedúry:

Pozrime sa pozorne na tento súbor. Kompilátor preloží názov RLOG definovaný v súbore s popisom rozhrania na rlog_1, pričom nahradí veľké písmená malými a pridá číslo verzie programu s podčiarkovníkom. Návratový typ sa zmenil z int na int*. Toto je pravidlo - RPC vám umožňuje prenášať a prijímať iba adresy parametrov deklarovaných pri popise rozhrania. Rovnaké pravidlo platí pre reťazec odovzdaný ako argument. Aj keď sa to z print.h nezdá, funkcia rlog_l() v skutočnosti odovzdá adresu reťazca ako argument.

Okrem hlavičkového súboru kompilátor rpcgen(l) vytvára moduly stub klienta a servera. Text týchto súborov v podstate obsahuje celý kód pre vzdialený hovor.

Server stub je hlavný program, ktorý spracováva všetky sieťové interakcie s klientom (presnejšie s jeho stub). Na vykonanie operácie vykoná stub servera lokálne volanie funkcie, ktorej text musí byť napísaný:

Klientsky stub prijme argument odovzdaný vzdialenej procedúre, vykoná potrebné konverzie, odošle požiadavku na portmap(1M) server, komunikuje so serverom vzdialenej procedúry a nakoniec odošle klientovi návratovú hodnotu. Pre klienta je volanie na vzdialenú procedúru zredukované na volanie na stub a nelíši sa od bežného miestneho hovoru.

klient.c

Klientsky stub log_clnt.c sa skompiluje s modulom client.c, aby vytvoril spustiteľný klientsky program.

Teraz na nejakom hostiteľskom server.nowhere.ru musíte spustiť proces servera:

Potom, keď spustíte klienta rlog na inom počítači, server pridá zodpovedajúcu položku do súboru protokolu.

Prevádzkový diagram RPC je v tomto prípade znázornený na obr. 1. Moduly sa navzájom ovplyvňujú takto:

1. Keď sa proces servera spustí, vytvorí soket UDP a naviaže akýkoľvek lokálny port na tento soket. Potom server zavolá knižničnú funkciu svc_register(3N) na registráciu čísiel a verzií programu. Na tento účel funkcia zavolá proces portmap(IM) a odovzdá požadované hodnoty. Portmap(IM) server sa zvyčajne spustí, keď je systém inicializovaný a naviaže sa na nejaký dobre známy port. Teraz portmap(3N) pozná číslo portu pre náš program a verziu. Server čaká na prijatie požiadavky. Všimnite si, že všetky popísané akcie vykonáva stub servera vytvorený kompilátorom rpcgen(IM).
2. Keď sa spustí rlog, prvá vec, ktorú urobí, je zavolať funkciu knižnice clnt_create(3N), pričom jej poskytne adresu vzdialeného systému, číslo programu a verzie a prenosový protokol. Funkcia odošle požiadavku na server mapy portov (IM) vzdialeného systému server.nowhere.m a získa číslo vzdialeného portu pre protokolový server.
3. Klient zavolá procedúru rlog_1() definovanú v klientskom stub a prenesie riadenie na stub. To zase vygeneruje požiadavku (konvertuje argumenty do formátu XDR) vo forme paketu UDP a odošle ju na vzdialený port prijatý zo servera s mapou portov (IM). Potom nejaký čas čaká na odpoveď a ak ju nedostane, odošle požiadavku znova. Za priaznivých okolností je požiadavka prijatá logger serverom (server stub module). Stub určuje, ktorá funkcia bola volaná (podľa čísla procedúry) a volá funkciu rlog_1() modulu log.c. Po návrate riadenia do stub tento konvertuje hodnotu vrátenú funkciou rlog_1() do formátu XDR a vygeneruje odpoveď tiež vo forme paketu UDP. Po prijatí odpovede klientský stub extrahuje vrátenú hodnotu, transformuje ju a vráti ju do hlavného programu klienta.

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.

Po reštarte počítača sa služba nespustila" Vzdialené volanie procedúry (RPC)". Veľa závisí od tejto služby. Výsledkom je obnovenie systému, sieťové prostredie, zvuk, Inštalátor systému Windows, konzola na správu (MMC) takmer nefunguje, na paneli úloh sa nezobrazuje 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 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 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š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 nahradením nesprávnych verzií správnymi. 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ť 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:

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 všetkým systémový disk pomocou prístupu k adresáru ako referencie. 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:

Vzdialené volanie procedúr RPC Koncept vzdialeného volania procedúr Myšlienkou vzdialeného volania procedúr (RPC) je rozšírenie 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äčšiu efektivitu využitia RPC dosahujú tie aplikácie, v ktorých dochádza k interaktívnej komunikácii medzi vzdialenými komponentmi s krátkymi časmi odozvy a relatívne malým množstvom prenášaných dát.

Takéto aplikácie sa nazývajú orientované na RPC. Charakteristickými znakmi volania lokálnych procedúr sú asymetria, to znamená, že jednou z interagujúcich strán je iniciátor Synchronicita, to znamená, že vykonávanie volacej procedúry sa zastaví od okamihu zadania požiadavky a obnoví sa až po návrate z volanej procedúry. Implementácia vzdialených hovorov je oveľa komplikovanejšia ako realizácia volaní do miestnych postupov.

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 by nemali obsahovať ukazovatele na pamäťové miesta bez zásobníka a že hodnoty parametrov by sa mali kopí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, ale implementácia RPC zahŕňa minimálne dva procesy - jeden v každom stroji.

V prípade zlyhania jednej z nich môžu nastať nasledujúce situácie: ak zlyhá volajúca procedúra, vzdialene volané procedúry osirejú a ak zlyhajú vzdialené procedúry, volajúce procedúry sa stanú osirelými rodičmi, ktorí budú márne čakať na odpoveď. 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é systémy. Základné operácie RPC Aby sme pochopili, ako RPC funguje, zvážme najprv uskutočnenie lokálneho volania procedúry na bežnom počítači, ktorý beží autonómne. 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ť volanie, volacia procedúra vloží parametre do zásobníka v opačnom poradí, ako na obrázku 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 sú parametre možno volať odkazom alebo menom alebo hodnotou. 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 volanej procedúre odovzdaný ukazovateľ na premennú, potom zmena hodnoty tejto premennej pomocou volanej procedúry znamená zmenu hodnoty tejto premennej pre volajúcu procedúru, čo je pre RPC veľmi významné. Existuje aj ďalší mechanizmus na odovzdávanie parametrov, ktorý sa v C nepoužíva. Nazýva sa obnova po kópii a spočíva v tom, že volajúci program skopíruje premenné do zásobníka ako hodnoty a potom ich skopíruje späť po vykonaní volania cez originál. hodnoty volacej procedúry.

O tom, ktorý mechanizmus odovzdávania parametrov použiť, rozhodujú vývojári jazyka. Niekedy to závisí od typu odovzdávaný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.

Ryža. 3.1. a Zásobník pred vykonaním volania čítania b Zásobník počas vykonávania procedúry c Zásobník po návrate k volajúcemu programu Myšlienkou RPC je, aby volanie vzdialenej procedúry vyzeralo čo najviac podobne ako volanie a miestny postup. Inými slovami, aby bolo RPC transparentné, volajúca procedúra nemusí vedieť, že volaná procedúra je na inom počítači a naopak RPC dosiahne transparentnosť nasledujúcim spôsobom.

Keď je volaná procedúra skutočne vzdialená, namiesto lokálnej procedúry sa do knižnice umiestni iná verzia procedúry, nazývaná klientsky stub. Podobne ako v pôvodnom postupe sa stub volá pomocou volacej sekvencie ako na obrázku 3.1 a pri prístupe k jadru dôjde k prerušeniu. Iba na rozdiel od pôvodnej procedúry neumiestňuje parametre do registrov a nepožaduje údaje od jadra, namiesto toho generuje správu, ktorá sa odošle do jadra vzdialeného počítača. Fázy vykonávania RPCInterakcia softvérové ​​komponenty pri vykonávaní vzdialeného volania procedúry je znázornené na obrázku 3.2. Keď klientský program zavolá klientsky stub, jeho prvou úlohou je naplniť vyrovnávaciu pamäť odosielanou správou.

V niektorých systémoch má klientský stub jedinú vyrovnávaciu pamäť s pevnou dĺžkou, ktorá sa napĺňa od samého začiatku pri každej novej požiadavke. V iných systémoch je vyrovnávacia pamäť správ skupina vyrovnávacích pamätí pre jednotlivé polia správ, z ktorých niektoré sú už plné.

Táto metóda je vhodná najmä pre prípady, keď má paket formát pozostávajúci z veľkého počtu polí, ale hodnoty mnohých z týchto polí sa medzi hovormi nemenia. Parametre sa potom musia previesť do príslušného formátu a vložiť do vyrovnávacej pamäte správ.V tomto momente je správa pripravená na odoslanie, takže sa vykoná prerušenie volania jadra. Ryža. 3.2. Vzdialené volanie procedúry Keď jadro získa kontrolu, prepne kontexty, uloží registre procesora a popisovače stránky mapy pamäte a nainštaluje novú mapu pamäte, ktorá sa použije na spustenie v režime jadra. Pretože kontext jadra a používateľa je odlišný, jadro musí správu presne skopírovať do vlastného adresného priestoru, aby k nej malo prístup, zapamätalo si cieľovú adresu a prípadne ďalšie polia hlavičky a musí ju odovzdať sieťovému rozhraniu.

Tým je práca na strane klienta ukončená.

Časovač prenosu je zapnutý a jadro môže buď cyklicky žiadať o odpoveď, alebo odovzdať riadenie plánovaču, ktorý vyberie na spustenie nejaký iný proces. V prvom prípade je vykonanie dotazu zrýchlené, ale absentuje multiprogramovanie. Na strane servera sú prichádzajúce bity umiestňované prijímajúcim hardvérom buď do vstavanej vyrovnávacej pamäte alebo do pamäte RAM.Po prijatí všetkých informácií sa vygeneruje prerušenie.

Obsluha prerušenia skontroluje platnosť údajov paketu a určí, ktorému stubu sa majú odovzdať. Ak paket neočakáva žiadny stub, obsluha prerušenia ho musí buď uložiť do vyrovnávacej pamäte, alebo ho úplne zahodiť. Ak existuje čakajúci útržok, správa sa doň skopíruje. Nakoniec sa vykoná kontextové prepnutie, v dôsledku čoho sa obnovia registre a pamäťová mapa, pričom sa prevezmú hodnoty, ktoré mali v okamihu, keď stub uskutočnil prijímací hovor.

Teraz začne fungovať útržok servera. Rozbalí parametre a vhodne ich vloží do zásobníka. Keď je všetko pripravené, uskutoční sa hovor na server. Po dokončení postupu server odošle výsledky klientovi, pričom sa vykonajú všetky vyššie uvedené kroky iba v opačnom poradí. Obrázok 3.3 zobrazuje postupnosť príkazov, ktoré sa musia vykonať pre každé volanie RPC, a Obrázok 3.4 ukazuje, aký podiel z celkového času vykonania RPC sa vynaloží na každý zo 14 opísaných krokov.

Výskum bol realizovaný na multiprocesore pracovná stanica DEC Firefly, a hoci prítomnosť piatich procesorov nevyhnutne ovplyvnila výsledky meraní, histogram zobrazený na obrázku poskytuje všeobecnú predstavu o procese vykonávania RPC. Ryža. 3.3. Etapy procedúry RPC Obr. 3.4. Časové rozloženie medzi 14 fázami vykonávania RPC 1. Zavolajte stub 2. Pripravte vyrovnávaciu pamäť 3. Zbalte parametre 4. Vyplňte pole hlavičky 5. Vypočítajte kontrolný súčet v správe 6. Prerušte jadro 7. Zaraďte paket do fronty na vykonanie 8. Preneste správu do riadiacej jednotky cez zbernicu QBUS 9. Čas prenosu Ethernetové siete 10. Prijmite paket z radiča 11. Postup spracovania prerušenia 12. Výpočet kontrolného súčtu 13. Prepnutie kontextu do užívateľského priestoru 14. Spustenie servera stub Dynamická väzba Zvážte otázku, ako klient špecifikuje umiestnenie servera.

Jednou z metód na vyriešenie tohto problému je priame použitie sieťovej adresy servera v klientskom programe.

Nevýhodou tohto prístupu je, že je extrémne neflexibilný pri presúvaní servera, zvyšovaní počtu serverov či zmene rozhrania, vo všetkých týchto a mnohých ďalších prípadoch je nutné prekompilovať všetky programy, ktoré využívali tvrdé nastavenie servera. Aby sa predišlo všetkým týmto problémom, niektoré distribuované systémy používajú to, čo sa nazýva dynamické prepojenie.

Východiskovým bodom pre dynamickú väzbu je formálne definovanie špecifikácie servera. Špecifikácia obsahuje názov súborového servera, číslo verzie a zoznam servisných procedúr poskytovaných týmto serverom klientom (obrázok 3.5). Pre každú procedúru je uvedený popis jej parametrov s uvedením, či je tento parameter vstupný alebo výstupný vzhľadom na server. Niektoré parametre môžu byť vstupné aj výstupné – napríklad sa upraví niektoré pole, ktoré klient odošle na server. tam a potom sa vrátil späť do klientskej operácie copy restore . Ryža. 3.5. Špecifikácia servera RPC Formálna špecifikácia servera sa používa ako vstup do programu generátora stub, ktorý vytvára stuby klienta aj servera.

Potom sa umiestnia do príslušných knižníc. Keď užívateľský klientsky program zavolá akúkoľvek procedúru definovanú v špecifikácii servera, je priradená zodpovedajúca procedúra stub binárny kód programy.

Podobne, keď je server kompilovaný, sú k nemu priradené útržky servera. Keď sa server spustí, jeho úplne prvou akciou je prenos jeho serverového rozhrania špeciálny program, nazývaný spojivo. Tento proces, známy ako proces registrácie servera, zahŕňa, že server odošle svoj názov, číslo verzie, jedinečný identifikátor a deskriptor umiestnenia servera. Deskriptor je nezávislý od systému a môže to byť IP, Ethernet, X.500 alebo nejaký iná adresa.

Okrem toho môže obsahovať ďalšie informácie, napríklad súvisiace s autentifikáciou. Keď klient po prvýkrát zavolá jednu zo vzdialených procedúr, napríklad číta, klientský stub vidí, že ešte nie je pripojený k serveru a odošle správu programu viazača so žiadosťou o import rozhrania požadovanej verzie. požadovaný server.Ak takýto server existuje, potom binder odovzdá deskriptor a jedinečný identifikátor klientovi.

Pri odosielaní správy s požiadavkou klientský stub používa ako adresu deskriptor. Správa obsahuje parametre a jedinečný identifikátor, ktorý jadro servera používa na smerovanie prichádzajúcej správy na požadovaný server, ak ich je na tomto počítači niekoľko. Tento spôsob importu a exportu rozhraní je veľmi flexibilný, napríklad môže existovať niekoľko serverov podporujúcich rovnaké rozhranie a klienti sú medzi servery rozmiestnení náhodne.

V rámci tejto metódy je možné pravidelne dotazovať servery, analyzovať ich výkon a v prípade zlyhania automatické vypnutie, čo zvyšuje celkovú odolnosť systému voči poruchám. Táto metóda môže podporovať aj autentifikáciu klienta. Server môže napríklad určiť, že ho môžu používať len klienti zo špecifického zoznamu. Dynamická väzba má však nevýhody, ako je dodatočná réžia a čas strávený exportovaním a importovaním rozhraní.

Veľkosť týchto nákladov môže byť značná, pretože mnoho klientskych procesov existuje na krátky čas a vždy, keď sa proces spustí, postup importu rozhrania sa musí vykonať znova. Okrem toho sa vo veľkých distribuovaných systémoch môže program binder stať prekážkou a vytváranie viacerých programov s rovnakým účelom tiež zvyšuje réžiu vytvárania a synchronizácie procesov Sémantika RPC v prípade zlyhania V ideálnom prípade by RPC malo fungovať správne v prípade zlyhaní.

Zvážte nasledujúce triedy zlyhania: 1. Klient nemôže nájsť server, napríklad ak požadovaný server zlyhá, alebo preto, že klientsky program bol skompilovaný už dávno a použitý stará verzia serverové rozhranie. V tomto prípade ako odpoveď na požiadavku klienta je prijatá správa obsahujúca chybový kód. 2. Požiadavka od klienta na server bola stratená Najjednoduchším riešením je zopakovať požiadavku po určitom čase. 3. Správa odpovede zo servera klientovi sa stratí.

Táto možnosť je zložitejšia ako predchádzajúca, pretože niektoré postupy nie sú idempotentné. Idempotentný postup je postup, ktorého žiadosť o vykonanie možno niekoľkokrát opakovať bez zmeny výsledku. Príkladom takéhoto postupu je čítanie súboru, ale postup výberu určitej sumy z bankového účtu nie je idempotentný a pri strate odpovede môže opakovaná požiadavka výrazne zmeniť stav klientskeho účtu.

Jedným z možných riešení je urobiť všetky postupy idempotentnými. V praxi to však nie je vždy možné, preto je možné použiť iný spôsob – postupné číslovanie všetkých požiadaviek klientskym jadrom. Jadro servera si pamätá číslo poslednej požiadavky od každého klienta a po prijatí každej požiadavky analyzuje, či ide o primárnu alebo opakovanú požiadavku. 4. Po prijatí požiadavky došlo k zlyhaniu servera, dôležitá je aj vlastnosť idempotency, ale bohužiaľ nie je možné použiť prístup s číslovaním požiadaviek.

V tomto prípade je dôležité, kedy k poruche došlo – pred operáciou alebo po nej. Ale klientske jadro nedokáže rozpoznať tieto situácie, vie len, že čas odozvy vypršal. Existujú tri prístupy k tomuto problému: Počkajte, kým sa server reštartuje a skúste operáciu zopakovať.Tento prístup zabezpečí, že RPC sa dokončí aspoň raz a možno aj viackrát. Okamžite nahláste chybu aplikácii.

Tento prístup zabezpečuje, že RPC sa vykoná maximálne raz. Tretí prístup nič nezaručuje. Keď server zlyhá, klientovi sa neposkytuje žiadna podpora. RPC sa nemusí spustiť vôbec alebo sa môže spustiť mnohokrát. V každom prípade je táto metóda veľmi jednoduchá na implementáciu. Ani jeden z týchto prístupov nie je veľmi atraktívny a ideálna možnosť by bola taká, ktorá by garantovala práve jeden vykonanie RPC, vo všeobecnom prípade nemožno zo zásadných dôvodov realizovať.

Napríklad vzdialenou operáciou je tlač nejakého textu, ktorá zahŕňa načítanie vyrovnávacej pamäte tlačiarne a nastavenie jedného bitu v niektorom riadiacom registri tlačiarne, v dôsledku čoho sa tlačiareň spustí. Zlyhanie servera môže nastať mikrosekundu pred alebo mikrosekundu po nastavení riadiaceho bitu. Okamžik zlyhania úplne určuje postup obnovy, ale klient sa o momente zlyhania nemôže dozvedieť.

Stručne povedané, možnosť zlyhania servera radikálne mení povahu RPC a jasne odráža rozdiel medzi centralizovaným a distribuovaným systémom. V prvom prípade zlyhanie servera vedie k zlyhaniu klienta a obnovenie nie je možné. V druhom prípade je možné a potrebné vykonať akcie obnovy systému. 1. Klient sa po odoslaní požiadavky zrútil. V tomto prípade sa výpočty vykonávajú s výsledkami, ktoré nikto neočakáva. Takéto výpočty sa nazývajú sirotské výpočty. Prítomnosť sirôt môže spôsobiť rôzne problémy: réžiu času CPU, blokovanie zdrojov, nahradenie odpovede na aktuálnu požiadavku odpoveďou na požiadavku, ktorá bola zadaná klientským počítačom pred reštartom systému.

Ako sa vysporiadať so sirotami? Zvážte 4 možné riešenia. Zničenie. Pred odoslaním správy RPC klient zaznamená do protokolu, čo bude robiť ďalej. Protokol je uložený na disku alebo v inej pamäti odolnej voči chybám.

Po nehode sa systém reštartuje, protokol sa analyzuje a siroty sa eliminujú. Nevýhody tohto prístupu zahŕňajú po prvé zvýšenú réžiu spojenú so zápisom každého RPC na disk a po druhé, možnú neefektívnosť v dôsledku objavenia sa sirôt druhej generácie generovaných volaniami RPC vydanými sirotami prvej generácie. Reinkarnácia.V tomto prípade sú všetky problémy vyriešené bez použitia nahrávania na disk. Metóda pozostáva z rozdelenia času do postupne očíslovaných období. Keď sa klient reštartuje, odošle správu všetkým počítačom, aby oznámil začiatok nového obdobia.

Po prijatí tejto správy sú všetky vzdialené výpočty eliminované. Samozrejme, ak je sieť segmentovaná, niektoré siroty môžu prežiť. Mäkká reinkarnácia je podobná ako v predchádzajúcom prípade, s tým rozdielom, že nie sú nájdené a zničené všetky vymazané výpočty, ale iba výpočty reštartujúceho klienta. Platnosť Každá žiadosť má štandardnú lehotu T, v rámci ktorej musí byť dokončená.

Ak sa žiadosť nedokončí v stanovenom čase, pridelí sa dodatočné množstvo. Aj keď si to vyžaduje ďalšiu prácu, ak po zlyhaní klienta server čaká na interval T pred reštartovaním klienta, potom sú všetky siroty nevyhnutne zničené. V praxi nie je žiaduci ani jeden z týchto prístupov, v skutočnosti môže zničenie sirôt situáciu ešte zhoršiť. . Predpokladajme napríklad, že sirota zamkla jeden alebo viac databázových súborov.

Ak je sirota náhle zničená, tak tieto zámky zostanú, navyše zničené siroty môžu zostať stáť v rôznych systémových frontoch, v budúcnosti môžu spôsobiť spustenie nových procesov atď.

Čo urobíme s prijatým materiálom:

Ak bol tento materiál pre vás užitočný, môžete si ho uložiť na svoju stránku v sociálnych sieťach: