Privatdozent Dr.-Ing. habil. Andriy Luntovskyy

Transkript

1 Studiengang Informationstechnik WWW: Privatdozent Dr.-Ing. habil. Andriy Luntovskyy WWW: 1

2 Verteilte Systeme und Entwicklung verteilter Anwendungen 6. Semester (36 LVS) Das Skript verwendet Lehrmaterialien von A.Schill (TU Dresden) und R.Oechsle (FH Trier) PD Dr. habil. A.Luntovskyy 2

3 Einleitung, Organisatorisches 6.Semester Periode: bis Mai

4 Aufbau und Plan der LV Verteilte Systeme 6. Studienhalbjahr (36 LVS = 24 VL + 12 Praktika) VL Vert. Systeme und Entwicklung verteilter Anwendungen Versuch 1: Socket- Kommunikation Versuch 2: WWW-Datenbankanbindung mittels serverseitiger Skripte PD Dr. habil. A.Luntovskyy 4

5 Inhalt. Verteilte Systeme und Entwicklung verteilter Anwendungen (1) 1. Einleitung 1.1 Definition und Abgrenzung 1.2. Nutzung verteilter Systeme 1.3. Transparenz 2. Kommunikation in verteilten Systemen 2.1. Client-Server-Kommunikation 2.2. Kommunikation über Sockets Kommunikation über UDP Kommunikation über TCP Nachteile der Sockets 2.3. Prozedurenaufruf (Remote Procedure Call) 2.4. Methodenfernaufruf RMI CORBA Auskunfts- und Verzeichnisdienste 2.5. Asynchrone Kommunikation 3. Entwicklung verteilter Anwendungen 3.1. Mehrschichtige Architekturmodelle 3.2. Enterprise Java Beans (EJB) Arten von Enterprise Java Beans Session Beans Clients von Session Beans Entities Funktionen eines EJB-Servers 3.3. Web basierte Anwendungen mit Servlets, Java Server Pages und Java Server Faces Java Servlets Java Server Pages (JSP) Java Server Faces (JSF) PD Dr. habil. A.Luntovskyy 5

6 Inhalt. Verteilte Systeme und Entwicklung verteilter Anwendungen (2) 4. Übersicht von Middleware- Spezifikationen 5. XML in verteilten Systemen 5.1. DTD, XSD 5.2. XML-Anwendungen (XHTML, SMIL) 6. Datenbankanbindung 6.1. SQL 6.2. ODBC, JDBC 7. SOA, Web Services 7.1. Grundlagen WS: WSDL, UDDI, SOAP, 7.2. REST, fortgeschrittene WS-* 7.3. Ausbau SOA, Forschungsfelder 8. Fortgeschrittene Verfahren der Softwaretechnik 8.1. MDA 8.2. AOP 9. Security in verteilten Systemen 9.1. Kryptographische Absicherung der Kommunikation per SSL 9.2. weitere Protokolle 10. Server- (Applikations-) Virtualisierung Klassifikation, V.-Arten Virtuelle Maschinen, Monitore, Hypervisor Netzwerk- und Speicher-V Systembeispiele PD Dr. habil. A.Luntovskyy 6

7 1. Literatur, Skripte Rainer Oechsle. Verteilte Systeme und Entwicklung verteilter Anwendungen, s , 6.Auflage, Hanser Verlag, 2007, ISBN: Alexander Schill, T.Springer. Verteilte Systeme - Grundlagen und Basistechnologien; Springer-Verlag Berlin Heidelberg 2007, ISBN: , examen.press 3. Heide Balzert. Basiswissen Web-Programmierung. XHTML, CSS, JavaScript, XML, PHP, JSP, ASP.NET, Ajax, W3L Verlag Herdecke (Taschenbuch April 2007), ISBN: Alexander Schill. Distributed Systems, Manuskript, TUD Georg Disterer, Friedrich Fels, Andreas Hausotter. Betriebliche Informationssysteme, s , 6.Auflage, Hanser Verlag, 2007, ISBN: Alexander Schill. Bürokommunikation, Manuskript, TUD Alexander Schill. Mobile Communication and Mobile Computing, Manuskript TUD, Heinz-Jürgen Spielmann. Softwaretechnik, s , 6.Auflage, Hanser Verlag, 2007, ISBN: Uwe Aßmann. Component-Based Software Engineering, Manuskript TUD, Uwe Aßmann. Softwaremanagement und Projektorganisation, Manuskript TUD, Ian Sommerville. Software Engineering. - München: Pearson Studium, Andriy Luntovskyy. Rechnernetzpraxis-1, Manuskript TUD, Andriy Luntovskyy. Rechnernetzpraxis-2, Manuskript TUD, Heide Balzert. UML2 in 5 Tagen. Der schnelle Einstieg in die Objektorientierung, W3L Verlag Herdecke, Bochum, , 184 Seiten, ISBN: Heide Balzert. Lehrbuch der Objektmodellierung - Analyse und Entwurf mit der UML 2, Elsevier Spektrum Akademischer Verlag, 2005, ISBN Helmut Balzert. Software-Technik, Manuskript von Lehrstuhl für Software-Technik, Ruhr- Universität Bochum, Helmut Balzert. Lehrbuch der Software-Technik. Band 1, 2.Auflage. Elsevier-Verlag, Unzählige Online-Quellen (Einstieg u. a. auch über Wikipedia etc.) PD Dr. habil. A.Luntovskyy 7

