Vyšlo v týdeníku: | COMPUTERWORLD |
Číslo: | 1/94 |
Ročník: | 1994 |
Rubrika/kategorie: | Co je čím ... v počítačových sítích |
Díl: | 79 |
Úvodem je vhodné si zdůraznit vztah firmy Sun Microsystems k mechanismu RPC a jeho standardizaci - platí zde přesně totéž, co jsme si v 75. dílu říkali již v souvislosti s protokolem NFS. Samotné volání vzdálených procedur můžeme chápat jako obecnou myšlenku, postup či techniku, kterou může kdokoli implementovat podle svých vlastních představ. Firma Sun Microsystems tak učinila, své konkrétní řešení zveřejnila, toto se ujalo a stalo se všeobecně uznávaným standardem v rámci rodiny protokolů TCP/IP (kodifikovaným ve formě dokumentu RFC, viz 75. díl). Pokud se tedy v dalším budeme odvolávat na mechanismus RPC resp. na standard RPC, budeme tím mít na mysli jednu konkrétní implementaci, resp. jeden konkrétní standard, pocházející od firmy Sun Microsystems.
každá vzdálená procedura má přiřazen jednoznačný číselný identifikátor, a její vzdálené volání (tj. volání na straně klienta) má obecně tvar
CALL ( <číslo_vzdálené_procedury> )
Praktická realizace této jednoduché myšlenky ovšem vyžaduje zavést vhodný řád do přidělování takovýchto číselných identifikátorů - aby byla zachována konzistence číslování procedur a jejich identifikátory byly skutečně jednoznačné (tedy aby se nikdy nemohlo stát, že dvě různé vzdálené procedury dostanou přiděleny stejné identifikátory). K tomu je ovšem nutná existence jediného centrálního subjektu, který bude přidělování těchto identifikátorů vhodně koordinovat. Této role se podujala právě firma Sun Microsystems.
Aby firma Sun Microsystems nemusela přidělovat jednoznačný identifikátor pro každou jednotlivou vzdálenou proceduru (což by bylo organizačně neúnosné), rozhodla se pro použití takových identifikátorů, které se skládají ze tří složek:
Právě naznačený problém správné interpretace přenášených dat má dvě principiální řešení: první spočívá v tom, že každá zúčastněná strana bude předem znát konvence, které používá kterákoli druhá strana. Pak je možné při přenosu dat provést potřebné konverze nejvýše jednou - ať již u odesilatele, nebo u příjemce (případně je vůbec neprovádět, pokud obě strany používají přesně stejné konvence). Alternativním řešením je zavést jeden společný mezitvar, a veškerá data pak vždy přenášet v něm. To sice znamená provádět nezbytné konverze dvakrát (na straně příjemce i na straně odesilatele), ale současně to znamená i to, že každá strana vystačí vždy jen s jednou sadou konverzních prostředků, a nemusí se jakkoli přizpůsobovat případným novým konvencím druhých stran. No a právě toto druhé řešení zvolila firma Sun pro implementaci svého mechanismu RPC.
Konkrétní realizací této volby je pak standard XDR (eXternal Data Representation), který byl opět zveřejněn, je všeobecně uznáván jako standard v rámci rodiny protokolů TCP/IP, a je kodifikován formou dokumentu RFC.
Standard XDR tedy definuje jednotný způsob reprezentace přenášených dat, nezávislý na konkrétní architektuře jejich odesilatele i příjemce. Kromě toho je součástí XDR také jazyk pro nezávislý popis těchto dat. Po stránce implementační souvisí s tímto standardem také konkrétní konverzní rutiny, které mají nejčastěji formu knihovních rutin, a jsou obvykle označovány jak XDR filtry.
Konkrétním prostředkem, kterým se lokální procedura registruje u RPC dispečera, je systémová rutina registerrpc s následujícími parametry:
Mechanismus RPC lze obvykle využívat na třech různých úrovních, přičemž ta, kterou jsme až dosud předpokládali, představuje tu prostřední. Je charakteristická tím, že na této úrovni je nutné si uvědomovat existenci distribuovaného prostředí (tj. existenci vzdálených uzlů), a vyžaduje také znalost konkrétních vzdálených procedur (které je nutně explicitně určovat). Vše ostatní je ale podřízeno snaze o maximální jednoduchost využití celého mechanismu volání vzdálených procedur.
To ale nemusí být vždy výhodné. Při seriózní tvorbě aplikací, které mechanismus RPC využívají, může být velmi nevýhodné, že na této úrovni není možné nijak ovlivnit celou řadu konkrétních aspektů - například to, jakým konkrétní transportní mechanismus je využíván pro skutečný přenos v síti (zda jde např. o nespolehlivou datagramovou službu protokolu UDP, nebo o spolehlivou spojovanou službu protokolu TCP), jaké časové limity (timeout-y) jsou používány, jak je řešena otázka chyb, ověřování přístupových práv a totožnosti (authentication) apod.
Standard RPC je řešen nezávisle na transportním protokolu (aby mohl být implementován nad různými protokoly), a nesnaží se sám zavádět jakoukoli dodatečnou spolehlivost (ošetřováním chyb). Aplikace, která mechanismus RPC využívá, si proto musí uvědomovat, jaký transportní mechanismus je pro implementaci RPC použit, a sama si z toho vyvodit příslušné důsledky (mj. z hlediska spolehlivosti). Pokud potřebuje nějak zasáhnout do způsobu, jakým RPC transportní prostředky využívá, pak k tomu musí využít zmíněnou nejnižší úroveň práce s mechanismem RPC (což v podstatě znamená realizovat prostředky typu callrpc pomocí prostředků nižší úrovně).
Práce s mechanismem RPC na této nejnižší úrovni jej již značně netriviální, a je míněna především pro odborníky, kteří vytváří nové systémové prostředky a služby. Jejich náročný úkol přitom mohou usnadnit různé nástroje, mezi které patří zejména překladač rpcgen, vyvinutý firmou Sun. Jeho hlavním úkolem je překlenout rozdíl mezi střední a nejnižší úrovní práce s mechanismem RPC, zbavit programátory maxima "špinavé práce", a umožnit jim soustředit se na to, co je pro jejich aplikaci podstatné. Na základě obecnějšího popisu ve zvláštním RPC jazyku (velmi blízkému k jazyku C) totiž překladač rpcgen generuje to, co by jinak bylo třeba explicitně naprogramovat na nejnižší úrovni (ve formě zdrojových textů jazyka C).
Naproti tomu na nejvyšší úrovni je celý mechanismus RPC obvykle "zabalen" takovým způsobem, že jeho samotná podstata již nemusí být vůbec patrná. Prostředky, které jsou na této úrovni k dispozici, již nejsou typu "volej tu a tu vzdálenou proceduru", a vůbec nepracují s čísly programů, procedur a verzí. Místo toho jde o lokální procedury, které vesměs přímo odpovídají jednotlivým vzdáleným procedurám (stylem 1:1), a také již nepotřebují dodržovat konvence o jediném vstupním a jediném výstupním parametru. Mají formu zdrojových knihoven, a mohou být přímo začleněny do zdrojových tvarů nejrůznějších aplikací, psaných ve vyšších programovacích jazycích (například v jazyku C). Vzhledem k tomu je pak tato nejvyšší úroveň určena pro méně náročné aplikační programování, které je ale možné prakticky i bez jakéhokoli tušení o existenci mechanismu RPC.