5. Verteilte Dienste

Transkript

1 5.1.1 Plurix Namensdienst 5. Verteilte Dienste 5.1 Namen & Adressen Baum im verteilten virtuellen Speicher: - Enthält irgendwelche Instanzen und Erweiterungen von NamedObject, - Verzeichnisse, Packages, Klassen, Instanzen, Texte, Bilder... root public admin users java plurix kernel device Tlak Wende Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-1

2 Implementierung: - Klassenhierarchie des Namensdienstes, - Vorerst als Binärbaum implementiert... Nutzanwendungen: - Root ist der Ansatzpunkt für die Freispeichersammlung, - Befehlsklassen in Verzeichnissen public und users, - Synergien mit den Symboltabellen im Compiler, - Maschinenkonfiguration im Namensdienst, - Textueller Aufruf von Befehlen, - Allgemeine Textelemente, - Verzeichnis als Text? - Hypertexte? Suche nach einem bestimmten Typ: - Verzeichnis, - Java Instanz, - Java Klasse... Die Verteilung geschieht automatisch. UserObj Scope NamedObj Node NameSvc find getpath getroot register unregister Search Compiler Objects Compiler Scopes Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-2

3 5.1.2 Namen, Pfade & Adressen Nur ausnahmsweise flache Namensräume: - Schwierig den Namensraum anders zu organisieren, - Skaliert nicht gut für größere Namensräume, - Ungünstig zum Navigieren. Üblicherweise hierarchische Namenssyntax: - Mit Separierungszeichen zwischen den einzelnen Namensteilen, - Präfix dient evtl. als Working Directory, - Kanonische Namen & Aliases, - Ähnl. wie Dateisysteme... URL-Notation für Internet "Universal Resource Locator", z.b.: mailto://schulthess@informatik.uni-ulm.de, ftp://plurix@fix.uni-ulm.de, :80. Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-3