8 Buchstabensuppe EJB.NET CORBA.NET C-S Sockets XML RPC RMI XHTML XHTML n-tier ACID ACID JSP 2PC Web Services 2PC UMLSOA SOA AOP WAP Web Web OOA/ CASE OOD MDA MDA AOP 8

9 2PC ACID AOP Black-Box CASE CORBA C-S EJB JSP MDA OOA/OOD RMI RPC SOA UML WAP White-Box XHTML XML Abkürzungen 2-Phasen-Commit Protocol Principle ACID, Atomicity, Consistency, Isolation, Durability Aspect-oriented Programming Testfallermittlungsmethode Computer-Aided Software Engineering Common Object Request Broker Architecture Client-2-Server Communication Enterprise Java Beans Java Server Pages Model-Driven Architecture Object-Oriented Analysis and Design Remote Method Invocation Remote Procedure Call Service-oriented Architecture Unified Modeling Language Wireless Access Protocol Testfallermittlungsmethode Extensible Hypertext Mark-up Language Extensible Mark-up Language und dann viel mehr 9

10 Kommunikation in verteilten Systemen PD Dr. habil. A.Luntovskyy 10

11 Verteiltes System vs Mehrprozessorsystem Ein verteiltes System besteht aus unabhängigen, über ein Rechnernetz kommunizierenden Rechnern, wobei keine zentrale Systemsteuerung existiert und der Verteilungsaspekt für die Benutzer des Systems möglichst transparent ist. Abgrenzung: Verteilte Systeme sind lose gekoppelte Systeme ohne gemeinsamen Speicher im Gegensatz zu eng gekoppelten, parallelen Systemen mit gemeinsamem Speicher (Mehrprozessorsysteme, MIMD). Der Fokus der Betrachtung liegt auf der Entwicklung verteilter Anwendungen. Die Existenz einer funktionierenden Kommunikationsinfrastruktur, welche von den tieferen Schichten erbracht wird, wird vorausgesetzt PD Dr. habil. A.Luntovskyy 11

12 Klassifikation von Rechnerarchitekturen nach M.Flynn (1972) Unterteilung von Rechnerarchitekturen (RA) nach der Anzahl der vorhandenen Befehls- (Instruction Streams) und Datenströme (Data Streams): SISD - Single Instruction Single Data SIMD Single Instruction Multiple Data MISD Multiple Instruction Single Data MIMD Multiple Data Multiple Instruction Daten/ Befehle Single Instruction Multiple Instruction Single Data SISD MISD Multiple Data SIMD MIMD Einfachste RA: SISD (Single Instruction, Single Data) Unter SISD-Rechnern versteht man traditionelle Einprozessor-Rechner, die ihre Aufgaben sequentiell abarbeiten. SISD-Rechner sind z.b. Personal-Computer (PCs) oder Workstations welche nach der Von-Neumann- oder Harvard-Architektur aufgebaut sind. Bei erster wird für Operanden und Instruktionen der gleiche Speicher verwendet, bei letzterer sind sie getrennt PD Dr. habil. A.Luntovskyy 12

13 SIMD (Single Instruction, Multiple Data) RA von Großrechnern beziehungsweise Supercomputern SIMD-Computer, Array-Prozessoren oder Vektorprozessor (Cray 1970), dienen der schnellen Ausführung gleichartiger Rechenoperationen auf mehrere gleichzeitig eintreffende oder zur Verfügung stehende Eingangsdatenströme vorwiegend in der Verarbeitung von Bild-, Ton- und Videodaten eingesetzt. Beispiele: SIMD Instruction Pool PU Processor Unit 1. gängige Mikroprozessoren (wie Intel x86, AMD 3DNow!) besitzen inzwischen SIMD-Erweiterungen, das heißt spezielle zusätzliche Befehlssätze, die mit einem Befehlsaufruf gleichzeitig mehrere gleichartige Datensätze verarbeiten (jedoch nur per Assembler programmierbar!). 2. Feldrechner - mehrere Recheneinheiten berechnen parallel auf verschiedenen Daten die gleiche Operation (Prozessautaumatisierung) 3. Vektorrechner - quasi-parallele Bearbeitung mehrerer Daten durch Pipelining PD Dr. habil. A.Luntovskyy 13 Data Pool PU PU PU

