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
zp∞t do archivu Φlßnk∙ | rejst°φk | p°edchozφ dφl | nßsledujφcφ dφl

Ji°φ Peterka: Co je Φφm ... v poΦφtaΦov²ch sφtφch (79):

RPC II.

V minulΘm dφlu jsme se zaΦali podrobn∞ji zab²vat mechanismem volßnφ vzdßlen²ch procedur (RPC, Remote Procedure Call), a to v kontextu implementace protokolu NFS pro transparentnφ sdφlenφ soubor∙ v sφtφch. Tento vÜeobecn∞ pou₧iteln² mechanismus byl toti₧ poprvΘ ve v²znamn∞jÜφm m∞°φtku pou₧it prßv∞ pro implementaci protokolu NFS. Minule jsme se seznßmili s jeho celkovou filosofiφ, a dnes ji₧ dojde °ada na to, jak²m konkrΘtnφm zp∙sobem tento obecn² mechanismus implementovala a standardizovala firma Sun Microsystems.

┌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.

Identifikßtory vzdßlen²ch procedur

Pro sprßvnΘ pochopenφ zp∙sobu, jak²m je mechanismu RPC implementovßn, je vhodnΘ zaΦφt s nßsledujφcφ p°edstavou:
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:

Logika, kterß stojφ za tφmto rozd∞lenφm identifikßtor∙ na t°i slo₧ky, je vcelku z°ejmß: firm∞ Sun jako globßlnφmu koordinßtorovi staΦφ peΦovat pouze o jednoznaΦnost prvnφ slo₧ky. Kdokoli, kdo se rozhodne implementovat pomocφ mechanismu RPC n∞jakou novou slu₧bu, si od firmy Sun m∙₧e vy₧ßdat jednoznaΦnΘ Φφslo programu. Jednotliv²m procedurßm, kterΘ pak pro zajiÜt∞nφ svΘ slu₧by vytvo°φ, ji₧ p°id∞luje druhou slo₧ku (Φφslo procedury) sßm. KoneΦn∞ t°etφ slo₧ka vychßzφ vst°φc postupnΘmu v²voji jednotliv²ch slu₧eb, kter² dßvß postupn∞ vznikat nov²m a nov²m verzφm. Dφky tΘto slo₧ce identifikßtoru vzdßlenΘ procedury je pak mo₧nΘ pr∙b∞₧n∞ implementovat nejnov∞jÜφ verze, ale souΦasn∞ s tφm zabezpeΦit i zp∞tnou kompatibilitu a podporovat i verze p°edchozφ.

Jeden parametr staΦφ

V zßjmu snazÜφ implementace zavedla firma Sun konvenci, ₧e vÜechny vzdßlenΘ procedury majφ prßv∞ jeden vstupnφ parametr, a prßv∞ jeden v²stupnφ parametr (resp. vracφ jedin² v²stup). Nenφ ale tato konvence p°φliÜ omezujφcφ? Nikoli - pokud by bylo zapot°ebφ p°edat vφce parametr∙, tyto se vhodn∞ "zabalφ" (p°esn∞ji: vytvo°φ se z nich vhodnß datovß struktura), a jako jedin² vstupnφ parametr bude vzdßlenΘ procedu°e p°edßn ukazatel na tuto datovou strukturu, kterß samoz°ejm∞ musφ b²t v rßmci vzdßlenΘho volßnφ p°enesena na server. K jejφmu sprßvnΘmu vyu₧itφ je dßle nutnΘ, aby ob∞ strany (tj. klient i server) byly p°edem dohodnuty na formßtu tΘto datovΘ struktury a v²znamu jejφch jednotliv²ch Φßstφ. To se ale dß vcelku snadno za°φdit (viz dßle).

XDR - eXternal Data Representation