4 5.1.3 Domain Name Service Hierarchischer Namensdienst mit Domains, Subdomains & Resources: - Z.B. Ergänzung zu etc/hosts und etc/resolve.conf unter UNIX: - Lokale Datei mit Übersetzungstabelle von URL auf IP-Adresse, - Lokale Datei mit Adressen von Namensdienst-Servern. Konvertierungsroutinen in Unix: - gethostbyname( url ) gibt eine IP-Adresse zurück, - gethostbyaddr( ip# ) gibt DNS-Namen zurück. Resolverfunktion in der lokalen Maschine: - Erst lokalen Cache konsultieren, - Dann evtl. externen Server. Cache User Program Resolver "Über"- Server "Über"- Server Externer Server Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-4

5 IP-Kenngrößen: - Kommunikation über TCP oder UDP, - Well Known Port für DNS ist 53, Anfrageszenarien zu den Servern: - Iterativ vom Klienten aus, - Iterativ vom Server aus, - Rekursiv vom Server. Client Client Server Server Server Server Server Server Server Client Server Server Server Server Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-5

6 DNS-Meldungsformat (RFC1035): 16 Bits Request ID Flags # Anfragen # Antworten # Authorit. # Zusatzl. N - mal DNS-Name, 0C Header Anfragen Antworten Authoritäten Zusätzliches N - mal DNS-Name, 0C DNS-Name, 0C DNS-Name, 0C Fragentyp Fragentyp Netzkürzel Fragentyp Netzkürzel Netzkürzel Netzkürzel Netzkürzel Time-to-live Netzkürzel Time-to-live Antwortlänge Time-to-live Antwort-L. Antwortbytes Antwort-L. Antwortbytes Antwortbytes Fragentyp Netzkürzel Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-6

7 Flags (16 Bits): - QR[1]: Query, not Reply? - Opcode[4]: Querytyp: - Reguläre Anfrage, - Inverse Anfrgae (IP zu DNS) - Statusanfrage an einen Server - AA[1]: Antwort vom verantwortlichen Server (authoritative) - TC[1]: Truncated message (auf 512 Bytes) - RD[1]: Recursion denied - RA[1]: Recursion available - ZR[3]: Reserved, are zero - RC[4]: Return code (=> RFC1035) QR QTYP[4] AA TC RD RA ZR[3] RC[4] Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-7

8 Verschiedene Typen von Resource-Records: - A: Adressauflösung eines DNS-Namens nach IPv4 - AAAA: Adressauflösung eines DNS-Namens nach Ipv6 - CNAME: Kanonischer DNS-Name anstatt Alias - WKS: Well Known Service auf IP-Nummer - TXT: Kontextabhängige Beschreibung - SOA: Start of Authority (IP-Bereich) - HINFO: Hostbeschreibung (CPU, OS) - NS: "authoritativer" Name Server - MX: Postamt für DNS-Namen WKS: - auf welchem Port wird der Dienst mit der gegebenen Protokollnummer angeboten? Reverse" Auflösung: IN-ADDR.ARPA ergibt severin.uni-ulm.de, - gewissermassen ein Pseudodomain in-addr.arpa. Protocol#[8] IP#[32 Bit] Port-Bitmap[n*8 Bit] Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-8

9 5.1.4 Andere Namensdienste X.500: Standardisierte Suche attributierter Objekte - LDAP: Light-weight Directory Access Protocol - Global Name Service: Rekonfigurierbarkeit im Rahmen von DCE - Globe: Weltweiter Namensdienst - Service Discovery Utility im Rahmen der Jini-Architektur - Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-9

10 5.2.1 Allgemeines: 5.2 Java Sockets (java.net) Socketobjekte enthalten Zustandsvariablen: - Eigene & entfernte Portnummer, - Entfernte Internetadresse (IP), - Puffer-Reservierung, - Sequenznummern, - Protokolltyp... Sockets sind Kommunikationsendpunkte: - Für Java nur Internet-Protokollarchitektur, - Allgemein für irgendeinen Protokollstack, Arten von Java Sockets: - ServerSocket() zur Entgegennahme von Verbindungsanforderungen am Server, - Socket() zur verbindungsorientierten Kommunikation vom Klienten her, - DatagramSocket() zur verbindungslosen Kommunikation. Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-10

11 5.2.2 Kommunikation über TCP-Sockets in Java: Beim Erzeugen der Socket-Instanz beim Klienten wird gleichzeitig die Verbindung aufgebaut. ServerSocket(): - Impliziert keinen Verbindungsaufbau, - Ist aber an einen Port gebunden, - optionale Warteschlangenlänge, - Accept() erwartet Verbindung. Lesen und Schreiben: - Garantierte End-zu-End Übertragung, - als unstrukturierter Bytestrom, - Full-Duplex... Viele Verbindungen an einen Port, aber nur eine pro IP-Adresse. Close() gibt Puffer & Ports frei. Klient Socket() write() read() close() Verbindung aufbauen Anfrage Antwort Server- Socket() accept() read() write() close() Server Warten auf Verbindung Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-11

12 5.2.3 Programmbeispiel für ServerSocket mit TCP import java.io.*; import java.net.*; public class EchoServer { public static void main(string[] s){ ServerSocket sock; Socket conn; DataInputStream in; String inputmsg; PrintStream out; try{ sock = new ServerSocket( 4711 ); conn = sock.accept(); in = new DataInputStream( conn.getinputstream( ) ); out = new PrintStream( conn.getoutputstream( ) ); out.println( "Echo Server active, enter bye to exit.\r"); do{ inputmsg = in.readline(); out.println("echo: "+ inputmsg +"\r"); if ( msg==null ) break; if ( msg.trim( ).equals( "bye") ) break; ; } while( true ); conn.close( ); } catch ( IOException iox ){ System.out.println( iox ); } } } Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-12

13 oder neuerdings: import java.io.*; import java.net.*; public class EchoServer { public static void main( String[] s ){ try { doecho(); } catch( IOException iox ) {System.out.println( iox );} } static void doecho() throws IOException { String inputmsg; ServerSocket sock = new ServerSocket( 23 ); // Portnummer für Server-Socket Socket conn = sock.accept(); // hier auf Verbindung warten PrintStream out = new PrintStream( conn.getoutputstream( ) ); InputStreamReader in = new InputStreamReader(conn.getInputStream() ); BufferedReader rdr = new BufferedReader( in ); // einen Stream in jede Richtung out.println( "Echo Server active, enter bye to exit.\r"); do { inputmsg = rdr.readline(); // Echo Schleife out.println("echo from server: "+ inputmsg +"\r"); if ( inputmsg.trim( ).equals( "bye") ) break; if ( inputmsg == null ) break; } while( true ); conn.close( ); } } Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-13

14 5.2.4 Kommunikation über UDP Datagram-Sockets: Weniger Protokolloverhead als TCP. Verbindungsaufbau entfällt. Lesen und Schreiben: - als einzelne Pakete/Datagramme, - Keine Ablieferungsgarantie, - Full-Duplex... Pufferung im Betriebssystem: - Nachträgliches receive() möglich, - Oder vorsorgliches receive() Close() gibt Puffer & Ports frei. IP-Paketfragmente unsichtbar. Peer Datagram Socket() send() receive() Warten auf Paket close() Nachricht Nachricht Peer Datagram Socket() receive() send() close() Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-14

15 5.2.5 Programmbeispiel mit Datagram-Sockets: import java.net.*; public class UDPClient{ static String url = "voyager.informatik.uni-ulm.de"; static int port = 13; // time demon public static void main (String[] args){ byte[] b = new byte[128]; byte[] msg = "Quick brown fox".getbytes(); try{ DatagramSocket socket = new DatagramSocket( ); DatagramPacket packet = new DatagramPacket( msg, msg.length, InetAddress.getByName( url ), port); socket.send( packet); // String "Quick brown fox" ist gesendet packet.setdata( b); // Puffer das Antwortpaket vorbereiten packet.setlength( 128); // mühselige Stringverarbeitung socket.receive( packet); // Auf Antwort warten, evtl. blockieren String antwort = new String( packet.getdata( ), 0, packet.getlength( )); System.out.println( "Antwort empfangen: " + antwort) ; socket.close(); } catch (Exception e) { e.printstacktrace( ); } } } Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-15

16 5.3.1 Beteiligte Instanzen Klientenklasse als Aufrufer: - Naming.Lookup(), - MyCall.Invoke(). Interface Spezifikation für: - Server Stub im Klienten, - Server-Skeleton*, - Serverklasse. RMI Namensdienst: - Naming.bind(..) durch Server, - Klient fragt nach Server. Codebasis für Klienten: - Liefert den Server-Stub, - Evtl. dynamisch laden. 5.3 RMI - Remote Method Invocation Klient Interface Server-Stub RMI-Registry Skelett * Codebase Server * Skelett entfällt ab jdk 1.2 Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-16

17 5.3.2 Compilationsprozess Interface Spezifikation für Klienten & Server. Übersetzungsreihenfolge: - Interface "Klasse" zuerst, - dann Server & Klienten, "rmic" für RMI-Compiler. RMI-Compiler erzeugt: - Stub für Klienten, - Skeleton für Server, - "-v1.2" kein Skelett. Klient.java Javac Klient.class Interface.java Javac Interface.class Server.java Javac Server.class rmic Server_Stub.class Java Server_Skel.class (nur jdk <1.2) Java Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-17

18 5.3.3 Ausführung Namensdienst starten - start rmiregistry.exe : - hört normalerweise auf Port Server starten (evtl. weiterer Maschine). - Properties "policy" & codebase setzen, sonst keine Verbindungen, - java -Djava.security.policy= - Djava.rmi.server.codebase= Server - Instanz der Serverklasse wird erzeugt, - Security-Manager im Server installieren, - Serverinstanz registriert sich namentlich, c:\rmi.policy - Anschließend wird auf Klientenaufrufe gewartet. grant { permission java.net.socketpermission " : ", "connect,accept"; permission java.net.socketpermission "*:80", "connect"; }; Klienten starten (evtl. dritte Maschine). - Stub für das Remote Interface wird erzeugt, - Interface-Methoden werden lokal im Stub gerufen, - Stub serialisiert die lokalen Aufrufe fürs Netz. (nur falls Stubklassen dynamisch über das Netz geladen werden sollen) Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-18

19 5.3.4 Parameter der Methoden Keine Änderung der Byte-Ordnung, da RMI nur zwischen JavaVM. Lokale serialisierbare Objekte werden "flachgeklopft" und übertragen. Parameter und Return-Werte müssen das Interface "serializable" implementieren, damit sie transportiert werden können. Remote Objekte werden als Interface von Remote-Referenz übertragen: - Im Server werden dann Stub-Referenzen in echte Referenzen übersetzt. - Klienten besitzen nur Referenzen auf Stubs und auf Server, - zu jedem benützten Remote Object gibt es einen Stub, Serialisieren, Kopieren und Übertragen umfangreicher Datenstrukturen kann teuer werden: Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-19

20 5.3.5 Beispiel für RMI-Programm Maschine #0: Microsoft(R) Windows NT(TM) (C) Copyright Microsoft Corp. D:\>path PATH=D:\WINNT\...;d:\jdk\bin\;d:\jdk\ D:\>cd jdk D:\jdk>javac Intface.java D:\jdk>javac Server.java D:\jdk>javac Client.java D:\jdk>rmic Server D:\jdk>rmiregistry no security properties. using defaults. DOS-Box für Compilierung und Registry: Server-Fenster (DOS-Box, evtl. Maschine 1): D:\jdk> java djava.sec...policy=... -Djava.rmi.server.codebase=file:/d:\jdk/ Server Server starting Server bound in registry request served at: Thu Nov 25 21:38: Klienten-Fenster (DOS-Box, Maschine 2): D:\jdk>java Client Client starting Received: Thu Nov 25 21:38:54 CEST 2004 Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-20

21 5.3.6 Quelltext für RMI-Klienten & -Server: Interface-Spezifikation: import java.rmi.*; public interface Intface extends Remote { public String TellTime() throws RemoteException; } Klienten-Klasse: import Intface; import java.rmi.*; import java.util.*; public class Client { public static void main(string[] s) { String servertime; String url = new String( "// /TimeServer"); System.out.println( "Client starting" ); try { Intface iface = (Intface ) Naming.lookup( url ); servertime = iface.telltime() ; System.out.println( "Received: "+servertime ); } catch (Exception e) { System.out.println( "Client exception: " + e.getmessage() ); } } } Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-21

22 Server-Klasse: import Intface; import java.rmi.*; import java.rmi. server.*; public class Server extends UnicastRemoteObject implements Intface { String name; public Server (String s) throws RemoteException { super(); this.name = s; } public String TellTime( ) throws RemoteException { String now =( new Date() ).tostring(); System.out.println( "request served at: "+now ); return now ; } public static void main(string args[]) { System.setSecurityManager( new RMISecurityManager() ); System.out.println( "Server starting"); try { Server srvr = new Server( "TimeServer 1" ); Naming.rebind("// /TimeServer", srvr ); System.out.println( "Server bound in registry"); } catch (Exception re) { System.out.println("TimeServer err: " + re.getmessage() ); } } } Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-22

23 5.3.7 RMI-Kommunikationsströme Übertragung von Parametern und Funktionsresultat: - stützt sich auf die Streams-Klassen, - in serialisierter Form Separater ObjectStream für jede Richtung. Klient ruft Methode im Stub. Die Methode erstellt ein Call-Objekt mit: - Referenz auf den Server, - Signatur der Methode, - Schlüsselwert/Hash... Dispatcher ruft die Methode im Server. Klient Server-Stub method1 write read Server method1 Skelett * Dispatch read write Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-23

24 5.3.8 Serialisierung von Parametern Serialisierung / Deserialisierung: - in einem Bytestrom (Netz oder Disk), - sinnvoll für RMI Parameterübergabe, - allgemein zum Abspeichern von Objekten, - vgl. Oberon-TextElemente in Dateien. Interface Serializable markiert Klassen, welche in ein "streamfähiges" Format überführt werden können: - Integer, Boolean, Real, Strings... - Ein- und mehrdimensionale Arrays, - Weitere explizit serialisierbare Objekte. Für nicht serialisierbare Objekte sind eventuell explizite Methoden zu schreiben, die unserialisierbare Felder besonders berücksichtigen: import java.io.*; private void writeobject(objectoutputstream stream) throws IOException private Object readobject(objectinputstream s) throws IOException, ClassNotFoundExcep.. Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-24

25 5.3.9 Remote Objects in Java Java Remote Objects: o implementieren das Interface java.rmi.remote, o erweitern..unicastremoteobject oder...activatable, o über RMI ansprechbare Methoden vereinbaren..remoteexception in throws... o die Methoden akzeptieren nur serialisierbare Parameter. HashCode() für jedes Remote Object: o Adressierung über das Netz (Analyse ohne Gewähr), o Gewährleistung der Typensicherheit, o Einfache Übergabe als Parameter, o Vergleich auf equals(). RemoteStub: ext RemoteObject: - ref - hashcode() - equals() RemoteRef: - invoke( ) UnicastRemoteObject: ext RemoteServer:..ext RemoteObject: - - hashcode() Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-25

26 Beispiel PrintObj - zum Serialisieren in den Printstream Das zu serialisierende Objekt sei ein Objekt der Klasse CnvrtMe: import java.io.*; public class CnvrtMe //implements Serializable { int num4711 = 4711; String gr = "Hallo!"; } "writeobject" schreibt Klassenobjekt in einen ObjectOutputStream: import java.io.*; public class PrintObj { static public void main( String[ ] args ) { CnvrtMe cvobj=new CnvrtMe(); ObjectOutputStream oos; try{ oos= new ObjectOutputStream( System.out ); oos.writeobject( cvobj ); } catch (Exception e) { }; } Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-26

27 ¼Ý sr CnvrtMeB +liqy I num4711l grt Ljava/lang/String;xp gt Hallo! Erzeugter Output Text entspricht dem serialisierten Objekt cvobj: - Eigentlich als binäres Format geschrieben, - Teilweise als ASCII-Zeichen erkennbar, - Klassenname CnvrtMe, - Integer num4711, - Aktueller Wert, - Referenztyp, - Zeichenkette. Lesen eines Objektes von einem ObjectInputStream: ObjectInputStream ois = new ObjectInputStream (ystream); Object obj = ois.readobject(); Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-27

28 5.4 Windows Sockets Winsock-Versionen 1.1 und 2.0: - Unter anderem QoS und Multicast in Winsock2.0, - Etwas umständlicher als in Java: - Winsock-DLL initialisieren, - Byte-Reihenfolge berücksichtigen, - Adressinformation explizit zuweisen, Beispielprogramm für einen TCP-Klienten (Teil 1): #include <stdio.h> // formatted stream io etc. #include <windows.h> // special data types #include <winsock.h> // socket DLL for windows int main( int argc, char **argv ) { // target as cmnd-line argument WSADATA wsa; // version of winsock SOCKADDR_IN desta; // destination addr., internet type PHOSTENT phe; // host by name SOCKET sock; // socket structure char buffer[256]; // packet buffer, 256 Bytes int rslt; // result of api-call Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-28

29 Beispielprogramm für einen TCP-Klienten (Teil 2): rslt = WSAStartup(MAKEWORD(1, 1), &wsa); // initialize the Windows Socket DLL phe = gethostbyname(argv[1]); // get Destin. IP-address via host name memcpy( (char FAR *) & (desta.sin_addr), phe->h_addr,phe->h_length); // copy bytes desta.sin_port = htons(10001); // Host to network order SHORT desta.sin_family = AF_INET; // Internet address family sock = socket( AF_INET, SOCK_STREAM, 0); // create a TCP socket rslt = connect( sock, (LPSOCKADDR) & desta, sizeof(desta) ); // connect to server sprintf(buffer, "Hello Server"); // build packet for the server rslt = send(sockt, buffer, strlen(buffer), 0); //bytecnt, send message, no flags closesocket(sock); // no more messages WSACleanup(); // no more sockets return 0; // error codes ignored, beware! } Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-29

30 Ausschnitt aus einem TCP-Server: - Für ServerSockets expliziter bind() erforderlich. - bind() bestimmt den Port, an welchem der Socket hören soll, - listen() schaltet den ServerSocket ein, - accept() liefert einen Socket für jede ankommende Verbindung. serversockaddr.sin_addr.s_addr = htonl( INADDR_ANY); // host to network long serversockaddr.sin_family = AF_INET; // Internet address family serversockaddr.sin_port = htons(10002); // host to network short status = bind( serversocket // bind() associates the socket with the port, (LPSOCKADDR) &serversockaddr, sizeof(serversockaddr) ); status=listen( serversocket, 1); // allow the socket to take connections clientsocket = accept( serversocket, // accept connect request, block until one is received, (LPSOCKADDR) &clientsockaddr, &addrlen ); numrcv = recv( clientsocket // receive data, buffer, MAXBUFLEN-1, NO_FLAGS_SET); Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-30

31 5.4.1 API für WinSock-Socketfunktionen Namensdienstfunktionen: gethostbyaddr gethostbyname gethostname getprotobyname getprotobynumber getservbyname getservbyport Liefert den Rechnernamen zur IP-Adresse Liefert Rechner-Adresse über den Rechnernamen Liefert Name des lokalen Rechners Protokoll über den bekannten Protokollnamen Protokoll über die Protokollnummer Serverport zu einem Dienstnamen Dienst-Information über die Portnummer Basisfunktionen für Winsock (TCP & UDP): accept bind closesocket connect Akzeptiert eine Verbindung mit einem wartenden Socket und gibt neu erzeugten, verbundenen Socket zurück. Bindet lokale Adresse und Port an einen Socket. Schließt einen Socket und gibt einen Deskriptor frei. Richtet eine Verbindung zu einem Remote-Rechner ein. Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-31

32 getpeername getsockname getsockopt ioclsocket listen recv recvfrom select send sendto setsockopt shutdown socket Holt Adresse und Port des Remote-Rechners. Holt Adresse und Port eines Sockets. Holt den Wert einer Option eines Sockets. Holt oder setzt die Parameter eines Sockets. Lässt Socket auf ankommende Verbindungen warten. Empfängt von einem Socket. Empfängt vom Socket und gibt RemoteAdresse zurück. Warten auf Lese-/Schreibbereitschaft mehrerer Sockets. Sendet Daten zu einem verbundenen Socket. Sendet zu expliziter Remote-Rechneradresse und -Port. Setzt eine Option für einen lokalen Socket. Deaktiviert Senden und Empfangen auf einem Socket. Erzeugt einen Socket. Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-32

33 5.5 RPC - Remote Procedure Call Historisch gesehen eine Vorstufe für RMI (Vorsicht bei Stub Namen!). Für die Implementierung von Klienten-Server Szenarien. Berücksichtigt heterogene Umgebungen bezüglich: - Betriebssystemplattformen, - Byteanordnungen, - Containergrößen. Nachbildung eines lokalen Prozeduraufrufes: - Über Rechnergrenzen und Adressräume hinweg, - Synchrone Aufrufssemantik, - Übergabe von Parametern, - Rückgabe des Resultats, - Aber kein Kontext. Klient Client-Stub (Server proxy) marshall unmarshall Server Server-Stub marshall unmarshall Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-33

34 5.5.1 RPC-Programmherstellung: *.c, *.acf, *.idl-dateien, MIDL, Stubs, C, Client.c Interf.acf Interf.idl Server.c MIDL Compiler Linker, Interf_C.C (stub) Interf.h Interf_S.C (stub) Run time C Compiler Client.obj. Server.obj C Compiler Interf_C.obj Interf_S.obj Client run time Linker Linker Server run time Client.exe Server.exe Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-34

35 5.5.2 Attribute Configuration File interf.acf : [ implicit_handle(handle_t string_ifhandle) ] interface Interf { } Mit implicit_handle benutzt das RPC Laufzeitsystem immer die spezifizierte globale Variable: RPC Library Implicit handle explicit_handle erlaubt verschiedene Remote-Interfaces per RPC anzusprechen, eventuell unter Verwendung unterschiedlicher Stubs: void ExplicitRemoteProcX( handle_t whichserver, [string] char * printmsg); auto_handle erledigt die Bindung automatisch und wählt zwischen explizit und impliziter RPC Handle, je nachdem, ob beim Prozeduraufruf ein Prozedurparameter erscheint Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-35

36 5.5.3 Interface Definition File interf.idl : Spezifiziert die Schnittstelle der Remote-Prozedur auf dem Server, Universally Unique Identifier mit Programm uuidgen erzeugen, Schnittstelle hat nur Routinen, ist also kein Objekt, IDL als erweiterte Datendeklaration in C, Kein strenges Typenkonzept. [ uuid(5afeb070-d4d5-11d f6c), version (1.0), ] interface Interf { void Print( [in, string] unsigned char *pszstring); } IDL Klient Server Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-36

37 5.5.4 Parameterübergabe und IDL-Attribute Marshalling: Konvertierung zwischen Hostformat & Netzwerkformat. Verschiedene Datentypen als maschinenunabhängiges Format: - boolean, byte, char, double, float, hyper, long, short, small, wchar_t - Stringformat berücksichtigen, - Containergrössen, - Byte-Order: Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-37

38 Übergabe von Zeigern in den fremden Adressraum: - Übergabe dynamischer Strukturen nur mit sogenannter "Pointer Emulation", - Parameter-Übergabe nötigenfalls nach dem Prinzip von Copy-Restore, - Referenz-Zeiger sind konstant und enthalten nie den Wert NULL, - Unique-Zeiger dürfen im Zeitpunkt des Aufrufs Null sein, lassen aber eine Allozierung des zurückgelieferten Parameterobjektes zu, - Full-Pointer zeigen auf ein Objekt, auf welches es auch Alias-Zeiger geben darf, - Kein automatische Hüllenbildung. Übergabemodell für Werte und Zeiger: - Als Kopie des Wertes, - Als Adresse des Wertes, - Als Adresse der Zeigervariablen, - Als Menge aller Zeiger auf das Objekt. "Hallo Server!" Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-38

39 Parametertransport mit speziellen Attributen: - [string, ] mit Nullcharacter abgeschlossener String, - [out, ] nur auf dem Rückweg übertragen, - [in,...] nur auf dem Hinweg übertragen. Weitere Attributfunktionen: - size_is(..), max_is, min_is, first_is, last_is, length_is - zum Beispiel für einen Array variabler Größe: [in] [out] Server // weiteres IDL-Dateibeispiel size_is // Name des Attributes, muss separat deklariert werden interface RPC_Array // vgl. Hamilton & Williams "Windows NT4.0..." SAMS Verlag { extern short Size; // im Klientenprogramm angesiedelt void myarrayproc( [in, size_is(size)] char Array[*] ) // Array variabler Größe } Attribute für RPC Binding-Handles: - [auto_handle] interface myservices, - [implicit_handle(handle_t InterfHdl] interface fixedservice ), - [explicit_handle] verlangt beim RPC einen zusätzlichen Handle-Parameter. Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-39

40 5.5.5 Quellprogramm client.c: Argument auf der Befehlszeile enthält einen auszugebenden String. Durch MIDL erzeugte Interface-Headerdatei mitcompilieren. u.a. der Interface Handle ist in der Headerdatei versteckt. Bind( )-Funktion für Windows-RPC: - Zeichenkette zusammenstellen mit den nötigen Binde-Parametern, - Je nach gewähltem Protokoll Verbindung implizit aufbauen, - Viele Protokollvarianten wählbar über eine Kennung; - Z.B. "ncagn_np" für Microsoft Named Pipes #include <stdlib.h> // File Client.c #include <stdio.h> #include <windows.h> #include "..\interf.h" void main(int argc, char **argv){ // Cmndline Argument implied! RPC_STATUS status; // status of RPC unsigned char *pszstringbinding=null; // binding handle as string unsigned char *pszstring = &argv[1]; // string to print Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-40

41 // make a concatenated string to feed the binding function - ignore errors here status = RpcStringBindingCompose(NULL, "ncacn_np", // proto.seq.=named-pipe NULL, // network-address (half open) "\\pipe\\hello", NULL, // end-point (pipe name) &pszstringbinding ); // the combined string status = RpcBindingFromStringBinding( pszstringbinding, &string_ifhandle); // now do the RPC RpcTryExcept { Print(pszString); } // try our remote print function, use RPC-Macro RpcExcept(1) // every exception is handled here { printf("runtime reported exception 0x%lx\n", RpcExceptionCode() ); } RpcEndExcept // end the try block, use RPC-Macro //might need to free the strings allocated by the RPC run-time library status = RpcStringFree(&pszStringBinding); // should check for error status = RpcBindingFree(&string_IfHandle); // should check for error exit(0); } // allocate and free memory for an RPC client object (here string) void RPC_FAR * RPC_USER midl_user_allocate(size_t len){ return (malloc(len)); } void RPC_USER midl_user_free(void RPC_FAR *ptr) { free(ptr); } Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-41

42 5.5.6 Quellprogramm server.c: Protokollsequenz auswählen. Server-Interface registrieren. Handle wird durch Midl deklariert. Server einschalten zur Entgegennahme von RPCs - concurrently. Server stoppen, keine weiteren RPCs. Registrierung wieder entfernen. Allozierungsroutinen für die Laufzeitumgebung bereitstellen: - Objekte beim Aufruf allozieren, - Beim Rücksprung freigeben. #include <stdlib.h> // >>>>>>>> Datei Server.c (Teil 1) <<<<<<<<<<<<< #include <stdio.h> #include <windows.h> #include "..\string.h" // name of the remote interface void Print(unsigned char *pszstring) { printf("rpc: %s\n", pszstring); } // rpc exported func Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-42

43 void main(int argc, char **argv) { // >>>>> Datei Server.c (Teil 2) <<<< RPC_STATUS status; // result status of RPC // tells the RPC library to use the specified protocol sequence combined // with the specified endpoint for receiving remote procedure calls. status = RpcServerUseProtseqEp("ncacn_np", 20, // named-pipe, # of concurrent calls "\\pipe\\hello", NULL ); // end-point name, security descr. // register interface with the RPC library status = RpcServerRegisterIf(string_ServerIfHandle, // interface to register (created by midl) NULL, NULL ); // nil UUID, default entry-point-vector // start the RPC server, ignore errors! status = RpcServerListen( 1, 20, 1); // concurrent calls in [1..20], don't wait getchar(); // wait for any key to shutdown server status = RpcMgmtStopServerListening(NULL); // shutdown and stop listening status = RpcServerUnregisterIf( NULL,NULL,FALSE ); // unregister any interface // interface to unregister, unregister interface for all UUIDs, shutdown without wait // allocates and frees memory for an RPC client object (here string) void RPC_FAR * RPC_USER midl_user_allocate(size_t len) { return malloc(len); } void RPC_USER midl_user_free(void RPC_FAR *ptr) { free( ptr ); } Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-43

44 5.6 Multicast Gruppenkommunikation (Multicast): - Versand der Nachricht an viele Teilnehmer, aber nicht an alle, - teilweise von niedrigen Schichten unterstützt (z.b. Ethernet). Kommunikationstopologien: - 1:n - ein ausgezeichneter Sender, viele Empfänger, - n:n - viele Sender, viele Empfänger, - evtl. kollektive Antwort an Sender. Zuverlässigkeit: - Evtl. keine Auslieferungsgarantie, - atomar: alle oder keiner erhält Nachricht, - k-zuverlässig: k Teilnehmer erhalten Nachricht, Ordnung der Nachrichten: - keine: zufällige Ordnung beim Empfänger - FIFO: Nachrichten des gleichen Senders in Sendereihenfolge - total geordnet: alle erhalten alle Nachrichten in gleicher Reihenfolge Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-44

45 5.6.1 Multicast MAC-Adressen: IEEE MAC-Adresse: 7 0 xxxxxxlb 7 0 xxxxxxxx 7 0 xxxxxxxx 7 0 xxxxxxxx 7 0 xxxxxxxx 7 0 xxxxxxxx - im Prinzip 46 Bit zur Unterscheidung zwischen versch. Multicast-Gruppen, - Locally administered kennzeichnet eine explizit gesetzte Ethernetadresse. - Broadcast/Multicast Bit adressiert eine Gruppe von Stationen oder alle, - $FFFF FFFF FFFF ist die Broadcastadresse. Die Abbildung von IP Multicast-Adressen auf MAC-Adressen erfolgt nach besonderen Regeln. MAC-Layer switching Hubs müssen Multicast-Nachrichten im Prinzip auf allen Ports replizieren. Optimierungsmöglichkeiten: - Abgestützt auf das Internet Group Management Protokoll (IGMP), - Interpretation vonn IGMP Nachrichten im Switch (IGMP snooping), - Proprietäres Protokoll zum Switch (CISCOs CGMP...) Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-45

46 5.6.2 Multicast IP-Adressen IP Multicast: - Interpretiert durch die Router Software, - Adressierung auf der Netzwerkebene (Ebene 3), - Adressbereich von bis , - Keine automatische Erkennung durch die Adapterhardware. Unterbereiche von IP Multicast Adresen: x: Multicast auf lokalem Segment, keine Weiterleitung durch Router, 239.x.x.x: Limited Scope Multicast Adressen, Unterstützung durch Router, x.x.x: Globally Scoped Multicast Adressen, z.b. Netzdienste. Reservierte IP-Adressen im lokalen Segment: : Alle Stationen am lokalen Segment, : Alle Router am lokalen Segment, : DHCP-Server oder DHCP-Proxy am lokalen Segment /6: OSPF-Router am lokalen Segment (= Open shortest path first), Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-46

47 5.7.1 Allgemeines 5.7 MPI für eine nachrichtengestützte Bibliothek: - Erweitertes Message-Passing Modell und Empfehlung, - Keine Spezifikation einer Programmiersprache, - Kein Produkt und keine Implementierung. Zielsetzung: - Nutzung durch Anwendungsprogrammierer, - zum Entwurf von Bibliotheken und Hifsprogrammen. Für Parallelrechner, Cluster und heterogene Rechnernetze. MPI: Fortran, C,... MPI-2: Objektorientierte Erweiterungen, C++... Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-47

48 Beispielprogramm in C:#include "mpi.h" #include <stdio.h> int main( int argc, char *argv[] ) { int rank, size; MPI_Init( &argc, &argv ); MPI_Comm_rank( MPI_COMM_WORLD, &rank ); MPI_Comm_size( MPI_COMM_WORLD, &size ); printf( "I am %d of %d\n", rank, size ); MPI_Finalize(); return 0; }Laufzeitunterstützung: Initialisierung und Terminierung der MPI-Umgebung, - Etablierung eines Communicators (Gruppe), - Anzahl der eingesetztenprozessoren, - Position des Rechners... Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-48

49 5.7.2 MPI Datentypen In einer Nachricht übertragene Daten werden durch ein Tripel beschrieben: (address, count, datatype). MPI Datentypen lassen sich rekursiv aus Skalaren aufbauen: - MPI_INT, MPI_DOUBLE_PRECISION, MPI_COMPLEX, MPI_BOOLEAN...) - Ein- oder mehrdimensionale zusammenhängende Arrays, - Nicht zusammenhängende Arrays ( strided ), - Strukturen im Sinne von C-Structs z.b., - Indizierter Aray von Structs Stride Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-49

50 5.7.3 Ausgewählte Funktionen MPI_SEND: Senden einer Nachricht - Startadresse, Anzahl Elemente, Datentyp, Ziel, tag-marke, Communicatorgruppe, - Empfänger nimmt entweder alle Tags oder nur einen ausgewählten ( Screening ). MPI_RECV: Empfangen einer Nachricht. MPI_BCAST: Verteilen einer Nachricht. MPI_REDUCE: Einsammeln von Nachrichten. MPI_COMM_SIZE: Grösse der Communicatorgruppe. MPI_COMM_RANK: Nummer des Rechners in der Gruppe. MPI_INIT: Initialisierung der Laufzeitumgebung. MPI_FINALIZE: Aufräumarbeiten. Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-50

51 5.7.4 Erweiterungen zum Message-Passing Interface 2 (MPI-2) Dynamische Prozessverwaltung - Dynamische Erzeugung von Prozessen, - Verbindungsaufbau zur Laufzeit. Generalized requests: - Nutzerdefinierbare Funktionen abgeleitet von regulären MPI Aufrufen, - Werden als asynchrone Requests auf dem lokalen Rechner eingerichtet, - Können lokal arbeiten oder mit anderen Prozessen kommunizieren, Zusätzliche Funktionen: - Einseitige Kommunikation: Put & Get, - Abbildungen von C++ Datentypen... - Parallele Eingabe und Ausgabe => Verteilte Betriebssysteme, 2004/2005, VS, Universität Ulm 5-51