4. előadás
4.1 Távoli eljáráshívás koncepciója
A távoli eljárások hívásának ötlete (Távoli eljáráshívás – RPC) Az egy gépen futó programon belüli vezérlés és adatok átvitelének jól ismert és értett mechanizmusának kiterjesztése a vezérlés és az adatok hálózaton keresztüli átvitelére. A távoli eljáráshívási eszközöket az elosztott számítástechnika szervezésének megkönnyítésére tervezték. Az RPC használatának legnagyobb hatékonysága azokban az alkalmazásokban érhető el, amelyekben interaktív kommunikáció van a távoli komponensek között gyors válaszidővel és viszonylag kis mennyiségű adatátvitellel. Az ilyen alkalmazásokat RPC-orientáltnak nevezzük.
A lokális eljárások hívásának jellemző vonásai: aszimmetria, vagyis az egyik interakciós fél a kezdeményező; szinkronitás, vagyis a hívó eljárás végrehajtása a kérelem kibocsátásának pillanatától leáll, és csak a hívott eljárás visszatérése után folytatódik.
A távoli hívások megvalósítása sokkal bonyolultabb, mint a helyi eljáráshívások megvalósítása. Először is, mivel a hívó és a meghívott eljárások különböző gépeken futnak, eltérő címterekkel rendelkeznek, és ez problémákat okoz a paraméterek és az eredmények átadásakor, különösen, ha a gépek nem azonosak. Mivel az RPC nem támaszkodhat megosztott memóriára, ez azt jelenti, hogy az RPC-paraméterek nem tartalmazhatnak mutatókat nem verem memóriahelyekre, és a paraméterértékeket át kell másolni egyik számítógépről a másikra. A következő különbség az RPC és a helyi hívás között az, hogy szükségszerűen az alapul szolgáló kommunikációs rendszert használja, de ennek nem szabad kifejezetten láthatónak lennie sem az eljárások meghatározásában, sem magukban az eljárásokban. A távollét további problémákat vet fel. A hívó program és a hívott helyi eljárás végrehajtása ugyanazon a gépen egyetlen folyamaton belül valósul meg. Az RPC megvalósítása azonban legalább két folyamatot foglal magában – minden gépen egyet. Ha valamelyik összeomlik, a következő helyzetek adódhatnak: ha a hívási eljárás összeomlik, a távolról hívott eljárások „árvává” válnak, ha pedig a távoli eljárások összeomlik, a hívó eljárások „árva szülőkké” válnak, hiába várnak egy válasz a távoli eljárásoktól.
Ezen túlmenően a programozási nyelvek és a működési környezetek heterogenitása számos problémával jár: az egyik programozási nyelvben támogatott adatstruktúrákat és eljáráshívási struktúrákat nem minden más nyelv támogatja ugyanúgy.
Ezeket és néhány más problémát megoldja a széles körben elterjedt RPC technológia, amely számos elosztott operációs rendszer mögött áll.
Alapvető RPC műveletek
Az RPC működésének megértéséhez először fontoljuk meg egy helyi eljáráshívás kezdeményezését egy tipikus offline gépen. Legyen ez például egy rendszerhívás
count=read(fd,buf,nbytes);
ahol fd egész szám;
buf – karaktertömb;
Az nbyte egy egész szám.
A hívás indításához a hívási eljárás fordított sorrendben tolja a paramétereket a verembe. Az olvasási hívás végrehajtása után a visszatérési értéket egy regiszterbe helyezi, áthelyezi a visszatérési címet, és visszaadja a vezérlést a hívó eljáráshoz, amely paramétereket ugrik ki a veremből, visszaállítva azt eredeti állapotába. Vegye figyelembe, hogy a C nyelvben a paraméterek vagy hivatkozással (név szerint) vagy értékkel (érték szerint) hívhatók meg. A meghívott eljárással kapcsolatban az értékparaméterek inicializált helyi változók. A meghívott eljárás megváltoztathatja ezeket anélkül, hogy befolyásolná ezen változók eredeti értékét a hívó eljárásban.
Ha egy változóra mutató mutatót adunk át a meghívott eljárásnak, akkor ennek a változónak a meghívott eljárás általi megváltoztatása maga után vonja a változó értékének megváltoztatását a hívó eljáráshoz. Ez a tény nagyon fontos az RPC számára.
Van egy másik paraméterátadási mechanizmus is, amelyet a C nem használ. Ezt call-by-copy/restore-nak hívják, amely megköveteli a hívótól, hogy a változókat értékként a verembe másolja, majd a hívást követően visszamásolja őket. a hívó eljárás eredeti értékei.
A nyelvi fejlesztők döntik el, hogy melyik paraméterátadási mechanizmust használják. Néha ez az átvitt adatok típusától függ. C-ben például az egész számokat és más skaláris adatokat mindig érték, a tömböket pedig mindig hivatkozással adjuk át.
Az RPC mögött meghúzódó ötlet az, hogy egy távoli eljáráshívás a lehető leghasonlóbb legyen a helyi eljáráshíváshoz. Más szóval, tegye átláthatóvá az RPC-t: a hívó eljárásnak nem kell tudnia, hogy a hívott eljárás egy másik gépen van, és fordítva.
Az RPC a következő módon éri el az átláthatóságot. Ha a hívott eljárás valójában távoli, az eljárás egy másik verziója, az úgynevezett kliens csonk kerül a könyvtárba a helyi eljárás helyett. Az eredeti eljáráshoz hasonlóan a csonkot egy hívási szekvencia segítségével hívják meg, és a kernel elérésekor megszakítás történik. Csak az eredeti eljárástól eltérően nem helyez el paramétereket a regiszterekbe, és nem kér adatokat a kerneltől, hanem üzenetet generál, amelyet a távoli gép kernelének küld.
RPC végrehajtási szakaszok
A szoftverkomponensek interakcióját távoli eljáráshívás végrehajtásakor a 2. ábra szemlélteti.
2. ábra Távoli eljáráshívás
Miután az ügyfélprogram meghívta a kliens csonkot, az első feladata a puffer feltöltése a küldendő üzenettel. Egyes rendszerekben az ügyfélcsonk egyetlen rögzített hosszúságú pufferrel rendelkezik, amely minden új kéréssel a kezdetektől fogva feltöltődik. Más rendszerekben az üzenetpuffer az egyes üzenetmezők puffereinek készlete, amelyek közül néhány már megtelt. Ez a módszer különösen alkalmas olyan esetekben, amikor a csomag formátuma nagyszámú mezőből áll, de sok mező értéke nem változik hívásról hívásra.
A paramétereket ezután a megfelelő formátumba kell konvertálni, és be kell illeszteni az üzenetpufferbe. Ezen a ponton az üzenet készen áll az elküldésre, így a kernelhívás megszakítása végrehajtódik.
Amikor a kernel átveszi az irányítást, kontextust vált, a processzorregisztereket és a memórialeképezést (oldalkezelőket) menti, és új memórialeképezést telepít, amelyet kernel módban fog használni. Mivel a kernel és a felhasználói kontextus különbözik, a kernelnek pontosan be kell másolnia az üzenetet a saját címterébe, hogy hozzáférhessen, emlékezzen a célcímre (és esetleg más fejlécmezőkre), és át kell adnia a hálózati interfésznek. Ezzel befejeződik a munka a kliens oldalon. Az átviteli időzítő be van kapcsolva, és a kernel ciklikusan lekérdezheti a választ, vagy átadhatja a vezérlést az ütemezőnek, amely kiválaszt egy másik folyamatot a futtatásra. Az első esetben a lekérdezés végrehajtása felgyorsul, de a többprogramozás hiányzik.
A szerver oldalon a bejövő biteket a fogadó hardver egy chipen lévő pufferbe vagy a RAM-ba helyezi. Amikor minden információ megérkezett, megszakítás jön létre. A megszakításkezelő ellenőrzi a csomagadatok helyességét, és meghatározza, hogy melyik csonknak kell azokat elküldeni. Ha egyik csonk sem várja ezt a csomagot, a kezelőnek vagy pufferelnie kell, vagy teljesen el kell dobnia. Ha van egy várakozó csonk, az üzenet átmásolódik rá. Végül egy kontextusváltást hajtanak végre, amelynek eredményeként a regiszterek és a memóriatérkép visszaáll, felveszi azokat az értékeket, amelyek abban a pillanatban voltak, amikor a csonk fogadta a hívást.
Most a kiszolgáló csonkja elkezd működni. Kicsomagolja a paramétereket, és megfelelően a verembe tolja. Amikor minden készen áll, hívás történik a szerver felé. Az eljárás végrehajtása után a szerver továbbítja az eredményeket a kliensnek. Ehhez hajtsa végre az összes fent leírt lépést, csak fordított sorrendben.
A 3. ábra az egyes RPC-hívásokhoz végrehajtandó parancsok sorrendjét mutatja.
3. ábra. Az RPC eljárás lépései
) Távoli eljáráshívás koncepciója
A Remote Procedure Call (RPC) ötlete az, hogy kiterjessze a jól ismert és értett mechanizmust a vezérlés és az adatok átvitelére egy egyetlen gépen futó programon belül a vezérlés és az adatok hálózaton keresztüli átvitelére. A távoli eljáráshívási eszközöket az elosztott számítástechnika szervezésének megkönnyítésére tervezték. Az RPC használatának legnagyobb hatékonysága azokban az alkalmazásokban érhető el, amelyekben interaktív kommunikáció van a távoli komponensek között gyors válaszidővel és viszonylag kis mennyiségű adatátvitellel. Az ilyen alkalmazásokat RPC-orientáltnak nevezzük.
A helyi eljárások hívásának jellemzői:
Aszimmetria, vagyis az egyik interakciós fél a kezdeményező; A szinkronitás, vagyis a hívó eljárás végrehajtása a kérés kibocsátásának pillanatától leáll, és csak a hívott eljárás visszatérése után folytatódik.
A távoli hívások megvalósítása sokkal bonyolultabb, mint a helyi eljáráshívások megvalósítása. Először is, mivel a hívó és a meghívott eljárások különböző gépeken futnak, eltérő címterekkel rendelkeznek, és ez problémákat okoz a paraméterek és az eredmények átadásakor, különösen, ha a gépek nem azonosak. Mivel az RPC nem támaszkodhat megosztott memóriára, ez azt jelenti, hogy az RPC-paraméterek nem tartalmazhatnak mutatókat nem verem memóriahelyekre, és a paraméterértékeket át kell másolni egyik számítógépről a másikra. A következő különbség az RPC és a helyi hívás között az, hogy szükségszerűen az alapul szolgáló kommunikációs rendszert használja, de ennek nem szabad kifejezetten láthatónak lennie sem az eljárások meghatározásában, sem magukban az eljárásokban. A távollét további problémákat vet fel. A hívó program és a hívott helyi eljárás végrehajtása ugyanazon a gépen egyetlen folyamaton belül valósul meg. Az RPC megvalósítása azonban legalább két folyamatot foglal magában – minden gépen egyet. Ha valamelyik összeomlik, a következő helyzetek adódhatnak: ha a hívási eljárás összeomlik, a távolról hívott eljárások „árvává” válnak, ha pedig a távoli eljárások összeomlik, a hívó eljárások „árva szülőkké” válnak, hiába várnak egy válasz a távoli eljárásoktól.
Ezen túlmenően a programozási nyelvek és a működési környezetek heterogenitása számos problémával jár: az egyik programozási nyelvben támogatott adatstruktúrákat és eljáráshívási struktúrákat nem minden más nyelv támogatja ugyanúgy.
Ezeket és néhány más problémát megoldja a széles körben elterjedt RPC technológia, amely számos elosztott operációs rendszer mögött áll.
Alapvető RPC műveletek
Az RPC működésének megértéséhez először fontoljuk meg egy helyi eljáráshívás kezdeményezését egy tipikus offline gépen. Legyen ez például egy rendszerhívás
Count=read(fd,buf,nbytes);
ahol fd egész szám,
buf - karakterek tömbje,
Az nbyte egy egész szám.
A hívás indításához a hívási eljárás fordított sorrendben tolja a paramétereket a verembe (3.1. ábra). Az olvasási hívás végrehajtása után a visszatérési értéket egy regiszterbe helyezi, áthelyezi a visszatérési címet, és visszaadja a vezérlést a hívó eljáráshoz, amely paramétereket ugrik ki a veremből, visszaállítva azt eredeti állapotába. Vegye figyelembe, hogy a C nyelvben a paraméterek vagy hivatkozással (név szerint) vagy értékkel (érték szerint) hívhatók meg. A meghívott eljárással kapcsolatban az értékparaméterek inicializált helyi változók. A meghívott eljárás megváltoztathatja ezeket anélkül, hogy befolyásolná ezen változók eredeti értékét a hívó eljárásban.
Ha egy változóra mutató mutatót adunk át a meghívott eljárásnak, akkor ennek a változónak a meghívott eljárás általi megváltoztatása maga után vonja a változó értékének megváltoztatását a hívó eljáráshoz. Ez a tény nagyon fontos az RPC számára.
Van egy másik paraméterátadási mechanizmus is, amelyet a C nem használ. Ezt call-by-copy/restore-nak hívják, amely megköveteli a hívótól, hogy a változókat értékként a verembe másolja, majd a hívást követően visszamásolja őket. a hívó eljárás eredeti értékei.
A nyelvi fejlesztők döntik el, hogy melyik paraméterátadási mechanizmust használják. Néha ez az átvitt adatok típusától függ. C-ben például az egész számokat és más skaláris adatokat mindig érték, a tömböket pedig mindig hivatkozással adjuk át.
Rizs. 3.1. a) Az olvasási hívás végrehajtása előtti verem;
b) Verem az eljárás végrehajtása során;
c) Verem a hívó programba való visszatérés után
Az RPC mögött meghúzódó ötlet az, hogy egy távoli eljáráshívás a lehető leghasonlóbb legyen a helyi eljáráshíváshoz. Más szóval, tegye átláthatóvá az RPC-t: a hívó eljárásnak nem kell tudnia, hogy a hívott eljárás egy másik gépen van, és fordítva.
Az RPC a következő módon éri el az átláthatóságot. Ha a hívott eljárás valójában távoli, az eljárás egy másik verziója, az úgynevezett kliens csonk kerül a könyvtárba a helyi eljárás helyett. Az eredeti eljáráshoz hasonlóan a csonkot egy hívási szekvencia segítségével hívják meg (mint a 3.1. ábrán), és megszakítás történik a kernel elérésekor. Csak az eredeti eljárástól eltérően nem helyez el paramétereket a regiszterekbe, és nem kér adatokat a kerneltől, hanem üzenetet generál, amelyet a távoli gép kernelének küld.
RPC végrehajtási szakaszok
A szoftverkomponensek interakcióját távoli eljáráshívás végrehajtásakor a 3.2. ábra szemlélteti. Miután az ügyfélprogram meghívta a kliens csonkot, az első feladata a puffer feltöltése a küldendő üzenettel. Egyes rendszerekben az ügyfélcsonk egyetlen rögzített hosszúságú pufferrel rendelkezik, amely minden új kéréssel a kezdetektől fogva feltöltődik. Más rendszerekben az üzenetpuffer az egyes üzenetmezők puffereinek készlete, amelyek közül néhány már megtelt. Ez a módszer különösen alkalmas olyan esetekben, amikor a csomag formátuma nagyszámú mezőből áll, de sok mező értéke nem változik hívásról hívásra.
A paramétereket ezután a megfelelő formátumba kell konvertálni, és be kell illeszteni az üzenetpufferbe. Ezen a ponton az üzenet készen áll az elküldésre, így a kernelhívás megszakítása végrehajtódik.
Rizs. 3.2. Távoli eljáráshívás
Amikor a kernel átveszi az irányítást, kontextust vált, a processzorregisztereket és a memórialeképezést (oldalkezelőket) menti, és új memórialeképezést telepít, amelyet kernel módban fog használni. Mivel a kernel és a felhasználói kontextus különbözik, a kernelnek pontosan be kell másolnia az üzenetet a saját címterébe, hogy hozzáférhessen, emlékezzen a célcímre (és esetleg más fejlécmezőkre), és át kell adnia a hálózati interfésznek. Ezzel befejeződik a munka a kliens oldalon. Az átviteli időzítő be van kapcsolva, és a kernel ciklikusan lekérdezheti a választ, vagy átadhatja a vezérlést az ütemezőnek, amely kiválaszt egy másik folyamatot a futtatásra. Az első esetben a lekérdezés végrehajtása felgyorsul, de a többprogramozás hiányzik.
A szerver oldalon a bejövő biteket a fogadó hardver egy chipen lévő pufferbe vagy a RAM-ba helyezi. Amikor minden információ megérkezett, megszakítás jön létre. A megszakításkezelő ellenőrzi a csomagadatok helyességét, és meghatározza, hogy melyik csonknak kell azokat elküldeni. Ha egyik csonk sem várja ezt a csomagot, a kezelőnek vagy pufferelnie kell, vagy teljesen el kell dobnia. Ha van egy várakozó csonk, az üzenet átmásolódik rá. Végül egy kontextusváltást hajtanak végre, amelynek eredményeként a regiszterek és a memóriatérkép visszaáll, felveszi azokat az értékeket, amelyek abban a pillanatban voltak, amikor a csonk fogadta a hívást.
Most a kiszolgáló csonkja elkezd működni. Kicsomagolja a paramétereket, és megfelelően a verembe tolja. Amikor minden készen áll, hívás történik a szerver felé. Az eljárás végrehajtása után a szerver továbbítja az eredményeket a kliensnek. Ehhez hajtsa végre az összes fent leírt lépést, csak fordított sorrendben.
A 3.3. ábra mutatja az egyes RPC-hívásokhoz végrehajtandó parancsok sorrendjét, a 3.4. ábra pedig azt, hogy a teljes RPC-végrehajtási idő mekkora hányadát fordítják a leírt 14 lépés mindegyikére. A teszteket egy DEC Firefly többprocesszoros munkaállomáson végezték, és bár az öt processzor jelenléte szükségszerűen befolyásolta a mérési eredményeket, az ábrán látható hisztogram általános képet ad az RPC végrehajtási folyamatáról.
Rizs. 3.3. Az RPC eljárás végrehajtásának lépései
Rizs. 3.4. Időeloszlás az RPC végrehajtás 14 szakasza között
1. Csonk hívása
2. Készítsen puffert
3. Csomagolási paraméterek
4. Töltse ki a cím mezőt
5. Számítsa ki az üzenetben szereplő ellenőrző összeget
6. Megszakítás a kernelhez
7. Csomag várakozási sor a végrehajtáshoz
8. Üzenet továbbítása a vezérlőnek a QBUS buszon keresztül
9. Ethernet átviteli idő
10. Csomag fogadása a vezérlőtől
11. Megszakítás kezelési eljárás
12. Ellenőrzőösszeg számítás
13. Kontextus váltás felhasználói térre
14. Szerver csonk végrehajtása
Dinamikus linkelés
Nézzük meg, hogyan határozza meg a kliens a szerver helyét. A probléma megoldásának egyik módja a kiszolgáló hálózati címének közvetlen használata az ügyfélprogramban. Ennek a megközelítésnek a hátránya a rendkívüli rugalmatlanság: egy szerver mozgatásakor, vagy a szerverek számának növelésekor, illetve ezekben és még sok más esetben is újra kell fordítani minden olyan programot, amely keményen kódolt szervercímet használt. Mindezen problémák elkerülése érdekében egyes elosztott rendszerek úgynevezett dinamikus linkelést alkalmaznak.
A dinamikus kötés kiindulópontja a szerver formális meghatározása (specifikációja). A specifikáció tartalmazza a fájlszerver nevét, a verziószámot és a szerver által az ügyfelek számára biztosított szolgáltatási eljárások listáját (3.5. ábra). Minden eljáráshoz meg van adva a paramétereinek leírása, jelezve, hogy ez a paraméter bemeneti vagy kimeneti a szerverhez képest. Egyes paraméterek bemeneti és kimeneti is lehetnek – például néhány tömb, amelyet a kliens elküld a szervernek, ott módosít, majd visszaküldi a kliensnek (másolás/visszaállítás művelet).
Rizs. 3.5. RPC szerver specifikáció
A formális szerverspecifikáció a csonkgenerátor program bemeneteként szolgál, amely kliens- és szervercsonkokat is létrehoz. Ezután a megfelelő könyvtárakba kerülnek. Amikor egy felhasználói (kliens) program meghív egy, a kiszolgáló specifikációjában meghatározott eljárást, a megfelelő csonk eljárás a program bináris kódjához van társítva. Hasonlóképpen, amikor egy kiszolgálót lefordítanak, a szerver csonkok hozzá vannak rendelve.
Amikor egy szerver elindul, a legelső dolga az, hogy átadja a szerver interfészét egy speciális programnak, az úgynevezett bindernek. Ez a szerverregisztrációs folyamatként ismert folyamat során a szerver átadja a nevét, verziószámát, egyedi azonosítóját és egy A kezelő rendszerfüggetlen, lehet IP, Ethernet, X.500 vagy más cím, és tartalmazhat egyéb információkat is, például hitelesítéssel kapcsolatos információkat.
Amikor egy kliens először hívja meg az egyik távoli eljárást, például olvassa el, a kliens csonkja azt látja, hogy még nem csatlakozik a szerverhez, és üzenetet küld a binder programnak azzal a kéréssel, hogy importálja a kívánt felületet. a kívánt szerver verziója. Ha létezik ilyen szerver, akkor a binder átadja a leírót és az egyedi azonosítót a kliens csonknak.
Amikor egy kérést tartalmazó üzenetet küld, a kliens csonk egy leírót használ címként. Az üzenet paramétereket és egy egyedi azonosítót tartalmaz, amelyet a kiszolgálómag arra használ, hogy a bejövő üzenetet a kívánt kiszolgálóra irányítsa, ha több ilyen van a gépen.
Az interfészek importálásának/exportálásának ez a módja rendkívül rugalmas. Például több szerver is támogathatja ugyanazt a felületet, és az ügyfelek véletlenszerűen vannak elosztva a szerverek között. Ennek a módszernek a keretein belül lehetővé válik a szerverek időszakos lekérdezése, teljesítményük elemzése és hiba esetén automatikus leállítás, ami növeli a rendszer általános hibatűrő képességét. Ez a módszer támogatja a kliens hitelesítést is. Például a szerver meghatározhatja, hogy csak egy adott listán szereplő ügyfelek használhatják.
A dinamikus összerendelésnek azonban vannak hátrányai, például többletköltség (idő) az interfészek exportálásához és importálásához. Ezeknek a költségeknek a nagysága jelentős lehet, mivel sok kliens folyamat rövid ideig létezik, és minden egyes folyamat indulásakor újra el kell végezni az interfész importálási eljárást. Emellett a nagy elosztott rendszerekben a binder program szűk keresztmetszetgé válhat, és több hasonló célú program létrehozása is megnöveli a folyamatok létrehozásának és szinkronizálásának költségeit.
RPC szemantika hibák esetén
Ideális esetben az RPC-nek még meghibásodások esetén is megfelelően kell működnie. Vegye figyelembe a következő hibaosztályokat:
A kliens nem találja meg a kiszolgálót, például ha a kívánt szerver meghibásodik, vagy mert a kliensprogramot régen fordították le, és a szerver interfész régi verzióját használta. Ebben az esetben a kliens kérésére egy hibakódot tartalmazó üzenet érkezik. A klienstől a szerver felé küldött kérés elveszett. A legegyszerűbb megoldás, ha egy bizonyos idő elteltével megismételjük a kérést. A szervertől az ügyfélnek küldött válaszüzenet elveszett. Ez a lehetőség bonyolultabb, mint az előző, mivel egyes eljárások nem idempotensek. Idempotens eljárásnak nevezzük azt az eljárást, amelynek végrehajtási kérése többször megismételhető az eredmény megváltoztatása nélkül. Ilyen eljárás például egy fájl olvasása. De egy bizonyos összeg bankszámláról történő felvételének eljárása nem idempotens, és ha a válasz elveszik, az ismételt kérés jelentősen megváltoztathatja az ügyfél számlájának állapotát. Az egyik lehetséges megoldás az összes eljárás idempotenssé tétele. A gyakorlatban azonban ez nem mindig lehetséges, ezért egy másik módszer is használható - az összes kérés szekvenciális számozása a kliens kernel által. A szervermag megjegyzi az egyes kliensek legfrissebb kérésének számát, és minden kérés beérkezésekor elemzi, hogy ez a kérés elsődleges vagy ismétlődő. A szerver összeomlott, miután megkapta a kérést. Itt is fontos az idempotencia tulajdonsága, de sajnos a lekérdezésszámozásos megközelítés nem alkalmazható. Ebben az esetben ez számít
A Java RMI mint távoli eljáráshívás típusa, független a hálózattól, a vele való munka fő lépéseitől és céljától. Elosztott és nem terjesztett Java programok összehasonlítása. A Java RMI architektúrája, csonkja és váza, távoli referencia- és szállítási rétegei.
SQL lekérdezések előzetes összeállítása a végrehajtási helyen. A readyStatement utasítás használata. Használja a hívásdefiníciós szintaxist egy eljárás vagy függvény visszatérési értékének megszerzéséhez. Kérésre mintavételi utasítás készítése.
A munka célja és rendszere. Összeállítás és telepítés. http csomag eljárás specifikáció.
Az eljárások és funkciók olyan zárt programegységekként definiálhatók, amelyek egy bizonyos algoritmust valósítanak meg. Valójában egy eljárás vagy függvény szinte program.
Automatizált TCP/IP konfiguráció, dinamikus konfiguráció BOOTP használatával. IP-címek kérése/válaszolása, üzenetvesztés és -formátum, BOOTP fázisok. A DHCP protokoll a BOOTP protokoll kiterjesztése. IP-címek kiosztása és kiosztása.
A rekurzió fogalmával már találkoztunk: az ismétlődési relációk meglehetősen gyakran megtalálhatók a matematikai kifejezésekben. A definícióban való rekurzió abban áll, hogy a definiált fogalmat ezen a fogalomon keresztül határozzuk meg.
1. Bevezetés 2 2. A COM technológia áttekintése 2 2.1. Egy COM objektum összetétele 3 2.2. Interfészek 4 2.3. COM objektumok tulajdonságai 6 2.4. COM szerverek 6 2.5. Rendező mechanizmus 7
A távoli adatbázisok lényegének, működési elvének és fő céljának tanulmányozása. Távoli adatkezelési modell (fájlszerver modell). A párhuzamosság típusai. A trigger az adatbázis állapotához kapcsolódó különleges események nyomon követésére szolgáló mechanizmus.
Metamodell, tény és biztonsági csomagok. Az ügyfél fogalmi modellje. Példa az elosztott architektúra működésére. A megvalósítás összetettsége.
Dll koncepció. Emlékezzünk a programozási folyamatra DOS-ban. A forrásszöveg gépi kódká konvertálása két folyamatot tartalmazott: a fordítást és az összekapcsolást. Az összekapcsolás során nem csak a függvények és eljárások deklarációi, hanem azok teljes kódja is bekerült a programkódba.
Funkciók a TCP/IP protokollal való munkavégzéshez, Socket, Bind, hallgatni és elfogadni. Fájlleíró. Kommunikációs folyamatok. Adatok fogadása. Olvasás konnektorból. Írjon egy aljzatba. Az aljzat bezárása. A QNX operációs rendszerben webszervert létrehozó program szövege.
A hálózati felhasználók hozzáférése a szerveren tárolt elektronikus üzenetekhez. A program leírása, egyszerű hitelesítés, APOP és AUTH hitelesítés. Funkciók megvalósítása, felhasználói kézikönyv, program működési algoritmusok, grafikus felület.
A Turbo-Paskal programozási nyelv főbb operátorainak működési elve: hozzárendelés operátor, Esetválasztás, feltétel nélküli ugrás, ciklus, fogás, összetett. Egy függvény és eljárás formális leírása és meghívása. A tényleges paraméterek listájára vonatkozó követelmények.
A Java servletek működési elve és célja, jelentősége a webszerverek funkcionalitásának növelésében és programozásuk fejlesztésében, a használat előnyei és hátrányai. A servletek böngészőből és oldalról történő hívásának módjai. A munkamenet attribútumainak írása és olvasása.
A Windows NT OS architektúrája. Az operációs rendszer felépítése mikrokernelen alapul. A Windows NT védett alrendszerei.
Alapvető üzenettovábbítási primitívek elosztott rendszerekben. Megszólítási módszerek. Blokkoló és nem blokkoló primitívek. Pufferelt és nem pufferelt primitívek.
Alkalmazások szervere. Ügyfél rész.
Két évvel ezelőtt az AJAX újdonság volt (és magát az AJAX szót még nem találták fel). Mostantól napirenden lévő webes alkalmazások, amelyek oldalai menet közben frissülnek. Éppen ellenkezőleg: nehéz elképzelni néhány szolgáltatást AJAX nélkül.
Szintaxis egy eljárás leírására és meghívására. Lehetőségek. Példa az eljárás leírására és hívásra. A paraméterek típusai. Program.
A kliens-szerver alkalmazásokhoz egy nagyon fontos mechanizmust biztosít az RPC ( Távoli eljáráshívás). Az RPC-t a Sun Micrsystems fejlesztette ki, és eszközök és könyvtári funkciók gyűjteménye. Különösen a NIS (Network Information System) és az NFS (Network File System) működik RPC-n.
Az RPC-kiszolgáló olyan eljárások rendszeréből áll, amelyekhez az ügyfél az eljárás paramétereivel együtt egy RPC-kérést küld a szervernek. A szerver meghívja a kijelölt eljárást, és visszaadja az eljárás visszatérési értékét, ha van ilyen. A gépfüggetlenség érdekében a kliens és a szerver között kicserélt összes adatot úgynevezett külső adatábrázolásra alakítják ( Külső adatábrázolás, XDR). Az RPC UDP és TCP socketekkel kommunikál az adatok XDR formátumú átviteléhez. A Sun az RPC-t közkinccsé nyilvánította, és leírása számos RFC-dokumentumban elérhető.
Néha az RPC-alkalmazások változásai inkompatibilitást okoznak az interfészhívási eljárásban. Természetesen egy egyszerű változtatás azt eredményezné, hogy a szerver összeomol minden olyan alkalmazást, amely még mindig ugyanazokra a hívásokra vár. Ezért az RPC-programokhoz verziószámok vannak hozzárendelve, amelyek általában 1-gyel kezdődnek. Az RPC minden új verziója nyomon követi a verziószámot. A szerver gyakran több verziót is kínál egyidejűleg. Az ügyfelek ebben az esetben megadják a használni kívánt verziószámot.
Az RPC szerverek és a kliensek közötti hálózati kommunikáció egy kicsit különleges. Az RPC szerver egy vagy több rendszereljárást kínál, ezek mindegyikét programnak nevezzük ( program) és egyedileg azonosítható a programszám alapján ( programszám). A szolgáltatásnevek listája általában az /etc/rpc könyvtárban található, erre az alábbiakban egy példát mutatunk be.
Példa 12-4. Minta /etc/rpc fájl
| # # /etc/rpc - vegyes RPC-alapú szolgáltatások # portmapper 100000 portmap sunrpc rstatd 100001 rstat rstat_svc rup perfmeter rusersd 100002 rusers nfs 100003 nfsprog yprogmount0 mount0yp0mount 5yp0000 bind 100007 walld 100008 rwall shutdown yppasswdd 100009 yppasswd bootparam 100026 ypupdated 100028 ypupdate |
A TCP/IP hálózatokban az RPC készítői azzal a feladattal álltak szemben, hogy a programszámokat leképezzék az általános hálózati szolgáltatásokra. Minden kiszolgáló minden programhoz és verzióhoz biztosít egy TCP- és UDP-portot. Az RPC-alkalmazások általában UDP-t használnak az adatok továbbítására, és visszatérnek a TCP-re, ha a továbbítandó adatok nem férnek el egyetlen UDP-datagramba.
Természetesen a kliensprogramoknak módot kell adni arra, hogy kitalálják, melyik port felel meg a programszámnak. Ehhez egy konfigurációs fájl használata túl rugalmatlan lenne; Mivel az RPC-alkalmazások nem használnak fenntartott portokat, nincs garancia arra, hogy a portot nem foglalja el valamelyik alkalmazás, és az elérhető számunkra. Ezért az RPC-alkalmazások kiválasztanak minden fogadható portot, és regisztrálják azt portmapper démon. Az az ügyfél, aki egy adott programszámmal szeretne kapcsolatba lépni egy szolgáltatással, először kéri a portmappert, hogy megtudja a kívánt szolgáltatás portszámát.
Ennek a módszernek az a hátránya, hogy egyetlen hibapontot vezet be, hasonlóan inetd démon Ez az eset azonban egy kicsit rosszabb, mert amikor a portmapper meghibásodik, a portokkal kapcsolatos összes RPC információ elvész. Ez általában azt jelenti, hogy manuálisan kell újraindítania az összes RPC-kiszolgálót, vagy újra kell indítania a gépet.
Linuxon a portmapper neve /sbin/portmap vagy /usr/sbin/rpc.portmap. Eltekintve attól, hogy a hálózati indítószkriptből kell elindítani, a portmapper nem igényel konfigurációs munkát.
Remote Procedure Call RPC A Remote Procedure Call koncepciója A Remote Procedure Call (RPC) ötlete az, hogy kiterjessze az egy gépen futó programon belüli vezérlés és adatok átvitelének jól ismert és értett mechanizmusát a vezérlés és az adatok hálózaton keresztüli átvitelére. A távoli eljáráshívási eszközök az elosztott számítástechnika megszervezését hivatottak elősegíteni.Az RPC használatának legnagyobb hatékonysága azokban az alkalmazásokban érhető el, amelyekben rövid válaszidővel és viszonylag kis mennyiségű adatátvitellel interaktív kommunikáció van a távoli komponensek között.
Az ilyen alkalmazásokat RPC-orientáltnak nevezzük. A helyi eljárások hívásának jellegzetessége az Aszimmetria, vagyis az egyik interakcióba lépő fél a kezdeményező Szinkronitás, vagyis a hívó eljárás végrehajtása a kérés kibocsátásának pillanatától leáll, és csak a hívott eljárásból való visszatérés után folytatódik. A távoli hívások megvalósítása sokkal bonyolultabb, mint a helyi eljárásokra irányuló hívások megvalósítása.
Először is, mivel a hívó és a hívott eljárások különböző gépeken futnak le, eltérő címterekkel rendelkeznek, és ez problémákat okoz a paraméterek és az eredmények átadásakor, különösen, ha a gépek nem azonosak. Mivel az RPC nem támaszkodhat megosztott memóriára, ez azt jelenti, hogy hogy az RPC paraméterek nem tartalmazhatnak mutatókat nem verem memóriahelyekre, és hogy a paraméterértékeket át kell másolni egyik számítógépről a másikra.
A következő különbség az RPC és a helyi hívás között az, hogy szükségszerűen az alapul szolgáló kommunikációs rendszert használja, de ennek nem szabad kifejezetten láthatónak lennie sem az eljárások meghatározásában, sem magukban az eljárásokban. A távollét további problémákat vet fel. A hívó program és a hívott helyi eljárás ugyanazon a gépen történő végrehajtása egyetlen folyamaton belül valósul meg, de az RPC megvalósítása legalább két folyamatot foglal magában - minden gépben egyet.
Ha valamelyikük összeomlik, akkor a következő helyzetek adódhatnak: ha a hívó eljárás lefagy, a távolról hívott eljárások árvává válnak, ha pedig a távoli eljárások, akkor a hívó eljárások árva szülőkké válnak, akik hiába várnak a válaszra. Ezen túlmenően a programozási nyelvek és működési környezetek heterogenitása számos problémát jelent, az egyik programozási nyelvben támogatott adatstruktúrák és eljáráshívási struktúrák nem támogatottak minden más programozási nyelvben. nyelvek.
Ezeket és néhány más problémát megoldja a széles körben elterjedt RPC technológia, amely számos elosztott operációs rendszer mögött áll. Alapvető RPC-műveletek Az RPC működésének megértéséhez először fontoljuk meg, hogy indítsunk el egy helyi eljáráshívást egy hagyományos gépen, amely autonóm módon fut. Legyen például az fd,buf,nbytes rendszerhívások száma, ahol fd egy egész szám, a buf egy tömb A karakterek közül az nbyte egy egész szám.
A hívás indításához a hívási eljárás a paramétereket a verembe tolja a 3.1. ábra fordított sorrendjében. Az olvasási hívás végrehajtása után a visszatérési értéket egy regiszterbe helyezi, áthelyezi a visszatérési címet, és visszaadja a vezérlést a hívó eljáráshoz, amely kiugrik a paraméterek a veremből, visszaállítva azt eredeti állapotába. hívható hivatkozással vagy névvel vagy értékkel. A meghívott eljárással kapcsolatban az értékparaméterek inicializált helyi változók.
A meghívott eljárás megváltoztathatja ezeket anélkül, hogy befolyásolná ezen változók eredeti értékét a hívó eljárásban. Ha egy változóra mutató mutatót adunk át a meghívott eljárásnak, akkor ennek a változónak az értékének megváltoztatása a meghívott eljárással azt jelenti, hogy ennek a változónak az értékét is megváltoztatjuk a hívó eljáráshoz, ami az RPC esetében nagyon fontos. Van egy másik mechanizmus is a paraméterek átadására, amelyet nem használ a C. Ezt hívják másolatonkénti visszaállításnak, és a hívó program a változókat értékként a verembe másolja, majd visszamásolja őket, miután a hívás megtörtént az eredetire. a hívó eljárás értékeit.
A nyelvi fejlesztők döntik el, hogy melyik paraméterátadási mechanizmust használják. Néha ez az átadott adatok típusától függ.C-ben például az egész számok és más skaláris adatok mindig érték szerint, a tömbök pedig mindig hivatkozással kerülnek átadásra.
Rizs. 3.1. a A verem az olvasási hívás végrehajtása előtt b A verem az eljárás végrehajtása közben c A verem a hívó programhoz való visszatérés után Az RPC mögött az az elgondolás, hogy egy távoli eljárás hívása a lehető leghasonlóbb legyen egy helyi eljárás. Más szóval, az RPC átláthatóvá tételéhez a hívó eljárásnak nem kell tudnia, hogy a hívott eljárás egy másik gépen van, és fordítva: az RPC a következő módon éri el az átláthatóságot.
Ha a hívott eljárás valójában távoli, a helyi eljárás helyett az eljárás egy másik verziója, az úgynevezett kliens csonk kerül a könyvtárba. Az eredeti eljáráshoz hasonlóan a csonkot a 3.1. ábrán látható hívási sorrend használatával hívják meg, és a kernel elérésekor megszakítás történik. Csak az eredeti eljárástól eltérően nem helyez el paramétereket a regiszterekbe, és nem kér adatokat a kerneltől, hanem üzenetet generál, amelyet a távoli gép kernelének küld. Az RPC végrehajtás szakaszai A szoftverkomponensek interakcióját távoli eljáráshívás végrehajtásakor a 3.2. ábra szemlélteti. Miután az ügyfélprogram meghívta a kliens csonkot, az első feladata a puffer feltöltése a küldendő üzenettel.
Egyes rendszerekben az ügyfélcsonk egyetlen rögzített hosszúságú pufferrel rendelkezik, amely minden új kéréssel a kezdetektől fogva feltöltődik. Más rendszerekben az üzenetpuffer az egyes üzenetmezők puffereinek készlete, amelyek közül néhány már megtelt.
Ez a módszer különösen alkalmas olyan esetekben, amikor a csomag formátuma nagyszámú mezőből áll, de sok mező értéke nem változik hívásról hívásra. A paramétereket ezután a megfelelő formátumra kell konvertálni és be kell illeszteni az üzenetpufferbe, ekkor az üzenet készen áll a küldésre, így a kernelhívás megszakítása végrehajtódik. Rizs. 3.2. Távoli eljáráshívás Amikor a kernel átveszi az irányítást, kontextust vált, elmenti a processzorregisztereket és a memórialeképezés oldalkezelőit, és új memórialeképezést telepít, amelyet kernel módban fog használni. Mivel a kernel és a felhasználói kontextus különbözik, a kernelnek pontosan be kell másolnia az üzenetet a saját címterébe, hogy el tudja érni, emlékezzen a célcímre és esetleg más fejlécmezőkre, és át kell adnia a hálózati interfésznek.
Ezzel befejeződik a munka a kliens oldalon.
Az átviteli időzítő be van kapcsolva, és a kernel ciklikusan lekérdezheti a választ, vagy átadhatja a vezérlést az ütemezőnek, amely kiválaszt egy másik folyamatot a futtatásra. Az első esetben a lekérdezés végrehajtása felgyorsul, de a többprogramozás hiányzik. Szerver oldalon a bejövő biteket a fogadó hardver vagy a beépített pufferbe, vagy a RAM-ba helyezi, és az összes információ vételekor megszakítás generálódik.
A megszakításkezelő ellenőrzi a csomag adatainak érvényességét, és meghatározza, hogy melyik csonknak adja át, Ha pedig nem várja a csomagot, a megszakításkezelőnek vagy pufferelnie kell, vagy teljesen el kell dobnia. Ha van egy várakozó csonk, az üzenet átmásolódik rá. Végül egy kontextusváltást hajtanak végre, amelynek eredményeként a regiszterek és a memóriatérkép visszaáll, felveszi azokat az értékeket, amelyek abban a pillanatban voltak, amikor a csonk fogadta a hívást.
Most a kiszolgáló csonkja elkezd működni. Kicsomagolja a paramétereket, és megfelelően a verembe tolja. Amikor minden készen áll, hívás történik a szerver felé. Az eljárás befejezése után a szerver továbbítja az eredményeket a kliensnek, ehhez az összes fent leírt lépést végrehajtja, csak fordított sorrendben. A 3.3. ábra mutatja az egyes RPC-hívásokhoz végrehajtandó parancsok sorrendjét, a 3.4. ábra pedig azt, hogy a teljes RPC-végrehajtási idő mekkora hányadát fordítják a leírt 14 lépés mindegyikére.
A teszteket egy DEC Firefly többprocesszoros munkaállomáson végezték, és bár az öt processzor jelenléte szükségszerűen befolyásolta a mérési eredményeket, az ábrán látható hisztogram általános képet ad az RPC végrehajtási folyamatáról. Rizs. 3.3. Az RPC eljárás szakaszai Fig. 3.4. Időeloszlás az RPC végrehajtás 14 szakasza között 1. Csonk hívása 2. Puffer előkészítése 3. Paramétercsomagolás 4. Töltse ki a fejléc mezőt 5. Számítsa ki az üzenetben szereplő ellenőrző összeget 6. Megszakítás a kernelhez 7. Állítsa sorba a csomagot a végrehajtáshoz 8. Az üzenet továbbítása a vezérlőnek a QBUS buszon keresztül 9. Átviteli idő Ethernet hálózaton keresztül 10. Csomag fogadása a vezérlőtől 11. Megszakításkezelési eljárás 12. Ellenőrzőösszeg számítás 13. Kontextus váltás felhasználói térre 14. Szerver csonk végrehajtása Dinamikus kötés Nézzük meg azt a kérdést, hogy a kliens hogyan határozza meg a szerver helyét.
A probléma megoldásának egyik módja a kiszolgáló hálózati címének közvetlen használata az ügyfélprogramban.
Ennek a megközelítésnek az a hátránya, hogy rendkívül rugalmatlan a szerver mozgatásakor, vagy a szerverek számának növelésekor, ill. az interfész megváltoztatásakor, mindezekben és sok más esetben újra kell fordítani minden olyan programot, amely a szerver hard beállítását használta. Mindezen problémák elkerülése érdekében egyes elosztott rendszerek úgynevezett dinamikus linkelést használnak.
A dinamikus összerendelés kiindulópontja a szerver specifikációjának formális meghatározása. A specifikáció tartalmazza a fájlszerver nevét, a verziószámot és a szerver által az ügyfelek számára biztosított szolgáltatási eljárások listáját (3.5. ábra). Minden eljáráshoz meg van adva a paramétereinek leírása, jelezve, hogy ez a paraméter a szerverhez viszonyítva bemeneti vagy kimeneti.Egyes paraméterek bemeneti és kimeneti is lehetnek - például módosul néhány tömb, amelyet a kliens küld a szervernek ott, majd visszatért a kliens művelethez a copy restore . Rizs. 3.5. RPC-kiszolgálóspecifikáció A formális kiszolgálóspecifikáció a csonkgenerátor program bemeneteként szolgál, amely kliens- és kiszolgálócsonkokat is létrehoz.
Ezután a megfelelő könyvtárakba kerülnek. Amikor egy felhasználói kliensprogram meghív egy, a kiszolgáló specifikációjában meghatározott eljárást, a megfelelő csonk eljárás a program bináris kódjához van társítva.
Hasonlóképpen, amikor egy kiszolgálót lefordítanak, a szerver csonkok hozzá vannak rendelve. Amikor a szerver elindul, a legelső lépése az, hogy a szerver interfészét átviszi egy speciális, binder nevű programra. Ez a szerver regisztrációs folyamatként ismert folyamat során a szerver elküldi a nevét, verziószámát, egyedi azonosítóját és a szerver helyének leíróját. A leíró rendszerfüggetlen, lehet IP, Ethernet, X.500 vagy valamilyen másik cím.
Ezenkívül egyéb információkat is tartalmazhat, például a hitelesítéssel kapcsolatban. Amikor egy kliens először hívja meg az egyik távoli eljárást, például olvassa el, a kliens csonkja azt látja, hogy még nem csatlakozik a szerverhez, és üzenetet küld a binder programnak azzal a kéréssel, hogy importálja a kiszolgáló felületét. Ha létezik ilyen szerver, akkor a binder leírót és egyedi azonosítót küld a kliens csonkjához.
Amikor egy kérést tartalmazó üzenetet küld, a kliens csonk egy leírót használ címként. Az üzenet paramétereket és egy egyedi azonosítót tartalmaz, amelyet a kiszolgálómag arra használ, hogy a bejövő üzenetet a kívánt kiszolgálóra irányítsa, ha több ilyen van a gépen. Az interfészek importálásának és exportálásának ez a módja rendkívül rugalmas, például előfordulhat, hogy több szerver is támogatja ugyanazt a felületet, és a kliensek véletlenszerűen vannak elosztva a szerverek között.
Ennek a módszernek a keretein belül lehetővé válik a szerverek időszakos lekérdezése, teljesítményük elemzése és hiba esetén automatikus leállítás, ami növeli a rendszer általános hibatűrő képességét. Ez a módszer támogatja a kliens hitelesítést is. Például a kiszolgáló meghatározhatja, hogy csak egy adott listából származó kliensek használhatják, azonban a dinamikus összerendelésnek vannak hátrányai, például többletköltség, valamint az interfészek exportálására és importálására fordított idő.
Ezeknek a költségeknek a nagysága jelentős lehet, mivel sok kliens folyamat rövid ideig létezik, és minden egyes folyamat indulásakor újra el kell végezni az interfész importálási eljárást. Ráadásul a nagy elosztott rendszerekben a binder program szűk keresztmetszetgé válhat, és több, azonos célú program létrehozása is növeli a folyamatok létrehozásának és szinkronizálásának többletköltségét RPC szemantika meghibásodás esetén Ideális esetben az RPC-nek megfelelően kell működnie abban az esetben a kudarcokról.
Vegye figyelembe a következő hibaosztályokat: 1. Az ügyfél nem találja a kiszolgálót, például ha a kívánt kiszolgáló meghibásodik, vagy mert a kliensprogramot régen fordították le, és a kiszolgálói felület régi verzióját használta. Ebben az esetben a kliens kérésére egy hibakódot tartalmazó üzenet érkezik. 2. A klienstől a szerver felé küldött kérés elveszett.A legegyszerűbb megoldás a kérés megismétlése egy bizonyos idő elteltével. 3. A szervertől az ügyfélnek küldött válaszüzenet elveszett.
Ez a lehetőség bonyolultabb, mint az előző, mivel egyes eljárások nem idempotensek. Idempotens eljárásnak nevezzük azt az eljárást, amelynek végrehajtási kérése többször megismételhető az eredmény megváltoztatása nélkül. Ilyen eljárás például egy fájl beolvasása, de egy bizonyos összeg bankszámláról történő felvétele nem idempotens, és ha a válasz elveszik, egy ismételt kérés jelentősen megváltoztathatja az ügyfél számlájának állapotát.
Az egyik lehetséges megoldás az összes eljárás idempotenssé tétele. A gyakorlatban azonban ez nem mindig lehetséges, ezért egy másik módszer is használható - az összes kérés szekvenciális számozása a kliens kernel által. A szervermag megjegyzi az egyes kliensek legfrissebb kérésének számát, és minden kérés beérkezésekor elemzi, hogy ez a kérés elsődleges vagy ismétlődő. 4. A szerver lefagyott a kérés fogadása után Itt is fontos az idempotency tulajdonság, de sajnos a kérésszámozásos megközelítés nem alkalmazható.
Ebben az esetben az számít, hogy a hiba mikor következett be – a művelet előtt vagy után. De az ügyfél kernel nem ismeri fel ezeket a helyzeteket, csak azt tudja, hogy a válaszidő lejárt. Ennek a problémának három módja van: Várja meg, amíg a kiszolgáló újraindul, majd próbálja meg újra a műveletet.Ez a megközelítés biztosítja, hogy az RPC legalább egyszer, de esetleg többször is befejeződjön. Azonnal jelentse a hibát az alkalmazásnak.
Ez a megközelítés biztosítja, hogy az RPC legfeljebb egyszer kerüljön végrehajtásra. A harmadik megközelítés nem garantál semmit. Ha a szerver meghibásodik, az ügyfél nem kap támogatást. Az RPC vagy egyáltalán nem, vagy többször is végrehajtható. Mindenesetre ez a módszer nagyon könnyen megvalósítható. Egyik megközelítés sem túl vonzó, és az ideális megoldás, amely pontosan egy RPC-végrehajtást garantálna, általános esetben elvi okokból nem valósítható meg.
Legyen például egy távoli művelet valamilyen szöveg nyomtatása, amely magában foglalja a nyomtató pufferének betöltését és egy bit beállítását valamilyen nyomtatóvezérlő regiszterben, aminek eredményeként a nyomtató elindul. a vezérlőbit beállítása után. A meghibásodás pillanata teljes mértékben meghatározza a helyreállítási eljárást, de az ügyfél nem tudhatja meg a meghibásodás pillanatát.
Röviden, a szerver összeomlásának lehetősége gyökeresen megváltoztatja az RPC természetét, és egyértelműen tükrözi a különbséget a központosított és az elosztott rendszer között. Az első esetben a szerver összeomlása kliens összeomlásához vezet, és a helyreállítás lehetetlen. A második esetben lehetséges és szükséges is a rendszer-helyreállítási műveletek végrehajtása. 1. Az ügyfél a kérés elküldése után összeomlott. Ebben az esetben olyan eredményeket végeznek, amelyekre senki sem számít, az ilyen számításokat árva számításoknak nevezzük. Az árvák jelenléte különféle problémákat okozhat: CPU-idő túllépése, erőforrások blokkolása, az aktuális kérésre adott válasz helyettesítése a kliens gép által a rendszer újraindítása előtt kiadott kéréssel.
Hogyan bánjunk az árvákkal? Nézzünk meg 4 lehetséges megoldást. Megsemmisítés. Mielőtt a kliens csonk RPC üzenetet küldene, feljegyzi a naplóba, hogy mit fog tenni a következő lépésben.
A baleset után a rendszer újraindul, a napló elemzése megtörténik, és az árvákat megszüntetik. Ennek a megközelítésnek a hátrányai közé tartozik egyrészt az egyes RPC-k lemezre írásával járó megnövekedett többletköltség, másrészt az első generációs árvák által kibocsátott RPC-hívások által generált második generációs árvák megjelenése miatti lehetséges hatástalanság. Reinkarnáció Ebben az esetben minden probléma megoldódik lemezrögzítés nélkül. A módszer abból áll, hogy az időt szekvenciálisan számozott periódusokra osztják. Amikor a kliens újraindul, üzenetet küld az összes gépnek, hogy bejelentse egy új időszak kezdetét.
Az üzenet megérkezése után minden távoli számítás megszűnik. Természetesen, ha a hálózat szegmentált, akkor néhány árva életben maradhat. A lágy reinkarnáció hasonló az előző esethez, azzal a különbséggel, hogy nem minden törölt számítás található meg és semmisül meg, hanem csak az újraindító kliens számításai. Lejárat: Minden kérésnek egy szabványos T időtartamot adunk, amelyen belül teljesíteni kell.
Ha a kérés nem fejeződik be a megadott időn belül, akkor további kvantum kerül kiosztásra. Ez ugyan további munkát igényel, de ha egy kliens összeomlása után a szerver egy T intervallumot vár, mielőtt újraindítaná a klienst, akkor minden árva megsemmisül. A gyakorlatban egyik megközelítés sem kívánatos, sőt az árvák megsemmisítése ronthat a helyzeten . Tegyük fel például, hogy egy árva egy vagy több adatbázisfájlt zárolt.
Ha az árva hirtelen megsemmisül, akkor ezek a zárak megmaradnak, ráadásul a megsemmisült árvák állva maradhatnak különböző rendszersorokban, a jövőben új folyamatok végrehajtását idézhetik elő, stb.
Mit csinálunk a kapott anyaggal:
Ha ez az anyag hasznos volt az Ön számára, elmentheti az oldalára a közösségi hálózatokon:
A távoli eljárások hívásának ötlete (Távoli eljáráshívás – RPC) Az egy gépen futó programon belüli vezérlés és adatok átvitelének jól ismert és értett mechanizmusának kiterjesztése a vezérlés és az adatok hálózaton keresztüli átvitelére. A távoli eljáráshívási eszközöket az elosztott számítástechnika szervezésének megkönnyítésére tervezték.
Az RPC használatának legnagyobb hatékonysága azokban az alkalmazásokban érhető el, amelyekben létezik interaktív kommunikáció a távoli komponensek között Val vel rövid válaszidőÉs viszonylag kis mennyiségű továbbított adat.Az ilyen alkalmazásokat RPC-orientáltnak nevezzük.
A helyi eljárások hívásának jellemzői:
aszimmetria, vagyis az egyik interakcióban részt vevő fél a kezdeményező;
szinkronitás, vagyis a hívó eljárás végrehajtása a kérelem kibocsátásának pillanatától felfüggesztésre kerül, és csak akkor folytatódik, amikor a hívott eljárás visszatér.
A távoli hívások megvalósítása sokkal bonyolultabb, mint a helyi eljáráshívások megvalósítása.
1. Kezdjük azzal, hogy mivel a hívó és a hívott eljárások különböző gépeken futnak, ezért különböző címterekkel rendelkeznek, és ez létrehozza problémák a paraméterek és eredmények átvitele során, különösen, ha a gépek nem azonosak.
Mivel az RPC nem támaszkodhat a megosztott memóriára, ez azt jelenti Az RPC paraméterek nem tartalmazhatnak nem verem memóriahelyekre mutató mutatókatÉs akkor mi van a paraméterértékeket át kell másolni egyik számítógépről a másikra.
2. A következő különbség az RPC és a helyi hívás között az, hogy az szükségszerűen a mögöttes kommunikációs rendszert használja, azonban ez nem lehet egyértelműen látható sem az eljárások meghatározásában, sem magukban az eljárásokban .
A távollét további problémákat vet fel. A hívó program és a hívott helyi eljárás végrehajtása ugyanazon a gépen belül valósul megegyetlen folyamat. De részt vesz az RPC végrehajtásábanlegalább két folyamat - minden autóban egyet. Ha valamelyik meghibásodik, a következő helyzetek fordulhatnak elő:
Ha a hívó eljárás összeomlik, a távolról hívott eljárások „árvává” válnak és
Ha a távoli eljárások rendellenesen zárulnak le, a hívó eljárások "nemtelen szülőkké" válnak, és eredménytelenül várnak a távoli eljárások válaszára.
Ezen kívül van számos probléma a programozási nyelvek és operációs környezetek heterogenitásával kapcsolatos : Az egyik programozási nyelvben támogatott adatstruktúrák és eljáráshívási struktúrák nem támogatottak ugyanúgy minden más nyelven.
Ezeket és néhány más problémát megoldja a széles körben elterjedt RPC technológia, amely számos elosztott operációs rendszer mögött áll.
Az RPC mögött meghúzódó ötlet az, hogy egy távoli eljáráshívás a lehető leghasonlóbb legyen a helyi eljáráshíváshoz. Más szóval, tegye átláthatóvá az RPC-t: a hívó eljárásnak nem kell tudnia, hogy a hívott eljárás egy másik gépen van, és fordítva.
Az RPC a következő módon éri el az átláthatóságot. Ha a hívott eljárás valójában távoli, az eljárás egy másik verziója, az úgynevezett kliens csonk kerül a könyvtárba a helyi eljárás helyett. Az eredeti eljáráshoz hasonlóan a csonkot egy hívási szekvencia segítségével hívják meg (mint a 3.1. ábrán), és megszakítás történik a kernel elérésekor. Csak az eredeti eljárástól eltérően nem helyez el paramétereket a regiszterekbe, és nem kér adatokat a kerneltől, hanem üzenetet generál, amelyet a távoli gép kernelének küld..
Rizs. 3.2. Távoli eljáráshívás
