Volání vzdálených procedur. Nástroj pro vzdálené volání procedur - RPC Co je vzdálené volání procedur rpc

Engine pro vzdálené volání procedur - RPC

Programy komunikující po síti vyžadují komunikační mechanismus. Na nižší úrovni, po příchodu paketů, je signál zpracován programem pro zpracování síťového signálu. Na nejvyšší úrovni funguje mechanismus setkání (rendezvous), který byl přijat v jazyce Ada. NFS používá mechanismus vzdáleného volání procedur (RPC), ve kterém klient komunikuje se serverem (viz obrázek 1). V souladu s tímto procesem klient nejprve přistupuje k proceduře, která odešle požadavek na server. Po příchodu paketu s požadavkem server zavolá proceduru pro jeho otevření, provede požadovanou službu, odešle odpověď a klientovi se vrátí řízení.

Rozhraní RPC lze považovat za rozhraní se třemi vrstvami:

Horní úroveň je zcela průhledná. Program na této úrovni může například volat rnusers (), který vrací počet uživatelů na vzdáleném počítači. O použití mechanismu RPC nemusíte vědět, protože provádíte hovor v programu.

Střední vrstva je pro nejběžnější aplikace. Volání RPC na této úrovni zpracovávají rutiny registerrpc () a callrpc (): registerrpc () přijímá tmavý kód celého systému a callrpc () provádí vzdálené volání procedury. Volání rnusers () je implementováno pomocí těchto dvou rutin.

Nižší úroveň se používá pro složitější úkoly a mění výchozí hodnoty hodnot parametrů procedury. Na této úrovni můžete explicitně manipulovat se sokety používanými k přenosu zpráv RPC.

Obecně platí, že byste měli používat horní vrstvu a zbytečně nepoužívat spodní vrstvy.

Navzdory skutečnosti, že v této příručky rozhraní považujeme pouze v jazyce C, přístup ke vzdáleným postupům lze provést z jakéhokoli jazyka. Práce mechanismu RPC pro organizaci komunikace mezi procesy na různá auta se neliší od jeho práce na jednom stroji.

RPC (Remote Procedure Call) je rozhraní mezi vzdálenými uživateli a konkrétními hostitelskými programy, které se spouští na žádost těchto uživatelů. Služba RPC pro hostitele obvykle poskytuje klientům sadu programů. Každý z těchto programů se zase skládá z jedné nebo více vzdálených procedur. Například služba vzdáleného systému souborů NFS, která je postavena na voláních RPC, může sestávat pouze ze dvou programů: například jeden program komunikuje s vysokou úrovní uživatelská rozhraní a druhý s nízkoúrovňovými I / O funkcemi.

Každé volání RPC zahrnuje dvě strany: aktivního klienta, který odešle požadavek na volání procedury na server, a server, který odešle odpověď klientovi.

Poznámka. Upozorňujeme, že výrazy „klient“ a „server“ v tomto případě odkazují na konkrétní transakci. Konkrétní hostitel nebo software (proces nebo program) může fungovat v rolích klienta i serveru. Například program, který poskytuje službu vzdálené procedury, může být současně klientem síťového systému souborů.

RPC je postaveno na vzdáleném modelu volání procedury, který je podobný místním voláním procedur. Když zavoláte místní proceduru, odešlete argumenty do konkrétního umístění paměti, zásobníku nebo proměnných prostředí a přenesete řízení procesu na konkrétní adresu. Po dokončení práce si přečtete výsledky na konkrétní adrese a pokračujete v procesu.

V případě vzdálené procedury je hlavní rozdíl v tom, že volání vzdálené funkce obsluhují dva procesy: klientský proces a serverový proces.

Proces klienta odešle na server zprávu, která obsahuje parametry volané procedury a čeká na zprávu s odpovědí s výsledky své práce. Po přijetí odpovědi se načte výsledek a proces pokračuje. Na straně serveru je proces obsluhy volání ve stavu čekání a když přijde zpráva, přečte parametry procedury, provede ji, odešle odpověď a stane se ve stavu čekání na další volání.

Protokol RPC neukládá žádné požadavky na další připojení mezi procesy a nevyžaduje synchronizaci prováděných funkcí, to znamená, že volání mohou být asynchronní a nezávislá, aby klient mohl během čekání na odpověď provádět další postupy. Server RPC může pro každou funkci přidělit samostatný proces nebo virtuální stroj, a proto bez čekání na dokončení předchozích požadavků může okamžitě přijmout další.

Existuje však několik důležitých rozdílů mezi místními a vzdálenými voláními procedur:

1. Chyba při zpracování. Klient by měl být v každém případě upozorněn na chyby, ke kterým dochází při volání vzdálených procedur na serveru nebo v síti.

2. Globální proměnné. Protože server nemá přístup do adresního prostoru klienta, nemůžete použít vzdálené volání procedur skryté parametry ve formě globálních proměnných.

3. Výkon. Rychlost provádění vzdálených procedur je zpravidla o jeden nebo dva řády nižší než rychlost provádění podobných místních procedur.

4. Ověření. Protože se vzdálená volání procedur vyskytují v síti, je nutné použít mechanismy autentizace klienta.

Zásady konstrukce protokolu.

Protokol RPC může používat několik různých transportních protokolů. Jedinou odpovědností protokolu RPC je prosazování standardů a interpretace přenosu zpráv. Spolehlivost a spolehlivost přenosu zpráv je zcela zajištěna transportní vrstvou.

RPC však může řídit výběr a některé funkce transportního protokolu. Jako příklad interakce mezi RPC a transportním protokolem zvažte postup přiřazení portu RPC aplikačnímu procesu prostřednictvím RPC - Portmapper.

Tato funkce dynamicky (na vyžádání) přiřadí konkrétní port připojení RPC. Funkce Portmapper se používá poměrně často, protože sada transportních portů vyhrazených pro RPC je omezená a počet procesů, které mohou potenciálně běžet současně, je velmi vysoký. Portmapper například volána, když jsou vybrány komunikační porty NFS klient / server.

Servis Portmapper využívá vysílací mechanismus RPC ke konkrétnímu portu - III. Na tomto portu klient vysílá požadavek na port konkrétní služby RPC. Servis Portmapper zpracuje daňovou zprávu, určí adresu místní služby RPC a odešle odpověď klientovi. Služba RPC Portmapper může pracovat s protokoly TCP i UDP.

RPC může pracovat s různými transportními protokoly, ale nikdy neduplikuje jejich funkce, to znamená, že pokud RPC běží nad TCP, RPC klade veškeré obavy ohledně spolehlivosti a spolehlivosti připojení na TCP. Pokud je však RPC nainstalován nad UDP, může poskytovat další nativní funkce, aby bylo zajištěno doručení zpráv.

Poznámka. Aplikace si mohou protokol RPC představit jako definovanou proceduru volání funkce přes síť JSR (Jump Subroutine Instruction).

Aby protokol RPC fungoval, musí být splněny následující podmínky:

1. Jedinečná identifikace všech vzdáleně volaných procedur na daném hostiteli. Požadavky RPC obsahují tři pole identifikátorů - číslo vzdáleného programu (služby), číslo verze vzdáleného programu a číslo vzdálené procedury zadaného programu. Číslo programu přiděluje výrobce služby, číslo procedury označuje konkrétní funkci této služby

2. Identifikace verze protokolu RPC. Zprávy RPC obsahují pole verze protokolu RPC. Používá se k porovnání formátů přenášených parametrů, když klient pracuje s různými verzemi RPC.

3. Poskytování mechanismů pro autentizaci klienta na server. Protokol RPC poskytuje postup pro autentizaci klienta ve službě a v případě potřeby s každým požadavkem nebo odesláním odpovědi klientovi. RPC navíc umožňuje různé další bezpečnostní mechanismy.

RPC může používat čtyři typy ověřovacích mechanismů:

AUTH_NULL - není použito žádné ověřování

AUTH_UNIX - standardní autentizace UNIX

AUTH_SHORT - UNIX autentizace s vlastní strukturou kódování

AUTH_DES - ověřování DES

4. Identifikace odpovědí na odpovídající požadavky. Zprávy s odpověďmi RPC obsahují ID požadavku, na kterém byly založeny. Tento identifikátor lze nazvat identifikátor transakce volání RPC. Tento mechanismus je zvláště užitečný při práci v asynchronním režimu a při provádění sekvence několika volání RPC.

5. Identifikace chyb protokolu. Všechny chyby v síti nebo na serveru mají jedinečné identifikátory, pomocí kterých může každý z účastníků připojení určit příčinu selhání.

Struktury zpráv protokolu

