Kap. 5: Remote Procedure Call

Transkript

1 Verteilte Systeme 5-1 Kap. 5: Remote Procedure Call 5.1 Einführung und Motivation 5.2 Grundprinzip 5.3 Binding / Trading 5.4 Behandlung von Parametern 5.5 Semantik im Fehlerfall 5.6 RPC-Protokoll 5.7 Beispiele

2 Verteilte Systeme Einführung und Motivation Nachrichtenorientierte Kommunikation asynchroner Nachrichtenaustausch explizit mit send()/receive()-operationen Fazit +: sehr flexibel, alle Kommunikationsmuster implementierbar -: explizit, I/O-Paradigma Ziel des Remote Procedure Call (RPC) deutsch: Fernaufruf (wenig verbreitet) Transparenz der Kommunikation Erscheinungsbild wie üblicher lokaler Prozeduraufruf Unterstützung für Dienstorientierung: Dienst = Service = Menge von Funktionen RPC für Funktionsaufruf Objektorientierung: RPC genutzt für Methodenaufrufe

3 Verteilte Systeme 5-3 Historie 5.1 Erste umfassende Darstellung: Def: Dissertation Nelson (1981, XPARC) abgeleitetes Paper Birrel/Nelson (1984, ACM ToCS) "RPC (Fernaufruf) ist der synchrone Transfer von Kontrolle und Daten zwischen Teilen eines in verschiedenen Adressräumen ablaufenden Programms" Nelson's These: RPC ist ein leistungsfähiges Konzept zur Konstruktion verteilter Anwendungen RPC vereinfacht die Programmierung verteilter Systeme Heute: Nelson's Sicht allgemein akzeptiert RPC-Systeme in vielen Produkten

4 Verteilte Systeme Grundprinzip Client Host (Adressraum) Server Host (Adressraum) client procedure client stub server stub server procedure process work call work pack args send receive unpack results return receive unpack args call pack results send work return process transmit BS-Kern transmit pack / unpack = marshaling / unmarshaling Stellvertreterkomponenten: stub, proxy, skeleton BS-Kern

5 Verteilte Systeme 5-5 Programmentwicklung 5.2 Grobstruktur: Schnittstellenspezifikation Client- Entwicklung Server- Entwicklung

6 Verteilte Systeme 5-6 Programmentwicklung (2) 5.2 genauer, aber immer noch unabhängig von speziellem RPC-System: Interface Compiler Client Stub Header Files Server Stub Schnittstellenspezifikation RPC Client- Server- RPC Library Programm Programm Library vom Anwendungs- entwickler Compile &Link Client Applikation Compile &Link Server Applikation

7 Verteilte Systeme 5-7 Beispiel SunRPC 5.2 Schnittstellenspezifikation RPC language foo.x Interface Compiler rpcgen foo_clnt.c c Client Stub Header Files foo.h foo_xdr.c Server Stub foo_svc.c RPC Library Client- Programm Server- Programm RPC Library Compile &Link Compile &Link Client Applikation Server Applikation

8 Verteilte Systeme 5-8 Beispiel DCE RPC 5.2 uuidgen (erzeugt eindeutigen Schnittstellennamen) Schnittstellenspezifikation DCE IDL foo.idl Interface Compiler idl foo_cstub.o o Client Stub Header Files foo.h Server Stub foo_sstub.o RPC Library Client- Programm Server- Programm RPC Library Compile &Link Compile &Link Client Applikation Server Applikation

9 Verteilte Systeme Binding / Trading Binding / Trading: Problem: Binden eines Clients an einen Server notwendig Problem gilt analog auch für andere Paradigmen Aspekte: Naming & Locating Naming Wie benennt der Client, an was er gebunden werden will (Service) Interface-Name allgemein aus systemweitem Namensraum Trading als Verallgemeinerung: zusätzlich Interface-Attribute vgl. Kap. 6: Allg. Namensdienste Locating Bestimmen der (ortsabhängigen) Adresse eines Servers, der das gewünschte Interface exportiert und zur Diensterbringung benutzt wird typisch: (IP-Adresse des Hosts, Portnummer).

