A Remote Procedure Call (RPC) ötlete az, hogy az ugyanazon a gépen futó programon belüli vezérlés és adatok átvitelének jól ismert és jól érthető mechanizmusát kiterjeszti a vezérlés és az adatok hálózaton keresztüli átvitelére. Vagyis az ügyfélalkalmazás hozzáfér a kiszolgálón tárolt eljárásokhoz. 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 leghatékonyabb felhasználása azokban az alkalmazásokban érhető el, amelyekben interaktív kommunikáció zajlik a távoli komponensek között, kis válaszidővel és viszonylag kis mennyiségű adatátvitellel. Az ilyen alkalmazásokat RPC-orientáltnak nevezzük.
Az RPC jellemzői a következők:
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érelem kibocsátásának pillanatától felfüggesztésre kerül, és csak a hívott eljárásból való visszatérés után folytatódik.
A távoli hívási eljárásoknak számos megvalósítása létezik operációs rendszerÓ. A UNIX operációs rendszer egy azonos nevű eljárást (Remote Procedure Call – RPC) használ. Ez az eljárás a rendszer magjába van ágyazva. Megvalósítását az RPC protokoll biztosítja. A Windows operációs rendszerekben az OLE mechanizmusokon alapuló távoli eljáráshívás kezdett kialakulni, amely fokozatosan DCOM (Distributed Component Object Model) technológiává fejlődött. Ez a technológia lehetővé teszi kellően nagy teljesítményű elosztott hálózati számítási környezetek létrehozását. A technológia a Microsoft szabadalmaztatott protokolljait használja.
A kliens és a szerver oldalon történő közvetlen hívás előtt speciális struktúrákat (eljárásokat, fájlokat) kell létrehozni - ezek az úgynevezett kliens csonk (stub) és szerverváz (skeleton), amelyek az RPC megfelelő működéséhez szükségesek. Leggyakrabban automatikusan generálódnak. speciális közművek a program fő kódja szerint.
Ha egy eljárást távolról hívnak meg egy elosztott rendszerben, a következő műveletek történnek:
1. A kliens eljárás normál eljárásként hívja meg a csonkot. A csonk csomagolja a paramétereket (rendező, rendező).
2. A csonk az operációs rendszer kernelére utal.
3. A kernel üzenetet küld a távoli gépnek (a távoli PC kernelének).
4. A kapott üzenet továbbítása a szerverfolyamat vázának.
5. Kicsomagolási paraméterek (unmarshaling, unmarshaling). A szükséges eljárás felhívása.
6. Az eljárás fut a szerveren. Visszaadja az eredményeket a csontvázhoz.
7. Skeleton csomagolja az eredményt.
8. Az eredmény átadása a kernelnek.
9. A szervermag elküldi az üzenetet a hálózaton keresztül a kliensmagnak.
10. Az ügyfélmag eléri a csonkot. A csonk kicsomagolja az eredményt.
11. Átvitel a csonkból a kliens folyamatba.
Ahhoz, hogy megértsük a távoli eljáráshívási mechanizmus fontosságát, legalább megfontolhatunk egy listát azon segédprogramokról és szolgáltatásokról, amelyek nem működnek RPC nélkül a Windows 2000 rendszerben. Valójában az RPC szolgáltatás letiltása meghatározott környezet az egész rendszer összeomlásához vezet. Tehát a következők a "Távoli eljáráshívás (RPC)" szolgáltatástól függenek:
1. Telnet – lehetővé teszi a távoli felhasználó számára, hogy a parancssor használatával bejelentkezzen és konzolprogramokat futtasson.
2. Windows Installer- szoftvereket telepít, eltávolít vagy visszaállít az MSI fájlok utasításai szerint.
3. IPSEC Policy Agent – kezeli az IP-biztonsági házirendet, és futtatja az ISAKMP/Oakley-t (IKE) és az IP-biztonsági illesztőprogramot.
4. Nyomtatási sorkezelő – betölti a fájlokat a memóriába a későbbi nyomtatáshoz.
5. Secure Vault – Érzékeny adatok, például privát kulcsok biztonságos tárolását biztosítja, hogy megakadályozza a szolgáltatások, folyamatok vagy felhasználók jogosulatlan hozzáférését.
6. Eszközkészlet Windows vezérlők- tájékoztatást ad a rendszerkezelésről.
7. Kliens a megváltozott hivatkozások nyomon követéséhez – értesítést küld a hálózati tartomány NTFS-kötetei között áthelyezett fájlokról.
8. Elosztott tranzakciók koordinátora - több adatbázison, üzenetsoron elosztott tranzakciók koordinálása, fájlrendszerek vagy más biztonságos tranzakciós erőforrás-kezelők.
9. Útválasztás és távelérés – Útválasztási szolgáltatásokat kínál a helyi és nagy kiterjedésű hálózatokon működő szervezetek számára.
10. Feladatütemező - lehetővé teszi a programok futtatását a megadott időben.
11. Hálózati kapcsolatok- kezeli a "Network and Dial-up Networking" mappa objektumait, amely megjeleníti a helyi hálózat és a kapcsolatok tulajdonságait távoli hozzáférés.
12. COM+ eseményrendszer - események automatikus továbbítása az előfizető COM komponensekhez.
13. Indexelő szolgáltatás - indexelés a gyors kereséshez.
14. Üzenetszolgáltatás – a rendszergazdák vagy az értesítési szolgáltatás által küldött üzeneteket küldi és fogadja.
15. Fax szolgáltatás - segít faxüzenetek küldésében és fogadásában.
16. Cserélhető tároló – kezeli a cserélhető adathordozókat, meghajtókat és könyvtárakat.
17. Telefónia – támogatja a Telephony API-t (TAPI) azon programok számára, amelyek ezen a számítógépen, valamint a LAN-on keresztül kezelik a telefonkészülékeket és a hang IP-kapcsolatokat – azokon a szervereken, ahol a megfelelő szolgáltatás fut.
A Remote Method Invocation (RMI) az RPC-ötletek megvalósítása a nyelvhez Java programozás.
Az RMI egy JavaSoft termék, amelyet Java számára fejlesztettek ki, és a JDK 1.1-es és újabb verzióiba integrálták. Az RMI elosztott számítási modellt valósít meg, és kommunikációs eszközt biztosít az egy vagy több távoli számítógépen futó Java programok (Java virtuális gépek) között. Az RMI lehetővé teszi, hogy a kliens- és kiszolgálóalkalmazások metódusokat hívjanak a Java virtuális gépeken futó klienseken/kiszolgálókon a hálózaton keresztül. Az RMI fő előnye, hogy a programozó számára magasabb szintű programozási felületet biztosít, amely lehetővé teszi egy távoli objektumra való hivatkozás argumentumként történő átadását vagy eredményként történő visszaadását. Az RMI megköveteli a Java programok futtatását a kapcsolat mindkét végén. internetkapcsolat a TCP/IP protokoll használatával érhető el. Az RMI architektúráját az ábra mutatja. "RMI architektúra".
A Client Stub (kliens csonk – az ügyfélen lévő valamely entitás, amely adási/fogadási funkciókat biztosít) és a Server Skeleton (szervercsonk – a szerveren lévő valamely entitás, amely távoli hívásokat kezel) egy közös interfészből származik, de abban különböznek, hogy a Client Stub egyszerűen az RMI Registry-hez való csatlakozáshoz, míg a Server Stub a kiszolgálófunkciókkal való közvetlen kommunikációra szolgál.
Az RMI valójában egy újfajta objektumkérés-közvetítő, amely a Java objektummodellre épül. Az ORB-hez hasonlóan az RMI is öt kulcsfontosságú pontot mutat be:
1. Lehetővé teszi a kód áthelyezését az adatok mellett.
2. Gyakorlatilag biztosítja a betöltött kód végrehajtásának biztonságát.
3. Lehetővé teszi az objektumok érték szerinti átadását.
4. Java-t használ interfészdefiníciós nyelvként és megvalósítási nyelvként.
5. Az Uniform Resource Locator (URL) alapján elnevezési sémát használ.
Ebben az esetben az objektumokat soros formává alakítják át - a TCP / IP protokollon keresztül üzenetben paraméterként továbbított bájtok folyamává.
Az RMI interfészek 4 kategóriába sorolhatók:
RMI mag – meghatározza a távoli metódushívásokhoz szükséges interfészeket;
RMI elnevezési szolgáltatás – interfészeket és osztályokat definiál, amelyek lehetővé teszik, hogy név szerint hivatkozzon a szerverobjektumokra;
RMI biztonság – új RMI biztonsági kezelőt és osztálybetöltő interfészt határoz meg (az RMI az igény szerinti Java osztálybetöltési mechanizmust kiterjeszti a csonkbetöltésre);
Marshaling (kérelem csomagolása, beleértve a paramétereket, a visszatérési értéket, magát a kérést szabványos formátumba, amely alkalmas hálózaton keresztüli továbbításra) - Az RMI alacsony szintű interfészt definiál a távoli objektumok rendezésére, amelyek segítségével Java objektumokat írnak egy adatfolyamba és objektumot olvasni a patakból.
A JavaSoft és az OMG a konvergencián dolgozik tárgymodellek RMI és CORBA. Ez a konvergencia két területen jelentkezik:
RMI az IIOP-n keresztül. A JavaSoft az RMI olyan verzióját fejleszti, amely az IIOP átvitelen felül fut. Az IIOP a következő előnyöket nyújtja az RMI számára:
1. Beépített támogatás a tranzakció terjesztéséhez.
2. ORB alapú tűzfal támogatás IIOP proxyval (nincs HTTP alagút).
3. Interakció más nyelveken írt objektumokkal az RMI/IDL egy részhalmazán keresztül.
4. Nyílt szabvány elosztott objektumokhoz.
RMI/IDL. Az IDL CORBA Java szabványa egy CORBA/RMI konvergencia szabvány. Lehetővé teszi a Java programozók számára, hogy a CORBA IDL helyett Java RMI szemantikával határozzák meg a CORBA interfészt. A fordító ezeket a szemantikákat használja a CORBA IDL-ek, csonkok és vázak automatikus generálására. Az RMI/IDL részhalmaz lehetővé teszi az RMI programok többnyelvű CORBA kliensek általi meghívását az IIOP használatával; azt is lehetővé teszi az RMI programok számára, hogy más nyelven írt CORBA objektumokat hívjanak meg.
RMI az IIOP-on keresztül úgy tűnik jó döntés a CORBA/Java rendszerhez, mert két erőteljes technológiát egyesít. Az RMI fő előnye, hogy ez a leggyorsabb és legegyszerűbb módja egy kisméretű elosztott rendszer létrehozásának tiszta Java környezetben. Az RMI fő hátránya, hogy nem tudja integrálni ezt a mechanizmust a meglévő alkalmazásokkal.
Az RMI fejlesztői arra törekedtek, hogy az elosztott Java objektumok használata ugyanaz legyen, mint a helyi objektumok. Az alábbi táblázat felsorol néhány fontos különbséget.
Az RMI architektúra egy fontos alapelven alapul: a viselkedés meghatározása és a viselkedés megvalósítása különböző fogalomnak minősül. Az RMI lehetővé teszi a viselkedést meghatározó kód és a viselkedést megvalósító kód elkülönítését és végrehajtását különböző JVM-eken.
Ez megfelel az elosztott rendszerek követelményeinek, ahol az ügyfelek tisztában vannak a szolgáltatásdefiníciókkal, és a szerverek nyújtják ezeket a szolgáltatásokat. Pontosabban, az RMI-ben a távoli szolgáltatás definíciója Java interfész segítségével van kódolva. A távoli szolgáltatás megvalósítása az osztályban kódolt. Az RMI megértésének kulcsa tehát az, hogy ne feledjük, hogy az interfészek határozzák meg a viselkedést, az osztályok pedig a megvalósítást.
Ne feledje, hogy a Java interfészek nem tartalmaznak végrehajtható kódot. Az RMI két olyan osztályt támogat, amelyek ugyanazt az interfészt valósítják meg. Az első osztály a viselkedés megvalósítása, és a szerveren kerül végrehajtásra. A második osztály a távoli szolgáltatás közbenső interfészeként működik, és az ügyfélgépen fut.
Az ügyfélprogram metódusokat hív meg a proxy objektumon, az RMI továbbítja a kérést a távoli JVM-nek, és továbbítja az objektum megvalósításához. Az implementációból származó minden visszatérési érték visszakerül a proxy objektumhoz, majd az ügyfélprogramhoz.
Egy RMI implementáció lényegében három absztrakt szintből áll. Az első a csonk és a vázréteg, amely közvetlenül az előhívó előtt található. Ez a réteg elfogja az ügyfél által interfész referenciaváltozó segítségével indított metódushívásokat, és továbbítja azokat a távoli RMI szolgáltatásnak.
A következő szint a távoli kapcsolat szintje. Ez a réteg megérti, hogyan kell értelmezni és kezelni a távoli szolgáltatásobjektumokra mutató hivatkozásokat. A JDK 1.1-ben ez a réteg kapcsolja össze az ügyfeleket a kiszolgálón futó távoli szolgáltatásobjektumokkal. Ez a kapcsolat egy-egy (egyirányú) kapcsolat. A Java 2 SDK-ban ezt a szintet kiterjesztették a passzív távoli objektumok aktiválásának támogatására a Remote Object Activation technológia használatával.
A szállítási réteg a hálózati gépek közötti TCP/IP kapcsolatokon alapul. Alapvető csatlakozást és néhány szabotázs elleni védelmi stratégiát biztosít. Réteges architektúra használatakor mindegyik réteg megváltoztatható vagy cserélhető anélkül, hogy ez a rendszer többi részét érintené. Például a szállítási réteg lecserélhető UDP/IP-re a többi réteg megváltoztatása nélkül.
Az RMI architektúráját vizsgálva felmerül a kérdés: "Hogyan találja meg az ügyfél a távoli RMI szolgáltatást?". Az ügyfelek elnevezési vagy címtárszolgáltatás segítségével találják meg a távoli szolgáltatásokat. Hogyan találhat az ügyfél szolgáltatást a szolgáltatás használatával? De ez igaz. A névadó vagy címtárszolgáltatás egy jól ismert gazdagépen fut, és jól ismert portszámmal rendelkezik (a jól ismert azt jelenti, hogy a szervezetben mindenki tud róla).
Az RMI számos különböző címtárszolgáltatást használhat, beleértve a Java elnevezési és címtári felületet (JNDI). Az RMI magában foglal egy egyszerű szolgáltatást, az RMI registry-t, az rmiregistry-t. Az RMI-nyilvántartás minden olyan gépen fut, amelyen távoli szolgáltatásobjektumokat tárolnak és szolgáltatáskéréseket fogadnak el, alapértelmezés szerint a 1099-es porton. A gazdagépen a kiszolgálóprogram távoli szolgáltatást hoz létre úgy, hogy először létrehoz egy helyi objektumot, amely megvalósítja a szolgáltatást. Ezután exportálja ezt az objektumot az RMI-be. Az objektum exportálása után az RMI létrehoz egy figyelő szolgáltatást, amely arra vár, hogy az ügyfél csatlakozzon és szolgáltatást kérjen. Az exportálás után a szerver a nyilvános név használatával regisztrálja az objektumot az RMI nyilvántartásban.
Az ügyféloldalon az RMI nyilvántartás a statikus elnevezési osztályon keresztül érhető el. Ez egy lookup() metódust biztosít, amelyet az ügyfél a beállításjegyzék lekérdezéséhez használ. A lookup() metódus elfogad egy URL-t, amely a kívánt szolgáltatás gazdagépnevére és nevére mutat. A metódus távoli hivatkozást ad vissza a szolgáltatásobjektumra. Az URL formátuma a következő:
rmi://
ahol a gazdagép_neve egy helyi hálózaton (LAN) felismerhető név, vagy egy DNS-név Internetes hálózatok. Csak akkor kell megadnia a névszolgáltatás_portját, ha a névszolgáltatás nem az alapértelmezett 1099-es porton fut.
Egy működő RMI rendszer több részből áll: interfészek definiálása távoli szolgáltatásokhoz, távoli szolgáltatások megvalósítása, csonk- és vázfájlok, távoli szolgáltatásokat nyújtó szerver, RMI névszolgáltatás, amely lehetővé teszi az ügyfelek számára, hogy távoli szolgáltatásokat találjanak, osztályfájl-szolgáltató (HTTP ill. FTP szerver). ), egy kliensprogram, amely távoli szolgáltatásokat igényel.
Feltételezve, hogy egy RMI rendszert már megterveztek, a következő lépéseket kell követni a létrehozásához:
1. Írjon és fordítson Java kódot interfészekhez.
2. Írjon és fordítson Java kódot a megvalósítási osztályokhoz.
3. Generáljon csonk- és csontváz osztályfájlokat a megvalósítási osztályokból.
4. Írja meg a gazdaprogram Java kódját a távoli karbantartáshoz.
5. Készítsen Java kódot az RMI kliensprogramhoz.
6. Telepítse és futtassa az RMI rendszert.
Az első lépés a Java kód megírása és lefordítása a szolgáltatási felületekhez. A Számológép felülete meghatározza a szolgáltatás által kínált összes távoli képességet:
nyilvános felület A Számológép kiterjeszti a java.rmi.Remote(
public long add(long a, long b) dobja a java.rmi.RemoteException;
public long sub(long a, long b) dobja a java.rmi.RemoteException;
public long mul(long a, long b) dobja a java.rmi.RemoteException;
public long div(long a, long b) dobja a java.rmi.RemoteException;
}
Ne feledje, hogy ez az interfész kiterjeszti a távoli felületet, és mindegyik metódus aláírása meghatározza, hogy képes RemoteException objektumot dobni. Általánosságban elmondható, hogy egy objektum távoli, ha megvalósítja a Távoli interfészt. "Implements" a fejléc értelmében (a nyilvános felület Calculator kiterjeszti a java.rmi.Remote-ot), ezen a felületen nincsenek metódusok. Ez egy címke. Most meg kell írnunk a távoli szolgáltatás megvalósítását. Alább látható a CalculatorImpl osztály:
public class CalculatorImpl kiterjeszti a java.rmi.server.UnicastRemoteObject
megvalósítja a számológépet (
// Az implementációknak explicit konstruktorral kell rendelkezniük a deklarációhoz
// RemoteException
public CalculatorImpl()
a java.rmi.RemoteException(
szuper();
}
public long add(long a, long b) dobja a java.rmi.RemoteException (
return a + b;
}
public long sub(long a, long b) dobja a java.rmi.RemoteException (
visszatér a-b;
}
public long mul(long a, long b) dobja a java.rmi.RemoteException (
return a*b;
}
public long div(long a, long b) dobja a java.rmi.RemoteException (
return a / b;
}
}
A megvalósítási osztály az Unicast RemoteObject segítségével csatlakozik az RMI rendszerhez. BAN BEN ezt a példát a megvalósítási osztály közvetlenül kiterjeszti az UnicastRemoteObject-et. Ez nem követelmény. Az UnicastRemoteObject kiterjesztést nem terjesztő osztály az exportObject() metódusával csatlakozhat az RMI-hez. Ha egy osztály kiterjeszti az UnicastRemoteObject objektumot, akkor biztosítania kell egy konstruktort, amely deklarálja, hogy képes RemoteException objektumot dobni. Ha ez a konstruktor meghívja a super() metódust, akkor meghívja a kódot az UnicastRemoteObjectben, amely végrehajtja az RMI-kapcsolatot és a távoli objektum inicializálását.
A távoli RMI szolgáltatásokat egy szerverfolyamatba kell helyezni. A CalculatorServer osztály nagyon egyszerű szerver A, amely egyszerű elemeket biztosít az elhelyezéshez.
import java.rmi.Naming;
public class CalculatorServer(
public CalculatorServer() (
próbáld ki(
Számológép c = new CalculatorImpl();
Naming.rebind("
rmi://localhost:1099/
CalculatorService", c);
) fogás (e kivétel) (
System.out.println("Hiba: " + e);
}
}
new CalculatorServer();
}
}
Az ügyfél forráskódja például a következő lehet:
import java.rmi.Naming;
import java.rmi.RemoteException;
import java.net.MalformedURLException;
import java.rmi.NotBoundException;
public class CalculatorClient(
public static void main(String args) (
próbáld ki(
Számológép c = (Számológép)
Naming.lookup(
"rmi://remotehost
/CalculatorService");
System.out.println(c.sub(4, 3));
System.out.println(c.add(4, 5));
System.out.println(c.mul(3, 6));
System.out.println(c.div(9, 3));
}
catch(MalformedURLException murle)(
System.out.println();
System.out.println(
"Rosszul formázott URL-kivétel");
System.out.println(murle);
}
catch(RemoteException re)(
System.out.println();
System.out.println(
"Távoli kivétel");
System.out.println(re);
}
fogás(NotBoundExceptionnbe)(
System.out.println();
System.out.println(
"NotBoundException");
System.out.println(nbe);
}
fogás(
java.lang.ArithmeticException
ae) (
System.out.println();
System.out.println(
"java.lang.ArithmeticException");
System.out.println(ae);
}
}
}
Most elindíthatja a rendszert. Ezt megteheti (miután megszerezte a megfelelő osztályfájlokat és elhelyezte őket ugyanazon vagy különböző PC-ken) a következőképpen:
1. Indítsa el az RMI nyilvántartást ("rmiregistry").
2. Indítsa el a szervert ("java CalculatorServer").
3. Indítsa el a klienst ("java CalculatorClient").
Ha minden jól megy, a következő információkat fogja látni:
1
9
18
3
Ez minden – egy működő RMI-rendszer készen áll. Még ha három konzolt is futtat ugyanazon a gépen, az RMI a hálózat TCP/IP protokollvermeit használja a három különálló JVM közötti kommunikációhoz. Ez egy teljes RMI rendszer.
Egy RMI alkalmazás futtatásához a támogató osztályfájlokat olyan helyen kell elhelyezni, ahol a szerver és a kliensek megtalálhatják azokat.
A következő osztályoknak kell rendelkezésre állniuk a szerver számára (az osztálybetöltő számára):
Távoli szolgáltatás megvalósítások
Csontvázak megvalósítási osztályokhoz (csak a JDK 1.1 alapú szerverekhez)
Csonkok végrehajtási osztályokhoz
Az összes többi szerverosztály
A következő osztályoknak elérhetőknek kell lenniük a kliens számára (az osztálybetöltő számára):
Távoli szolgáltatási interfész definíciói
Csonkok olyan osztályokhoz, amelyek távoli szolgáltatást valósítanak meg
Szerverosztályok az ügyfél által használt objektumokhoz (például visszatérési érték)
Az összes többi ügyfélosztály
Ha tudja, hogy milyen fájlokat kell elhelyezni a különböző gazdagépeken, akkor nem nehéz ezeket elérhetővé tenni az egyes JVM osztálybetöltők számára.
A Java platformra való programozás egyik előnye, hogy nem kell aggódnia a memóriafoglalás miatt. A JVM automatikus szemétgyűjtővel rendelkezik, amely felszabadítja a végrehajtó program által már nem használt objektumok által elfoglalt memóriát. Az RMI egyik tervezési követelménye a Java programozási nyelvbe való zökkenőmentes integráció volt, beleértve a szemétgyűjtést is. Egyetlen géphez hatékony szemétgyűjtő tervezése nehéz feladat; elosztott szemétgyűjtő fejlesztése nagyon nehéz feladat. Az RMI rendszer a Modula-3-ban használt hálózati objektumok alapján referenciaszámláló elosztott szemétgyűjtési algoritmust biztosít. Ez a rendszer nyomon követi, hogy mely ügyfelek kértek hozzáférést a szerveren futó távoli objektumokhoz. Amikor megjelenik egy hivatkozás, a szerver "piszkosnak" jelöli az objektumot, és amikor a kliens eltávolítja a hivatkozást, az objektumot "tiszta"-ként jelöli meg.
A DGC (elosztott szemétgyűjtő) interfésze csonkok és csontvázak szintjén el van rejtve. A távoli objektum azonban megvalósíthatja a java.rmi.server.Unreferenced interfészt, és a hivatkozás nélküli metóduson keresztül értesülhet arról, ha nincs másik kliens, amely élő hivatkozást tartalmaz. A linkszámlálási mechanizmuson kívül az ügyfélben lévő élő linknek meghatározott időre szóló bérleti futamideje van. Ha az ügyfél nem újítja meg a kapcsolatot a távoli objektummal a bérleti szerződés lejárta előtt, a hivatkozás halottnak minősül, és a távoli objektum szemétgyűjtésre kerülhet. A bérleti időt a java.rmi.dgc.leaseValue rendszertulajdonság szabályozza. Értéke ezredmásodpercben van megadva, alapértelmezés szerint 10 perc. E szemétgyűjtési szemantika miatt a kliensnek fel kell készülnie az „eltűnhet” objektumok kezelésére.
A Remote Method Invocation (RMI), amelyet először a JDK 1.1-ben vezettek be, a hálózati programozást a következő szintre emelte. Bár az RMI viszonylag könnyen használható, és nem mentes a hibáktól, ez egy hihetetlenül erős technológia, és egy teljesen új paradigmát nyit meg az átlagos Java programozó számára – az elosztott objektum-számítástechnika világát.
|
Távoli eljáráshívás(vagy Távoli eljárások hívása) (angolról. Távoli eljáráshívás (RPC)) – olyan technológiák osztálya, amelyek lehetővé teszik a számítógépes programok számára, hogy függvényeket vagy eljárásokat hívjanak meg egy másik címtérben (általában távoli számítógépeken). Az RPC technológia megvalósítása általában két összetevőből áll: hálózati protokoll a kliens-szerver módban történő cseréhez és az objektumok (vagy struktúrák, nem objektív RPC-k esetén) szerializációs nyelve. Az RPC különböző implementációi nagyon eltérő architektúrával és képességeikben különböznek: egyesek a SOA architektúrát, mások CORBA vagy DCOM architektúrát valósítanak meg. A szállítási rétegben az RPC-k főként a TCP és az UDP protokollokat használják, néhány azonban a HTTP-re épül (ami sérti az ISO/OSI architektúrát, mivel a HTTP eredetileg nem szállítási protokoll).
Számos technológia kínál RPC-t:
A Remote Procedure Call (RPC) ötlete az, hogy az ugyanazon a gépen futó programon belüli vezérlés és adatok átvitelének jól ismert és jól érthető mechanizmusát kiterjeszti 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 célja az elosztott számítástechnika megszervezése és az elosztott kliens-szerver létrehozása. információs rendszerek. Az RPC leghatékonyabb felhasználása azokban az alkalmazásokban érhető el, amelyekben interaktív kommunikáció zajlik a távoli komponensek között, kis válaszidővel és viszonylag kis mennyiségű adatátvitellel. Az ilyen alkalmazásokat RPC-orientáltnak nevezzük.
A távoli hívások megvalósítása sokkal bonyolultabb, mint a helyi eljáráshívások megvalósítása. A következő problémákat és feladatokat tudjuk azonosítani, amelyeket az RPC megvalósítása során meg kell oldani:
Kimenő és bejövő kapcsolatok kezelése. - az "üzenethatár" fogalmának támogatása azon szállítási protokollok esetében, amelyek közvetlenül nem támogatják (TCP). - az azt közvetlenül nem támogató szállítási protokollok garantált kézbesítésének támogatása (UDP).
Az RPC (.NET Remoting) egyes megvalósításaiban az alrendszer határai nyitott polimorf interfészek, és szinte az összes felsorolt alrendszerhez saját implementáció írható. Más megvalósításokban (Windows rendszeren a DCE RPC) ez nem így van.
Távoli eljáráshívás (RPC) A távoli eljáráshívás fogalma
A Remote Procedure Call (RPC) ötlete az, hogy az ugyanazon a gépen futó programon belüli vezérlés és adatok átvitelének jól ismert és jól érthető mechanizmusát kiterjeszti 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 leghatékonyabb felhasználása azokban az alkalmazásokban érhető el, amelyekben interaktív kommunikáció zajlik a távoli komponensek között, kis 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 legfontosabb jellemzői:
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 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, hogy szükségszerűen az alapul szolgáló kommunikációs rendszert használja, azonban ezt nem szabad kifejezetten látni 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. De legalább két folyamat vesz részt az RPC megvalósításában, mindegyik gépen egy. Abban az esetben, ha valamelyik összeomlik, 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 összeomlanak, akkor a hívó eljárások „ráhagyó szülőkké” válnak, amelyek megvárják a a távoli eljárások válasza eredménytelenü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á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. Alapműveletek RPC
Az RPC működésének megértéséhez először fontolja meg egy helyi eljáráshívás kezdeményezését egy normál, offline üzemmódban futó gépen. Legyen ez például egy rendszerhívás
count=read(fd, buf, nbytes);
ahol az fd egy egész szám, a buf egy karaktertömb, az nbyte pedig 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 befejezése 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 lekéri a paramétereket a veremből, és visszaállítja azt. Vegye figyelembe, hogy a C-ben a paraméterek vagy hivatkozással (névvel) vagy értékkel (érték szerint) hívhatók meg. A hívott eljárás tekintetében az értékparaméterek inicializálható helyi változók. A meghívott eljárás megváltoztathatja ezeket, és ez nem befolyásolja 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.
A paraméterek átadására van egy másik, a C nyelvben nem használt mechanizmus is. Ezt call-by-copy/restore-nak hívják, és abból áll, hogy a hívó programnak be kell másolnia a változókat a verembe értékként, majd átmásolni. vissza a hívás után a hívási eljárás eredeti értékein.
A használni kívánt paraméterátadási mechanizmus kiválasztása a nyelvi tervezőkön múlik. 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 eszközök jelentős része távirányító A Windows operációs rendszer (Event Viewer, Server Manager, nyomtatáskezelés, felhasználói listák) a DCE RPC-t használja hálózati kommunikációs eszközként a felügyelt szolgáltatás és a kezelő alkalmazás között. felhasználói felület. A DCE RPC támogatás a Windows NT rendszerben a legelső 3.1-es verzió óta létezik. A DCE RPC klienseket a Windows 3.x/95/98/Me lite operációs rendszerek is támogatták.
Szisztémás windows könyvtárak, amelyek az ilyen vezérlés lehetőségeit biztosítják, és alapszintként szolgáltak a felhasználói felület vezérlőalkalmazásaihoz (netapi32.dll és részben advapi32.dll), valójában az ezt a vezérlést megvalósító DCE RPC interfészek klienskódját tartalmazzák.
Ezt az építészeti döntést a Microsoft aktívan bírálta. A DCE RPC-ben jelenlévő általános rendezési rutinok nagyon összetettek, és hatalmas lehetőségük van a hálózaton belüli hibák kihasználására egy szándékosan hibás DCE RPC csomag küldésével. A 90-es évek végétől a 2000-es évek közepéig felfedezett Windows biztonsági hibák jelentős része a DCE RPC rendezőkódjában volt.
A DCE RPC mellett a Windows aktívan használja a DCOM technológiát. Így például kommunikációs eszközként használják a menedzsment eszközök között IIS webszerverés magát a felügyelt szervert. Teljes funkcionalitású interfész az MS levelezőrendszerrel való kommunikációhoz Exchange Server- MAPI - szintén DCOM alapú.
A Windows operációs rendszer bármely módosításának összetétele, az XP-től kezdve, tartalmaz egy szolgáltatási összetevőt, amelyet RPC-nek neveznek. Mi ez, a hétköznapi felhasználók többnyire nem tudják, annál is inkább, nem tudják, mire való ez a szolgáltatás és hogyan működik. Ebben a tekintetben javasolt néhány alapvető szempontot figyelembe venni magával az alkatrészrel, működési elveivel és felhasználási körével, anélkül, hogy szükségtelen és bonyolult szakkifejezéseket leírnánk. Koncentráljunk külön erre lehetséges hibákat szolgáltatások és módszerek azok gyors megszüntetésére.
Úgy tűnik, sok felhasználó ennek a szolgáltatási összetevőnek a neve alapján már megállapította, hogy mi az. Valójában a távoli eljárások (távoli eljáráshívások) bizonyos műveleteket foglalnak magukban, ha azokat nem hajtják végre helyi számítógép, hanem távolról (leggyakrabban a szerveren).
Ez azt jelenti, hogy a kérést az egyik terminálon alakítják ki, majd továbbítják a másikra, ahol végrehajtják, majd a végrehajtásról szóló választ (jelentést) visszaküldik az első számítógépre. De ez csak primitív magyarázat. Valójában minden sokkal bonyolultabb, hiszen itt figyelembe kell venni az adatátviteli protokollokat (UDP, TCP, HTTP) és sok más mechanizmust.
Elsődleges célja ellenére a távoli eljáráshívás (RPC) nem használható különböző számítógépek, hanem az egyiken. A legegyszerűbb példa egy program valamely funkciójának hívása egy másik alkalmazásból. Sok zenész, aki virtuális stúdiókkal és szekvenszerekkel dolgozik, tudja, hogy minden ilyen alkalmazásnak saját hangszerkesztő vagy feldolgozó modulja van, ami nem mindig felel meg a felhasználó igényeinek. És bármely stúdió lehetővé teszi, hogy ehelyett bármilyen másik stúdiót csatlakoztasson külső program.
Például az FL Studio szekvenszer beállításaiban megadhatunk egy másik alkalmazást (mondjuk az Adobe Auditiont), amely alapértelmezés szerint a hangfájlok (minták) szerkesztésére lesz használva a főprogram környezetében. Ebben az esetben az Adobe Audition és az FL Studio közötti kapcsolat nem jön létre virtuális gazdagépek mint a VST, RTAS vagy DX, de közvetlenül egy távoli eljáráshívási szolgáltatás használatával. Magától értetődik, hogy nem ez az egyetlen példa, mivel a leírt komponens hatóköre sokkal szélesebb.
Gyakran ezt a szolgáltatást A számítási terhelés azon terminálokon való elosztásával is kapcsolatosak, amelyek között interaktív kapcsolat jön létre. Ugyanakkor, ha a terhelés egyenletesen oszlik el több számítógép számítási erőforrásai között, csak kis adatmennyiség cseréje és a komponensek közötti gyors válaszadás mellett lehet maximális teljesítményt elérni.
Sajnos az ilyen igények miatt a szolgáltatással kapcsolatos meghibásodások és hibák megjelenése meglehetősen gyakori jelenség.
Ennek eredményeként lehetetlenné válik nemcsak magának az alkatrésznek a használata. Néha nem is tud hozzáférni néhányhoz rendszerbeállítások, és a Windows XP teljesen összeomlik, ami után elég problémás lehet a normál működő állapot visszaállítása. Egy másik probléma az operációs rendszerhez mellékelt DISM online javítóeszköz.
A munkájában bekövetkezett megsértésekhez kapcsolódik az 1726-os hiba megjelenése, amely közvetlenül befolyásolja az RPC szolgáltatás összetevőinek működését.
Az ilyen hibák fő okait a rendszerellenőrző vagy -visszaállító eszközök hívásának nevezik, amikor a DISM folyamat aktív, vagy nem tud megfelelően leállni (például amikor a DISM és az SFC eszközök két parancskonzoljáról egyszerre indul). ; amikor a szolgáltatás párhuzamosan fut az RPC-összetevők kiszolgálásával; ha a szolgáltatást víruskereső szoftver blokkolja.
Ezért, ha RPC-hibát tapasztal a Windows 7 és újabb rendszeren, először be kell zárnia a DISM-et, újra kell indítania a számítógépet, és újraindítania a szolgáltatást. Ha ez nem segít, megpróbálhat csökkentett módba váltani, és teljesen letiltani a helyreállítás idejére. vírusvédelem. Kitérünk azokra a további intézkedésekre, amelyek segítenek kijavítani a távoli eljáráshívások és a Windows bármely módosítása során fellépő hibákat. Addig is nézzük meg a rendszerkomponens letiltásával kapcsolatos problémákat (sajnos sok olyan felhasználó próbálkozik, aki nem ismeri a probléma lényegét).
Lássuk tehát, mennyire reális a távoli eljáráshívások letiltása. A távoli eljárásokat a fejlesztők javaslatai alapján semmiképpen sem szabad letiltani. Fontos! Alapvetően önmaga nem fogja tudni megtenni. Természetesen van néhány megkerülő megoldás, amely magában foglalja egy kiegészítő használatát szoftver, de nyilvánvaló okokból nem adjuk meg az ilyen alkalmazások nevét, mivel ha helytelenül használják őket, az egész rendszer használhatatlanná válhat.
Még ha a felhasználónak sikerül is valahogyan letiltani a távoli eljárásokat (távoli eljáráshívásokat), a következmények sajnos a legbeláthatatlanabbak lehetnek. Mint már említettük, előfordulhat, hogy a Windows XP teljesen leáll, és magasabb besorolású operációs rendszerben ennek következtében rengeteg olyan rendszerhiba jelenhet meg, amelyeket nem lehet kiküszöbölni, már csak azért is, mert nincs hozzáférés a kritikus rendszerekhez. fontos beállításokatÉs Windows beállítások, és még benne is biztonságos mód vagy cserélhető adathordozóról indítva. A távoli eljáráshívások azonban sikertelenek a Windows 10 vagy újabb rendszeren korai változatai operációs rendszer javítható. A módszer nem a legegyszerűbb, ezért használatánál nagyon óvatosnak kell lenni.
Tehát a fő RPC szolgáltatás nem tiltható le. De talán van értelme kikapcsolni néhány kísérő komponenst? Igen, valóban, ha a rendszerszolgáltatások és összetevőik részre lépünk (services.msc), akkor megtalálhatjuk benne az úgynevezett RPC lokátort.
De deaktiválható anélkül, hogy félne a katasztrofális következményektől. A paraméterek szerkesztésébe lépve le kell állítani az összetevőt, és az indítási típust letiltásra kell állítani. A távoli eljárásokat használó programok továbbra is távoli eljárásokat hívnak meg (az ő segítsége nélkül).
Ha valamilyen okból a beállított paraméterek nem működnek, használhatja a telepítést Windows lemez, amikor arról indít, hívja meg a parancssort, és írja be a következőket:
Az újraindítás után a „Feladatkezelő” meghívásra kerül, majd a parancssorba beírjuk a %TEMP% \ explorer.exe %SYSTEMROOT% / y másolatot, ami után az összes svchost folyamat leáll a „Feladatkezelőben” . Most különösen óvatosnak kell lennie, mert a folyamatok befejezése után már csak hatvan másodpercig tart parancskonzol időre van szüksége a copy %TEMP%\svchost.exe %systemroot%\system32 /y parancs regisztrálására.
Ha a felhasználó például normál vagy csökkentett módban hozzáfér a rendszerleíró adatbázis, a szerkesztőben (regedit) a HKCC ágban meg kell találni a CSConfigFlags paramétert, és hozzá kell rendelni egy nulla értéket.
Végül az 1726-os hiba javítása is a beállításjegyzéken keresztül történik. De ez az eset a HKLM ágban meg kell keresni az RpcSs könyvtárat, és a jobb oldalon módosítani kell a Start paraméter értékét.
Négyről – általában alapértelmezés szerint – kettőre kell módosítani, majd újra kell indítani a rendszert.
Valójában ez minden, ami a távoli eljáráshívásokra vonatkozik. A távoli eljárások, ennek a komponensnek a működési elvei bővített változatban nagyon sokáig leírhatóak, de a bemutatott anyagban a hangsúly a szolgáltatás általános megismertetésén volt és néhány módszerrel az esetleges hibák és meghibásodások kiküszöbölésére. ban ben számítógépes rendszer. A hétköznapi felhasználóknak türelmesnek és nagyon óvatosnak kell lenniük, mert egy rossz művelet a rendszerleíró adatbázisban az operációs rendszer teljes összeomlásához vezethet.
Kérjük, vegye figyelembe, hogy az ilyen típusú hibákat semmilyen más módon nem lehet kiküszöbölni, például optimalizáló programokkal és Windows operációs rendszerek beállítási módosítóival. Minden vágyaddal, parancs sor, sőt ráadásul a regisztrációs kulcsok szerkesztési szintjén történő beavatkozás sem olyan szoftvercsomagok nem biztosított.
Ennek a cikknek a célja a terminológia megvitatása. A cikk nem arról szól, hogyan és miért, hanem csak a terminológia használatáról. A cikk a szerző véleményét tükrözi, és nem állítja, hogy tudományos.
Ha a programozás területén dolgozik elosztott rendszerek vagy be rendszerintegráció, akkor az itt bemutatottak nagy része nem újdonság számodra.
A probléma akkor merül fel, amikor az emberek találkoznak a használatával különböző technológiákés amikor azok az emberek technikai beszélgetésbe kezdenek. Ilyenkor gyakran a terminológia miatt kölcsönös félreértés adódik. Itt megpróbálom összehozni a különböző kontextusokban használt terminológiákat.
Ezen a területen nincs egyértelmű terminológia és osztályozás. Az alábbiakban használt terminológia a szerző modelljét tükrözi, vagyis szigorúan szubjektív. Bármilyen kritikát és vitát szívesen fogadunk.
A terminológiát három területre osztottam: RPC (Remote Procedure Call), Messaging és REST. Ezeknek a területeknek történelmi gyökerei vannak.
RPC technológiák a legrégebbi technológiák. Az RPC legfényesebb képviselői: CORBAÉs DCOM.
Akkoriban főleg rendszereket kellett gyorsan és viszonylag megbízhatóan összekapcsolni helyi hálózatok. Az RPC fő ötlete a hívás kezdeményezése volt távoli rendszerek nagyon hasonlít a függvények programon belüli meghívásához. Minden távoli hívás mechanika el volt rejtve a programozó elől. Legalább megpróbálták elrejteni. A programozóknak sok esetben mélyebb szinten kellett dolgozniuk, ahol megjelent a marshaling kifejezés ( rendező) És rendezetlen(hogy van ez oroszul?), ami lényegében a szerializálást jelentette. A folyamatokon belüli normál függvényhívásokat a bejövő hívó kezelte meghatalmazott, és a rendszer funkciót ellátó oldalán, in Diszpécser. Ideális esetben sem a hívó rendszer, sem a feldolgozó rendszer nem kezelte a rendszerek közötti adatátvitel bonyolultságát. Mindezek a finomságok a Proxy - Dispatcher csomagban összpontosultak, amelynek kódja automatikusan generált.
Tehát nem fog észrevenni, nem is szabad észrevennie semmi különbséget a helyi függvény és a távoli függvény hívása között.
Most egyfajta RPC reneszánsz van, melynek legkiemelkedőbb képviselői: Google ProtoBuf, Thrift, Avro.
Idővel kiderült, hogy az a kísérlet, hogy megvédjék a programozót attól, hogy a hívott függvény még mindig eltér a helyitől, nem vezetett a kívánt eredményhez. A megvalósítás részletei és az elosztott rendszerek közötti alapvető különbségek túl nagyok voltak ahhoz, hogy automatikusan generált proxykóddal megoldhatóak legyenek. Fokozatosan jött az a felismerés, hogy a programkódban kifejezetten tükröződnie kell annak, hogy a rendszereket megbízhatatlan, lassú, kis sebességű környezet köti össze.
Megjelentek a technológiák webszolgáltatások. Elkezdtünk beszélgetni ABC: Cím, kötés, szerződés. Nem teljesen világos, miért jelentek meg a szerződések, amelyek lényegében borítékok (borítékok) az input argumentumokhoz. A szerződések gyakran inkább bonyolítják az egész modellt, mintsem egyszerűsítik azt. De... mindegy.
Most a programozó kifejezetten létrehozta szolgáltatás(Szolgáltatás) vagy ügyfél(ügyfél), amely felhívja a szolgáltatást. A szolgáltatás készlet volt tevékenységek (művelet), amelyek mindegyike a bemenetnél vett kérés(Kérés) és kiadták válasz(Válasz). ügyfél kifejezetten küldött(Szent) kérésére a szolgáltatás kifejezetten kapott ( kap) és válaszolt (Elküldve), elküldve a választ. Az ügyfél megkapta (Fogadása) a választ, és ezzel a hívás véget ért.
Csakúgy, mint az RPC-ben, itt is működött valahol a Proxy és a Dispatcher. És mint korábban, a kódjuk automatikusan generált, és a programozónak nem kellett értenie. Kivéve, ha az ügyfél kifejezetten a Proxy osztályait használta.
A kérések és válaszok kifejezetten vezetékes formátumra konvertálódnak. Leggyakrabban bájtok tömbje. Az átalakítást ún SorozatosításÉs Deszerializációés néha elbújik a proxy kódban.
Az üzenetküldés csúcspontja egy paradigma megjelenésében nyilvánult meg ESB (Enterprise Service Bus). Senki sem tudja igazán megfogalmazni, hogy mi ez, de abban mindenki egyetért, hogy az ESB-re vonatkozó adatok üzenetek formájában mozognak.
A kód összetettségével való folyamatos küzdelemben a programozók megtették a következő lépést és létrehoztak PIHENÉS.
A REST alapelve az, hogy a függvényműveletek erősen korlátozottak, és csak egy műveletsor marad meg. CRUD: Létrehozás - Olvasás - Frissítés - Törlés. Ebben a modellben minden művelet mindig bizonyos adatokra vonatkozik. A CRUD-ban elérhető műveletek a legtöbb alkalmazáshoz elegendőek. Mivel a REST technológiák a legtöbb esetben HTTP protokollt használnak, a CRUD parancsok tükröződnek a parancsokban http (hozzászólás - Kap - Tedd - Töröl) . Folyamatosan azzal érvelnek, hogy a REST nem feltétlenül kapcsolódik a HTTP-hez. A gyakorlatban azonban széles körben használják a műveleti aláírások tükrözését a HTTP-parancsok szintaxisában. Például egy függvényhívás
EntityAddress ReadEntityAddress(string param1, string param2)
Így kifejezve:
GET: entityAddress?param1=value1¶m2=value2
Mielőtt elkezdené a vitát elosztott rendszerek vagy integráció, dönt a terminológiáról. Ha a proxy mindig ugyanazt jelenti a különböző kontextusokban, akkor például a kérés keveset jelent az RPC szempontjából, és a rendeződés zavart okoz a REST technológiák tárgyalása során.
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 Microsystems fejlesztette ki, és ez eszközök és könyvtári funkciók készlete. Különösen a NIS (Network Information System) és az NFS (Network File System) működik RPC-n.
Az RPC-kiszolgáló egy olyan eljárásrendszerből áll, amellyel az ügyfél kapcsolatba léphet úgy, hogy RPC-kérést küld a szervernek az eljárás paramétereivel együtt. 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 cserélt összes adatot úgynevezett külső adatábrázolássá alakítják ( Külső adatábrázolás, XDR). Az RPC UDP és TCP socketekkel van társítva az adatok XDR formátumban történő átviteléhez. A Sun az RPC-t nyilvánossá nyilvánította, és leírása megtalálható az RFC sorozatban.
Néha az RPC-alkalmazások változásai összeférhetetlenséget okoznak egy interfész hívási eljárásában. Természetesen egy egyszerű változtatással a szerver megsemmisít minden olyan alkalmazást, amely még a régi hívásokra vár. Ezért az RPC-programokhoz verziószámok vannak hozzárendelve, amelyek általában 1-gyel kezdődnek. Mindegyik egy új verzió Az RPC nyomon követi a verziószámot. Egy szerver gyakran több verziót is kínálhat egyszerre. 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ámmal ( programszám). A szolgáltatásnevek listája általában az /etc/rpc könyvtárban található, amelyre 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 yprogmount show0mount 5yp0000mount41y bind 100007 walld 100008 rwall shutdown yppasswdd 100009 yppasswd bootparam 100026 ypupdated 100028 ypupdate |
A TCP/IP hálózatokban az RPC szerzőknek az volt a feladata, hogy a programszámokat hozzárendeljék az általános hálózati szolgáltatásokhoz. 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 átvitelére, és visszatérnek a TCP-re, ha az átvinni kívánt adatok nem férnek bele egyetlen UDP-datagramba.
Természetesen a kliensprogramoknak módot kell adni arra, hogy kitalálják, melyik port felel meg egy 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 a kliens, aki egy adott programszámmal szeretne kapcsolatba lépni egy szolgáltatással, először egy portmapper kérést intéz a kívánt szolgáltatás portszámának megtudásához.
Ennek a módszernek az a hátránya, hogy egyetlen hibapontot vezet be, hasonlóan inetd démon. Ez az eset azonban valamivel rosszabb, mert amikor a portmapper meghibásodik, minden RPC port információ elveszik. 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 portleképező /sbin/portmap vagy /usr/sbin/rpc.portmap. Eltekintve attól, hogy hálózati indító parancsfájlból kell elindítani, a portmapper nem igényel konfigurációs munkát.