Při přenosu zpráv RPC přes transportní protokol lze v jednom transportním paketu umístit několik zpráv RPC. Aby bylo možné odlišit jednu zprávu od druhé, používá se značka záznamu (RM - Record Marker). Každá zpráva RPC je „označena“ přesně jedním RM.

Zpráva RPC může být složena z několika fragmentů. Každý blok se skládá ze čtyř bajtů záhlaví a (0 až 2 ** 31-1) dat. První bit záhlaví označuje, zda je blok poslední, a zbývajících 31 bitů označuje délku datového paketu.

Struktura RPC je formálně popsána v jazyce popisu a reprezentace datových formátů - XDR s dodatky týkajícími se popisu postupů. Můžete dokonce říci, že značkovací jazyk RPC je rozšířením XDR, doplněným prací s postupy.

Struktura balíčku RPC vypadá takto:

struct rpc_msg (

unsigned int xid;

sjednocující přepínač (msg_type mtype) (

call_body cbody;

tělo odpovědi rbody;

kde xid je identifikátor aktuální transakce, call_body je paket požadavku, response_body je paket odpovědí. Struktura požadavku vypadá asi takto:

struktura volání těla (

unsigned int rpcvers;

unsigned int prog;

nepodepsaný int vers;

unsigned int proc;

opaque_auth cred;

opaque_auth verf;

/ * parametry postupu * /

Struktura response_body může obsahovat buď strukturu předanou v případě chyby (v takovém případě obsahuje chybový kód), nebo strukturu pro úspěšné zpracování požadavku (v takovém případě obsahuje vrácená data).

Programovací rozhraní na vysoké úrovni.

Použití podprogramů v programu je tradičním způsobem, jak úkol strukturovat, aby byl přehlednější. Nejčastěji používané podprogramy se shromažďují v knihovnách, kde je lze použít v různých programech. V tomto případě mluvíme o místním (místním) volání, tj. Jak volající, tak volané objekty fungují ve stejném programu na stejném počítači.

V případě vzdáleného volání proces spuštěný na jednom počítači spustí proces na vzdáleném počítači (to znamená, že ve skutečnosti spustí kód procedury na vzdáleném počítači). Je zřejmé, že vzdálené volání procedury se výrazně liší od tradičního místního volání, ale z pohledu programátora takové rozdíly prakticky neexistují, to znamená, že architektura vzdáleného volání procedury umožňuje simulovat místní volání.

Pokud však v případě místního volání program předá parametry volané proceduře a obdrží výsledek své práce přes oblasti zásobníku nebo sdílené paměti, pak se v případě vzdáleného volání přenos parametrů změní na přenos požadavku po síti a výsledek práce je v přijaté odpovědi.

Tento přístup je možným základem pro vytváření distribuovaných aplikací, i když jich je mnoho moderní systémy nepoužívejte tento mechanismus, základní pojmy a termíny jsou v mnoha případech zachovány. Při popisu mechanismu RPC budeme tradičně označovat volající proces jako klienta a vzdálený proces, který implementuje proceduru jako server.

Vzdálené volání procedury zahrnuje následující kroky:

1. Klientský program provede místní volání procedury zvané stub. V tomto případě se klient „zdá“, že voláním pahýlu skutečně zavolá proceduru serveru. Ve skutečnosti klient předá požadované parametry útržku a vrátí výsledek. To však není přesně to, jak si to klient představuje. Úkolem útržku je přijmout argumenty pro vzdálenou proceduru, případně je převést na některé standardní formát a vytvořit požadavek na síť. Balení argumentů a vytvoření síťového požadavku se nazývá zařazování.

2. Síťový požadavek je odeslán přes síť na adresu vzdálený systém... K tomu stub používá příslušná volání, například volání popsaná v předchozích částech. V tomto případě lze použít různé transportní protokoly, nejen rodinu TCP / IP.

3. Na vzdáleném hostiteli se vše děje v opačném pořadí. Útržek serveru čeká na požadavek a po přijetí načte parametry - argumenty volání procedury. Extrakce (unmarshalling) může zahrnovat nezbytné převody (například změna pořadí bajtů).

4. Útržek zavolá skutečné proceduře serveru, na kterou je adresován požadavek klienta, a předá mu argumenty přijaté po síti.

5. Po dokončení procedury se ovládací prvek vrátí do stubu serveru a předá mu požadované parametry. Jako útržek klienta; stub serveru převede hodnoty vrácené procedurou a vytvoří zprávu síťové odpovědi, která se pošle přes síť do systému, ze kterého požadavek přišel.

6. Operační systém předá přijatou zprávu klientovi, který po nezbytné transformaci předá hodnoty (což jsou hodnoty vrácené vzdálenou procedurou) klientovi, který to interpretuje jako normální návrat z postupu.

Z pohledu klienta tedy provádí vzdálené volání procedur, jako by to bylo pro místní. Totéž lze říci o serveru: procedura se volá standardním způsobem, objekt (stub serveru) zavolá lokální proceduru a přijme jí vrácené hodnoty. Klient zachází se stubem jako s volatelnou procedurou serveru a server interpretuje svůj vlastní stub jako klienta.

Útržky tedy tvoří jádro systému RPC, které je odpovědné za všechny aspekty generování a přenosu zpráv mezi klientem a vzdáleným serverem (procedura), ačkoli klient i server předpokládají, že jsou hovory prováděny lokálně. Toto je základní koncept RPC - úplně skrýt distribuovanou (síťovou) povahu komunikace v kódu stubu. Výhody tohoto přístupu jsou zřejmé: klient i server jsou nezávislé na síťové implementaci, oba fungují v rámci nějakého distribuovaného virtuální stroj a volání procedur mají standardní rozhraní.

Předávání parametrů

Předávání hodnotových parametrů je jednoduché. V tomto případě klientský stub umístí hodnotu parametru do síťového požadavku, případně provede převody do standardního formuláře (například změna pořadí bajtů). Situace s předáváním ukazatelů je mnohem komplikovanější, když je parametrem adresa dat, a nikoli jejich hodnota. Předání adresy v požadavku nemá smysl, protože vzdálená procedura se provádí ve zcela jiném adresním prostoru. Nejjednodušším řešením RPC je zabránit klientům v předávání parametrů jinak než podle hodnoty, i když to určitě znamená vážná omezení.

Vazba

Než může klient volat vzdálenou proceduru, musí se svázat se vzdáleným systémem, který je hostitelem požadovaného serveru. Úkol propojení je tedy rozdělen na dva:

Nalezení vzdáleného hostitele s požadovaným serverem

Nalezení požadovaného procesu serveru na daném hostiteli

K nalezení hostitele lze použít různé přístupy. Možnou možností je vytvoření nějakého centralizovaného adresáře, ve kterém hostitelé oznamují své servery, a kde si klient může v případě potřeby vybrat vhodnou adresu hostitele a procedury.

Každá procedura RPC je jednoznačně identifikována číslem programu a procedury. Číslo programu definuje skupinu vzdálených procedur, z nichž každá má své vlastní číslo. Každému programu je také přiděleno číslo verze, takže při drobných změnách programu (například při přidání procedury) není nutné měnit jeho číslo. Obvykle je v jednom programovém modulu implementováno několik funkčně podobných postupů, které se po spuštění stanou serverem těchto postupů a který je identifikován číslem programu.

Když tedy chce klient volat vzdálenou proceduru, potřebuje znát čísla programů, verzí a procedur, které poskytují požadovanou službu.

K předání požadavku musí klient také vědět síťová adresačíslo hostitele a portu spojené s programem serveru, který poskytuje požadované postupy. To se provádí pomocí démona portmap (IM) (v některých systémech nazývaného rpcbind (IM)). Démon běží na hostiteli, který poskytuje službu vzdálené procedury, a používá známé číslo portu. Když se proces serveru inicializuje, zaregistruje své rutiny a čísla portů v portmap (IM). Nyní, když klient potřebuje znát číslo portu pro volání určité procedury, odešle požadavek na server portmap (IM), který zase vrátí číslo portu, nebo přesměruje požadavek přímo na server RPC a vrátí odpověď klientovi při spuštění. V každém případě, pokud požadovaný postup existuje, klient obdrží číslo portu procedury ze serveru portmap (IM) a další požadavky lze odeslat přímo na tento port.

Zpracování výjimek

Zpracování výjimek při volání místních procedur není nijak zvlášť problematické. UNIX zpracovává chyby procesu, jako je dělení nulou, neplatný přístup do paměti atd. Volání vzdálené procedury zvyšuje pravděpodobnost chybových situací. Přidány na server a chyby stubu jsou chyby související například s přijetím chybné zprávy v síti.

Například při použití UDP jako transportního protokolu se zprávy znovu vysílají po zadaném časovém limitu. Pokud se po určitém počtu pokusů neobdrží odpověď ze serveru, vrátí se klientovi chyba. V případě, že se používá protokol TCP, vrátí se klientovi chyba, pokud server ukončil připojení TCP.

Volejte sémantiku

Volání místní procedury jednoznačně vede k jejímu provedení, po kterém se ovládací prvek vrátí do hlavního programu. Při volání vzdálené procedury je situace jiná. Není možné určit, kdy přesně bude postup proveden, zda bude vůbec proveden, a pokud ano, kolikrát? Například pokud vzdálený systém přijme požadavek poté, co se serverový program neobvykle ukončí, procedura nebude provedena vůbec. Pokud klient poté, co neobdrží odpověď po určité době (timeout), znovu odešle požadavek, pak může nastat situace, kdy je odpověď již přenášena po síti a opakovaný požadavek je znovu přijat ke zpracování vzdálený postup. V takovém případě bude postup proveden několikrát.

Provedení vzdálené procedury lze tedy charakterizovat následující sémantikou:

- Jednou a jen jednou. Toto chování (v některých případech nejžádanější) je obtížné vynutit kvůli možnému selhání serveru.

- Maximální časy. To znamená, že procedura nebyla provedena vůbec, nebo byla provedena pouze jednou. Podobné prohlášení lze učinit, když je místo normální odpovědi přijata chyba.

- Alespoň jednou. Procedura byla pravděpodobně provedena jednou, ale je možné více. Pro normální provoz v takové situaci musí mít vzdálená procedura vlastnost idempotency (z anglického idemponent). Tato vlastnost je vlastněna procedurou, jejíž opakované provádění nezpůsobí kumulativní změny. Například čtení souboru je idempotentní, ale přidání textu do souboru nikoli.

Prezentace dat

Když klient a server běží ve stejném systému na stejném počítači, nedochází k žádným problémům s nekompatibilitou dat. Binární data jsou pro klienta i server reprezentována stejným způsobem. V případě vzdáleného volání to komplikuje skutečnost, že klient a server mohou běžet na systémech s různými architekturami s různými reprezentacemi dat (například reprezentace s plovoucí desetinnou čárkou, pořadí bajtů atd.)

Většina implementací RPC definuje určité standardní zastoupení dat, na které musí být převedeny všechny hodnoty předávané v požadavcích a odpovědích.

Například formát pro reprezentaci dat v RPC od Sun Microsystems je následující:

Byte Order - Nejvýznamnější - Poslední

Reprezentace s plovoucí desetinnou čárkou - IEEE

Reprezentace znaků - ASCII

Z hlediska funkčnosti je systém RPC prostředníkem mezi aplikační vrstvou a transportní vrstvou. V souladu s OSI model tato pozice odpovídá úrovním prezentace a relace. RPC je tedy teoreticky nezávislý na implementaci v síti, zejména na síťových protokolech transportní vrstvy.

Softwarové implementace systému zpravidla podporují jeden nebo dva protokoly. Například systém RPC Sun Microsystems podporuje zasílání zpráv pomocí protokolů TCP a UDP. Volba jednoho nebo druhého protokolu závisí na požadavcích aplikace. Volba UDP je oprávněná pro aplikace s následujícími charakteristikami:

Volané procedury jsou idempotentní

Velikost předaných argumentů a výsledek vrácení je menší než velikost paketu UDP - 8 kB.

Server poskytuje práci s několika stovkami klientů. Protože při práci s protokoly TCP je server nucen udržovat spojení s každým z aktivních klientů, zabírá to významnou část jeho prostředků. UDP je v tomto ohledu méně náročné na zdroje.

Na druhou stranu TCP poskytuje efektivní provoz aplikací s následujícími charakteristikami:

Aplikace vyžaduje spolehlivý přenosový protokol

Volané postupy nejsou identické

Argumenty nebo vrácený výsledek je větší než 8 kB

Volba protokolu obvykle zůstává na klientovi a systém organizuje tvorbu a přenos zpráv různými způsoby. Při použití protokolu TCP, pro který jsou přenášená data proudem bajtů, je tedy nutné zprávy od sebe oddělit. K tomu se například používá protokol označování záznamů popsaný v RFC1057 „RPC: Specifikace protokolu vzdáleného volání procedur verze 2“, který předchází každé zprávě 32bitové celé číslo určující velikost zprávy v bajtech.

Situace je jiná se sémantikou hovoru. Například pokud se RPC provádí pomocí nespolehlivého transportního protokolu (UDP), systém zprávu znovu vysílá v krátkých intervalech (časové limity). Pokud klientská aplikace neobdrží odpověď, lze s jistotou říci, že procedura byla provedena nula nebo vícekrát. Pokud byla přijata odpověď, může aplikace dojít k závěru, že postup byl proveden alespoň jednou. Při použití spolehlivého transportního protokolu (TCP) lze v případě přijetí odpovědi říci, že procedura byla provedena jednou. Pokud není přijata žádná odpověď, nelze s jistotou říci, že postup nebyl proveden3.

Jak to funguje?

Skutečný systém RPC je v podstatě zabudován do klientského programu a serveru. Je potěšitelné, že při vývoji distribuovaných aplikací se nemusíte zabývat podrobnostmi zpracování protokolu RPC nebo zpracování zpráv programu. Systém předpokládá existenci vhodného vývojového prostředí, které výrazně usnadňuje život tvůrcům aplikačního softwaru. Jedním z klíčových bodů RPC je, že vývoj distribuované aplikace začíná definicí rozhraní objektu - formálním popisem funkcí serveru, vytvořeným ve speciálním jazyce. Z tohoto rozhraní se pak automaticky generují klientské a serverové pahýly. Jedinou věcí, kterou je třeba udělat, je napsat skutečný kód procedury.

Jako příklad zvažte RPC od společnosti Sun Microsystems. Systém se skládá ze tří hlavních částí:

Rpcgen (1) je kompilátor RPC, který generuje klientské a serverové pahýly jako programy C na základě popisu rozhraní vzdálené procedury.

Knihovna XDR (eXternal Data Representation), která obsahuje funkce pro transformaci odlišné typy data ve strojově nezávislé formě, která umožňuje výměnu informací mezi heterogenními systémy.

Knihovna modulů, které zajišťují provoz systému jako celku.

Podívejme se na příklad základní distribuované aplikace pro protokolování událostí. Klient při spuštění volá vzdálenou proceduru, aby zapsal zprávu do souboru protokolu vzdálený počítač.

K tomu budete muset vytvořit alespoň tři soubory: specifikaci rozhraní vzdálených procedur log.x (v jazyce popisu rozhraní), vlastní text vzdálených procedur log.c a text hlavní program klienta main () - client.c (v jazyce C).

Kompilátor rpcgen (l) generuje tři soubory na základě specifikace log.x: klientské a serverové stuby C (log clnt.c a log svc.c) a definiční soubor log.h používaný oběma stuby.

Zvažme to zdrojové texty programy.

Tento soubor určuje registrační parametry vzdálené procedury - program, verzi a čísla procedur - a definuje volající rozhraní - vstupní argumenty a návratové hodnoty. Je tedy definována procedura RLOG, která bere jako argument řetězec (který se zapíše do protokolu) a návratová hodnota ve výchozím nastavení označuje úspěch nebo neúspěch objednané operace.

program LOG_PROG (

verze LOG_VER (

int RLOG (řetězec) = 1;

) = 0x31234567;

Kompilátor rpcgen (l) generuje soubor záhlaví log.h, kde jsou definovány zejména postupy:

log.h

* Tento soubor prosím neupravujte.

* Byl vygenerován pomocí rpcgen.

#ifndef _LOG_H_RPCGEN

#define _LOG_H_RPCGEN

#zahrnout

/ * Číslo programu * /

#define LOG_PROG ((bez znaménka dlouho) (0x31234567))

#define LOG_VER ((unsigned long) (1)) / * Číslo verze * /

#define RLOG ((unsigned long) (1)) / * rutinní číslo * /

extern int * rlog_l ();

/ * Interní procedura - nebudeme ji muset používat * / extern int log_prog_l_freeresult ();

#endif / *! _LOG_H_RPCGEN * /

Podívejme se na tento soubor blíže. Překladač převádí název RLOG definovaný v deskriptoru rozhraní na rlog_1, nahrazuje velká písmena malými písmeny a přidává číslo verze programu podtržítkem. Typ návratu se změnil z int na int *. Toto je pravidlo - RPC umožňuje odesílat a přijímat pouze adresy parametrů deklarovaných při popisu rozhraní. Stejné pravidlo platí pro řetězec předaný jako argument. Ačkoli to ze souboru print.h nevyplývá, ve skutečnosti je adresa řádku předána také jako argument funkci rlog_l ().

Kromě souboru záhlaví generuje kompilátor rpcgen (l) klientský modul a serverový modul. Text těchto souborů v zásadě obsahuje veškerý kód vzdáleného volání.

Serverový pahýl je hlavní program, který zpracovává veškerou síťovou interakci s klientem (přesněji s jeho pahýlem). Chcete-li provést operaci, stub serveru provede místní volání funkce, jejíž text musí být napsán:

log.c

#zahrnout

#include "log.h"

int * rlog_1 (char ** arg)

/ * Návratová hodnota musí být definována jako statická * /

statický výsledek int;

int fd; / * Deskriptor souboru protokolu * /

/ * 0 otevřete soubor protokolu (vytvořte jej, pokud neexistuje), v případě selhání vraťte výsledek chybového kódu == 1. * /

if ((fd = open ("./ server .log",

O_CREAT | O_RDWR | O_APPEND))< 0) return (&result);

len = strlen (* arg);

if (write (fd, * arg, strlen (* arg))! = len)

návrat (& výsledek); / * Vrátit výsledek - výsledek adresy * /

Klientský stub vezme argument předaný vzdálené proceduře, provede potřebné transformace, vydá požadavek na server portmap (1M), komunikuje se vzdáleným serverem procedur a nakonec předá klientovi návratovou hodnotu. Pro klienta je vzdálené volání procedur volání se zakázaným inzerováním a nijak se neliší od běžného místního volání.

klient.c

#zahrnout

#include "log.h"

main (int argc, char * argv)

char * server, * mystring, * clnttime;

if (argc! = 2) (

fprintf (stderr, "Formát volání:% s adresa_hostitele \ n",

/ * Získejte deskriptor klienta. V případě poruchy vás budeme informovat o

nemožnost navázání spojení se serverem * /

if ((с1 = clnt_create (server,

LOG_PROG, LOG_VER, "udp")) == NULL) (

clnt_pcreateerror (server);

/ * Přidělte vyrovnávací paměť pro řetězec * /

mystring = (char *) malloc (100);

/ * Určete čas události * /

bintime = time ((time_t *) NULL);

clnttime = ctime (& bintime);

sprintf (mystring, "% s - klient spuštěn", clnttime);

/ * Pošleme zprávu pro protokol - čas, kdy klient začal pracovat. V případě poruchy nahlásíme chybu * /

if ((result = rlog_l (& mystring, cl)) == NULL) (

fprintf (stderr, "chyba2 \ n");

clnt_perror (cl, server);

/ * V případě poruchy na vzdáleném počítači nahlásíme chybu * /

if (* výsledek! = 0)

fprintf (stderr, "Chyba při zápisu do protokolu \ n");

/ * 0 uvolněte deskriptor * /

cint zničit (cl);

Klientský stub log_clnt.c je zkompilován s modulem client.c, aby získal spustitelný soubor klienta.

cc -o rlog client.c log_clnt.c -Insl

Stub serveru log_svc.c a rutina log.c jsou zkompilovány, aby se server spustil.

cc -o logger log_svc.c log.c -Insl

Nyní na nějakém hostitelském serveru.nowhere.ru musíte spustit proces serveru:

Poté, když je klient rlog spuštěn na jiném počítači, server přidá odpovídající položku do souboru protokolu.

Schéma provozu RPC je v tomto případě znázorněno na obr. 1. Moduly interagují následovně:

1. Po spuštění procesu serveru vytvoří soket UDP a na tento soket naváže libovolný místní port. Server poté zavolá funkci knihovny svc_register (3N), aby zaregistroval čísla programů a čísla verzí. K tomu funkce zavolá proces portmap (IM) a předá požadované hodnoty. Server portmap (IM) se obvykle spouští při inicializaci systému a váže se na nějaký známý port. Portmap (3N) nyní zná číslo portu pro náš program a verzi. Server čeká na přijetí požadavku. Všimněte si, že všechny popsané akce provádí stub serveru vytvořený kompilátorem rpcgen (IM).

2. Když se spustí rlog, první věc, kterou udělá, je volání funkce knihovny clnt_create (3N), která mu dá adresu vzdáleného systému, čísla programu a verze a transportní protokol. Funkce odešle požadavek na server portmap (IM) serveru vzdáleného systému.nowhere.m a získá číslo vzdáleného portu pro server protokolu.

3. Klient zavolá rutinu rlog_1 () definovanou v klientském stubu a předá řízení do stubu. To zase vytvoří požadavek (převod argumentů do formátu XDR) ve formě paketu UDP a předá jej na vzdálený port přijatý ze serveru portmap (IM). Poté nějakou dobu čeká na odpověď a pokud není přijata, znovu odešle požadavek. Za příznivých okolností je požadavek přijat serverem protokolování (modul stub serveru). Útržek identifikuje, která funkce byla volána (podle čísla procedury), a volá funkci rlog_1 () modulu log.c. Poté, co se ovládací prvek vrátí zpět do stubu, stub převede hodnotu vrácenou funkcí rlog_1 () do formátu XDR a vytvoří odpověď také ve formě paketu UDP. Po obdržení odpovědi klientský stub načte vrácenou hodnotu, transformuje ji a vrátí ji hostiteli klienta.

Mechanismus zásuvky

Mechanismus soketů se poprvé objevil ve verzi 4.3 BSD UNIX (Berkeley Software Distribution UNIX - pobočka UNIX, která se začala vyvíjet na Kalifornské univerzitě v Berkeley). Později se vyvinul v jeden z nejpopulárnějších systémů pro zasílání zpráv v síti. Dnes je tento mechanismus implementován v mnoha operačních systémech, někdy se stále nazývá Berkeley Sockets, což vzdává hold jeho tvůrcům, ačkoli existuje velké množství jeho implementací jak pro různé OS rodiny UNIX, tak pro jiné OS, například pro OS Rodina Windows kde se nazývá Windows Sockets (WinSock).

Mechanismus soketu poskytuje pohodlné a přiměřeně obecné rozhraní pro zasílání zpráv pro vývoj síťově distribuovaných aplikací. Následující koncepty poskytují jeho univerzálnost.

Nezávislost na základních síťových protokolech a technologiích. K tomu se používá termín komunikační doména. Komunikační doména má určitou sadu komunikačních vlastností, které určují způsob pojmenování síťových uzlů a zdrojů, vlastnosti síťových připojení (spolehlivé, datagramové, uspořádané), metody synchronizace procesů atd. Jednou z nejpopulárnějších domén je internetová doména s protokoly zásobníku TCP / IP.

Používání koncového bodu abstraktního připojení zvaného soket. Soket je bod, kterým procházejí zprávy do sítě nebo jsou ze sítě přijímány. Síťové připojení mezi těmito dvěma procesy probíhá prostřednictvím dvojice soketů. Každý proces používá vlastní soket, zatímco sokety lze umístit na různé počítače a jedna (v tomto případě je síťová meziprocesová komunikace omezena na místní).

Soket může mít buď symbolický název (adresu) na vysoké úrovni, nebo ten na nízké úrovni, který odráží specifika adresování určité komunikační domény. Například v internetové doméně je název nízké úrovně představován dvojicí (IP adresa, port).

Pro každou komunikační doménu mohou existovat různé typy soketů. Typ soketu lze použít k určení konkrétního druhu komunikace, která má pro doménu smysl. Například mnoho domén má připojení k datagramu a streamu, aby bylo zajištěno spolehlivé a objednané doručení.

Dalším pohodlným mechanismem, který usnadňuje interakci operačních systémů a aplikací v síti, je mechanismus vzdáleného volání procedur (Vzdálené volání procedur, RPC). Tento mechanismus je doplňkem systému zasílání zpráv OS, proto v některých případech umožňuje pohodlnější a transparentnější organizaci interakce programů přes síť, ale jeho užitečnost není univerzální.

Myšlenkou vzdáleného volání procedury je rozšířit známý a dobře srozumitelný mechanismus pro přenos řízení a dat v rámci programu běžícího na jednom stroji na přenos řízení a dat přes síť. Zařízení pro vzdálené volání procedur jsou navržena pro usnadnění organizace distribuovaného výpočtu. Poprvé byl mechanismus RPC implementován společností Sun Microsystems a dobře zapadá do hesla „Network is a computer“, které tato společnost zaujala, protože přibližuje síťové programování k místnímu programování. RPC je nejúčinnější v aplikacích, kde existuje interaktivní komunikace mezi vzdálenými komponentami s rychlou dobou odezvy a relativně malým přenosem dat. Takovým aplikacím se říká RPC.

Místní volání procedur se vyznačují:

Asymetrie - jedna z interagujících stran je iniciátorem interakce;

Synchronicita - provedení volající procedury je blokováno od okamžiku vydání požadavku a pokračuje až po návratu z volané procedury.

Další rozdíl mezi RPC a místním voláním spočívá v tom, že nutně používá základní systém zasílání zpráv, ale toto by nemělo být výslovně vidět ani v definici postupů, ani v samotných postupech. Odlehlost přináší další problémy. Provádění volajícího programu a volané lokální procedury na stejném počítači se provádí v jednom procesu. Implementace RPC však zahrnuje alespoň dva procesy - jeden na každém počítači. Pokud dojde k chybě jednoho z nich, mohou nastat následující situace:

Pokud volací procedura selže, vzdálené volané procedury se stanou osiřelými;

Když se vzdálené procedury neobvykle ukončí, volající se stanou „zbavenými rodiči“ procedury a budou bezvýsledně čekat na odpověď vzdálených procedur.

Kromě toho existuje řada problémů spojených s heterogenitou programovacích jazyků a provozních prostředí: datové struktury a struktury volání procedur podporované v jednom programovacím jazyce nejsou podporovány přesně stejným způsobem v jiných jazycích.

Pojďme se podívat na to, jak technologie RPC, která je srdcem mnoha distribuovaných operačních systémů, řeší tyto problémy.

Abychom pochopili, jak RPC funguje, zvažte nejprve provedení volání místní procedury na samostatném počítači. Nechť je to například postup zápisu dat do souboru:

m. = my_write (fd, buf.length);

Zde fd je deskriptor souboru, celé číslo, buf je ukazatel na pole znaků, délka je délka pole, celé číslo.

Chcete-li uskutečnit volání, volací procedura vloží zadané parametry do zásobníku v opačném pořadí a předá řízení volané proceduře my_write. Tato uživatelská procedura po několika manipulacích s daty symbolického pole buf provede systémové volání write pro zápis dat do souboru a předá mu parametry stejným způsobem, to znamená, že je vtlačí do zásobníku (když systémové volání je implementován, jsou zkopírovány do systémového zásobníku a při návratu z něj je výsledek vložen do uživatelského zásobníku). Po provedení funkce my_write vrátí návratovou hodnotu m do registru, přesune zpáteční adresu a vrátí řízení volající proceduře, která vysune parametry ze zásobníku a vrátí ji do původního stavu. Všimněte si, že v jazyce C lze parametry volat pomocí reference (podle názvu), což je adresa oblasti globální paměti, ve které je parametr uložen, nebo podle hodnoty (podle hodnoty), v tomto případě se parametr zkopíruje z oblasti původní paměti do místní paměti procedury, obvykle umístěné v segmentu zásobníku. V prvním případě volaná procedura pracuje s původními hodnotami parametrů a jejich změny jsou volající proceduře okamžitě viditelné. V druhém případě volaná procedura pracuje s kopiemi hodnot parametrů a jejich změny nijak neovlivňují hodnotu originálů těchto proměnných ve volající proceduře. Tyto okolnosti jsou pro RPC velmi významné.

Je na návrhářích jazyků, aby se rozhodli, jaký mechanismus předávání parametrů použít. Někdy to závisí na typu přenášených dat. Například v C jsou celočíselná a další skalární data vždy předávána podle hodnoty a pole jsou vždy předávána podle odkazu.

Obrázek 69 ilustruje předávání parametrů volané proceduře: zásobník před výzvou k zápisu (a), zásobník během provádění procedury (b), zásobník po návratu do volajícího programu (c).

Obr. 69. Předávání parametrů volané proceduře

Myšlenkou RPC je, aby vzdálené volání procedur vypadalo co nejblíže místnímu volání procedury. Jinými slovy, musíte programátorovi zajistit transparentní mechanismus RPC: volající nepotřebuje vědět, že volaná procedura je na jiném stroji a naopak.

Mechanismus RPC dosahuje transparentnosti následujícím způsobem. Když je volaná procedura skutečně vzdálená, místo místní implementace původního kódu procedury se do knihovny procedur umístí jiná verze procedury s názvem útržek klienta (pahýl je útržek). Původní kód volané procedury je umístěn na vzdáleném počítači, který funguje jako server procedur, stejně jako další stub s názvem útržek serveru ... Účelem pahýlů klienta a serveru je organizovat přenos parametrů volané procedury a vrácení hodnoty procedury po síti, přičemž kód původní procedury umístěné na serveru musí být zcela zachován. Bodnutí používají podsystémy zasílání zpráv k přenosu dat prostřednictvím sítě, to znamená k odesílání a přijímání primitiv existujících v operačním systému. Někdy v podsystému zasílání zpráv je přidělen programový modul, který organizuje připojení stubů s primitivy přenosu zpráv, nazývanými modul RPCRimtime.

Stejně jako původní procedura je klientský stub volán obvyklým přenosem parametrů přes zásobník (Obrázek 69), ale místo provedení systémového volání, které pracuje s místním prostředkem, je vygenerována zpráva obsahující název volané procedury a jeho parametry (Obrázek 70).

Obr. 70. Provedení vzdáleného volání procedury

Tato operace se nazývá operace boxu s parametry. Poté klientský pahýl odkazuje na primitiv odeslání k přenosu této zprávy na vzdálený počítač, který je hostitelem implementace původního postupu. Po přijetí zprávy ze sítě zavolá jádro operačního systému vzdáleného počítače stub serveru, který extrahuje parametry ze zprávy a obvyklým způsobem zavolá původní postup. Chcete-li obdržet zprávu, musí serverový pahýl nejprve zavolat primitivní příjem, aby jádro vědělo, pro koho zpráva přišla. Stub serveru rozbalí parametry volání obsažené ve zprávě a zavolá původní proceduru obvyklým způsobem a předá mu parametry prostřednictvím zásobníku. Po skončení procedury serverový pahýl zabalí výsledek své práce do nové zprávy a pomocí primitivního odeslání odešle zprávu po síti do klientského pahýlu, který vrátí výsledek a řízení volající proceduře v obvyklým způsobem. Volací procedura ani původní volaná procedura se nezměnila, protože běží na různých počítačích.

Bodnutí lze generovat ručně nebo automaticky. V prvním případě programátor používá ke generování řady pomocných funkcí, které poskytuje vývojář nástrojů RPC. S touto metodou programátor získá velkou svobodu při výběru metody pro přenos parametrů volání a použití určitých primitiv pro přenos zpráv, ale tato metoda je spojena s velkým množstvím manuální práce.

Automatická metoda je založena na aplikaci speciální jazyk Interface Definition Language (IDL) Pomocí tohoto jazyka programátor popisuje rozhraní mezi klientem a serverem RPC. Popis obsahuje seznam názvů procedur, které může klient požadovat ze serveru, a také seznam typů argumentů a výsledků těchto procedur. Informace obsažené v popisu rozhraní jsou dostatečné pro to, aby stuby provedly kontrolu typu u argumentů a vygenerovaly volající sekvenci. Popis rozhraní navíc obsahuje některé další informace užitečné pro optimalizaci interakce stubů, například každý argument je označen jako vstup, výstup nebo hraní obou rolí (vstupní argument se předává z klienta na server a výstupní argument je předán v opačném směru). Rozhraní může také obsahovat popis konstant společných pro klienta a server. Je třeba zdůraznit, že rozhraní RPC obvykle nezahrnuje jednu, ale určitou sadu postupů, které provádějí vzájemně související funkce, například funkce přístupu k souborům, funkce vzdáleného tisku atd. Proto je při volání vzdálené procedury obvykle nutné nějak určit požadované rozhraní a Viz také konkrétní postup podporovaný tímto rozhraním. Rozhraní se často také označuje jako server RPC souborový server, tiskový server.

Poté, co programátor zkompiluje popis rozhraní, je zkompilován speciálním překladačem IDL, který generuje zdrojové moduly klientských a serverových stubů pro procedury uvedené v popisu a také generuje speciální hlavičkové soubory popisující typy procedur argumenty. Generování zdrojových modulů a souborů záhlaví se zakázaným inzerováním se provádí pro konkrétní programovací jazyk, například pro jazyk C. Poté mohou být moduly zdrojového rozhraní zahrnuty do libovolné aplikace spolu s dalšími moduly, které napsal programátor i knihovna , zkompilovaný a propojený do spustitelný program standardním systémem systému programovacích nástrojů.

Mechanismus RPC pracuje se dvěma typy zpráv: zprávami o volání, s jejichž pomocí klient požaduje, aby server provedl konkrétní vzdálenou proceduru, a předá své argumenty; zprávy s odpovědí, pomocí nichž server vrací výsledek vzdálené procedury klientovi.

Tyto zprávy se používají k implementaci protokolu RPC, který určuje, jak klient interaguje se serverem. Protokol RPC je obvykle nezávislý na transportních protokolech, které přenášejí zprávy RPC z klienta na server a naopak po síti. Při použití zásobníku protokolu TCP / IP v síti to mohou být protokoly TCP nebo UDP v místní sítěčasto se také používá NetBEUI / NetBIOS nebo IPX / SPX.

Typický formát pro dva typy zpráv používaných RPC je uveden na obrázku 71.

Obr. 71. Formát zpráv RPC

Typ zprávy rozlišuje zprávy s výzvou od zpráv s odpovědí. Pole identifikátoru vzdálené procedury ve zprávě o volání umožňuje serveru pochopit volání, kterou proceduru klient ve zprávě požaduje (procedury nejsou identifikovány jmény, ale čísly, která jim při automatickém generování přiděluje překladač IDL. pahýlů a programátor pro manuální). Pole argumentů má proměnná délka, určený počtem a typem argumentů volané procedury. Pole identifikátoru zprávy obsahuje pořadové číslo zprávy, které je užitečné pro zjišťování skutečnosti ztracených zpráv nebo příchodu duplicitních zpráv. Toto číslo navíc umožňuje klientovi správně porovnat odpověď přijatou od serveru s jeho voláním v případě, že odpovědi nebudou přijaty v pořadí, v jakém byla volání odeslána. Server potřebuje identifikátor klienta, aby věděl, kterému klientovi má poslat výsledek volané procedury. Toto pole lze také použít v procedurách autentizace klienta, pokud jsou tyto procedury poskytovány protokolem RPC.

Pole stavu a výsledku ve zprávách s odpovědí umožňují serveru informovat klienta o úspěšném dokončení vzdálené procedury nebo o tom, že byla při pokusu o provedení procedury zachycena chyba určitého typu. Server se může setkat s různými situacemi, které brání normálnímu provedení procedury. Takové situace mohou nastat ještě před provedením, protože klient nemusí mít povolení k provedení tento postup, klient může nesprávně formulovat argumenty procedury, klient může používat verze rozhraní, které serveru nevyhovují atd. Provedení procedury může také vést k chybě, například v souvislosti s dělením nulou. Všechny tyto situace musí být správně zpracovány stubem klienta a odpovídající chybové kódy musí být předány volající proceduře.

Pro stabilní provoz serverů a klientů RPC je nutné nějakým způsobem řešit situace spojené se ztrátou zpráv, ke kterým dochází v důsledku chyb v síti (transportní protokoly se snaží tyto chyby kompenzovat, ale stále existuje určitá pravděpodobnost ztráty) nebo v důsledku havárie operačního systému a restartování počítače (dopravní protokoly zde nemohou situaci napravit). Protokol RPC v takových případech používá mechanismus časového limitu opětovného přenosu. Aby server znovu odeslal ztracený výsledek klientovi, aniž by musel odesílat druhé volání od klienta, je do protokolu RPC někdy přidána speciální zpráva - potvrzení klienta, které klient odešle, když obdrží odpověď od serveru .

Zvažte, jak klient zná umístění serveru, na který je třeba poslat výzvu. Procedura, která navazuje korespondenci mezi klientem a serverem RPC, se nazývá vazba. Metody vazby používané v různých implementacích RPC se liší:

Způsob zadání serveru, ke kterému by se klient chtěl připojit;

Metoda detekce síťové adresy (umístění) požadovaného serveru procesem vazby;

Fáze, ve které dochází k propojení.

Metoda vazby úzce souvisí s přijatou konvencí pojmenování serveru. V nejjednodušším případě je název nebo adresa serveru RPC explicitně zadána jako argument pro klientský stub nebo pro serverový program, který implementuje rozhraní konkrétního typu. Například můžete jako takový argument použít IP adresu počítače, na kterém běží nějaký server RPC, a číslo portu TCP / UDP, přes který přijímá zprávy, které volají jeho postupy. Hlavní nevýhodou tohoto přístupu je nedostatek flexibility a transparentnosti. Při přesouvání serveru nebo když existuje více serverů klientský program nelze automaticky vybrat nový server nebo server, který je v tento moment nejméně naložený. Nicméně v mnoha případech je tato metoda docela přijatelná a kvůli své jednoduchosti se často používá v praxi. Požadovaný server je často vybrán uživatelem, například prohlížením seznamu nebo grafickým znázorněním sdíleného souborové systémy(lze sestavit sadu těchto souborových systémů operační systém klientský počítač posloucháním oznámení o vysílání, která servery pravidelně vydávají). Uživatel může navíc nastavit název požadovaného serveru na základě předem známých informací o adrese nebo názvu serveru.

Tuto metodu propojení lze nazvat zcela statickou. Existují další metody, které jsou více či méně dynamické, protože nevyžadují, aby klient specifikoval přesnou adresu serveru RPC, až do zadání čísla portu, ale dynamicky vyhledal server, který klient potřebuje.

Dynamické propojení vyžaduje změnu konvence pojmenování serveru. Nejflexibilnější je pro tento účel použít název rozhraní RPC, které se skládá ze dvou částí:

Typ rozhraní;

Instance rozhraní.

Typ rozhraní definuje všechny vlastnosti rozhraní, s výjimkou jeho umístění. Jedná se o stejné vlastnosti, které se nacházejí v popisu kompilátoru IDL, například souborová služba určité verze, včetně postupů otevření, zavření, čtení, zápisu atd. Část popisující instanci rozhraní musí přesně specifikovat síť adresa serveru, který podporuje toto rozhraní. Pokud je klientovi jedno, který server jej bude obsluhovat, je druhá část názvu rozhraní vynechána.

Dynamická vazba se někdy označuje jako import / export rozhraní: klient importuje rozhraní a server jej exportuje.

V případě, že je pro klienta důležitý pouze typ rozhraní, lze proces vyhledání požadovaného serveru v síti s instancí rozhraní určitého typu sestavit dvěma způsoby:

Používání vysílání;

Pomocí centralizovaného vazebného činidla.

Tyto dvě metody jsou typické pro vyhledání síťového prostředku jakéhokoli typu podle jeho názvu, v němž již byly zváženy obecný pohled Další informace najdete v podsekci Metody adresování mechanismu přenosu zpráv v distribuovaných systémech. První metoda se spoléhá na servery RPC, které po síti vysílají jejich název rozhraní, včetně adresy instance. Pomocí této metody se automaticky vyvažuje zátěž na několika serverech, které podporují stejné rozhraní - klient jednoduše vybere první reklamu, která mu vyhovuje.

Schéma centralizovaného agenta vazeb předpokládá, že v síti je jmenný server, který váže typ rozhraní na adresu serveru, který toto rozhraní podporuje. Aby bylo možné implementovat toto schéma, musí každý server RPC nejprve zaregistrovat svůj typ rozhraní a síťovou adresu u agenta vazeb spuštěného na jmenném serveru. Síťová adresa agenta vazby (ve formátu běžném v síti) musí být známá adresa jak pro servery RPC, tak pro klienty. Pokud server z nějakého důvodu již nemůže podporovat určité rozhraní RFC, musí kontaktovat agenta a zrušit registraci. Na základě požadavků na registraci agent vazeb udržuje tabulku aktuální dostupnosti serverů v síti a rozhraní RFC, která podporují.

Klient RFC kontaktuje agenta vazby s charakteristikami, které definují typ rozhraní, aby určil adresu serveru obsluhujícího požadované rozhraní. Pokud tabulka agenta vazeb obsahuje informace o serveru, který podporuje tento typ rozhraní, vrátí klientovi jeho síťovou adresu. Klient poté uloží tyto informace do mezipaměti, aby následná volání postupů tohoto rozhraní neztrácela čas na volání agenta vazby.

Agent vazby může běžet jako součást běžné centralizované síťové služby nápovědy, jako je NDS, X.500 nebo LDAP (služby nápovědy jsou podrobněji popsány v následující kapitole).

Popsaný způsob importu / exportu rozhraní je vysoce flexibilní. Může například existovat více serverů podporujících stejné rozhraní a klienti jsou mezi servery náhodně distribuováni. V rámci této metody je možné periodicky dotazovat servery, analyzovat jejich výkon a v případě poruchy automatické vypnutí, což zvyšuje celkovou odolnost systému proti chybám. Tato metoda může také podporovat ověřování klientů. Například server může určit, že k němu mají přístup pouze klienti na konkrétním seznamu.

Dynamické propojení má však nevýhody, jako je další režie (čas) exportu a importu rozhraní. Velikost těchto nákladů může být významná, protože mnoho klientských procesů existuje na krátkou dobu a při každém spuštění procesu je nutné provést proceduru importu rozhraní znovu. Ve velkých distribuovaných systémech se navíc vazební agent může stát překážkou a pak je nutné použít distribuovaný systém agentů, což lze provést standardním způsobem pomocí distribuovaného podpora(NDS, X.500 a LDAP mají tuto vlastnost).

Je třeba poznamenat, že i v případech, kdy se používá statická vazba, je taková část adresy jako port serveru rozhraní (tj. Identifikátor procesu obsluhujícího toto rozhraní) klientem určována dynamicky. Tento postup podporuje speciální modul RPCRuntime nazývaný portmapper v systému UNIX a RPC Locator v systému Windows. Tento modul běží na každém síťovém uzlu podporujícím RPC a je přístupný přes známý port TCP / UDP. Každý server RPC obsluhující konkrétní rozhraní při spuštění adresuje takový modul s požadavkem na přidělení čísla portu z dynamicky přidělené oblasti (tj. S číslem větším než 1023) pro provoz. Modul mapování portů přiděluje serveru číslo volného portu a ukládá toto mapování do své tabulky, přičemž přidružuje port k typu rozhraní podporovaného serverem. Klient RPC, který nějakým způsobem zjistil síťovou adresu uzlu, který má server RPC s požadovaným rozhraním, se nejprve připojí k modulu mapování portů přes známý port a požádá o číslo portu požadovaného serveru. Po obdržení odpovědi klient používá toto číslo k odesílání zpráv - volání na vzdálené procedury. Mechanismus je velmi podobný mechanismu, na kterém je vázán agent vazby, kromě toho, že pracuje na jediném portu počítače.

Přednáška 4

4.1 Koncept vzdáleného volání procedury

Myšlenka volání vzdálených procedur (Vzdálené volání procedur - RPC) spočívá v rozšíření známého a dobře srozumitelného mechanismu pro přenos řízení a dat v rámci programu běžícího na jednom stroji na přenos řízení a dat přes síť. Zařízení pro vzdálené volání procedur jsou navržena pro usnadnění organizace distribuovaného výpočtu. RPC je nejúčinnější v aplikacích, kde existuje interaktivní komunikace mezi vzdálenými komponentami s rychlou dobou odezvy a relativně malým přenosem dat. Takovým aplikacím se říká RPC.

Charakteristické rysy výzvy k místním postupům jsou: asymetrie, to znamená, že jedna z interagujících stran je iniciátorem; synchronicita, to znamená provedení volající procedury, když se zastaví od okamžiku vydání požadavku a obnoví se až po návratu z volané procedury.

Implementace vzdálených volání je podstatně složitější než implementace volání místních procedur. Za prvé, protože volající a volaná procedura jsou prováděny na různých počítačích, mají různé adresní prostory a to vytváří problémy při předávání parametrů a výsledků, zejména pokud nejsou stroje totožné. Vzhledem k tomu, že RPC nemůže počítat se sdílenou pamětí, znamená to, že parametry RPC nesmí obsahovat ukazatele na umístění paměti bez zásobníku a že hodnoty parametrů musí být zkopírovány z jednoho počítače do druhého. Dalším rozdílem mezi RPC a místním hovorem je, že nutně používá základní komunikační systém, ale toto by nemělo být výslovně vidět ani v definici postupů, ani v samotných postupech. Odlehlost přináší další problémy. Provádění volajícího programu a volané lokální procedury na stejném počítači se provádí v jednom procesu. Implementace RPC však zahrnuje alespoň dva procesy - jeden na každém počítači. Pokud dojde k chybě jednoho z nich, mohou nastat následující situace: pokud dojde k chybě volající procedury, vzdálené volané procedury se stanou „osiřelými“ a pokud se vzdálené procedury neobvykle ukončí, volající se stanou „zbavenými rodiči“ volajících, kteří marně čekat na odpověď ze vzdálených procedur.

Tyto a některé další problémy řeší rozšířená technologie RPC, která je základem mnoha distribuovaných operačních systémů.

Základní operace RPC

Abychom pochopili, jak RPC funguje, zvažte nejprve provedení volání místní procedury na konvenčním počítači, který běží autonomně. Například ať je to systémové volání

count = read (fd, buf, nbytes);

kde fd je celé číslo;

buf - pole znaků;

nbytes je celé číslo.

Chcete-li uskutečnit volání, volací procedura posune parametry do zásobníku v opačném pořadí. Po provedení přečteného volání vrátí návratovou hodnotu do registru, přesune zpáteční adresu a vrátí řízení volající proceduře, která vyskočí parametry ze zásobníku a vrátí ji do původního stavu. Všimněte si, že v jazyce C lze parametry volat buď odkazem (podle názvu) nebo podle hodnoty (podle hodnoty). S ohledem na volanou proceduru jsou hodnotové parametry inicializovatelné lokální proměnné. Volaná procedura je může změnit bez ovlivnění hodnoty originálů těchto proměnných ve volající proceduře.

Pokud je ukazatel na proměnnou předán volané proceduře, pak změna hodnoty této proměnné volanou procedurou vede ke změně hodnoty této proměnné i pro volající proceduru. Tato skutečnost je pro RPC zásadní.

Existuje také další mechanismus pro předávání parametrů, který se nepoužívá v jazyce C. Nazývá se call-by-copy / restore a spočívá v nutnosti volajícího programu kopírovat proměnné do zásobníku jako hodnoty a poté je zkopírovat zpět po uskutečnění volání přes původní hodnoty volací procedury.

Myšlenkou RPC je, aby vzdálené volání procedur vypadalo co nejblíže místnímu volání procedury. Jinými slovy, udělejte RPC transparentní: volající nemusí vědět, že volaná procedura je na jiném stroji, a naopak.

RPC dosahuje transparentnosti následujícím způsobem. Když je volaná procedura skutečně vzdálená, místo místní procedury se do knihovny umístí jiná verze procedury zvaná klientský stub (stub). Stejně jako původní postup je stub vyvolán pomocí volající sekvence a při přístupu k jádru dojde k přerušení. Pouze na rozdíl od původního postupu nevkládá parametry do registrů a nepožaduje jádro o data, místo toho vygeneruje zprávu, kterou odešle do jádra vzdáleného počítače.

Kroky provádění RPC

Interakce softwarových komponent během provádění vzdáleného volání procedury je znázorněna na obrázku 2.

Obrázek 2. Vzdálené volání procedur

Poté, co klientský program zavolá stub klienta, jeho prvním úkolem je vyplnit vyrovnávací paměť odesílanou zprávou. V některých systémech má klientský stub jednu vyrovnávací paměť s pevnou délkou, která se vyplňuje od začátku pokaždé, když dorazí nový požadavek. V jiných systémech je vyrovnávací paměť zpráv fond vyrovnávacích pamětí pro jednotlivá pole zpráv, z nichž některá jsou již plná. Tato metoda je zvláště vhodná, pokud je balíček ve formátu skládajícím se z velké množství pole, ale hodnoty mnoha z těchto polí se nemění z volání na volání.

Parametry musí být poté převedeny do příslušného formátu a vloženy do vyrovnávací paměti zpráv. V tomto okamžiku je zpráva připravena k odeslání, takže se provede přerušení volání jádra.

Když jádro získá kontrolu, přepne kontexty, uloží registry procesorů a mapu paměti (deskriptory stránek) a nastaví novou mapu paměti, která se použije ke spuštění v režimu jádra. Jelikož se kontext jádra a uživatele liší, musí jádro zkopírovat zprávu přesně do svého vlastního adresního prostoru, aby k ní mohl přistupovat, pamatovat si cílovou adresu (a případně další pole záhlaví) a musí ji také přenášet. síťové rozhraní... Tím je práce na straně klienta dokončena. Časovač přenosu je povolen a jádro může buď cyklicky požadovat odpověď, nebo předat řízení plánovači, který zvolí nějaký jiný proces k provedení. V prvním případě je provádění dotazu zrychleno, ale nedochází k multiprogramování.

Na straně serveru jsou příchozí bity umístěny přijímajícím hardwarem buď do vestavěné vyrovnávací paměti, nebo do RAM... Když jsou přijaty všechny informace, je generováno přerušení. Obslužný program přerušení zkontroluje správnost dat paketu a určí, který stub by měl být předán. Pokud žádný z pahýlů tento paket neočekává, musí jej obslužný program buď umístit do vyrovnávací paměti, nebo jej úplně zahodit. Pokud existuje čekající útržek, zpráva se do něj zkopíruje. Nakonec se provede kontextový přepínač, v důsledku čehož se obnoví registry a mapa paměti, přičemž se vezmou hodnoty, které měly v okamžiku, kdy stub provedl volání příjmu.

Nyní začne fungovat útržek serveru. Rozbalí parametry a vhodně je posune do zásobníku. Když je vše připraveno, provede se volání serveru. Po dokončení postupu server odešle výsledky klientovi. Za tímto účelem se provádějí všechny kroky popsané výše, pouze v opačném pořadí.

Obrázek 3 ukazuje posloupnost příkazů, které musí být provedeny pro každé volání RPC.

Obrázek 3. Fáze postupu RPC

Největší efektivity používání RPC je dosaženo v aplikacích, ve kterých je interaktivní komunikace mezi vzdálenými komponentami z krátká doba odezvy a relativně malé množství přenášených dat.Takovým aplikacím se říká RPC.

Místní volání procedur se vyznačují:

Asymetrie, to znamená, že jedna z interagujících stran je iniciátorem;

Synchronicita, to znamená, že provádění volající procedury je pozastaveno od okamžiku vydání požadavku a obnoveno až po návratu volané procedury.

Implementace vzdálených volání je podstatně složitější než implementace volání místních procedur.

1. Začněme tím, že protože volací a volané procedury jsou prováděny na různých strojích, jsou i oni mít různé adresní prostory a to vytváří problémy s přenosem parametrů a výsledků, zejména pokud nejsou stroje identické.

Protože RPC nemůže počítat se sdílenou pamětí, znamená to, že Parametry RPC nesmějí obsahovat ukazatele na paměťová místa bez zásobníku No a co hodnoty parametrů musí být zkopírovány z jednoho počítače do druhého.

2. Dalším rozdílem mezi RPC a místním hovorem je to nutně používá základní komunikační systém nicméně toto by neměly být jasně viditelné ani v definici postupů, ani v samotných postupech .

Odlehlost přináší další problémy. Provádění volajícího programu a volané lokální procedury na stejném stroji implementováno uvnitřjediný proces... Ale podílí se na implementaci RPCalespoň dva procesy - jeden v každém autě... Pokud dojde k chybě jednoho z nich, mohou nastat následující situace:

pokud volací procedura selže, vzdáleně volané procedury se stanou "osiřelými" a

neobvyklé ukončení vzdálených postupů způsobí, že volající budou „znevýhodnění rodiče“ a budou bezvýsledně čekat na odpověď ze vzdálených postupů.

Kromě toho existuje řada problémů spojených s heterogenitou programovacích jazyků a operačních prostředí : Datové struktury a struktury volání procedur podporované v jednom programovacím jazyce nejsou podporovány stejným způsobem ve všech ostatních jazycích.

Tyto a některé další problémy řeší rozšířená technologie RPC, která je základem mnoha distribuovaných operačních systémů.

Myšlenkou RPC je, aby vzdálené volání procedur vypadalo co nejblíže místnímu volání procedury. Jinými slovy, udělejte RPC transparentní: volající nemusí vědět, že volaná procedura je na jiném stroji, a naopak.

RPC dosahuje transparentnosti následujícím způsobem. Když je volaná procedura skutečně vzdálená, místo místní procedury se do knihovny umístí jiná verze procedury zvaná klientský stub (stub). Stejně jako původní postup je útržek vyvolán pomocí volající sekvence (jako na obrázku 3.1) a při přístupu k jádru dojde k přerušení. Pouze na rozdíl od původního postupu nevkládá parametry do registrů a nepožaduje jádro o data, místo toho generuje zprávu, kterou odešle do jádra vzdáleného počítače.

Rýže... 3.2. Vzdálené volání procedury

Po restartování počítače se služba nespustila “ Vzdálené volání procedur (RPC)". Na této službě hodně záleží. Výsledkem je, že Obnovení systému nefunguje, síť zvuk, Instalační služba systému Windows„Microsoft Management Console (MMC) téměř nefunguje, na hlavním panelu se nezobrazují žádná otevřená okna atd. atd. Pokus o ruční spuštění má za následek chybu " Nelze spustit ... (RPC) na xxxComp. Chyba 5: Přístup odepřen"Antivirus nenašel nic. Dva dny kopání a počítač byl přiveden zpět k životu."

Jak doporučil Microsoft, první věcí, kterou jsem zkoušel, bylo najít a odstranit klíč registru ... Neměl jsem to, možná v důsledku některých nainstalovaných aktualizací.

Dále se provede pokus o obnovení parametrů služby v registru. Protože regedit.exe fungoval pouze na čtení / mazání (další vedlejší efekt), nebylo možné provádět změny. Ano, nebyly potřeba, tk. všechno bylo v pořádku. Mělo by to vypadat takto:

Windows Registry Editor verze 5.00 "Description" = "Poskytuje mapování pro koncové body a další služby RPC." "DisplayName" = "Vzdálené volání procedur (RPC)" "ErrorControl" = dword: 00000001 "Group" = "Infrastruktura 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" "Start" = dword: 00000002 "Type" = dword: 00000010 "FailureActions" = hex: 00,00,00,00,00,00,00,00,00,00,00,00,01, 00,00,00,00,00,00, \ 00,02,00 , 00,00,60, ea, 00,00 "ServiceSidType" = dword: 00000001 "ServiceDll" = hex (2): 25,00, 53,00,79,00,73,00,74,00,65, 00,6d, 00,52,00,6f, 00,6f, \ 00,74,00,25,00,5c, 00, 73,00,79,00,73,00,74,00,65,00 , 6d, 00,33,00,32,00,5c, 00, \ 72,00,70,00,63,00,73, 00,73,00,2e, 00,64,00,6c, 00, 6c, 00,00,00 „Zabezpečení“ = 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.05.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" = "Kořen \\ LEGACY_RPCSS \\ 0000" "Počet" = dword: 00000001 "NextInstance" = dword: 00000001

Hodnota parametru Start se mohou lišit. Stále můžete změnit registr, ale musíte z něj spustit Velitel MS ERD.

Jednoduše popíšu další kroky bod po bodu. Obecná myšlenka je nahradit soubory známými funkčními. Mohou být převzaty z jiného stroje nebo z Distribuce Windows(jako já).

Spusťte konzolu (Start> Spustit: cmd)
cd z: \ i386(existuje distribuce Windows)
rozbalte explorer.ex_% TEMP% \ explorer.exe
rozbalte svchost.ex_% TEMP% \ svchost.exe
Spusťte Správce úloh (Ctrl + Shift + Esc)
Zastavte proces exlporer.exe
zkopírujte% TEMP% \ explorer.exe% SYSTEMROOT% / r
Zastavte všechny procesy svchost.exe. Pozornost! Poté budete mít 60 sekund na restartování stroje.
zkopírujte% TEMP% \ svchost.exe% systemroot% \ system32 / y

Tento trik také nedal výsledky. Další možnost: spustit kontrolu všech chráněných systémové soubory s výměnou špatné verze opravit. V konzole proveďte:

sfc / PURGECACHE- Vymažte mezipaměť souborů a soubory okamžitě zkontrolujte
sfc / SCANONCE- Jednorázová kontrola při příštím spuštění

Nepomohlo to ... Pak úplně brutální krok - obnovení bezpečnostních parametrů. Opět v konzole:

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

Po restartu počítač začal pracovat, byly spuštěny základní služby. Objevil se nový okraj (nebo to možná bylo od samého začátku): alespoň se pod mým účtem nespustil správce správy disků a Instalační služba Windows Installer. Přístup odepřen. Prostřednictvím konzoly můžete obnovit přístupová práva na „výchozí“ systémový disk:

secedit / configure / db% TEMP% \ temp.mdb / Cfg% WINDIR% \ inf \ defltwk.inf / oblasti úložiště souborů

Pak musíte ručně definovat práva pro každý účet nebo je znovu vytvořte, podle toho, co je jednodušší.

V mém případě jsem jednoduše přidělil stejná práva celému systémovému disku, přičemž přístup k adresáři jsem bral jako referenci. Přidal jsem svůj účet k referenci v doméně s plnými právy k disku. Možná je to z bezpečnostního hlediska špatné, ale nemám čas kopat do každého adresáře zvlášť.

Co jiného by se dalo udělat

Zatímco byl počítač „nemocný“, nebyl v registru:

"ActiveService" = "RpcSs"

Možná jeho ruční přidání by situaci nějak změnilo.

Pokusy o ruční spuštění služby, například pomocí příkazu „ čistý start rcpss„skončil omylem“ Chyba 5: přístup odepřen". Myslím, že přístup byl odepřen, protože služba musí běžet pod účtem systému -" NT AUTHORITY ". Registr má tento parametr:

"ObjectName" = "NT AUTHORITY \\ NetworkService"

Pokusil bych se zde zadat účet správce a spustit službu znovu. Ale toto je jen myšlenka, která se nedožila implementace.

Další možnost: pomocí nástroje KiTrap0D získat konzolu se systémovými právy. Toto zneužití bylo nahlášeno v. Samotný binární soubor. Mám ale nové aktualizace systému Windows, takže to vypadá, že toto zneužití již nefunguje.

Související materiály:

Co jiného by se dalo udělat

Populární