10 Locating-Alternativen 5.3 Adresse statisch im Anwendungsprogramm kein Suchvorgang erforderlich i.d.r. nicht flexibel genug zu frühes Binden Suchen nach Exporteuren zur Laufzeit, z.b. durch Broadcast hoher Laufzeitaufwand Broadcast über Netze hinweg gproblematisch i.d.r. zu spätes Binden Verwaltung von Zuordnunginformation durch zwischengeschaltete Instanz vermittelnde Instanz wird Binder, Trader oder Broker genannt Exporteur lässt angebotenes Interface (mit allen Attributen) registrieren i Bindeanforderung eines Importeurs bewirkt Zuordnung durch Binder/Trader R. Kröger, Hochschule RheinMain Verteilte Systeme 5-10

11 Verteilte Systeme 5-11 Prinzipielle Vorgehensweise Binder/ Trader 1 Exportieren des Interface Registrieren eines Interfaces bei Binder Client client stub 1 3 Server 2 Binder hat bekannte Adresse Importieren bei erster Inanspruchnahme des Dienstes aus stub heraus liefert handle mit Adresse 3 Fernaufruf client stub benutzt Adresse für Aufruf an Server

12 Verteilte Systeme 5-12 Binder / Trader 5.3 Typische Schnittstelle Register( Dienstname, Version, Adresse, evtl. Attribute ) Deregister( Dienstname, Version, Adresse ) Lookup( Name, Version, evtl. Attribute ) Adresse Vorteile: sehr flexibel kann mehrere gleichartige Server berücksichtigen Basis für Lastausgleich zwischen äquivalenten Servern Nachteile: zusätzlicher Aufwand beim Exportieren und Importieren eines Interfaces problematisch bei kurzlebigen Servern und Clients

13 Verteilte Systeme 5-13 Beispiel: SunRPC 5.3 Namen Paare (Programmnummer, Versionsnummer) Adressen Paare (IP-Adresse des Hosts, Portnummer) Binder: Portmapper Abbildung von Namen auf Portnummern IP-Adresse des Hosts muss bekannt sein, der dort lokale Portmapper wird befragt Portmapper ist selbst SunRPC-Dienst (Port 111)

14 Verteilte Systeme 5-14 Beispiel: DCE RPC 5.3 Namen UUID (Universal Unique Identifier) weltweit eindeutiger String enthält Netzwerk-Adressinformationen (z.b. Ethernet MAC-Adresse) und Zeitmarke generiert durch Tool uuidgen Adressen Paare (IP-Adresse des Hosts, Portnummer) Binding zweistufig innerhalb einer DCE-Zelle kein zusätzliches Wissen notwendig Binder heisst RPC Daemon

15 Verteilte Systeme 5-15 Beispiel: DCE RPC (2) 5.3 Client 1 "Interface xx?" 2 "Node A" CDS Cell Directory Service evtl. globale Suche 3 4 reply 6 5 Node A P rpcd RPC Daemen

16 Verteilte Systeme Behandlung der Parameterübergabe Heterogenitätsproblem verschiedene Codes (z.b. ASCII - EBCDIC) Little Endian - Big Endian unterschiedliche Zahlenformate Lösungsmöglichkeiten Abbildungen zwischen lokalen Datendarstellungen» Sender sendet in seiner lokalen l Darstellung, Empfänger transformiert t» erfordert n*n Abbildungen kanonische Netzdatendarstellung für alle Typen» erfordert 2n Abbildungen (bei n lokalen Darstellungen)» evtl. unnötige Codierung

17 Verteilte Systeme 5-17 Verbreitete Netzdatendarstellungen 5.4 XDR (External Data Representation) definiert durch Sun im Rahmen von SunRPC i.w. Motorola Datenformate: ASCII; Big-Endian, 2-Komplement; IEEE-Gleitpunktzahlen,... zusammengesetzte Typen: Arrays, Structures, Unions keine explizite Typisierung der Daten, d.h. keine sich selbst beschreibenden Daten für RPC-Systeme sind die Parameter-Typen aber beim Generieren des Stub Codes für beide Seiten bekannt Beispiel: struct { string author<>; int year; string publisher<>; } 5 Stee n Wesl ey jeweils 4 Bytes lang