Pon∞kud slo₧it∞jÜφ je ale to, aby ob∞ strany takΘ sprßvn∞ interpretovaly ka₧dou jednotlivou Φßst vstupnφch a v²stupnφch dat vzdßlen²ch procedur. Budou-li nap°φklad srozum∞ny s tφm, ₧e obsah dvou byt∙ mß p°edstavovat celΘ Φφslo bez znamΘnka, mohou jej stßle jeÜt∞ interpretovat r∙zn∞ - jedna strana m∙₧e pova₧ovat za vyÜÜφ ten z obou byt∙, kter² druhß strana naopak pova₧uje za ni₧Üφ.

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.

Volßnφ vzdßlen²ch procedur na stran∞ klienta

Nynφ se m∙₧eme op∞t vrßtit k naÜφ prvnφ p°edstav∞ volßnφ vzdßlen²ch procedur - jakmile je dokß₧eme jednoznaΦn∞ identifikovat pomocφ vhodnΘho identifikßtoru (slo₧enΘho z Φφsla programu, Φφsla verze a Φφsla procedury), m∙₧e nßm k jejich volßnφ (na stran∞ klienta) staΦit vlastn∞ jedin² prost°edek - systΘmovß rutina, pojmenovanß p°φznaΦn∞ callrpc. Ta mß celkem osm parametr∙: Na stran∞ klienta lze vystaΦit jen s tφmto jedin²m prost°edkem, pomocφ kterΘho lze volat libovolnou vzdßlenou proceduru. Jak tomu ale bude na stran∞ serveru, kde jsou jsou tyto vzdßlenΘ procedury skuteΦn∞ provßd∞ny?

Registrace vzdßlen²ch procedur

Na stran∞ serveru musφ v₧dy existovat n∞kdo, kdo mß p°ehled o slu₧bßch poskytovan²ch formou vzdßlen²ch procedur - konkrΘtn∞ o vÜech vzdßlen²ch procedurßch, kterΘ je mo₧nΘ na danΘm serveru volat. Tφm, kdo tento p°ehled mß, je tzv. RPC dispeΦer (RPC library dispatcher), kter² je jednak p°φjemcem vÜech ₧ßdostφ klient∙ o volßnφ vzdßlen²ch procedur, a jednak skuteΦn∞ volß ty lokßlnφ rutiny, kterΘ vzdßlenΘ procedury implementujφ (a v∙Φi klient∙m proto vystupuje v roli spojky serveru, viz minul² dφl). Ka₧dß lokßlnφ procedura, kterß chce implementovat n∞kterou vzdßlenou proceduru, se musφ u tohoto dispeΦera registrovat - p°itom mu musφ sd∞lit nejen to, o kterou vzdßlenou proceduru se jednß, ale i konkrΘtnφ zp∙sob svΘho volßnφ, co₧ vzhledem ke konvenci o jednom vstupnφm parametru a jednom v²stupnφm parametru vzdßlen²ch procedur znamenß v podstat∞ sd∞lenφ o tom, kterΘ konverznφ rutiny mß dispeΦer pou₧φt pro konverzi t∞chto parametr∙ z/do p°enosovΘho tvaru (nebo¥ to musφ b²t prßv∞ RPC dispeΦer, kdo pot°ebnou konverzi iniciuje).

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:

T°i ·rovn∞ RPC

Prßv∞ naznaΦen² zp∙sob vyu₧itφ mechanismu RPC (na ·rovni systΘmov²ch rutin callrpc a registerrpc) nenφ zdaleka jedin² mo₧n².

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.

zp∞t do archivu Φlßnk∙ | rejst°φk | p°edchozφ dφl | nßsledujφcφ dφl
Tento Φlßnek m∙₧e b²t voln∞ Üφ°en, pokud se tak d∞je pro studijnφ ·Φely, na nev²d∞leΦnΘm zßklad∞ a se zachovßnφm tohoto dov∞tku. Podrobnosti hledejte zde, resp. na adrese http://archiv.czech.net/copyleft.htm