14 MISD (Multiple Instruction, Single Data) Einsatz umstritten gibt es nicht? RA von Großrechnern beziehungsweise Supercomputern Jedoch kann man fehlertolerante Systeme, die redundante Berechnungen ausführen, in diese Klasse einordnen. Beispiel: Schachcomputer. Zukünftige Umsetzung: Makro-Pipelining, bei dem mehrere PU hintereinander geschaltet sind redundante Datenströme zur Fehlererkennung bzw. -korrektur. SIMD Instruction Pool MISD Data Pool Data Pool PU PU PU PD Dr. habil. A.Luntovskyy 14 Instruction Pool PU PU PU?

15 MIMD (Multiple Instruction, Multiple Data) RA von Großrechnern bzw. Supercomputern. MIMD-Computer führen gleichzeitig verschiedene Operationen auf verschieden gearteten Eingangsdatenströmen durch, wobei die Verteilung der Aufgaben an die zur Verfügung stehenden Ressourcen meistens durch einen oder mehrere Prozessoren des Prozessorverbandes selbst zur Laufzeit durchgeführt wird. Jeder Prozessor hat Zugriff auf die Daten anderer Prozessoren. Jedoch sehr allgemein definiert Multiprozessorsysteme teilen sich den vorhandenen Speicher und sind somit also ein Shared-Memory-System; Synchronisationsproblem bei Memory Access. MIMD-Klassen: eng gekoppelte Systeme Multiprozessorsysteme lose gekoppelte Systeme Multicomputersysteme (bzw. VS und Grid Computing) PD Dr. habil. A.Luntovskyy 15

16 MIMD (Fort.) PU PU PU PU PU PU Shared Memory Memory Memory Memory Data Pool Instruction Pool MIMD: enge Kopplung Multiprozessorsystem Beispiele: Transputer ( Transmit + Computer ) ist ein Parallelrechner (mehrere SISD, Von-Neumann-RA), der mit einer zusätzlichen Kommunikationshardware ausgestattet ist, um den Datenaustausch zu benachbarten Rechnern effizient zu ermöglichen (Großbritannien, , Firma Inmos). Verteilte Systeme - autonome Prozessoren die gleichzeitig verschiedene Befehle auf verschiedenen Daten bearbeiten PD Dr. habil. A.Luntovskyy 16 Data Instruction Data Instruction Memory Access Data MIMD: lose Kopplung Multicomputersystem VS Instruction

17 Merkmale verteilter Systeme Merkmale der VS: 1. Kopplung räumlich verteilter Rechner mittels Rechnernetz 2. Kooperation mit dem Ziel, eine bestimmte Anwendungsfunktionalität zu erbringen 3. Kein gemeinsamer physikalischer Speicher, keine strikt synchronisierten Uhren 4. Dezentrale Organisation und Verwaltung 5. Häufig auch Fehlertoleranz und Lastausgleich durch Replikation Realisierung von VS auf Basis des Client/Server-Modells bzw. durch verteilte Objekte und Software-Komponenten die P2P-Systeme liegen zum Teil außerhalb der Betrachtung in dieser LV PD Dr. habil. A.Luntovskyy 17

18 Nutzung verteilter Systeme Verteilte Systeme werden vor allem für folgende Zwecke eingesetzt: 1. gemeinsame Nutzung von Daten (z. B. verteilte Dateisysteme und World Wide Web), auch zur Erreichung von Fehlertoleranz durch Redundanz (z. B. Replikation von Daten einer Datenbank), 2. gemeinsame Nutzung von Geräten (z. B. Drucker und Scanner) 3. gemeinsame Nutzung von Rechenleistung (z. B. Zugriff auf Hochleistungsrechner), 4. Kommunikation der Benutzer eines verteilten Systems (z. B. elektronische Post, gemeinsamer Terminkalender einer Arbeitsgruppe, Mehrbenutzeranwendungen wie Mehrbenutzertexteditoren oder Mehrbenutzergrafikeditoren, IP-Telefonie, Audio-Video-Konferenzen). VS im Hintergrund: Neben solchen, für die Endanwender sichtbaren verteilten Anwendungen gibt es auch solche, die von anderen Komponenten intern benutzt werden und den Endanwendern verborgen bleiben wie z. B. Anwendungen zur Berechnung von Wegewahltabellen (OSPF, RIP, BGP usw.), Namensdienste (DNS), Konfigurationsdienste (DHCP) und Netzmanagement-Dienste (SNMP) PD Dr. habil. A.Luntovskyy 18