18 Verteilte Systeme 5-18 Verbreitete Netzdatendarstellungen (2) 5.4 ASN.1 BER (ISO Abstract Syntax Notation Number 1, Basic Encoding Rules, ISO 8824, 8825, ITU X.409) explizite Typisierung der übertragenen Daten, d.h. allen Datenfeldern geht die Typinformation voraus. noch verbreitet: t CANopen, ISO MMS, UMTS! Standard-Repräsentierung: (Type, Länge, Inhalt) Nachteil: laufzeitaufwendig e (Bitzugriffe) Beispiel: count::=integer Type (Identifier) 0 2 Type (Identifier) 0 1 Länge 1 A Inhalt (26 10 ) jeweils 1 Byte (hex) Tag: Type: Class: 1 Boolean 2 Integer, Sequence 0 Primitive 1 Constructed 00 Universal 01 Application,...

19 Verteilte Systeme 5-19 Verbreitete Netzdatendarstellungen (3) 5.4 CDR (Common Data Representation) Definition in OMG CORBA 2.0 Nutzung im CORBA IIOP-Protokoll Versenden im eigenen Format, "Receiver makes it right" Simple types (short, long, float, char, ) Complex types (sequence, string, union, struct, ) Alignment/Padding entsprechend Mehrfachem h der Elementlänge Big-endian Beispiel: struct <string, unsigned long> 5 S T E E N Adresse Inhalt E D2 Länge Padding

20 Verteilte Systeme 5-20 Probleme 5.4 komplexe, zusammengesetzte Parametertypen z.b. structs, arrays, erfordern Regeln zur Serialisierung Adressen in Parametern keine Bedeutung im Zieladressraum! einfachste Lösung: Verbieten, nur call-by-value zulassen (i.w. SunRPC) Nutzung eines gemeinsamen globalen Adressraums, falls vorhanden Ersetzen von Zeigern durch Marker, Rekonstruktion zusammengesetzter t Datenstrukturen t auf Empfängerseite durch dort lokale Zeiger (z.b. DCE RPC)

21 Verteilte Systeme 5-21 Sicherheit 5.4 Probleme gegenseitige Authentisierung Autorisierung bzgl. ausführbarer Funktionen auf Server-Seite Verschlüsselung der übertragenen Daten ausführliche Betrachtung in separatem Kapitel

22 Verteilte Systeme Semantik des RPC im Fehlerfall Fehler-Problematik lokaler Funktionsaufruf: Rufer und Gerufener werden gleichzeitig abgebrochen RPC: Ausfall einzelner Komponenten in verteilter Umgebung möglich Zusätzlich Fehlerfälle des Nachrichtensystems berücksichtigen» Nachrichtenverlust» unbekannte Übertragungszeiten» Out-of-order-Ankunft von Nachrichten (Überholen)

23 Verteilte Systeme 5-23 Semantik des RPC im Fehlerfall (2) 5.5 at-least-once-semantik erfolgreiche Ausführung des RPC aufgerufene Prozedur mindestens einmal ausgeführt, d.h. Mehrfachaufruf kann passieren beliebiger Effekt bei nicht-erfolgreicher Ausführung möglich i.a. nur für idempotente Operationen geeignet, d.h. mehrfacher Aufruf ändert nicht Zustand und Ergebnis Realisierung einfachste Form kommt innerhalb eines Timeouts kein Ergebnis auf Client-Seite an, wird Aufruf vom Stub wiederholt keine Vorkehrungen auf Server-Seite

