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

RPC I.

Nejprve si ale zopakujme, jak²m principißlnφm zp∙sobem je v protokolu NFS °eÜen po₧adavek klienta na p°φstup ke vzdßlenΘmu souboru: k uspokojenφ tohoto po₧adavku je nutnΘ provedenφ urΦit²ch akcφ (nap°. Φtenφ Φi zßpisu na disk), kterΘ ale musφ prob∞hnout na tom poΦφtaΦi, na kterΘm se soubor skuteΦn∞ nachßzφ - tedy na poΦφtaΦi v roli serveru. Na stran∞ klienta, kter² o p°φstup ke vzdßlenΘmu souboru ₧ßdß, je proto zformulovßn po₧adavek na provedenφ t∞chto akcφ, je sestaven ve form∞ zprßvy, a tato je odeslßna serveru. Ten zprßvu p°ijme, provede po₧adovanΘ akce, a jejich v²sledek vrßtφ zp∞t klientovi jako svou odpov∞∩.

Nynφ si zkusme p°edstavit, jak²m konkrΘtnφm zp∙sobem m∙₧e b²t toto obecnΘ schΘma realizovßno. Aplikace, kterß po₧adavek na p°φstup ke vzdßlenΘmu souboru vznßÜφ, si vzhledem k pln∞ transparentnφmu sdφlenφ nemusφ v∙bec uv∞domovat, ₧e jde o vzdßlen² soubor - svou ₧ßdost tedy formuluje p°esn∞ stejn∞, jako kdyby Ülo o mφstnφ soubor (v prost°edφ Unixu formou systΘmovΘho volßnφ, viz minul² dφl). SkuteΦnost, ₧e jde o vzdßlen² soubor, si pln∞ uv∞domuje a₧ ta programovß entita, kterß p°φsluÜn² po₧adavek skuteΦn∞ vy°izuje. Ta si takΘ musφ b²t v∞doma, ₧e pracuje v prost°edφ sφt∞, musφ si uv∞domovat existenci vzdßlen²ch uzl∙ a musφ znßt zp∙sob, jak s nimi komunikovat. Tato konkrΘtnφ programovß entita, kterou ve vφce·lohovΘm prost°edφ bude nejspφÜe samostatn² proces, tedy nejprve sestavφ p°φsluÜn² po₧adavek ve form∞ zprßvy, tu odeÜle, a pak Φekß na odpov∞∩ serveru. Toto Φekßnφ p°itom bude nejspφÜe realizovßno jako suspendovßnφ p°φsluÜnΘho procesu (tedy jeho p°evedenφ ze stavu "probφhajφcφ" do stavu "Φekajφcφ"), s po₧adavkem na nßslednΘ aktivovßnφ v okam₧iku p°φchodu odpov∞di (kterß bude z°ejm∞ signalizovßna prost°ednictvφm mechanismu p°eruÜenφ).

Zkusme si prßv∞ popsan² postup zrekapitulovat: proces, kter² dostal za ·kol uspokojit po₧adavek na p°φstup ke vzdßlenΘmu souboru, zajistφ provedenφ p°φsluÜn²ch akcφ prost°ednictvφm akcφ typu odeslßnφ zprßvy a Φekßnφ na vn∞jÜφ udßlost (kterß je z jeho pohledu asynchronnφ).

Tento postup je samoz°ejm∞ mo₧n², a v praxi je takΘ hojn∞ pou₧φvßn. Je ovÜem v zßsadnφm rozporu se souΦasnou p°edstavou o tom, jak sprßvn∞ psßt programy - tedy se zßsadami strukturovanΘho programovßnφ. Vzhledem k tomu pak neumo₧≥uje nasadit osv∞dΦenΘ metody nßvrhu a v²voje rozsßhl²ch programov²ch celk∙, kterΘ jsou na strukturovanΘm programovßnφ zalo₧eny.

Obr. 78.1.: P°edstava volßnφ lokßlnφ a vzdßlenΘ procedury