19 Transparenz Da die Nutzung verteilter Systeme in der Regel komplizierter ist als die Nutzung eines einzelnen Rechners, wurden auf unterschiedlichen Ebenen (Programmierebene, Benutzerebene usw.) Mechanismen eingeführt, die den Aspekt der Verteilung verbergen Ein verteiltes System erscheint wie ein zentrales System. Man spricht von Verteilungstransparenz. Sie bemerken allenfalls eine Leistungseinbuße. Folgende Arten der Verteilungstransparenz lassen sich unterscheiden: 1. Zugriffstransparenz: Der Zugriff auf lokale und ferne Ressourcen erfolgt in derselben Weise. 2. Ortstransparenz: Der Zugriff auf Ressourcen ist ohne Kenntnis des Orts, an dem sich die Ressourcen befinden, durchführbar. 3. Namenstransparenz: Der Name einer Ressource ist für alle Rechner des verteilten Systems gleich. (DNS, URL, URi) 4. Skalierungstransparenz: Die Erweiterung des Systems um weitere Rechner ist möglich, ohne dass die Gesamtstruktur oder die Anwendungsprogramme geändert werden müssen 5. Replikationstransparenz: Falls das verteilte System zur Erhöhung der Verfügbarkeit und Fehlertoleranz mehrere Kopien von einer Ressource hält, so bleibt dies den Anwendungsprogrammen bzw. Benutzern verborgen PD Dr. habil. A.Luntovskyy 19

20 Transparenz (Fort.) 6. Nebenläufigkeitstransparenz: Mehrere Anwendungsprogramme bzw. Benutzer können nebenläufig auf dieselben Ressourcen zugreifen, ohne dass es dabei zu Problemen kommt. 7. Ausführungs- bzw. Migrationstransparenz: Es ist für die Anwendungsprogramme bzw. Benutzer nicht erkennbar, auf welchem Rechner ein angeforderter Dienst ausgeführt wird. Es ist sogar möglich, dass ein laufendes Anwendungsprogramm während der Ausführung eines Dienstes auf einen anderen Rechner bewegt wird (Migration). 8. Leistungstransparenz: Bei sich ändernden Belastungen kann das System umkonfiguriert werden, um die Leistung zu verbessern, ohne dass die Anwendungsprogramme bzw. Benutzer dies bemerken. 9. Ausfalltransparenz: Der Ausfall von Software- oder Hardwarekomponenten bleibt Anwendungsprogrammen bzw. Benutzern weitgehend verborgen PD Dr. habil. A.Luntovskyy 20

21 Transparenzkonzept: VS vs. Grid Computing In einem verteilten System können unterschiedliche Transparenzaspekte mehr oder weniger stark ausgeprägt sein. Ein Beispiel für verteilte Systeme, bei denen besonders großer Wert auf Transparenz - insbesondere auf Ausführungstransparenz - gelegt wird, stellt das dar. Während die ersten Einsatzgebiete für das Grid Computing wissenschaftlicher Natur waren, wird es mittlerweile verstärkt auch im kommerziellen Umfeld eingesetzt. Eine scharfe Abgrenzung zwischen Grid Computing und anderen verteilten Systemen gibt es nicht PD Dr. habil. A.Luntovskyy 21

22 Grid Computing: weitere Details Grid-Computing ist eine Form des verteilten Rechnens, bei der ein "virtueller Supercomputer" aus einem Cluster lose gekoppelter Computer erzeugt wird. Es wurde entwickelt, um rechenintensive wissenschaftliche insbesondere mathematische Probleme zu lösen. Heute wird Grid-Computing in vielen zum Teil auch kommerziellen Bereichen eingesetzt: in der Pharmaforschung in den Wirtschaftswissenschaften, beim elektronischen Handel bei Web Services (Webdiensten). zum Risikomanagement in der Baudynamik im Bereich Finanzmanagement. Von typischen Computerclustern unterscheidet sich Grid-Computing in der wesentlich loseren Kopplung, der Heterogenität und der geographischen Zerstreuung der Computer. Des Weiteren ist ein Grid meistens bestimmt für eine spezielle Anwendung und nutzt häufig standardisierte Programmbibliotheken, Middleware und Web Services Quelle: Wikipedia PD Dr. habil. A.Luntovskyy 22

