Remote Procedure Call

Client/Server-Systeme
Prof. Dr.-Ing. Wilhelm G. Spruth
WS 2004 / 2005
Teil 3
Remote Procedure Call
cs 0400 ww6
wgs 09-96
Schwierigkeiten mit Sockets
Sockets nur Schnittstelle zur Transportschicht. Keine
Unterstützung zur
Kommunikationssteuerung
Datendarstellung
Anwendungsprogrammierer muß selber Protokolle definieren
und implementieren um
Kommunikationspartner finden
Austausch von Nachrichten steuern
Eigenschaften des Transportmechnanismus berücksichtigen
Wechsel der Transferrichtung steuern
auf Fehler reagieren
(z.B. Verbindungsabbruch)
Name Server
Sync Punkte
Verbindungsorientiert
verbindungslos
Please Token
Waisen
und
einheitliche Datendarstellung
XDR, ASN.1
Bei komplizierten Anforderungen aufwendige und
fehleranfällige Programmierung
cs 0408 ww6
wgs 09-98
RPC - Remote Procedure Call
Unterprogrammaufruf auf einem anderen Rechner
standardisierte Interprozeßkommunikation (Interprocess
Communication, IPC) zwischen Rechnern unterschiedlicher
Architektur und Hersteller
verdeckt den Transportmechanismus.
RPC definiert:
•
•
•
•
•
•
Auffinden des Kommunikationspartners
Steuerung des Datenaustausches
Wechsel der Transferrichtung
Erkennung von Fehlern
Überwachung von Zugriffsberechtigungen
Datenrepräsentation
Der Begriff "RPC" wird sowohl generisch als auch für spezifische
Implementierungen verwendet :
• Sun RPC
• DCE RPC
RPC ähnliche Interprozesskommunikation
•
•
•
•
CICS Direct Program Link (DPL)
Corba
RMI
Microsoft DotNet (DCOM, COM+, DNA)
cs 0307 ww6
wgs 09-99
Viele Hersteller,.
viele RPC Produkte
OSI
ASN.1
SUN
RPC, XDR
CICS
DPL
Zeitachse
DCE
RPC
CORBA
Microsoft
Object RPC
RMI
Web
Services
Viele Programm Pakete, die RPC intern benutzen
z. B. Tivoli (DCE)
Entwicklung des RPC
cs 0327 ww6
wgs 02-03
SUN RPC
(auch als ONC RPC bezeichnet)
Die Firma SUN entwickelt
1. RPC (Remote Procedure Call)
Aufruf eines Unterprogramms auf einem anderen
Rechner ohne Wechsel des Programmkontextes
einheitliches Protokoll für die Prozeßkommunikation
auf Rechnern unterschiedlicher Architektur und
Hersteller
2. XDR (eXternal Data Representation)
betriebssystem- und rechnerunabhängige ,
einheitliche Darstellung von Daten
RPC und XDR Protokolle und Quellcode werden von SUN
als Public Domain Software zur Verfügung gestellt.
Internet Activity Board nimmt RPC und XDR als RFC
(Request For Comment) auf:
RPC
XDR
cs 0404 ww6
RFC 1050
RFC 1014
wgs 09-98
OSI
Schichten
5-7
Anwendung
4
TCP
UDP
3
IP
2
z. B. Ethernet
1
Hardware
Schichten der Internet Protokoll Suite
cs 0406 ww6
wgs 09-98
OSI
Schichten
7
Anwendung
6
XDR
5
RPC
4
TCP
UDP
3
IP
2
z. B. Ethernet
1
Hardware
Einordnung des SUN RPC
in das OSI Modell
cs 0405 ww6
wgs 09-98
Klient
Server
KlientenProgramm
warten
RPC ( ..... ) ;
RPC
Aufruf
warten
Server
Programm
RPC
Ergebnis
warten
Synchroner RPC
Klient blockiert während der Ausführung des Server Programms
cs 0316 ww6
wgs 09 -00
Client
Aufrufende
Prozedur
Argumente
Server
Ergebnisse
Aufgerufene
Prozedur
Local Procedure Call
Ein aufrufender Prozess führt eine aufgerufene Prozedur in
seinem eigenen Adressraum aus
Client
Server
Aufrufende
Prozedur
Aufgerufene
Prozedur
Argumente
Ergebnisse
Argumente
Client
Stub
Request
Nachricht
Ergebnisse
Server
Stub
Reply
Nachricht
Request
Nachricht
Reply
Nachricht
Netzwerk
Remote Procedure Call
Client und Server laufen als zwei separate Prozesse. Sie
können (Ausnahmefall), müssen aber nicht, auf dem gleichen
Rechner laufen.
Die beiden Prozesse kommunizieren über Stubs. Stubs sind
Routinen, welche lokale Prozedur Aufrufe auf Netzwerk RPC
Funktionsaufrufe abbilden.
cs 0308u ww6
wgs 09-99
RPC Beispiel (1)
Angenommen, der Server ist nur eine Library. Dann ist Add
lediglich ein Procedur Aufruf.
RPC Beispiel (2)
RPC Beispiel (3)
Aufgaben der Stubs (Prozedurrümpfe)
Binden des Client-Anwendungsprogramms an den Server
Parameter des RPC einsammeln und in einen Puffer
packen, dessen Inhalt in der Form einer Nachricht an den
Empfänger gesendet wird. Dieser Vorgang wird als
Parameter marshalling bezeichnet.
Fehlerbehandlung
Kommunikationsfehler
Klientenfehler
Serverfehler
Transparente Kommunikation
Transportmechanismus, z.B. TCP, UDP
Datenrepräsentation, z.B. ASN.1, XDR
Sicherheit
Verschlüsselung, Authentifizierung
z.B. Kerberos, SSL
vs1010 ww
wgs 06-95
Client
Server
Aufrufende
Prozedur
1
Aufgerufene
Prozedur
10
6
Client
Stub
2
5
Server
Stub
9
7
4
RPC/XDR
Bibliothek
RPC/XDR
Bibliothek
3
8
8
3
Netzwerk
Aufruf eines SUN Remote Procedure Calls
Aufgaben der Stubs:
• Parameter des RPC Aufrufs einsammeln und in eine
Nachricht packen (marschalling)
• Transparente Weiterleitung (entfernte Ausführung soll für
den Anwendungsprogrammierer verborgen bleiben)
Aufgaben der RPC/XDR Bibliothek:
• Fehlerbehandlung (Client, Server, Netzwerk)
• Transparente Kommunikation , z.B. TCP, UDP
• Datenrepräsentation
• Sicherheit
s 0310u ww6
wgs 09-99
Stub
RPC Routine
SVC
System Call
User Status
Kernel Status
Transport Schicht
Routine
Stub des Klienten-Programms
RPC und XDR sind System Calls. Die Routinen laufenteilweise im
User Status, verzweigen aber in den Kernel status.
cs 0317 ww6
wgs 09 -00
RPC
RPC
RPC
Service Service Service
RPC Server
andere Prozesse
Betriebssystem Kernel
Die RPC Services (RPC Dienstprogramme) können entweder in
getrennten virtuellen Adressenräumen laufen, oder alternativ als
Threads innerhalb eines virtuellen Adressenraums implementiert
werden.
Ein RPC Service wird auch als Implementation bezeichnet.
Häufig Hunderte oder Tausende unterschiedlicher RPC Services auf
dem gleichen Rechner.
Der RPC Server stellt Verwaltungsdienste für seine RPC Services
zur Verfügung, z.B. das Binding.
Auf einem Rechner können mehrere RPC Server laufen, die z.B.
unterschiedliche Arten von RPC Services gruppieren.
Die RPC Ebenen
RPC bietet Schnittstellen in mehreren Ebenen an. Die
wichtigsten sind:
High Level
einfache Schnittstelle, um ein RPC abzusetzen
keine besonderen Kenntnisse über Netzwerkarchitektur
notwendig
basiert auf dem UDP-Protokoll
Lower Level
erlaubt detaillierte Kontrolle über
Verbindung
Auswahl des Protokolls (z.B. TCP oder UDP)
Übermittelung komplexer Datenstrukturen
verschiedene Arten der Zugriffsüberwachung
Setzen von Zeitkonstanten (timeouts)
Überwachen der Sockets
Reaktion auf Fehler
Call Back Mechanismen
cs 0409 ww6
wgs 06-94
Identifikation eines RPC Dienstprogrammes
o
Jedes RPC Dienstprogramm auf einem Server ist
eindeutig durch das Tripel
Programmnummer
Versionsnummer
Prozedurnummer
program number
version number
procedure number
identifiziert.
Jede Nummer wird durch einen 4-Byte langen IntegerWert dargestellt.
o
Klient kennt nur
Internetadresse und das Tripel Programmnummer,
Versionsnummer, Prozedurnummer
um über einen RPC ein Dienstprogramm des Servers
aufzurufen.
o
Portnummer des Servers ist dem Klienten unbekannt.
cs 0201 ww
wgs 06-94
0
31
Transaktions-ID
Senderichtung
RPC - Protokollversionsnummer
Programmnummer
Versionsnummer
Prozedurnummer
Berechtigungsnachweis
Berechtigungsnachweis-Verifizierung
Parameter des Prozeduraufrufes
RPC - Protokollkopf
cs 0315
ww6
wgs 05 -94
RPC Binding
Wie findet der Klient die Lokation des RPC Services und des
dazugehörigen Servers ?
2 Probleme für den Klienten:
1.
Server identifizieren (z.B. Internet Adresse)
2.
RPC Service identifizieren (z.B. Port Nummer)
Portnummer muss aus Portierungsgründen variabel sein.
Binding ist die Abbildung (mapping) von Programmnummer,
Versionsnummer und Prozedurnummer auf die physische Adresse
(z.B. Internet Adresse und Port Nummer).
Ein Binder ist ein Dienst der das Binding zur Verfügung stellt
(z.B.. portmapper beim Sun RPC).
Der Binder hat drei Functionen:
1.
2.
3.
Register
Unregister
LookUp
Der High Level RPC setzt voraus, das der Klient die physische
Adresse des Servers kennt (z.B. Internet ID).
#include ..........
int main( ..... )
{
int result;
static char *datain ;
static char *dataout ;
•
•
result=callrpc(host, PROGNUM, VERSNUM, PROCNUM,
inproc, &datain, outproc, &dataout);
return(1);
•
•
}
High Level RPC Client Programm
inproc() ist eine XDR Routine, welche die Daten von &datain
encodiert um dem Server das Request Argument mitzuteilen.
outproc() ist eine XDR Routine, welche die Antwort des Servers
nach &dataout decodiert.
#include ..........
servicexxx( ..... )
{
•
•
/* hier passiert die eigentliche Arbeit der RPC Server Routine
*/
•
•
}
int main(void)
{
•
•
/* register with port mapper so that the client knows
where to contact for service */
registerrpc(PROGNUM, VERSNUM, PROCNUM, progname,
inproc, outproc);
•
•
/* run the server RPC */
svc_run();
•
•
return 1;
}
High Level RPC Server Programm
Ein RPC Server Programm besteht in der Regel aus zwei Teilen:
• dem eigentlichen Server, und
• einem oder mehreren Services ( auch als Server Implementation
bezeichnet)
Wenn der Server eine Anforderung für PROGNUM, VERSNUM,
PROCNUM erhält, versucht er progname auszuführen.
Arbeitsweise des High Level RPC
Aufrufes
Der High Level RPC Aufruf bewirkt unter der Decke 2 RPC
Aufrufe:
1. Aufruf des Server-Portmappers. Dieser teilt
dem Klienten die zu der angegebenen
Programmnr./Versionsnummer dazugehörige Portnummer
des Serverrechners mit.
2. Aufruf des Server Programms über die so ermittelte
Portnummer.
Jeder High Level RPC Aufruf benötigt somit für den
Benutzer unsichtbar 2 reale Aufrufe (zusätzliche
Netzbelastung).
Das aufgerufene Server-Programm kann aus mehreren
Prozeduren bestehen, von denen der RPC Aufruf eines in
Anspruch nimmt. Nur das Server-Programm ist über die
Portnummer ansprechbar. Das Server-Programm enthält
einen Dispatcher, welcher in die gewünschte Prozedur
verzweigt.
High Level RPC Aufrufe benutzen das verbindungslose
UDP Protokoll. Die Verwendung von TCP ist nur in
Verbindung mit den lower level RPC Aufrufen möglich.
vs1016
ww
+
wgs 05 -94
Client
Rechner
Server
Rechner
Port
111
Port
Mapper
Port
a
Port
b
2
1
Client
Program
Port
c
RPC
Service
3
Client - Server Adressierung
1. RPC Server etabliert Adresse, auf der er auf Anforderungen
lauscht. Er registriert diese Adresse
(hier Port c) beim Port Mapper
2. Klient erfragt beim Port Mapper die Adresse der
gewünschten Server Prozedur
3. Klient öffnet Übertragungsweg mit der gewünschten
Server Prozedur
cs 0411 ww6
wgs 06-94
Erfragen der Portnummer
cs 0403a ww6
wgs 07-03
Lower Level RPC
Interface Definition Language
Ein RPC Programm definiert seine Interface (Schnittstelle) unter
Benutzung einer Interface Definition Language (IDL). Die IDL
Beschreibung der Schnittstelle enthält die Namen und Parameter
aller Proceduren des RPC Programms, sowie Angaben zur
Fehlerbehandlung. Jede Prozedur muss in der Schnittstellenbeschreibung festgehalten werden
Ein Stub Compiler liest die IDL Schnittstellenbeschreibung und
produziert zwei Stub Proceduren für jede Server Procedure (client
side stub und server side stub).
• Der Server Programmierer implementiert die Server Procedur und
linked sie mit dem Server Side Stub
• Der Klient Programmer implementiert das Klienten Programm
und linked es mit dem Client Side Stub
• Die Stubs sind zuständig, alle Details der Kommunikation
zwischen Klient und Server zu steuern und zu verwalten.
Ein Client Side Stub ist eine Procedur die so aussieht, als wäre es
eine callable Server Procedur. Ein Server Side Stub sieht für die
Server Prozedur so aus, als hätte ein Klient sie aufgerufen.
• Das Klienten Programm glaubt, es hätte den Server aufgerufen. In
Wirklichkeit ruft es den Client Side Stub auf.
• Das Server Programm glaubt, es würde vom Klienten Programm
aufgerufen. In Wirklichkeit ruft es der Server Side Stub auf.
• Die Stubs senden sich gegenseitig Messages für eine
transparente Ausführung des RPC.
In Corba and Java/RMI werden die Server Side Stubs als Skeletons
bezeichnet.
Sun RPC:
XDR and RPC language
XDR - eXternal Data Representation language
•
•
•
•
Use to describe data formats
Transfer data between different computer architectures
It is not a programming language
XDR data types, similiar as in C/C++
RPC Language (Interface Definition Language, IDL)
• identical to XDR, only added program- definition
• Parameters passing
o A single argument and a single result are allowed
o Multiple arguments and result values
should be packaged into a single structure
/* date.x - Specification of remote date and time service. */
/* Define 2 procedures:
bin_date_1() returns the binary time and date (no arguments).
str_date_1() takes a binary time and returns
a human-readable string. */
program DATE_PROG {
version DATE_VERS {
long
BIN_DATE(void) = 1;
string STR_DATE(long) = 2;
} = 1;
} = 0x31234567;
/* procedure number = 1 */
/* procedure number = 2 */
/* version number = 1 */
/* program number =
0x31234567 */
Lower Level RPC
Interface Definition Language (IDL)
Compilation Schritte für den
Lower Level Remote Procedure Call
Fehlerbehandlung
Fehlermöglichkeiten
•
Server kann Prozedur nicht beenden
(z.B. Rechnerausfall, SW-Fehler)
•
Klient wird während des RPCs abgebrochen
(z.B. Rechnerausfall, SW-Fehler)
Im Gegensatz zum lokalen Prozeduraufruf sind Fehlerbehandlungsmaßnahmen erforderlich.
cs 0311 ww6
Klient
Server
Fehler
Fehler
wgs 11-99
Fehlerbehandlung - Ausfall des Servers
1.
Idempotente Arbeitsvorgänge
"Idempotent" sind Arbeitsvorgänge, die beliebig oft ausgeführt
werden können; Beispiel: Die neuesten Fußballergebnisse in die
Bundesligatabelle auf einer Webseite eintragen. Nicht idempotent
ist die Überweisung eines Geldbetrages von einem Konto auf ein
anderes.
2.
Nicht-idempotente Arbeitsvorgänge
Problem: Wie wird festgestellt, ob ein Arbeitsgang
durchgeführt wurde oder nicht.
• "Genau einmal" (exactly once).
• "Höchstens einmal" (at most once).
• "Wenigstens einmal" (at least once). Ideal für idempotente
Vorgänge.
Die „genau einmal“ (exactly once) Semantik wird mit Hilfe von
Transaktionen verwirklicht.
cs 0324 ww6
wgs 08-00
Fehlerbehandlung
Nicht-idempotente Arbeitsgänge
Ohne Fehler garantiert das RPC System, daß entfernte
Operationen genau einmal durchgeführt werden.
Problem: wie wird im Fehlerfall festgestellt, daß
Arbeitsgang durchgeführt wurde oder nicht.
"Genau einmal" (exactly once) Semantik ist mit TCP für die
Datenübertragung erreichbar. Problem bei den auf UDP
basierenden High Level RPC Aufrufen.
Die „ACID“ Eigenschaften eines Transaktionsmonitors
garantieren die Genau einmal Semantik für die
Verarbeitung durch den (die) Server.
"Höchstens einmal" (at most once, maybe). Das Client
Anwendungsprogramm erhält eine Fehlermeldung, und
muß die Fehlerbehandlung übernehmen. Kann versuchen,
das "Genau einmal" Ideal zu simulieren. Garantiert keine
Mehrfachausführungen des RPC.
"Wenigstens einmal" (at least once). Ideal für idempotente
Vorgänge. Bei nicht-idempotenten Vorgängen wird jede
durch den Zeitgeber verursachte Neuübertragung mit
einer Kennziffer versehen, die vom Server zurückgegeben
wird und von der Fehlerbehandlungsroutine des
Clientprogrammes ausgewertet wird.
cs0321
ww6
wgs 09 -00
Eingabe Queue
enqueue
dequeue
Queue
Manager
RPC
Prozess
Klient
dequeue
enqueue
Ausgabe Queue
Server
Fehlerbehandlung - Ausfall des Klienten
Getrennte Warteschlangen für eingehende und ausgehende
Nachrichten lösen viele Probleme. Wenn der Klient abstürzt
(Waise), schließt der Server seine Arbeit ab. Das Ergebnis der RPC
Verarbeitung steht in der Ausgabe Queue, und kann beim
Wiederanlauf des Klienten dort abgeholt werden.
Andere Aufgaben der Queues:
• Prioritätensteuerung
• Lastverteilung auf mehrere Server
cs 0323 ww6
wgs 08-00
Aufruf eines OS/390 Mainframe-Programms aus Java
Die Integration von OS/390 Mainframe-Programmen in Javabasierte Client/Server-Systeme funktioniert prinzipiell recht einfach.
In der folgenden Methode wird ein OS/390 RPC-Programm namens
„KFZRES01 “aufgerufen.Diesem Programm werden zwei Strings
übergeben,einer für die Eingabeparameter,der zweite für die durch
KFZRES01 erzeugte Ausgabe.
/** *Folgende Methode ruft einen RPC auf dem Mainframe
auf. */
private boolean rpcCall(String inputString,
StringBuffer outBuffer){
RPC m_rpc =new RPC();
try {
//Mainframe braucht UserID und Password!
m_rpc.setUser(“k3216 ”);
m_rpc.setPwd(“TESTPW ”);
//Name des aufzurufenden Programms setzen
m_rpc.setRpcName(“KFZRES01 ”);
//remote procedure call ausführen
m_rpc.execute(inputString,outBuffer);
return true;
}
catch (Exception e) {
m_stateField.setText(“Execute-Error:“
+m_rpc.getApiMessage());
return false;
}
}
Seitens der OS/390 Mainframe-Programme ändert sich rein gar
nichts gegenüber der Nutzung per 3270-Terminal. Das Programm
KFZRES01 „weiß “also nicht, ob es durch ein Java-Programm
benutzt wird oder über konventionelle OS/390 MainframeTerminals.
cs 0328 ww6
wgs 02-03
DCE Remote Procedure Call
Kann konfiguriert werden, die Host Computer Sicherheitseinrichtungen zu benutzen
Unterstützt verbindungslose und verbindungsorientierte
Protokolle
20 unterschiedliche Nachrichten Typen definiert, davon
einige nur für den verbindungslosen oder den
verbindungsorientierten Transport. Die Nachrichten
werdenals Protocol Data Units (PDU´s) bezeichnet
Der Microsoft RPC ist eine auf DCOM basierende
objektorientierte Erweiterung des DCE RPC (auch als
„Objekt RPC“ bezeichnet. Die Syntax der übertragenen
Pakete ist nahezu vollständig mit der ursprünglichen DCE
Spezifikation kompatibel. Wird als Bestandteil von NT
ausgeliefert.
cs 0806 ww6
wgs 06-98
XML - RPC
Part of Web Services
• XML - RPC is a Remote Procedure calling protocol that
works over the Internet. An XML - RPC Message is a
HTTP- POST request.
• The body of the request is in XML. A procedure executes
on the server and the value it returns is also formatted in
XML.
• Procedure parameters can be scalars, numbers, strings,
dates, etc.
Second generation RPCs:
Corba
RMI
Microsoft .NET
Third generation RPCs: Web services and XML
XML RPC
cs 0313
wgs 09-00
Schicht
7
Anwendungen
RPC
Named
Pipes
CPI-C
5-6
4
Sockets
NetBIOS
API
APPC
NLM
API
TCP/IP
NetBIOS
SNA
IPX
Gebräuchliche Programmierschnittstellen
(zahlreiche Querverbindungen
weitere Protokolle: HTTP, 3270 (verwendet SNA)
Corba / IIOP, RMI, DCOM, verwenden Sockets und/oder
RPC. Microsoft SMB verwendet Named Pipes.
cs 0401 ww
wgs 01-96
Anwendungen
SMB
NetBIOS
IPX/SPX
TCP/UDP
NetBEUI
IP, PPP
Ethernet, Token Ring, Seriell
Service Message Block (SMB) Protokoll Stack
Ein SMB ist ein Kommando mit dessen Hilfe ein Klient auf einen
Server zugreift. Beispiel: Die Partition C: eines Servers erscheint
auf einem Klienten als Partition E: . Microsoft proprietärer
Standard, 1987 definiert, wird mit allen Windows Betriebssystemen
(3.11, 95, 98, NT) als Klient und als Server ausgeliefert.
Mehrere inkompatible Varianten. Klient sendet negprot Kommando
an Server, um Protokollvariante zu vereinbaren.
NT LAN Manager, OS/2 LAN Server, PATHWORKS (Digital) sowie
LAN Manager for Unix verwenden SMB, ebenso SAMBA´s NT
Version .
Microsoft TCP Implementierung ist in Wirklichkeit eine „NetBIOS
over RCP/IP Implementierung, entsprechend RFC 1001 und 1002,
von Microsoft alternativ auch als NBT oder NetBT bezeichnet.
CIFS (Common Internet File System) ist ein neuer, SMB basierter
Microsoft Standard.
Wird ein NT Netzwerk installiert, erfolgt automatische die Installation des
„.Arbeitsstationsdienstes“. Es erscheint Meldung: “Installiert Unterstützung für das SMB
(Server Message Block) Protokoll. Anderes Beispiel: Interlnk, Intersvr Kommandos.
cs 0417x ww6
wgs 11-99