|
RPC
- Remote Procedure Call
ÜBERSICHT
1. Definition und Funktionsweise
des RPC
2. Ablauf eines RPC
3. Aufgaben der Prozedurrümpfe (Stubs)
4. RPC-Semantiken
5. RPC-Protokolle
6. Waisenbehandlung
7. Quellen
1.
Definition und Funktionsweise des RPC
RPC ist ein Mechanismus um verteilte
Anwendungen auf Basis des Client/Server-Modells zu realisieren.
Neben dem Client/Server gibt es zwei weitere Kooperationsformen,
nämlich Produzenten/Konsumenten-Systeme und das Pipeline-Modell.
Prozesse kooperieren, um ein gemeinsames Ziel zu erreichen.
Client/Server-Modell
Der Server bietet seinen Service einer Menge a priori unbekannter
Clients an. Service bezeichnet die Software-Instanz, die auf
einer oder mehreren Maschinen ausgeführt wird. Der Server
ist eine Maschine, die Service-Software ausführt. Der
Client ist der Nutzer eines Services.
Produzenten/Konsumenten-Systeme
Der Konsument nimmt Daten auf, die vom Produzenten erzeugt
wurden. Hier genügt ein unidirektionaler Kanal.
Pipeline-Modell
Eine Pipeline kann man sich als ein unidirektionalen Kanal
vorstellen.
2. Ablauf eines RPC
3. Aufgaben der Prozedurrümpfe
(Stubs)
3.1 Binden von Clients an
Server
Binden ist die Zuordnung eines
Clients an einen Server. Der Server muss die vom Client gewünschte
Prozedur anbieten. Beim Binden unterscheidet man zwei Arten,
nämlich das statische Binden und das dynamische Binden.
Statisches Binden
Beim statischen Binden geschieht das Binden beim Übersetzen
des Clientprogramms. Der Client-Stub identifiziert den Server
mittels einer Adresse. Diese Art des Bindens hat den Vorteil,
dass es kein Overhead zur Laufzeit gibt. Ein großer
Nachteil ist aber, dass keine dynamische Server-Rekonfiguration
möglich ist. Auch ist der Einsatz von mobilen Servern
nicht möglich. Sämtliche Server müssen zur
Zeit der Übersetzung bekannt sein.
Dynamische Binden
Beim dynamischen Binden gibt es Unterschiede in der Wahl des
Bindezeitpunktes und der Art des Bindevorgangs.
Das Binden kann zu Beginn des
Programmablaufs gemacht werden. Dies hat den Vorteil, das
ein Bindevorgang pro entfernter Prozedur nötig ist. Dabei
spielt die Anzahl der Aufrufe der entfernten Prozedur keine
Rolle. Der Nachteil ist, dass keine dynamische Anpassung an
den aktuellen Systemzustand während der Programmausführung
möglich ist.
Geschieht das Binden erst beim Aufruf der entfernten Prozedur,
so hat es des Vorteil, dass eine dynamische Anpassung an den
Systemzustand möglich ist. Dem gegenüber steht der
Nachteil des mehrfachen Bindens pro entfernter Prozedur.
Auf welche Art kann ein Bindevorgang
durchgeführt werden? Es gibt die Möglichkeit der
Zuhilfenahme eines Directory-Dienstes oder mittels Broadcast-Aufrufen.
Einen Directory-Dienst kann man
sich als Dienst vorstellen, der sämtliche Server mit
den angebotenen Diensten verwaltet. Falls ein Client einen
RPC startet, so wird zuerst im Directory-Dienst nachgeschaut,
welcher Server den gewünschten Dienst anbietet. Als Antwort
auf die Anfrage wird dem Client die Adresse des Servers übergeben.
Erst dann kann auf der Client-Seite das Binden gemacht werden.
Diese Art des Bindevorgangs kann auch in größeren
Systemen eingesetzt werden, hat aber den Nachteil, dass der
Directory-Dienst sehr zuverlässig und leistungsfähig
sein muss.
Falls kein Directory-Dienst gewünscht
wird, so bietet sich die Möglichkeit mittels Broadcast-Aufrufen
den Server zu finden, der den gewünschten Dienst anbietet.
Dabei startet der Client einen Broadcast-Aufruf. Alle Server
antworten mit den zur Verfügung gestellten Diensten und
ihren Adressen. Der Client entscheidet sich für den Server,
der den benötigten Dienst zur Verfügung stellt.
Diesen kann er mittels der Adresse ansprechen. Broadcast-Aufrufe
erfordern, dass alle Server den Aufruf bearbeiten. Auch sind
sie nur in lokalen Netzen praktikabel.
3.2 Transparente Kommunikation:
Transport-Mechanismus (z.B. TCP, UDP), Datenrepräsentation
und Sicherheit (Verschlüsselung, Authentifizierung)
Auf welche Art und Weise (welches
Protokoll, Art der Verschlüsselung, Authentifizierung)
die Kommunikation zwischen Client und Server stattfindet ist
Sache des Client-Stubs. Z.B. baut SUN RPC auf TCP und UDP
auf.
Idealerweise sollte der Aufruf
von eine entfernten Prozedur das gleiche Verhalten haben wie
der Aufruf einer lokalen Prozedur. Man unterscheidet zwischen
call-by-value und call-by-reference Parameteraufrufen.
3.3 Kodierung (Marshalling)
und Dekodierung (Unmarshalling) von Argument- und Ergebnisparametern
der entfernten Prozedur
call-by-value
function inc1(i: integer) : integer;
begin
i:= i+1;
return (i)
end;
Aufruf z:=inc1(x);
Client-Stub: Bei einem Aufruf
der entfernten Prozedur inc1, wird der Wert des Variable x
als Argument in die Nachricht an den Server kopiert.
Server-Stub: Der Server-Stub kopiert die Nachricht in eine
Variable i
Die Prozedur wird ausgeführt.
Server-Stub: Server-Stub kopiert aus Variable i Ergebnis in
Nachricht an Client-Stub.
Client-Stub: Kopiert Ergebnis aus Nachricht in Variable z
call-by-reference, Mögliche
Realisierung durch Call-by-Copy / Restore-Ansatz
procedure inc2 (var i : integer);
begin
i:=i+2;
end;
Aufruf inc2(x);
Client-Stub: Bei einem Aufruf
der entfernten Prozedur inc2, wird Variable x als Argument
in Nachricht an den Server kopiert.
Server-Stub: Der Server-Stub kopiert Argument aus Nachricht
in Stub-Variable und übergibt der Prozedur Pointer auf
Stub-Variable.
Die Prozedur wird ausgeführt.
Server-Stub: Kopiert wird der Wert der Stub-Variable als Ergebnis
in Nachricht an den Client.
Client-Stub: Kopiert Ergebnis aus Nachricht in Variable x
Allerdings gibt es Probleme mit
dem Call-by-Copy / Restore Ansatz. Falls es bei einem entfernten
Prozeduraufruf unterschiedliche Kopien für eine Referenzvariable
gibt, so unterscheiden sich die Ergebnisse bei einer lokalen
und entfernten Ausführung. Kurz: Probleme entstehen,
falls zwei oder mehr Parameter das gleiche Objekt referenzieren.
Eine alternative Realisierung
ist der Zugriff des Servers auf den entfernten Parameterwert
auf der Clientseite. Das verursacht allerdings einen hohen
Overhead.
Als Fazit kann man festhalten,
dass Call-by-Value Parameterübergabe einfach und effizient
zu realisieren sind. Call-by-Reference und Pointer-Parameter
sind problematisch bzw. ineffizient. Deshalb erlauben viele
RPC-Systeme nur Call-by-Call-Value-Parameter.
3.4 Fehlerbehandlung (Kommunikationsfehler,
Clientfehler und Serverfehler)
Es können folgende Fehler
auftreten:
Fehler 1: RPC Auftrag nicht korrekt
übertragen oder geht verloren.
Fehler 2: RPC Ergebnis nicht
korrekt übertragen oder geht verloren.
Fehler 3: Server kann Prozedur
nicht beenden, z.B. durch Rechnerausfall oder Software-Fehler.
Fehler 4: Client wird während
des RPCs abgebrochen, z.B. durch Rechnerausfall oder Software-Fehler.
Es gibt drei Möglichkeiten
wie der Client-Stub im Falle des Ausbleibens einer Antwort
reagiert.
1: Als erstes kann der Client-Stub
auf die Antwort warten, ohne etwas zu unternehmen. Damit ist
der Client permanent blockiert. Die Prozedur wird entweder
irgendwann ausgeführt oder nicht.
2: Der Client-Stub benutzt Timeout-Mechanismus.
Falls es innerhalb der eingestellten Zeit zu keiner Ausführung
der Prozedur kommt, gibt der Client-Stub eine Fehlermeldung
an den Client weiter.
3: Der Client-Stub benutzt Timeout-Mechanismus.
Falls es innerhalb der eingestellten Zeit zu keiner Ausführung
der Prozedur kommt, sendet der Client-Stub den Auftrag erneut
an Server. Falls der Server Duplikate (von Anfragen) erkennt,
wird die Prozedur nur einmal ausgeführt, falls nicht
>=1.
Ohne Fehler garantiert jedes
RPC-System, dass eine entfernte Operation genau einmal ausgeführt
wird. Im Fehlerfall können unterschiedliche RPC-Systeme
ein unterschiedliches Verhalten aufweisen, wie oben beschrieben.
RPC-Semantiken beschreiben, wie
sich ein RPC-System im Fehlerfall verhält.
4. RPC-Semantiken
4.1
Maybe
Ein Aufruf wird nicht oder höchstens einmal ausgeführt.
Der Client erhält im Fehlerfall eventuell keine Information
über den Status des Aufrufs.
4.2
At-Least-Once
Ein Aufruf wird mindestens einmal ausgeführt, d.h. Mehrfachausführungen
sind möglich.
4.3
At-Most-Once
Ein Aufruf wird genau einmal ausgeführt. Jedoch gibt
es Einschränkungen bei Systemfehlern. D.h. es wird keine
Garantie für eine Ausführung gegeben, aber es wird
garantiert, dass es keine Mehrfachausführung gibt.
4.4
Exactly-Once
Der Aufruf wird genau einmal ausgeführt, es gibt keine
Einschränkung bei Systemfehlern.
5. RPC-Protokolle
Ein RPC-Protokoll ist die Realisierung
einer RPC-Semantik. Unter 4. wurden RPC-Semantiken vorgestellt.
Hier soll näher darauf eingegangen werden, wie die geforderten
Eigenschaften der jeweiligen RPC-Semantik erreichen lässt.
Es gibt zwei unterschiedliche
Protokollklassen. Request/ Response (RR) und Request/ Response/
Acknowledge (RRA)
5.1 Maybe
Der Client-Stub sendet einen
Auftrag und startet Timer. Falls Timeout oder ein Fehler auftritt,
bevor die Antwort eintrifft, wird eine Fehlermeldung (Exception)
an den Client weitergegeben.
Der Server-Stub erkennt keine Duplikate. Er sendet die Antwort
nach Ausführung der Prozedur.
Was passiert, wenn request unterwegs verloren geht? Der Client-Stub
wartet bis Timeout und gibt Exception an den Client weiter.
Was passiert, wenn response verloren geht? Der Client-Stub
wartet bis Timeout und gibt Exception an den Client weiter.
Falls es zu keinem Fehler kommt, wird der Aufruf höchstens
einmal ausgeführt. Bei einem Fehler wird der Aufruf nicht
ausgeführt. Somit ist die obere Forderung erfüllt.
5.2
At-Least-Once
Der Client-Stub speichert den Auftrag in einem flüchtigen
Speicher. Falls es zu einem Timeout kommt, sendet er Auftrag
periodisch an den Server, bis eine Antwort eintrifft. Der
Auftrag wird aus dem flüchtigen Speicher gelöscht,
wenn die Antwort eintrifft.
Der Server-Stub erkennt keine Duplikate und sendet Antwort
nach Ausführung der Prozedur an Client-Stub.
Was passiert, wenn request verloren geht? Nach Timeout sendet
der Client-Stub die Anfrage nochmals. Dies wird so oft wiederholt,
bis eine Antwort eintrifft.
Was passiert, wenn response verloren geht? Nach Timeout sendet
der Client-Stub die Anfrage nochmals. Dies wird so oft wiederholt,
bis eine Antwort eintrifft.
Falls request verloren geht, wird die Anfrage nur einmal ausgeführt.
Falls allerdings response verloren geht, wird die Anfrage
mehrmals ausgeführt. Der Server erkennt nämlich
keine Duplikate.
Die Forderung ist erfüllt. Aufruf wird mindestens einmal
ausgeführt, aber Mehrfachausführungen sind möglich.
5.3 At-Most-Once
Der Unterschied zu At-Least-Once
ist, dass der Server die Antwort in einen flüchtigen
Speicher schreibt und sie danach erst an den Client-Stub sendet.
Der Server-Stub ist in der Lage Duplikate auf der Basis von
Auftrag-Id zu erkennen und führt eine Anfrage genau einmal
durch. Nur wenn ack beim Server einkommt, wird das Ergebnis
der Anfrage aus dem Speicher gelöscht. Wenn nicht, sendet
der Server-Stub die Antwort periodisch bis ack eintrifft.
Was passiert, wenn request verloren geht? Nach Timeout sendet
Client-Stub die Anfrage nochmals. Die wird periodisch wiederholt,
bis eine Antwort eintrifft.
Was passiert, wenn response verloren geht? Nach Timeout sendet
Client-Stub die Antrage erneut. Durch den Auftrag-Id erkennt
der Server-Stub das Duplikat. Die gespeicherte Antwort wird
ausgelesen und erneut gesendet. Damit ist die Forderung erfüllt,
dass die Anfrage genau einmal berechnet wird.
Was passiert, wenn ack verloren geht? Server-Stub sendet die
Antwort periodisch, bis ack eintrifft. Weitere Frage: Wie
weiß der Client-Stub, falls er die Anfrage nach Empfang
von response (d.h. ack ging verloren) löscht, ob er ein
ack einfach so, nach einem erneuten Empfang von response,
senden soll? Eine Möglichkeit wäre, dass der Client-Stub
die acks speichert und erst nach einer gewissen Zeit löscht.
Die Forderung, dass der Aufruf
genau einmal ausgeführt wird, ist somit erfüllt.
Bei Client- und Server-Fehlern kann die Ausführung nicht
garantiert werden.
5.4 Exactly-Once
Dieses Protokoll ist wie bei
At-Most-Once, außer das die Aufträge und Antworten
auf stabilen Speicher geschrieben werden. Save und Unsave
sind atomare Operationen. Ein Server-Fehler vor save macht
alle Änderungen der Prozedur rückgängig.
6. Waisenbehandlung
Ein Abbruch von Clients kann
zu Waisen (Orphans) führen. Ein Waise ist ein aktiver
Server ohne wartenden Clients. Waisen bedeuten Verschwendung
von Ressourcen, sowie die unnötige Sperrung von Betriebsmitteln.
Außerdem können die Nachrichten von verwaisten
Servern weiderangelaufene Clients stören. Es gibt einige
Ansätze, um diese Probleme zu lösen.
6.1 Extermination
Der Client-Stub schreibt alle
Adressen der aktiven Server in einen stabilen Log. Nach Wiederanlauf
des Client sendet dieser "abort-server"-Nachrichten
an alle Server im Log.
Bei diesem Ansatz führt der Client die Waisenentdeckung
durch. Außerdem führt häufiges Schreiben auf
stabilem Speicher zu einem hohen Overhead. Allerdings kann
eine Netzpartitionierung den Server unerreichbar machen.
6.2 Expiration
Bei diesem Ansatz bekommt der
Server eine genaue Zeit zur Auftragsbearbeitung. Läuft
die Zeit ab, so muss der Server die Verlängerung explizit
beantragen. Wird die Verlängerung nicht gewährt
oder nicht beantwortet, so wir der Auftrag abgebrochen.
Hier übernimmt der Server die Waisenentdeckung. Eine
Netzwerkpartitionierung wird hier toleriert, d.h. falls der
Client und der Server sich nicht mehr erreichen können,
erfolgt trotzdem ein Abbruch der Auftrages auf dem Server.
Außerdem gibt es hier einen erhöhten Aufwand durch
die Anfrage-Nachrichten.
6.3 Drakonische Inkarnation
Die Zeit wird in Epochen eingeteilt
und sequentiell durchnumeriert. Das System hält die Nummer
der aktuellen Epoche auf stabilem Speicher fest. request-
und response-Nachrichten enthalten die Nummer der aktuellen
Epoche. Nach einem Crash des Client startet dieser nach dem
Wiederanlaufen eine neue Epoche mit new epoche und wird mittels
Broadcast new epoche an alle Server gesendet. Die empfangenden
Server werden abgebrochen. Falls ein Server ein request aus
einer neuen Epoche empfängt, so wird dieser ebenfalls
abgebrochen. Es gibt also zwei Möglichkeiten um eine
Server zum Abbruch zu bringen.
Wie merkt der angefahrene Client, dass er kurz zuvor zusammengebrochen
war? Nach dem Anfahren vergleicht der Client seine aktuelle
Epochennummer mit der Nummer auf dem stabilem Speicher.
Die Waisenentdeckung übernehmen Client und Server. Ein
großes Nachteil der drakonischen Inkarnation ist, dass
bei einem Wechsel der Epoche alle Server abgebrochen werden.
6.4 Behutsame Inkarnation
Der Unterschied zur drakonischen
Version ist hier, dass beim Beginn einer neuen Epoche der
Server überprüft, ob er tatsächlich Waise ist.
Das hat den Vorteil, dass nur Waise abgebrochen werden.
7. Quellen
[1] Skript Grundlagen Verteilte
Systeme; Prof. Dr. Kurt Rothermel - Abteilung Verteilte Systeme
an der Universität Stuttgart
|