23 Kommunikationsarten in VS Verteilte Systeme unterteilen sich nach der Art der Kommunikation: 1. Client-Server-Kommunikation Kommunikation über Sockets (Transport: TCP/UDP) Prozedurenaufruf (RPC, Remote Procedure Call) Methodenfernaufruf (RMI, Remote Method Invocation, und CORBA, Common Object Request Broker Architecture) Asynchrone Kommunikation (MQ, Message Queuing) 2. Peer-to-Peer-Kommunikation (gleichberechtigte Partner, P2P) Dies sind hauptsächlich VS zur Realisierung von Tauschbörsen für Dateien (File-Sharing wie z. B. Napster, KaZaa usw.), mit denen vorwiegend Musik- und Videodateien (MP3, AVI, MPEG usw.) (nicht selten illegal) getauscht werden PD Dr. habil. A.Luntovskyy 23

24 P2P-Systeme P2P-Systeme lassen sich in unstrukturierte und strukturierte P2P-Systeme unterteilen. Unstrukturierte P2P-Systeme unterteilen sich nochmals nach der Art ihres Aufbaus. Man unterscheidet Zentralisierte P2P-Systeme (Beispiel: Napster), welche einen zentralen Server zur Verwaltung benötigen, um zu funktionieren Reine P2P-Systeme ohne zentrale Instanz (Beispiele: Gnutella 0.4, Freenet) Eine spezielle Art eines reinen, dezentralen Netzwerkes bildet das Friend-2- Friend- oder Web-of-Trust-Netzwerk, bei dem keinerlei Verbindungen zu unbekannten IP-Adressen unterhalten werden, sondern ausschließlich Verbindungen zu Freunden (trusted friends) etabliert werden. (Beispiel: RetroShare) Hybride P2P-Systeme, welche dynamisch mehrere zentrale Server zur Verwaltung bestimmen (Beispiele: Gnutella 0.6, JXTA) Zentralisierte und reine P2P-Systeme bezeichnet man auch als Systeme erster Generation und dezentrale Systeme als Systeme zweiter Generation. Systeme, die Dateien über nicht-direkte Verbindungen weiterreichen, sind Systeme dritter Generation (File Sharing) PD Dr. habil. A.Luntovskyy 24

25 C-S-Kommunikation SW C-S-Kommunikation SW BS mit TCP/IP API MW Sockets RPC, RMI, MQ API MW BS mit TCP/IP HW Transportsystem TCP, UDP HW BS mit Unterstützung des TCP/IP- Protokollstack API Application Programming Interface C-S-Kommunikation über:(client-server-kommunikation) Sockets (TCP, UDP Transportprotokolle) Prozedurenaufruf (RPC, Remote Procedure Call) Methodenfernaufruf (RMI, Remote Method Invocation, und CORBA, Common Object Request Broker Architecture) Asynchrone Kommunikation (MQ, Message Queuing) Erscheinen von MW, einer Zwischenschicht MW-Spezifikationen CORBA, weitere Spezifikationen EJB (Enterprise Java Beans),.NET PD Dr. habil. A.Luntovskyy 25

26 Mehrstufige Architektur Client Server Kasse Geldautomat Server (z.b. Kontenserver) Server (z.b. Datenbank) Client (z.b. Homezugang) Benutzerschnittstelle, ggf. Vorverarbeitung Anwendungslogik 3-tier: 2-tier: Datenverwaltung dreistufige Struktur; bei komplexen Anwendungen zu bevorzugen zweistufige Struktur (Benutzerschnittstelle Host); einfacher, aber weniger flexibel PD Dr. habil. A.Luntovskyy 26

27 2-tier: Thin Client vs. Thick Client Thin-Client nur die Benutzerschnittstelle auf dem Client-System Ähnlich zu zentralem System, aber oft Download-Mechanismen Vorteil: kostengünstige Clients Nachteil: Überlastsituationen wenn zu viele Clients auf denselben Server zugreifen, begrenzte Skalierbarkeit Thick-Client (auch Fat- Client) Teile oder gesamte Fachlogik auf dem Client- System Hauptfunktion des Servers: Datenhaltung Vorteil: Entlastung des Servers Nachteil: Zusätzliche Anforderungen an Clients: Softwareinstallation +Wartung), Entwicklungsaufwand PD Dr. habil. A.Luntovskyy 27

