Kommunikationsunterstützung:

Transkript

1 Kommunikationsunterstützung: Entfernter Prozeduraufruf (Remote Procedure Call, RPC) VSS1-RPC-1 Kooperation: Nachrichtenversand vs. Prozeduraufruf A) Nachrichtenaustausch: i.d.r. keine Verteilungstransparenz Nachrichtenaustausch über explizite 'Ports' Zugriff von (vielen!) Prozessen auf Ports Synchronisation durch expliziten Nachrichtenaustausch Nebenläufigkeit als dominantes Programmierparadigma B) Entfernter Prozeduraufruf: Einfache Analogie Inter- / Intraprozessmodell keine expliziten Kommunikationspfade Kooperation z.b. durch Sperren, Semaphore oder Monitore Verteilungstransparenz möglich Sequentialität als dominantes Programmierparadigma Lauer / Needham (1979): Dualität beider Modelle! VSS1-RPC-2

2 Entfernter Prozeduraufruf Remote Procedure Call (RPC) IDEE: Aufruf entfernter Prozeduren wie lokaler Prozeduraufruf ('Verteilungstransparenz') Alternative: 'Message Passing' - aber: andersartiges Kooperationsmodell! Abstraktion von: - Kommunikationsdetails, - Übertragungsfehlern,... Aber: z.b. - Fehlertransparenz ist nie vollständig möglich! - Einschränkungen bei den Parametertypen! Beispiele - Birrell & Nelson (1981), XEROX - Liskov et al. (1983): "Argus", MIT - SUN RPC (1985), Admiral RPC: UC London (1985, UNIX ) + ISO/OSI ROSE (89) / ECMA RPC / OSF DCE RPC /... VSS1-RPC-3 Remote Procedure Call (RPC) Rechner A -Prozess Prozeduraufruf suspendiert fährt fort Request Reply Rechner B -Prozess Ausführung der Prozedur Ergebnis-Rückgabe Prozeduraufruf im entfernten Rechner ähnlich wie im lokalen Fall Abstraktion von der Verteilung RPC realisiert die Kommunikationsgrundstruktur des /-Modells -> spiegelt Semantik der Aufrufe zwischen unterschiedlichen Modulen wider -> einfach zu verstehen und zu implementieren Fazit: RPC ist in verteilten Systemen oft ein geeignetes Mittel zur effizienten Implementierung von ('abstrakten') Datenobjekten! VSS1-RPC-4

3 Aspekte der Verteilungstransparenz beim RPC -> vollständige Transparenz bzgl. des lokalen Prozduraufrufs ist nicht möglich: Parameterübergabe Performanz Kommunikations- und Knotenfehler Ausnahmebehandlung -> vollständige Transparenz ist auch nicht immer unbedingt wünschenswert! Alternative RPC- Semantiken 1) keine Garantie bei Fehlerfällen (maybe-semantik) 2) höchstens einmal (at most once) - Vernichten von Duplikaten auf -Seite, sonst nur einmalige Nachrichtenübertragung 3) mindestens einmal (at least once) - nur für wiederholbare Funktionen - transparent für 4) atomare Ausführung der -Prozedur (exactly once) - -Prozedur wird ganz oder gar nicht ausgeführt VSS1-RPC-5 Unterschiede zum lokalen Prozeduraufruf Allgemeine Charakteristik des RPC: - Parameterübergabe durch 'Call by Value' - Keine globalen Variablen - Typenprüfung - Alternativen der Fehlersemantik - Autorisierung - Lokale Leistungsoptimierung Unterschiede zum lokalen Prozeduraufruf: disjunkte Ausführungsumgebungen Performanz Kommunikations- und Knotenfehler Ausnahmebehandlung Authentisierung oftmals notwendig HETEROGENITÄT: TRANSPARENZ: -> verschiedene Prozesse -> kein Zugriff auf gemeinsame Variable -> nur Call-by-value HW/SW, Offene Systemschnittstellen, Datentypen, (Un-) Marshalling, "Stubs" Fehlersemantik (o, 1, n mal), Parameterübergabe, Exceptions BINDUNG: /, Schnittstellen, Syntax- und Semantikdefinition, "Trading",... PARALLELITÄT: Zu löe Probleme: (Nicht) blockierender RPC, Multi-Prozesssysteme, Threads VSS1-RPC-6