24 Verteilte Systeme 5-24 Semantik des RPC im Fehlerfall (3) 5.5 exactly-once-semantik erfolgreiche Ausführung des RPC aufgerufene Prozedur genau einmal ausgeführt beliebiger Effekt bei nicht-erfolgreicher Ausführung möglich gelegentlich als "at-most-once" bezeichnet entspricht im Normalfall lokalem Funktionsaufruf am weitesten verbreitet Realisierung komplexer kommt innerhalb eines Timeouts kein Ergebnis auf Client-Seite an, wird Aufruf vom Client-Stub wiederholt Server-Stub Stub ignoriert Anfrage-Duplikate, wenn Antwort noch nicht geschickt (Erkennung durch Sequenznummer) Server wiederholt bereits gesendete Antwort bei wiederholtem Aufruf f (maskiert verlorene Antwort) t)

25 Verteilte Systeme 5-25 Semantik des RPC im Fehlerfall (4) 5.5 at-most-once-semantik erfolgreiche Ausführung des RPC aufgerufene Prozedur genau einmal ausgeführt nicht-erfolgreiche Ausführung des RPC aufgerufene Prozedur erscheint als niemals ausgeführt auch als atomarer RPC bezeichnet höchster Komfort für Programmierer, da keine partiellen Fehlerauswirkungen zurückbleiben Realisierung sehr komplex erfordert Transaktionsmechanismus heute eher Einbettung von RPCs in allg. Transaktionskonzept (vgl. Transaktionsdienst)

26 Verteilte Systeme 5-26 Orphan-Problem 5.5 Orphan = Waise Problem: Client stirbt nach Absetzen des RPC erzeugter RPC kann weitere Aktivität nach sich ziehen, obwohl niemand darauf wartet nach Restart Eintreffen von Antworten aus früherem "Leben" Lösungsansätze gezielter Abbruch verwaister RPCs basierend auf stabilem Speicher (praktisch unbrauchbar) max. Lebensdauern von RPCs im Netz Warten nach Restart Einführung von Epochen Einfangen durch übergeordnete Recovery-Mechanismen (z.b. Transaktionsmechanismus)

27 Verteilte Systeme RPC-Protokolle RPC-Protokoll: Regeln zur Abwicklung von RPCs abhängig von unterlagertem Transportdienst Layer 4 Transport (z.b. TCP) unzuverlässiger Datagrammdienst (z.b. UDP) Duplikate (durch Timeouts), Vertauschungen und Verlust sind möglich in der Praxis meistens zuverlässiger Transportdienst unterlagert, aber leistungsmindernd Aufruf/Antwort-Protokolle Ziel: möglichst wenige ausgetauschte Nachrichten auf Datagrammdienst basierend eigene Mechanismen zur Erkennung und Behebung von Kommunikationsfehlern (Sequenznummern, wiederholtes Senden) Bester Fall: Je RPC genau zwei Nachrichten (Antwort quittiert Aufruf, nächster Aufruf quittiert letzte Antwort)

28 Verteilte Systeme Beispiel: Der SunRPC C-Spracheinbettung Unterlagerter Transportdienst TCP oder UDP RPC fügt keine die Zuverlässigkeit steigernde Maßnahmen hinzu UDP und timeouts auf Applikationsebene führen zu "at-least-once"-semantik TCP und message transaction ids auf Applikationsebene führen zu "exactly-once"-semantik Binding durch Portmapper Portmapper-Protokoll ist selbst RPC-basiert Parameter i.w. nur call-by-value l Sicherheit Authentifizierung: Null, UNIX, DES

29 Verteilte Systeme 5-29 Andere RPC-Protokolle 5.7 ISO OSI Remote Operations ROSE Remote Operations Service Elements heute ohne Bedeutung OSF DCE RPC Teil des OSF Distributed Computing Environments Microsoft RPC weitgehend kompatibel C/C++-Spracheinbettung "exactly-once" und "at-least-once"-semantiken wählbar, unabhängig von unterlagertem Transport-Dienst Unterstützung für Threads beliebige Parameter-Typen, "lange" Parameter über "Pipe" -Mechanismus Sicherheit basierend auf Kerberos-Framework Bedeutung stark gesunken.