28 Verteilte Anwendungen: Techniken der Verteilung Time Sharing Distr. Presentation Remote Processing Distr. Processing Remote DB Distr. DB Stand Alone Processing Server DB DB DB DB DB DB DB DB DB DB DB DB DB DB Logik Logik Logik Logik Logik Logik Logik Logik Logik Logik Logik Logik Logik Logik GUI GUI GUI GUI GUI GUI GUI GUI GUI GUI GUI GUI GUI GUI PD Dr. habil. A.Luntovskyy 28 Client

29 Verteilte Anwendungen: Techniken der Verteilung Time Sharing Distr. Presentation Remote Processing Distr. Processing Remote DB Distr. DB Stand Alone Processing Server DB DB DB DB DB DB TCP/IP- Netzwerk DB DB Logik Logik Logik Logik Logik Logik Logik Logik GUI TCP/IP- Netzwerk GUI GUI GUI GUI GUI GUI GUI PD Dr. habil. A.Luntovskyy 29 Client

30 Sockets PD Dr. habil. A.Luntovskyy 30

31 IP-Adressen und Ports Kommunikation per TCP oder UDP Jeder Host hat max. 65,536 Ports (2^16-1) Manche Ports sind reserviert für spez. Internet-Services 21: FTP 23: Telnet 80: HTTP Socket bietet eine Schnittstelle zum Paar: (IP- Address ; Port) Besteht aus Byte folgende Funktionalität ist notwendig: Spezifizieren lokale und entfernte Dienstzugangspunkte für Kommunikation zwischen Applikationen Verbindungsaufbau bzw. -abbau initiieren Daten senden und empfangen Sockets erzeugen/beenden Port 0 Port 1 Port PD Dr. habil. A.Luntovskyy 31

32 Threads - "leichtgewichtige" Prozesse (1) Prozess P1 Threads Prozess P2 Threads ProzessP3 Threads T1a T1b T2a T2b T2с T3a Anwendungen/Prozesse Px mit mehreren Threads Txy Wegen ihres umfangreichen Kontextes sind Prozesse oft "schwergewichtig" (z. B. in UNIX). Um feinere Parallelität, auch innerhalb einer Anwendung zu erreichen, wurden "leichtgewichtige" Prozesse bzw. Threads entwickelt. Ein Thread ist ein Aktivitätsträger (sequenzieller "Ausführungsfaden") mit minimalem Kontext (Stack und Register) innerhalb einer Ausführungsumgebung (Prozess). Jeder Prozess besitzt in diesem Fall mindestens einen (initialen) Thread. Alle Threads, die zu ein und demselben Prozess gehören, benutzen denselben Adressraum sowie weitere Betriebsmittel dieses Prozesses gemeinsam PD Dr. habil. A.Luntovskyy 32

33 Threads - "leichtgewichtige" Prozesse (2) In der Praxis eignen sich viele Anwendungen und Systemprozesse für eine Implementierung in Form paralleler Threads. So können z.b. Textverarbeitungsprogramme wie etwa MS Word verschiedene Bearbeitungsfunktionen innerhalb desselben Textes (z.b. Texterfassung, Textumbruch, Rechtschreibprüfung) durch verschiedene Threads parallel ausführen. Auch Anwendungen, die viele unabhängige Anfragen bearbeiten müssen, z. B. Datenbanksysteme oder Web-Server, lassen sich effizient mittels Multithreading implementieren. Die Implementierung von Threads kann erfolgen in Form von: User-Level-Threads: Threads aus der Sicht einer Anwendung bzw. des Programmierers. Kernel-Level-Threads (auch Kernel-Threads): Threads aus der Sicht des Betriebssystems zum Ablauf auf einer CPU, z.b. in MS Windows NT/2000/XP/Vista/Win PD Dr. habil. A.Luntovskyy 33

34 Threads und Parallelablauf Software Quelle / OpenMP API Parallelle Sektion Parallelle Sektion T1 Tn T2 Tn+1 HT FORK JOIN HT FORK JOIN HT Sequentielle Sektion Sequentielle Sektion Sequentielle Sektion Struktur einer Anwendung: HT Hauptthread Ti Thread Fork-Join-Modell für Threads in OpenMP API (Application Programming Interface) Runtime

35 Socket als SW-Struktur (1) Das Socket ist eine Software-Struktur, die eindeutig einen TSAP (Transport Layer Service Access Point) zu einem Anwendungsprozess in einem Knoten eines Netzes charakterisiert Jeder Anwendungsprozess wird durch die Sockets eindeutig definiert Socket dient für Aufbau einer logischen Verbindung zwischen Netzanwendungen Kennung durch zwei IDs: Portnummer 2 Byte und IP-Netzadresse - 4 Byte Die Portnummern werden von Internet Assigned Numbers Authority (IANA) nach RFC 1700 festgelegt Manche Dienste haben feste Portnummer, z.b. Telnet, FTP, DNS usw PD Dr. habil. A.Luntovskyy 35