P°edstava akce, kterß je iniciovßna vyslßnφm zprßvy, probφhß asynchronn∞ (nezßvisle na dalÜφm pr∙b∞hu v²poΦtu), a jejφ konec je signalizovßn p°eruÜenφm prßv∞ probφhajφcφho programu, skuteΦn∞ v∙bec nezapadß do rßmce strukturovanΘho programovßnφ - to se naopak sna₧φ dφvat na ka₧dou v²konnou akci jako na proceduru, kterß se zaΦne provßd∞t v okam₧iku jejφho zavolßnφ a konΦφ nßvratem z tΘto procedury, neboli p°edßnφm °φzenφ bezprost°edn∞ za mφsto jejφho volßnφ - viz obrßzek 78.1.

Tomu, aby se tato p°edstava mohla aplikovat i na zajiÜt∞nφ p°φstupu ke vzdßlen²m soubor∙m, stojφ v cest∞ jedna v²znamnß skuteΦnost - vlastnφ v²konnΘ akce nebudou probφhat na tom poΦφtaΦi, na kterΘm je po₧adavek na jejich provedenφ vznesen. Pokud bychom tedy cht∞li vyhov∞t zßsadßm strukturovanΘho programovßnφ, pot°ebovali bychom n∞jak² mechanismus, kter² by nßm umo₧nil volat procedury na jednom uzlovΘm poΦφtaΦi, ale skuteΦn∞ je provßd∞t na jinΘm uzlovΘm poΦφtaΦi. Tedy volat takovΘ procedury, kterΘ jsou z pohledu volajφcφho vzdßlen²mi procedurami (remote procedures). P°edstavu volßnφ takovΘto vzdßlenΘ procedury ukazuje op∞t obrßzek 78.1.: po₧adavek na provedenφ vzdßlenΘ procedury nech¥ vznßÜφ programovß entita (proces A) na stran∞ klienta, a to obvyklou formou volßnφ procedury. Tato je ovÜem vzdßlenß, proto je jejφ skuteΦnΘ provßd∞nφ zahßjeno na vzdßlenΘm uzlu (serveru). Kdy₧ provßd∞nφ tΘto procedury skonΦφ, dojde i na stran∞ klienta k p°edßnφ °φzenφ bezprost°edn∞ za mφsto volßnφ vzdßlenΘ procedury (tedy k b∞₧nΘmu nßvratu z volanΘ procedury).

Mechanismus, kter² prßv∞ naznaΦen² zp∙sob volßnφ vzdßlen²ch procedur umo₧≥uje, se pak p°φznaΦn∞ oznaΦuje jako RPC (Remote Procedure Call, doslova: volßnφ vzdßlen²ch procedur). V ideßlnφm p°φpad∞ zcela zakr²vß jak²koli rozdφl mezi volßnφm mφstnφ a vzdßlenΘ procedury, tak₧e volajφcφ si ani nemusφ b²t v∞dom, ₧e jφm volanß procedura se ve skuteΦnosti provßdφ na vzdßlenΘm poΦφtaΦi (dosa₧enφ tohoto ideßlnφho stavu ale stojφ v cest∞ n∞kterΘ technickΘ problΘmy, o kter²ch se zmφnφme pozd∞ji).

Zastavme se nynφ u toho, v Φem tkvφ skuteΦnß odliÜnost vzdßlenΘho volßnφ procedur od p∙vodnφ p°edstavy explicitnφho zasφlßnφ zprßv a Φekßnφ na odpov∞di. Samotnß komunikace mezi dv∞ma uzly sφt∞ bude v₧dy muset mφt formu p°edßvßnφ zprßv - rozdφl je zde pouze v tom, kdo a jak bude tyto zprßvy sestavovat a odesφlat, a takΘ Φekat na odpov∞di a vyhodnocovat je. V₧ijme se do postavenφ toho, kdo pφÜe programovou entitu, skuteΦn∞ zajiÜ¥ujφcφ p°φstup ke vzdßlen²m soubor∙m - v souladu s obrßzkem 78.1. proces A. Bez mechanismu RPC musφ proces A sßm explicitn∞ sestavovat a odesφlat zprßvy, vhodn²m zp∙sobem Φekat na odpov∞di a tyto pak vyhodnocovat. Ten, kdo pφÜe (a hlavn∞ ladφ) zdrojov² tvar tohoto procesu, se pak musφ obejφt bez vÜech podp∙rn²ch prost°edk∙, kterΘ pro v²voj a tvorbu strukturovan²ch program∙ existujφ.