4 Transaktionsgeschützter RPC Call Response Transaktionssicherung implementiert "Dienst" als abstraktes "Objekt" ; Implementationsdetails unsichtbar. exportiert Operationen und Regeln für deren Benutzung über Kommunikationsschnittstelle. Zugang zum über Menge von vorgegebenen Nachrichten. Schnittstellen und Protokolle sind standardisiert für Kommunikation in heterogenen Systemen. Transaktionen garantieren "genau/ höchstens/ mindestens einmal"-semantik des RPC. RPC-Erweiterungen: Call-back: aufgerufener Prozess meldet sich selbst wieder Broadcast: -> bei -Klassen: Aufruf aller (Muticast: vieler) anderer Prozesse VSS1-RPC-7 Beispiel: zustandsbehafteter Beispiel: Einfacher Datei- mit Zustandsinformationen -Prozess -Prozess Open (filename, mode) File descriptor Read (file desc., bytes) Bytes read, data read -Zustand: Dateiname, Beschreibg., Mode, Aktuelle Position in der Datei - muss -Fehler feststellen - muss nach Fehlern synchronisieren - hält ev. ungültige Zustandsinformation + Effiziente Implementierungen möglich + Einfaches Programmierparadigma VSS1-RPC-8

5 Beispiel: zustandslose Beispiel: Einfacher Datei- ohne Zustandsinformationen -Prozess Read (filename, file position, num bytes) -Prozess -Zustand: Dateiname, Beschreibg., Mode, Aktuelle Position in der Datei Num. bytes read, new file position, data read + Einfaches Protokoll in Fehlerfällen + braucht - oder Netzfehler nicht speziell zu berücksichtigen + Kein Recovery nach Fehlern nötig - einfaches Wiederholen des RPC genügt VSS1-RPC-9 UNIX-Beispiel: C/S-Bindung mittels 'Portmapper' - Programm C Portmapper S - Programm -Knoten -Knoten 1. meldet sich beim Portmapper an 2. fragt Dienst beim Portmapper nach 3. bekommt -Port vom Portmapper 4. ruft Dienst (direkt) auf VSS1-RPC-10

6 Zeitlicher Ablauf beim (a)synchronen Aufruf des RPC synchron asynchron process args. process res. process res. execute req. execute req. process args. process args. process res. process res. execute req. execute req. time VSS1-RPC-11 Ablauf eines RPC-Aufrufes stub Nachrichten-Modul NachrichtenModul stub Verpacken der Argumente Senden der Anfrage > Empfangen Auspacken der Argumente lokaler Prozeduraufruf Prozeduraufruf Ausführung der Prozedur lokale Antwort Auspacken des Ergebnis Empfangen < Senden des Ergebnis Verpacken des Ergebnis Rückgabe der Antwort -Stub - generiert die Nachricht - führt das Glätten (ing) der Nachricht - z.b. mit Hilfe der XDR-Routinen durch Stub - kreiert Port - registriert sich beim Portmapper - Entpacken der Nachricht (ing) - Dispatching (Aufruf der entsprechenden -Prozedur) VSS1-RPC-12

7 "Marshalling" der Nachrichten - Nachrichten werden gepackt und vom Empfänger wieder entpackt - Mechanismus muss und bekannt sein Nachrichtenformat Nachrichtentyp Request-ID Nachrichten-ID -Port Prozedur-Nr. Argumente (request/reply) für für zum Herausfiltern von Duplikaten zur Zuordnung der Antwort zur Anfrage Netzwerkfehlerbehandlung Datagramm-Dienst Fehlerart verlorene Nachrichten Internetworking: duplizierte Nachrichten vertauschte Reihenfolge veränderte Nachrichten Heterogenitäts- und Verteilungstransparenz Definition gemeinsamen Schnittstellen (HW- und SW-Heterogenität) Typumwandlung in eine Transfersyntax -> Externe Datenrepräsentationssprache Unterstützung durch RPC-SW: -> Automatische Generierung der (Un-) Marshalling-Routinen -> Automatische Stub-Generierung -> erkannt/behoben durch: -> Timeout-Mechanismus -> Herausfiltern anhand der Nachrichten-ID -> Überprüfung, ob erwartete Nachrichten- ID mit ankommender übereinstimmt -> Check-Summe VSS1-RPC-13 - Anwendungsprogramm Benutzerpaket RPC-SW ( Stub) Kommunikationsunterstützung Benutzerpakete Schnittstelle des Benutzerpaketes RPC-Schnittstelle - Benutzerpakete verbergen viele Probleme der Verteilung vor dem - Bsp.: Orts- und Plazierungsprobleme von Dateien VSS1-RPC-14