36 Socket als SW-Struktur (2) Schnittstelle zwischen Anwendung und Netzwerk bzw. Internet Anwendung kann Daten senden und empfangen Unterstützt durch Socket-APIs zu bekannten Programmiersprachen durch alle Betriebssysteme (bspw. durch UNIX seit 1970er) Anwendung Socket User Kern Anwendung Socket-API Protokoll A Protokoll B Protokoll C TCP/UDP IP (Netzwerk) PD Dr. habil. A.Luntovskyy 36

37 Thread Multiplexing IANA Internet Assigned Numbers Authority, IANA ist verantwortlich für die Zuordnung der Ports Portsnummer werden von IANA reserviert und verwaltet, z.b. die Hauptanwendungsdienste haben feste Nummer: FTP (#21), TFTP (#69) DNS (#53) Telnet (#23) SMTP (#25) WWW (#80) Übrige Ports kann man dynamisch für Anwendungsprozesse zuordnen ( ) Untermenge ( ) ist temporär ( ephemeral ) in Interessen der Internet- Gemeinschaft reserviert Thread-Konzept: Netzwerkanwendungen bestehen aus einem oder mehreren Threads Jedem Thread wird eine Prozessorzeiteinheit zugeteilt Threads werden mittels TCP/UDP umgeschaltet Prozess FTP Prozess DNS Prozess Telnet Port21 Port53 Port23 Eingehende Segmente TCP - Multiplexing IP Netzwerkinterface (NIC) Ausgehende Segmente PD Dr. habil. A.Luntovskyy 37

38 Socket 1: DNS = aa.inf.tu-dresden.de IP = bb.cc Port = SOCK_STREAM request Sockets: Beispiel Client 1 reply TELNET Port 23 Client 2 Socket 2: DNS = xx.inf.tu-dresden.de IP = yy.zz Port = SOCK_STREAM Port 21 FTP Server DNS = nn.inf.tu-dresden.de IP = qq.pp PD Dr. habil. A.Luntovskyy 38

39 Socket-Programmierung: Socket-APIs Socket API besteht aus 4 Gruppen der Programmierfunktionen für Kommunikation zwischen zwei Netzwerkpartnerprozessen: Funktionen für lokale Verwaltung F. für Verbindungsaufbau F. für Datentransfer F. für Verbindungsabbau Socket-Programmierung ist möglich mit Einsatz mehrerer Programmiersprachen, wie z.b. C, C++, Java Jeder Socket bekommt eine eindeutige ID: IP- Adresse/Portnummer Socket kann eine verbindungsorientierte (TCP) oder verbindungslose (UDP) Kommunikation erzeugen PD Dr. habil. A.Luntovskyy 39

40 Socket als Schnittstelle Application Application Protocol Application Socket Socket TCP/UDP IP TCP/UDP IP TCP/UDP IP Physical Protocol PD Dr. habil. A.Luntovskyy 40

41 Sockets: verbindungslose Kommunikation 1. Client und Server fordern jeweils mit dem Systemaufruf einen Socket an. Dabei wird als Transportprotokoll UDP angeben. socket() 2. 1 Der Server bindet eine Portnummer an den erstellten Socket. 3. Durch den Aufruf von recvfrom blockiert der Server-Prozess und 1 socket() bind() 2 wartet auf eingehende Daten auf dem erstellten Socket Der Client versendet unter Angabe 4 sendto() recvfrom() 3 der Adressinformationen (die zuvor in eine sockaddr_in-struktur gefüllt wurden) mit Hilfe von sendto Daten an den Server, die durch recvfrom von diesem entgegengenommen werden. Implizit wird dabei 5 ebenfalls in eine sockaddr_inrecvfrom() sendto() Struktur, die recvfrom als Parameter übergeben wurde, die Absenderadresse bzw. der Absenderport eingetragen, so dass 6 close() dem Client geantwortet werden kann. Client Server 5. Der Server antwortet dem Client. 6. Der Socket auf Client-Seite wird nach abgeschlossener Kommunikation geschlossen PD Dr. habil. A.Luntovskyy 41

42 Sockets: verbindungsorientierte Kommunikation 1. Sowohl Client, als auch Server fordern einen Socket an, der daraufhin als Schnittstelle zur Transportschicht 1 socket() connect() send() recv() close() 5 socket() bind() listen() accept() recv() send() close() 8 8 Client 6 Server verwendet werden kann. Bereits an dieser Stelle wird das zu verwendende Transportprotokoll, hier TCP, angegeben. 2. Der Server bindet eine lokale Adresse (eine Portnummer) an den erstellten Socket, über die der Prozess in der Folge verfügbar ist. 3. Daraufhin wird durch den Aufruf von listen auf eingehende Verbindungen gelauscht. 4. Die Möglichkeit eingehende Verbindungen anzunehmen wird durch den Aufruf von accept erreicht. 5. Der Client initiiert eine Verbindung auf dem unter 1. angelegten Socket. Dabei werden alle notwendigen Daten, wie IP- Adresse und Portnummer spezifiziert. Bei dem Verbindungsvorgang handelt es sich um einen 3-Wege-Handshake. 6. Auf Server-Seite wird eine eingehende Verbindung zunächst in eine Warteschlange eingehängt. Der vorherige Aufruf von accept bewirkt, dass diese Warteschlange abgearbeitet wird. Für jede eingegangene Anfrage wird dazu ein neuer, verbundener Socket erstellt. Damit ist zwischen den beiden Endpunkten ein Kommunikationskanal hergestellt. 7. Auf diesem Kanal können nun mit Hilfe entsprechender Systemaufrufe Daten geschrieben bzw. gelesen werden. 8. Nachdem alle Daten übertragen wurden PD Dr. habil. A.Luntovskyy können die Sockets geschlossen werden.

43 Socket-Programmierung: Analogie für Socket-Begriffe Telefonlinie Telefonnummer (Zentrale) Erweiterung (Apparat) auf den Anruf warten Vorwählen Antwort Sprechen/Hören Hörer auflegen socket(); IP-Adresse Portnummer bind(); listen(); connect(); accept(); send() / recv(); close(); PD Dr. habil. A.Luntovskyy 43

44 TCP/IP-Programmierung Basis: Sockets als Dienstzugangspunkt Prozess A socket() => Socket connect (Socket, Prozeß B) send (Socket, data) receive (Socket, data) close(socket) Prozess B socket() => Socket bind (Socket, Name) - Benennt Socket listen (Socket) - Erzeugt Pufferplatz accept (Socket) - Wartet auf Verbindungsanforderung receive (Socket,data) send (Socket,data) zusätzlich: "Select" zum Warten an mehreren Sockets, ODER-verknüpft Stream-Sockets: Realisierung auf Basis von TCP für Datenströme Datagram Sockets: UDP-basiert, einfache Datagramme PD Dr. habil. A.Luntovskyy 44

45 Java Sockets: Beispiel für Server- Seite ServerSocket serversocket = new ServerSocket(port); // generiere neuen Socket mit bestimmter Portnummer while (true) { Socket clientsocket = serversocket.accept(); // warte auf Nachrichten } InputStream input = clientsocket.getinputstream(); // Datenstrom empfangen int data = input.read(); // Daten auslesen clientsocket.close(); // Verbindung schließen PD Dr. habil. A.Luntovskyy 45

46 Nachteile der Sockets Die Nutzung von Sockets zur Realisierung verteilter Anwendungen besitzt folgende Nachteile: 1. Da UDP unzuverlässig ist, müssen die obigen Programmstrukturen für den UDP-Server und -Client um Maßnahmen zur Erhöhung der Zuverlässigkeit (befristetes Warten auf eine Antwort, wiederholtes Senden des Auftrags usw.) erweitert werden. 2. Bei der Nutzung von TCP muss der Verbindungsauf- und -abbau jeweils explizit programmiert werden. 3. Da die Server von vielen Clients beauftragt werden, ist es ratsam, einen Server durch mehrere parallele Prozesse zu realisieren. Dies muss explizit programmiert werden. 4. Die übertragenen Daten müssen unter Umständen vor und/oder nach der Übertragung gewandelt werden, insbesondere bei der Übertragung von Binärdaten (Big-Endian- vs. Little-Endian-Darstellung ganzer Zahlen, Länge von int-zahlen: 2, 4 oder 8 Byte, Layout von Datenstrukturen usw.). 5. Beim Software-Entwurf wird ein zu entwickelndes System in Module oder Objekte von Klassen aufgeteilt. Die Module interagieren über Prozeduraufrufe, die Objekte über Methodenaufrufe. Die Kommunikation über Sockets passt nicht zu diesem Paradigma PD Dr. habil. A.Luntovskyy 46