Obr. 78.2.: P°edstava spojek (stubs)

Naproti tomu p°i existenci mechanismu RPC je vlastnφ komunikace se vzdßlen²m uzlem p°ed procesem A skryta - sestavovßnφ a odesφlßnφ zprßv i Φekßnφ na odpov∞di je zde realizovßno v rßmci programov²ch entit, kterΘ implementujφ mechanismus RPC. Tyto entity pak v∙Φi procesu A vystupujφ jako lokßlnφ procedury, kterΘ proces A m∙₧e obvykl²m zp∙sobem volat. KonkrΘtnφ p°edstavu ilustruje obrßzek 78.2.: proces A, kter² pot°ebuje zajistit provedenφ urΦit²ch akcφ na vzdßlenΘm uzlu (serveru), pouze volß p°φsluÜnou lokßlnφ proceduru, kterß je souΦßstφ implementace mechanismu RPC (a oznaΦuje se jako stub, v ΦeÜtin∞ pak: spojka). Tato spojka (procedura) zajistφ vÜe pot°ebnΘ (vΦetn∞ Φekßnφ na p°φchod odpov∞di), a potΘ °ßdn²m zp∙sobem skonΦφ, neboli vrßtφ °φzenφ zp∞t procesu A, bezprost°edn∞ za mφsto svΘho volßnφ.

Pokud bychom tedy vÜe maximßln∞ zjednoduÜili, mohli bychom se na mechanismus RPC dφvat jako na "vrstviΦku", kterß p°ekr²vß explicitnφ komunikaci se vzdßlen²m uzlem (zalo₧enou na p°edßvßnφ zprßv), a nahrazuje ji volßnφm lokßlnφch procedur (spojek).

Ve skuteΦnosti je ovÜem ·loha mechanismu RPC mnohem obecn∞jÜφ. Krom∞ p°φsluÜn²ch spojek na stran∞ klienta tento mechanismus definuje i obdobnΘ spojky na stran∞ serveru, kterΘ p°ijφmajφ zprßvy od spojek klient∙, a na jejich zßklad∞ pak volajφ v²konnΘ procedury, kterΘ zajistφ provedenφ po₧adovan²ch akcφ - tedy procedury, kterΘ jsou z pohledu klienta (procesu A) vzdßlenΘ, ale pro spojku na stran∞ serveru ji₧ jsou lokßlnφ! Dßle je souΦßstφ definice mechanismu RPC i p°esn² zp∙sob komunikace mezi spojkami klient∙ a server∙, a v neposlednφ °ad∞ i repertoßr vzdßlen²ch procedur, mo₧nosti a zp∙soby rozÜi°ovßnφ tohoto repertoßru atd.