8 Bestandteile RPC-Schnittstellendefinition - Definition der Typen der Argumente - Spezifikation der Prozedurköpfe - Zuweisung von Id.nummern zu den Prozeduren - Definition des Programms und der Version Schnittstellensprache - wird benötigt, wenn die Sprache kein Definitionsmodul besitzt oder wenn und in unterschiedlichen Sprachen geschrieben sind - bietet skalare und strukturierte Datentypen - kann oft von verschiedenen Sprachen aus benutzt werden - Bsp. RPC-Language (umfasst auch XDR-Funktionen in UNIX) Datenabstraktion Marshalling/Uning-Routinen Interface Definition Language - entspricht von der Idee her der Definitionsdatei in Modula-2 - exportiert die Schnittstelle, importiert die Schnittstelle - und müssen dieselbe Version der Schnittstelle benutzen - Generierung einer Marshalling/Uning-Prozedur für jeden im Schnittstellenmodul definierten Datentyp Prozedurnummern - und kommunizieren nur über die Prozedurnummern - Dispatching erfolgt über die Prozedurnummern VSS1-RPC-15 IDL-Beispiel: 'Files Interface' in Sun XDR /* File ReadWrite service interface definition in file File ReadWrite.x */ const MAX = 1000; typedef int FileIdentifier; typedef int FilePointer; typedef int Length; struct Data { int length char buffer [MAX]; struct writeargs { FileIdentifier f; FilePointer position; Data data; struct readargs { FileIdentifier f; FilePointer position; Length length; program FILEREADWRITE { version VERSION { void WRITE (writeargs) = 1; data READ (readargs) = 2; } = 2; } = 9999; VSS1-RPC-16

9 IDL-Beispiel: 'Files Interface' in ANSA IDL FileReadWrite : INTERFACE = BEGIN FileIdentifier, FilePointer, Length : TYPE = CARDINAL; Data : TYPE = SEQUENCE OF CHAR; Write : ANNOUNCEMENT OPERATION [ f: FileIdentifier; position: FilePointer; data: Data; ] RETURNS [ ]; Read OPERATION [ f: FileIdentifier; position: FilePointer; length: Length; ] RETURNS [ Data ]; END. VSS1-RPC-17 IDL-Beispiel: 'RoomBooking' in CORBA IDL aus: A. Vogel, K. Duddy: "Java Programming with CORBA", John Wiley & Sons, 1997 module RoomBooking { interface Meeting { // A meeting has two read-only attributes which describe the // purpose and the participants of that meeting. readonly attribute string purpose; readonly attribute string participants; interface MeetingFactory { // A meeting factory creates meeting objects. Meeting CreateMeeting ( in string purpose, in string participants); VSS1-RPC-18

10 IDL-Beispiel: 'RoomBooking' in CORBA IDL (cont.) interface Room { // A Room can be booked for several (here: 8) time slots. enum Slot {am9, am10, am11, pm12, pm1, pm2, pm3, pm4 // Since cardinality of slots cannot be determined in IDL MaxSlots defines it: const short MaxSlots = 8; // "Meetings" associates meetings with time slots typedef Meeting Meetings [MaxSlots]; exception NoMeetingsInThisSlot { exception SlotAlreadyTaken { // The attribute "name" names a room: readonly attribute string name; // "View" returs the bookings for a room, "Book" and "Cancel" book resp. cancel // reservation for a room (here: only for a day): Meetings View (); void Book ( in Slot a_slot, in Meeting a_meeting ) raises (SlotAlreadyTaken); void Cancel ( in Slot a_slot ) raises (NoMeetingsInThisSlot) VSS1-RPC-19 Automatische SW-Generierung beim UNIX-RPC lokales - Anwendungsprogramm Schnittstellendefinition IDL - Compiler "rpcgen" lokale - Prozeduren Stub_0 XDR Routinen Header Datei Stub_0 C-Compiler C-Compiler C-Compiler C-Compiler Stub Stub Anwendungsobjekt Prozedurenobjekt Linker Linker - Programm - Programm VSS1-RPC-20

11 Ap plicati on Entit y ROSE Ap plication Entit y ROSE RPC-Standardisierung - Beispiel: ISO/OSI Remote Operations Service Element (ROSE) RPC-Request RPC-Response ISO / OSI - Ebenen 1 bis 6 Operation Response: or1: 'always result or failure returned', or2: 'only failure returned', or3: 'only result returned' oder or4: 'nothing returned'. Operation Call: oc1: 'synchronous' oder oc2: 'asynchronous'. Operation Classes: Operation Class 1 : or1 + oc1 Operation Class 2 : or1 + oc2 Operation Class 3 : or2 + oc2 Operation Class 4 : or3 + oc2 Operation Class 5 : or4 + oc2. <--- RDA VSS1-RPC-21 Effiziente Realisierung: 'Multi-threaded' Transaktionssicherung Call Response _i _i Ein kann an mehreren Transaktionen gleichzeitig beteiligt sein Ein bearbeitet zu jedem Zeitpunkt genau eine Transaktion - kann aber auf eine andere umschalten bevor die erste beendet wird (durch 'commit' oder 'rollback') VSS1-RPC-22

12 Effiziente Realisierung von (RPC-) n Alternativen: 1) Erzeugen eines neuen -Prozesses für jede neue -Anfrage -> mehrere Instanzen desselben Prozesses bestehen gleichzeitig -> Synchronisation beim Zugriff auf gemeinsame Variable notwendig 2) Ein -Prozess läuft kontinuierlich und wartet auf -Anfragen -> Erhöhung des Parallelitätsgrades durch Threads Beispiel für RPC-Implementierung mittels Threads (s.u.): Ablauf des Arbeiter 5: - wird aktiviert - Herausholen des Auftrags - Prozedurausführung - Veren der Antwort - wait ( Arbeiter 5 ) Verteiler: Synchronisation: - Thread, der auf Anfragen wartet - Schreibt ankommende Aufträge in den gemeinsamen Speicher - aktiviert den nächsten Arbeiter-Thread -> durch Monitor VSS1-RPC-23 Beispiel für RPC-Implementierung mit Hilfe von Threads Rechner A Rechner B Nachrichten- Puffer 2 Arbeiter 1: Prozeduraufruf wait(arbeiter1) 10 1 Arbeiter Arbeiter Arbeiter 3 Nachrichten- Puffer Condition Variable Arbeiter1 8 Verteiler 9 signal(arbeiter1) Arbeiter Arbeiter 6 Verteiler Arbeiter Arbeiter 5 signal(arbeiter5) wait( Arbeiter5 ) Condition Variable Arbeiter5 VSS1-RPC-24

13 RPC-Implementierung: -Klassen d.h.: auf verschiedenen Rechnern läuft mind. ein -Prozess desselben Dienstes Probleme: Rechner A - Prozess 1 Rechner B - Prozess 3 Rechner C - Prozess 4 - Prozess 2 Wann werden -Klassen vergrößert / verkleinert? durch Systemverwalter vorgegebene Scheduling-Strategie --> Dynamische Erweiterung / Verkleinerung der Klasse Wieviel Zustandsinformation muss ein verwalten? ist kontextfrei vs. Zustand wird in Datenbank verwaltet (für Fehlertoleranz) -> Verwaltung von Zustandsinformationen in den n Wann / Wie wird Last-Balancierung durchgeführt? Gemeinsame Warteschlange / Scheduler ordnet jeden einem zu. -> Lastverteilung (Load Balancing) (z.b. durch ausgezeichneten Verteiler-) VSS1-RPC-25