Zastavme se ale jeÜt∞ u n∞kter²ch technick²ch aspekt∙ mechanismu RPC, kterΘ nßm umo₧nφ lΘpe pochopit jeho samotnou podstatu. V souladu s obrßzkem 78.2. vychßzejme op∞t z toho, ₧e tφm, kdo na stran∞ klienta mechanismus RPC bezprost°edn∞ vyu₧φvß (ani₧ si to nutn∞ musφ uv∞domovat), je proces A. Pokud nap°φklad pot°ebuje naΦφst Φßst souboru, kter² se nachßzφ na vzdßlenΘm poΦφtaΦi, bude za tφmto ·Φelem volat proceduru (nap°. read), kterß je ve skuteΦnosti spojkou (stub). TΘto spojce-procedu°e p°itom p°edß vÜechny pot°ebnΘ parametry stejn²m zp∙sobem, jako kterΘkoli jinΘ lokßlnφ procedu°e. Spojka pak na zßklad∞ svΘho volßnφ sestavφ zprßvu pro svou partnerskou spojku na stran∞ serveru, a v nφ mj. uvede, kterß vzdßlenß procedura mß b²t provedena. Parametry, kterΘ spojka klienta dostala p°i svΘm volßnφ, vÜak ve skuteΦnosti "pat°φ" vzdßlenΘ procedu°e. Spojka klienta je proto p°evede do takovΘho tvaru, kter² je vhodn² pro p°enos (tomuto ·konu se °φkß marshalling, nebo tΘ₧: serializing), a p°ipojφ je ke zprßv∞, odesφlanΘ spojce serveru. Tato spojka pak zprßvu p°ijme, v nφ obsa₧enΘ parametry "rozbalφ" (provede tzv. unmarshalling, tΘ₧: deserializing), a zajistφ volßnφ po₧adovanΘ procedury. Tato je pro spojku na stran∞ serveru lokßlnφ procedurou, a proto ji vÜechny pot°ebnΘ parametry p°edß zp∙sobem, obvykl²m pro lokßlnφ procedury. Jakmile v²konnß procedura skonΦφ, vrßtφ °φzenφ tomu, kdo ji volal - tedy spojce serveru. Ta vezme vÜechny p°φpadnΘ v²stupy, upravφ je do vhodnΘho tvaru pro p°enos, a odeÜle zp∞t spojce klienta.

S p°edßvßnφm parametr∙ je ovÜem spojena hned celß °ada technick²ch problΘm∙. NejjednoduÜÜφ je situace v p°φpad∞, kdy jsou parametry vzdßlenΘ procedury volßny hodnotou. Pak toti₧ staΦφ vytvo°it jejich kopii, tu odeslat spojce serveru, a p°i skuteΦnΘm volßnφ vzdßlenΘ procedury je op∞t p°edat jako parametry volanΘ hodnotou. V p°φpad∞ volßnφ referencφ (neboli: odkazem) dostßvß volanß procedura na stran∞ klienta (tj. spojka) pouze ukazatel na objekt, kter² je jejφm skuteΦn²m parametrem. Tento objekt vÜak existuje jen na stran∞ klienta, a proto nenφ mo₧nΘ pou₧φt tent²₧ ukazatel i na stran∞ serveru a p°edat jej p°i skuteΦnΘm volßnφ vzdßlenΘ procedu°e. Mo₧n²m °eÜenφm je v tomto p°φpad∞ strategie copy/restore: ta p°edpoklßdß, ₧e objekt, na kter² ukazatel ukazuje, je nejprve zkopφrovßn (resp. p°enesen) i na server. Vzdßlenß procedura pak p°i svΘm volßnφ dostane ukazatel na tento zkopφrovan² exemplß° programovΘho objektu, kter² pak m∙₧e v rßmci svΘ Φinnosti p°φsluÜn²m zp∙sobem modifikovat. Jakmile provßd∞nφ vzdßlenΘ procedury skonΦφ, je dotyΦn² objekt zase zkopφrovßn zp∞t na klienta.

DalÜφ okruh problΘm∙ je pak spojen s tφm, ₧e r∙znΘ uzlovΘ poΦφtaΦe mohou pou₧φvat odliÜnΘ konvence pro reprezentaci nejr∙zn∞jÜφch operand∙, kterΘ jsou p°edßvßny v roli parametr∙ vzdßlen²ch procedur. Proto je v rßmci "balenφ" parametr∙ p°ed p°enosem (marshalling, serializing) a p°i nßslednΘm "rozbalenφ" t°eba provßd∞t i pot°ebnΘ konverze. O tom, jak je tato otßzka °eÜena v prost°edφ TCP/IP sφtφ, si ale povφme v dalÜφch pokraΦovßnφch.