Verteilte Systeme
Transcription
Verteilte Systeme
Prof. Dr. Th. Letschert CS5001 Verteilte Systeme Master of Science (Informatik) - Netzwerkprogrammierung - © Th Letschert FH Gießen-Friedberg Plattformen der Verteiltheit Netzwerk-Programmierung : Verteilte Systeme als interagierende Prozesse Themen: ● ● ● ● ein Blick zurück Socket-API Server-Struktur einfache Abstraktionen oberhalb der Socket-Ebene in Java Verteilte Systeme Th Letschert, FH Giessen 2 Plattformen der Verteiltheit Plattformen der Verteiltheit : ein Blick zurück Verteilte Systeme Th Letschert, FH Giessen 3 Plattformen der Verteiltheit – Ende 1980er Plattformen der Verteiltheit ~ Ende 1980-er – LAN- / X25-Zeitalter : LANs und Fern-Netze: getrennte Welten – wichtige Protokolle (Protokoll-Stack kein Standard-Bestandteil eines BS) ● Netbios ~1984 eingeführt als API für LAN-Controller, IBMs PC_LAN Netze – ungerouteter Protokoll-Stack (keine Schicht-3 / keine Router) SPX/IPX: – ● – – – ● Protokoll in Novell-Netzen, bis Mitte der 1990er Markt-beherrschend basierend auf Xerox Internetworking Protokollen geroutetes Protokoll ähnlich zu TCP/IP X25 Protokoll (Schicht 2 / 3) in Telekom-Netzen – dominierend in kommerziellen eingesetzten Fern-Netzen TCP/IP – ● – – Verteilte Systeme kommerziell (fast) bedeutungslos Einsatz (fast) nur in Fern-Netzen von Universitäten und Forschungsinstituten Th Letschert, FH Giessen 4 Plattformen der Verteiltheit – 1980er Plattformen der Verteiltheit : 1980-er – Anwendungsplattform LANs ● Netzwerk-Betriebssysteme für Standard-Dienste – Betriebssysteme (d.h. DOS) wird um Zugriff auf gemeinsame Ressourcen erweitert DOS-Aufrufe (Interrupts) werden abgefangen und umgeleitet – ● – typische Ressource: File- / Drucker-Server (unter speziellem Multitasking-BS) Entwicklung angepasster verteilter Anwendungen auf der Ebene von – Interrupt-Handlern – C- / Assembler-Routinen Anwendungsplattform Fern-Netze ● Kommerzielle Systeme: X25, Proprietäre Protokolle mit entspr. speziellen APIs ● Forschung: OSI-Protokolle, TCP/IP mit speziellen APIs Verteilte Systeme Th Letschert, FH Giessen 5 Plattformen der Verteiltheit – 1980er Anwendungsplattform Beispiel: Datenpaket unter IPX empfangen ● Interrupt-Handler schreiben (in Assembler) – – – – – ● Empfangs-Routine in C schreiben – – – ● System-Kontext: Kein User-Stack Grobe Analyse des ECB Ablage der Daten im Userspace Anwendungs-Programm – – ● System-Kontext: Kein User-Stack Register-Paar ES:SI enthält Zeiger auf ECB ECB, Event-Control-Block: Datenstruktur mit Info über das Ereignis und mit Zeigern auf Fragmente des empfangenen Datenpakets Aufruf C-Routine zur Annahme der Daten Interrupt-Handler installieren Test ob Daten angekommen Daten annehmen, verarbeiten / Fehler behandeln Notwendige Kenntnisse der Anwendungsentwickler – – – Verteilte Systeme Assembler / C / komplexe APIs (Kontroll-Blöcke) BS: Interrupts, Scheduling-/Tasking-Probleme, Funktion bestimmter Register, Stack, Stack-Frames, User-Space vs. System-Space, ... Protokoll: Paketformat, ... Th Letschert, FH Giessen 6 Plattformen der Verteiltheit – Ende 1980er Plattformen der Verteiltheit ~ Ende 1980-er – Protokolle ● BS mit integriertem Protokoll-Stack – – – – ● installierbare Protokolle – – – Unix-Varianten: TCP/IP Mainframes, Mini-Computer (z.B. DEC): proprietäre Protokolle (Lan-) Netz-Server (Netware): IPX/SPX (Lan-) Netz-Server (IBM / MS, bis Bruch mit IBM->NT), OS/2): NETBIOS PC: Netbios (IBM/MS), SPX/IPX (Netware), TCP/IP (Sun) Mainframes, Mini-Computer: X25, TCP/IP, OSI-Protokolle Typische Anwendungsplattform ● Fernnetze: wie Ende 1980er, X25 ● LANs: Netbios, SPX/IPX mit speziellen APIs (abhängig von Protokoll- und Protokoll-Implementierung und BS) – Notwendige Kenntnisse der Anwendungsentwickler weit verbreit: LANs (vor allem unter Netware), X25 in Fernetzen ● ● LANs unter NETWARE, NETBIOS: BS (Protokoll-Installation, -Konfiguration), API WANs unter X25, TCP/IP, propr. Protokollen: BS-spezifische APIs Verteilte Systeme Th Letschert, FH Giessen 7 Plattformen der Verteiltheit – Frühe 1990er Plattformen der Verteiltheit ~ Frühe 1990-er – Protokolle ● BS mit integriertem Protokoll-Stack – – – – ● installierbare Protokolle – – – Unix-Varianten, Mini-Computer: TCP/IP Mainframes, Mini-Computer (z.B. DEC): proprietäre Protokolle (Lan-) Netz-Server (Netware): IPX/SPX (Lan-) Netz-Server (MS-NT): NETBIOS PC: Netbios (IBM/MS), SPX/IPX (Netware), TCP/IP (Sun) Mainframes, Mini-Computer: X25, TCP/IP Typische Anwendungsplattform Beginn der Vereinheitlichung der LAN- / WAN-Netze unter TCP/IP ● Socket-API für TCP/IP und SPX/IPX ● NETBIOS-API für Netbios-basierte LANs ● Interaktion auf API für Nutzung von Schicht-4-Diensten, z.B. via Socket-API Verteilte Systeme Th Letschert, FH Giessen 8 Plattformen der Verteiltheit – Frühe 1990er – – Interaktion auf Schicht-4 ● Rechner-Identifikation (IP-Adresse, DNS-Name, ..) ● Anwendungs-Identifikation (Port, well-known-port, ..) ● Datenaustausch (Pakete senden/empfangen, Verbindungen aufbauen nutzen, ..) ● Verteilte Anwendung: Mangement von Inter-Prozess-Kommunikation ● Entwicklung einer verteilte Anwendung ~ Socket-Programmierung Notwendige Kenntnisse der Anwendungsentwickler ● ● ● LAN / WAN: Schicht-4- API (Netbios / Socket-) API, Protokolle, Konfiguration der Protokoll-SW WAN: BS-spezifische Schicht-4-APIs Tiefere BS-Kenntnisse nicht mehr notwendig Verteilte Systeme Th Letschert, FH Giessen 9 Plattformen der Verteiltheit – Mitte 1990er Plattformen der Verteiltheit ~ Mitte 1990-er – Protokolle ● alle BS mit integriertem Protokoll-Stack – – – TCP/IP weit verbreitet Trennung der Technologie von LAN und WAN beendet Anwendungsplattformen ● typisch: Nutzung einer Schicht-4-API (Sockets) ● Forschungsthema, Anwendung durch fortgeschrittene Entwickler – Abstraktion von Schicht-4 Diensten ● – Unterstützung durch spezielle Dienste ● – Verteilte Systeme z.B. RPC Middleware, SOA, .... Bereitstellung von Standardlösungen in Bibliotheken ● – z.B. Namensdienste Standard-Code-Bausteine (generiert / bereit gestellt) ● – z.B. OSI: Presentation- / Session-Layer z.B. XDR Integration in Programmiersprachen Th Letschert, FH Giessen 10 Plattformen der Verteiltheit – Mitte 1990er ● Protokoll-Stack bis Schicht-4 in BS integriert ● Anwendungs-Protokolle als Anwendungsprogramme ● Schicht-4- (Socket-) API in Programmiersprachen integriert ● Höherwertige Unterstützung der Verteilung – Wetzwelt / OSI: als Schicht-4 / -5 konzipiert – Informatik ● Forschung: – ● Nicht erfolgreich (Warum?) Fortsetzung der Integration in das BS (transparente Verteiltheit) Praxis: Beginn der Middleware Bibliotheken – Generierungs-Werkzeuge – Standard-Dienste zur Unterstützung der Entwickler / Entlastung von StandardAufgaben – Verteilte Systeme Th Letschert, FH Giessen 11 Plattformen der Verteiltheit Plattformen der Verteiltheit : Verteilte Systeme als interagierende Prozesse Verteilte Systeme Th Letschert, FH Giessen 12 Plattformen der Verteiltheit Verteiltes Systeme auf Schicht-4 Diensten System = interagierende Prozesse in der Regel Client-Server-Struktur Interaktion: Kommunikation über Socket-API Themen Nutzung der Socket-API Struktur der Prozesse (der Server) Nebenläufigkeit der System-Komponenten Verteilte Systeme Th Letschert, FH Giessen 13 Protokolle: OSI / Internet Schicht 7 Anwendungs-Protokolle Schicht 6 Session/Presentation -> Middleware-Protokolle Schicht 5 Schicht 4 Internet-Protokolle Schicht 3 Schicht 2 Schicht 1 ISO/OSI Protokolle Protokoll - (De-) Multiplexing Rahmen- / Paket-Struktur Verteilte Systeme Th Letschert, FH Giessen 14 Schicht-4 Service Access Point (SAP) : Sockets TFTP SMTP FTP verbindungslos verbindungsorientiert (De-)Multiplexing Anwendungen System ... NFS Port TCP Socket-API ... UDP P-ID IP P-ID Ethernet Verteilte Systeme Token-Ring Th Letschert, FH Giessen Seriell 15 Schicht-4 API: Socketkommunikation Sockets ● ● Schnittstelle zur Schicht-4-Implementierung (BS) ursprünglich BSD-Unix, heute 'alle' Systeme (z.B. WinSock) Schicht-4 unabhängige Schnittstelle heute meist für TCP/IP Protokollstack Verbindungsendpunkt (SAP Service-Accesspoint) ● UPD Server stellt Daten-Socket bereit wartet auf Daten-Pakete von Client und antwortet ● TCP Server stellt Verbindungs-Socket bereit wartet auf Verbindungswünsche von Clients Verbindung -> Daten-Socket -> bi-dirketionaler Datenstrom zum Client Verteilte Systeme Th Letschert, FH Giessen 16 Socket-Abstraktionen: Zugriff auf Schicht-4-API in Sprachen integriert Java (Package java.net) ServerSocket lokale Adr: IP+Port Server: accept ● Socket ● Client: ferne Adr: IP+Port Verbindungsaufbau, ● Server: autom: ferne Adr Komminikation als Klassenbibliotheken z.B. C++: ACE (Adapitve Communication Environment) etc.: diverse andere Kommunikation C# (Namespace system.net) ● low-level: ● Socket ● IPEndPoint, IPAddress,... ● high-level: ● TCP-Client ● TCP-Listener andere: Perl, TCL, Python, ... Verteilte Systeme Th Letschert, FH Giessen 17 Prozesse / Threads: Nebenläufigkeit in Komponenten Prozesse/ Threads Verteilte Systeme bestehen aus Komponenten, die durch Nachrichten kommunizieren Komponenten sind in der Regel nebenläufige Systeme, die aus Threads und/oder Prozessen bestehen Nebenläufige Komponente Verteiltes System Verteilte Systeme Th Letschert, FH Giessen 18 Verteilte Systeme als interagierende Prozesse Verteilte Systeme als interagierende Prozesse: Struktur der Komponenten / Server Verteilte Systeme Th Letschert, FH Giessen 19 Struktur der Komponenten / Server : Nebenläufigkeit in Komponenten Nebenläufigkeit vereinfacht SW-Organisation unabhängige Ereignisverarbeitung, z.B. blockiernde I/O-Operationen möglich Verbesserung des Durchsatzes Nutzung mehrerer CPUs, Parallelität in sonstiger HW Nebenläufigkeit in Client/Server-Systemen besonders wichtig für Server hohe Anforderungen effiziente HW-Nutzung (hohe Last) hohe Anforderung an Verfügbarkeit Verteilte Systeme Th Letschert, FH Giessen 20 Struktur der Komponenten / Server : Server-Architektur Architektur des Servers Ziele keine ignorierten Service-Anforderungen ( Denial-of-Service ) hoher Durchsatz Einflussfaktoren Randbedingungen Plattformeigenschaften (HW / BS) Struktur der Anwendung Nutzung der Anwendung Protokoll-Struktur Verbindungslos / Verbindungsorientiert Request-Response / Sessions-Konzept Verteilte Systeme Th Letschert, FH Giessen 21 Serverarchitektur : Einflussfaktor Protokollstruktur Protokollstruktur ● synchrones Request-Response Protokoll – – ● Neue Anfragen erst nach Antwort auf die vorhergehende Einsatz ● Neue Anfragen hängen von der Antwort ab ● Kurze Bearbeitungszeit + geringe Netz-Latenz (LAN) ● Einfachheit vor Performanz synchrones Protokoll asynchrones Request-Response Protokoll – – Anfragen und Antwort entkoppelt Einsatz ● Anfragen und Antworten sind nicht eng gekoppelt (z.B. HTTP-Gets) ● Latenz im Netz groß (WAN) ● Performanz vor Einfachheit asynchrones Protokoll Verteilte Systeme Th Letschert, FH Giessen 22 Serverarchitektur : Einflussfaktor Protokoll Dienstdauer ● Protokoll mit kurz andauerndem Dienst (short duration service) – – – – Dienst umfasst eine kurze (feste) Zeitdauer Oft eine Frage / eine Antwort Oft verbindungslos Beispiele: ● ● ● ● HTTP ARP Time Protokoll mit lang andauerndem Dienst (long duration service) – Dienst umfasst eine (unbestimmt) lange Zeitdauer Oft Austausch mehrerer Nachrichten Oft verbindungsorientiert – Beispiele – – ● ● ● Telnet FTP etc. Verteilte Systeme Th Letschert, FH Giessen 23 Serverarchitektur : Einflussfaktor Dienststruktur ● interner Dienst – – – – Dienst wird im Adressraum des Servers ausgeführt geringere Latenzzeit Server in größerer Gefahr (Absturz / Hänger) Bindung: Dienst ● statisch ● ● externer Dienst – – – ● dynamisch zum Server gebunden Dienst wird in eigenem Adressraum ausgeführt (Prozess starten) höhere Latenzzeit Server weniger in Gefahr Beispiel inetd – kann konfiguriert werden Dienste intern oder extern auszuführen – kurze Dienste intern / Lange Dienste extern Verteilte Systeme Th Letschert, FH Giessen 24 Serverarchitektur : Einflussfaktor Dienststruktur ● zustandsloser Dienst (stateless service) – – ● Dienst wird ohne Zustandsinformation im Server ausgeführt, jede Anfrage enthält alle Informationen, die notwendig sind, um sie auszuführen Beispiel: ● einfache Dienste, ● NFS ● HTTP (ohne Cookies, etc.) zustandsbehafteter Dienst (stateful service) – – – Anfragen werden in Zustand ausgeführt, Zustand ● Verbindungs-/Sitzungs -Zustand: Protokoll wickelt FSM (endlichen Automat) ab ● dauerhafter Zustand: Zustand dauerhaft (über die Dauer einer Sitzung hinaus) ● Zustand Absturz-resistent Beispiel: ● Telnet / FTP: Sitzungszustand ● Naming-Services: Absturz-resistent Verteilte Systeme Th Letschert, FH Giessen 25 Serverarchitektur : Einflussfaktor Dienststruktur ● einfacher Dienst (single service server) – – – – ● Server ist auf einen Dienst spezialisiert Jeder Dienst benötigt seinen eigenen Server Erhöhter Ressourcenbedarf / adminstrativer Aufwand Robust multipler Dienst (multi-service server) – – – – Server bedient mehrere Dienste Server bedient mit internem oder externem Dienst Geringerer Rssourcenverbrauch / adminstrativer Aufwand weniger robust Verteilte Systeme Th Letschert, FH Giessen 26 Serverarchitektur: Einflussfaktor Bereitschaft ● Temporärer Server (one shot server) – – – ● Server wird auf ein Anfrage/Sitzung hin erzeugt, bedient nur diese geringer Ressourcenbedarf erhöhte Latenz stehender Server (standing server) – – – Server wird bei Systemstart erzeugt existiert permanent im Adressraum Beispiel Apache Web-Server Verteilte Systeme Th Letschert, FH Giessen 27 Serverarchitektur: Einflussfaktor Verbindungs-/Sitzungskonzept Verbindungen und Sitzungen Verbindung (Connection) – Schicht-4 Konzept – Fehler-/Flusskontrolle erfordert Verbindung (Verbindung = Information über den Zustand der Kommunikation) Sitzung (Session) – Anwendungskonzept – „logische“ Verbindung der Kommpunikationspartner für die Dauer einer Interaktion – OSI-Modell: Session-Layer (so praktisch nie realisiert) Verteilte Systeme Th Letschert, FH Giessen 28 Verbindung / Session : Beispiel HTTP Beispiel HTTP basiert auf TCP-Verbindung Request-Response Kommunikation Session nach HTTPProtokoll= Frage / Antwort reale Session der Anwendung oft länger Anwendung: Session = Einkaufstour HTTP: Session = Request / Response Schicht-4 : TCP Verbindung Schicht-3 : IP / verbindungslos Schicht-2 : Ethernet / verbindungslos Schicht-1 : physikalische Verbindung Verteilte Systeme Th Letschert, FH Giessen 29 Verbindung / Session : Multiplexing Verbindungen und Sitzungen ohne Multiplexing der Sitzungen ● Jede Beziehung Client (Thread) – Service-Provider (Thread) (Session / Sitzung) hat ihre eigene Verbindung mit Multiplexing der Sitzungen ● Eine gemeinsame Verbindung für jede Beziehung Client – Service-Provider Sitzungen Client-Threads Sitzungen Server-Threads Client-Threads TCP-Verbindung Verteilte Systeme Server-Threads TCP-Verbindungen Th Letschert, FH Giessen 30 Serverarchitektur: iterativer Server Iterativer Server ● behandelt eine Anfrage komplett ab bevor die nächste betrachtet wird – WS-Strategie ● Warteschlange für eintreffende Anfragen ● ● ● Ignorieren geeignet für – Dienste mit kurzen Bearbeitungszeiten – unregelmäßig und eher selten angefragte Dienste Struktur for ever: retrieve request perform service send response Verteilte Systeme Th Letschert, FH Giessen 31 Serverarchitektur: iterativer Server ● ● Vorteil – einfach – kein Thread- / Prozess-Overhead Nachteil – eventuell schlechte Nutzung der Plattform-Fähigkeiten mehrere CPU's, asynchroner DMA-Transfer, ... – schlechte Antwortzeiten / Verlust von Anfragen – eventuell Sende-Wiederholung bei Time-out -> Problemverschärfung Verteilte Systeme Th Letschert, FH Giessen 32 Serverarchitektur: Nebenläufiger Server Nebenläufiger Server ● bearbeitet mehrere Anfragen gleichzeitig – ● ● ● Threads (oder Prozesse) Service-Art – single service : ein Dienst – multiple service : verschiedene Dienste Einsatz – I/O-intensive Dienste – lang andauernde Dienste Struktur – Thread (Prozess) pro Verbindung / Session – Thread (Prozess) pro Anfrage Verteilte Systeme Th Letschert, FH Giessen 33 Serverarchitektur: Nebenläufiger Server Struktur: Thread pro Session / Verbindung do for ever { handle = accept new connection; thread = get SessionThread(handle); thread.start(); } Connection-Handler while ( ! finished ) { msg = handle.getMsg(); answer = preform service handle.send(answer) } Protocol / Session=-Handler neuer Client Connection-Handler Client C Client B Client A Protocol/Session-Handler Server Clients Verteilte Systeme Th Letschert, FH Giessen 34 Serverarchitektur: Nebenläufiger Server Struktur: Thread pro Aufgabe: Leader / Follower request = handle.getMsg(); answer = preform service handle.send(answer) if ( ! finished ) { followerThread = Synchronizer.getThread (); followerThread.activate(handle); } do for ever { handle = accept new connection; thread = get LeaderThread(handle); thread.activate(handle); } Worker-Tread Connection-Handler Worker Clients Leader Followers Conn.Handler Synchronzier Leader nimmt die Anfrage an, gibt sie an den Follower weiter der damit zum Leader wird Leader / Followers Muster, synchron Verteilte Systeme Th Letschert, FH Giessen 35 Serverarchitektur: Reaktiver Server Reaktive Server (Reactive Server) ● Verarbeiten mehrere Anfragen / Verbindungen virtuell gleichzeitig ● – ein Thread / Prozess – leichtgewichtiges (Anwendungs-) Multitasking Struktur for ever requestEvents = select() for each event in requestEvents receive request perform service send response Verteilte Systeme Th Letschert, FH Giessen 36 Serverarchitektur: Reaktiver Server ● Vorteil – ● ● kein Thread / Prozess – Overhead Nachteil – kein Ausnutzen von Plattform-Parallelismus – Probleme in einer Verbindung / Verarbeitung (Deadlock / Loop) betrifft den gesamten Server – komplexere Programmierung Programmierung – kurze / zustandslose Dienste: OK – Dienst mit Client-spezifischem Kontext : ● – FSM (endlicher Automat) pro Client verwalten lange andauernde Dienste (z.B. Filetransfer) ● ● blockieren Server oder müssen mit Unterbrechungen (auf Anwendungsebene) realisiert werden (Multitasking auf Anwendungsebene) Verteilte Systeme Th Letschert, FH Giessen 37 Serverarchitektur: Reaktiver Server ● Struktur – – Warte auf I/O-Ereignis an einem von mehreren Handlern (select) Verarbeite Ereignis synchroner Event-Demultiplexer BS: select-System-Call Java: SocketChannel Clients Client-spezifische Kontexte Server Reaktiver Server Verteilte Systeme Th Letschert, FH Giessen 38 Serverarchitektur: Reaktiver Server ● Reaktor-Muster Gestaltung reaktiver Server beobachtet channel bearbeitet I/O-Ereignis z.B. channel Nach Douglas C. Schmidt: Reactor, An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events. Verteilte Systeme Th Letschert, FH Giessen 39 Serverarchitektur: Halb reaktiver / Halb nebenläufiger Server Mischform: Halb reaktiv / Halb nebenläufig (Half-sync / Half async) ● Annahme der Anfragen / Verbindungen reaktiv ● Weiterverarbeitung iterativ Clients Worker IO-Thread Queue Clients Half-Sync / Half-Async mit Task-Queue Worker Leader Followers Half-Sync / Half-Async mit Leader- und Follower-Threads Synchronzier Struktur Verteilte Systeme Th Letschert, FH Giessen 40 Serverarchitektur: Thread-Management Threads erzeugen / aufspannen (Thread Spawning) ● ● Erzeugungs-Strategien – Im Voraus erzeugen (eager spawning) – Bei Bedarf erzeugen (on demand spawning) Im Voraus erzeugte Threads – bei Start erzeugen und in einem Pool platzieren – vermeidet Erzeugungs-/Vernichtungs-Overhead – erfordert Thread-Verwaltung – Größe des Thread-Pools ● ~ Zahl der CPUs ● ~ Last ● ~ dynamisch variabel – – Verteilte Systeme ~ Last ~ aktuelle Länge der Warteschlange der Anfragen Th Letschert, FH Giessen 41 Serverarchitektur: Thread-Management ● Bei Bedarf erzeugen (on demand spawning) – – Vorteil ● Ressourcen-Schonung ● einfacher Nachteil ● Schlecht konfigurierbar ● Performance Probleme ● längere Reaktionszeit Verteilte Systeme Th Letschert, FH Giessen 42 Serverarchitektur: Thread-Management Task-basierte Thread-Zuteilung ● pro Aufgabe ein Thread – IO-Thread Task-1 Task-2 ... Muster z.B.: Pipes and Filters Message – Nachrichten-basierte Thread-Zuteilung ● pro Nachricht / Session / Verbindung ein Thread Message Task-1 Task-2 ... Muster z.B.: Half-sync / Half-Async Message Task-1 Task-2 ... Verteilte Systeme Th Letschert, FH Giessen 43 Server-Architektur: Threading-Strategie Threading-Strategie – ein Thread ● select ● Bedienen der Ereignisse ● andere Aktivitäten – zwei Threads ● select / Ereignise bedienen ● andere Aktivitäten OK bei 1-Prozessor System (welcher Server ist das noch?) – Thread-Pool ● Thread: select ● Thread-Pool: Ereignisse bedienden Anpassbar an System – Schlecht: select blockiert Mehrere Threads / Thread-Pools ● Thread: select ● Thread(-Pool) A: Ereignisklasse A ● Thread(-Pool) B: Ereignisklasse B ● etc. Verteilte Systeme Th Letschert, FH Giessen Ereignisbehandlung konfigurierbar (Wichtigkeit, ...) 44 Server-Architektur: Thread-Erzeugung / Thread-Aufgaben ● Thread-Erzeugung und Thread-Aufgaben – Thread-Erzeugung ● Wann / Wie werden Threads erzeugt – Thread vs. Task ● Welche Aufgaben werden den Threads zugeteilt – Thread vs. I/O Ereignis ● welche(r) Thread(s) bearbeiten I/O-Ereignisse Verteilte Systeme Th Letschert, FH Giessen 45 Plattformen der Verteiltheit Plattformen der Verteiltheit : Einfache Abstraktionen über der Socket-Ebene in Java Verteilte Systeme Th Letschert, FH Giessen 46 Abstraktionen oberhalb der Socket-Ebene in Java Einfache Abstraktionen über der Socket-Ebene in Java: URL Verteilte Systeme Th Letschert, FH Giessen 47 URL Uniform Resource Locator Ein URL lokalisiert Web-Ressourcen: Wo und wie finde ich etwas Beispiele: http://en.wikipedia.org/wiki/Uniform_Resource_Identifier#References shttp://meine.bank.de http://127.0.0.1:8080/factorize?number=1234 ftp://anonymous:[email protected]/downloads mailto://[email protected] URL Aufbau Beispiel Scheme (Protocol) Zugriffsprotokoll http Authority Besitzer www.fh-giessen.de Path lokaler Weg zur Ressource /home/~hg51/index.html Query-String Suche in der Ressource searchString=java Fragment Id (Ref) Index in der Ressource #intro einzelne Bestandteile können fehlen Verteilte Systeme Th Letschert, FH Giessen 48 URL Uniform Resource Locator Syntax / Beispiel (aus RFC 3986): foo://example.com:8042/over/there?name=ferret#nose foo Schema example.com:8042 Authority /over/there Path name=ferret Query nose Fragment Zeichensatz: US-ASCII-Zeichen in der Codierung 'der Umgebung' (umgebender Text / Übertragungs-Protokoll) a .. z, A .. Z, 0 .. 9, -, ., _, ~ (Alphanumerisch, Punkt, Bind-/Unterstrich, Tilde) Zeichen mit besonderer Bedeutung: / ? # [ ] @ : ! $ & ' ( ) * + , ; = % %HEX-Code für alle anderen und die mit besonderer Bedeutung z.B. %25 für % . Sonderformen möglich, z.B. + für ' ' (Blank) Hexcode ist abhängig von der (impliziten) Codierung! Verteilte Systeme Th Letschert, FH Giessen 49 URL in Java java.net Class URL Umschlagklasse für einen URL: java.net.URL mit: Konstruktoren zur Konstruktion getter-/setter-Methoden für die URL-Komponenten Methoden zum Aufbau einer Verbindung zur Ressource Verbindungsaufbau basiert auf Protocol-Handler Protocol-Handler von JVM implementiert (abhängig von der JVM) von der Anwendung zur Verfügung gestellt Verteilte Systeme Th Letschert, FH Giessen 50 URL in Java Beispiel : Test welche Protokoll-Handler stellt die JVM zur Verfügung ? import java.net.MalformedURLException; import java.net.URL; public class JVMProtocolHandler { public static void main(String[] args) { String[] standardProtocols = { "http", "https", "ftp", "mailto", "telnet", "file", "ldap"}; for ( String p : standardProtocols) try { URL url = new URL(p+"://some.where"); System.out.println(p + "\t is OK"); } catch(MalformedURLException e) { System.out.println(p + "\t is not supported"); } } } mögliche Ausgabe Verteilte Systeme Th Letschert, FH Giessen Die Tests auf Wohlgeformtheit der URL sind grob und nicht Protokollspezifisch (z.B. mailto-URL ist nicht korrekt). Die Verfügbarkeit des Handlers wird geprüft. - Kein Test ob die URL erreichbar ist. http https ftp mailto telnet file ldap is is is is is is is OK OK OK OK not supported OK not supported 51 Zugriff auf URL-Ressource java.net Class URL Zugriff auf die Daten der Ressource auf die eine URL zeigt mit Hilfe der URL-Methoden: InputStream openStream(); verbindet sich mit der Ressource liefert InputStream zum Lesen der Daten URLConnection openConnection(); erzeugt Verbindung zur Ressouce zm lesen / schreiben von Daten, Zugriff auf weitere Info URLConnection openConnection(Proxy proxy); erzeugt Verbindung via Proxy Object getContent(); liest Daten der Ressource und erzeugt ein Objekt aus diesen Daten Object getContent(Class[] classes); liest Daten und erzeugt ein Objekt daraus, die Klassen sind Vorschläge für die Klasse des neu erzeugten Objekts Verteilte Systeme Th Letschert, FH Giessen 52 Zugriff auf URL-Ressource / Beispiel openStream public class URLViewer { public static void main(String[] args) { Scanner scan = new Scanner(System.in); String urlString = scan.nextLine(); try { URL url = new URL(urlString); InputStream inS = url.openStream(); int c; while ( (c = inS.read()) != -1 ) { System.out.print((char)c); } } catch (MalformedURLException e) { System.err.println("malformed url "+e); } catch (IOException e) { e.printStackTrace(); } } } erzeugt: Zugriff auf lokalen Tomcat mit der URL-Eingabe: http://127.0.0.1:8080 <!doctype html public "-//w3c//dtd html 4.0 transitional//en" "http://www.w3.org/TR/REC-html40/strict.dtd"> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <title>Apache Tomcat/5.0</title> .... etc ... Verteilte Systeme Th Letschert, FH Giessen 53 Zugriff auf URL-Ressource / Beispiel getContent public class URLContentGetter { public static void main(String[] args) { Scanner scan = new Scanner(System.in); String urlString = scan.nextLine(); Class[] urlTypes = { String.class, Image.class, InputStream.class }; try { URL url = new URL(urlString); Object obj = url.getContent(urlTypes); if ( obj instanceof String ) { System.out.println("String found at "+urlString); } else if ( obj instanceof Image ) { System.out.println("Image found at "+urlString); } else if ( obj instanceof InputStream ) { System.out.println("InputStream found at "+urlString); } else System.out.println("Can not handle "+urlString); } catch (MalformedURLException e) { System.err.println("malformed url "+e); } catch (IOException e) { e.printStackTrace(); } } } Eingabe: file:///home/thomas/Documents/Pictures/applelogo.gif Ausgabe: Image found at file:///home/thomas/Documents/Pictures/applelogo.gif Verteilte Systeme Th Letschert, FH Giessen 54 Zugriff auf URL-Ressource / Beispiel openConnection public class ConnectionOpener { public static void main(String[] args) { Scanner scan = new Scanner(System.in); String urlString = scan.nextLine(); try { URL url = new URL(urlString); URLConnection connection = url.openConnection(); System.out.println(connection.getContentEncoding()); System.out.println(connection.getContentType()); Object obj = connection.getContent( new Class[]{ String.class, InputStream.class}); if ( obj instanceof String ){ System.out.println("String found: "+(String)obj); } if ( obj instanceof InputStream ){ System.out.println("InputStream found "); } } catch (MalformedURLException e) { System.err.println("malformed "+e); } catch (IOException e) { e.printStackTrace(); } } } Verteilte Systeme Eingabe: http://127.0.0.1:8080 Ausgabe: null text/html;charset=ISO-8859-1 InputStream found Th Letschert, FH Giessen 55 Abstraktionen oberhalb der Socket-Ebene in Java Einfache Abstraktionen über der Socket-Ebene in Java: URI Verteilte Systeme Th Letschert, FH Giessen 56 URI Uniform Resource Identifier Ein URI identifiziert eine Ressource Verallgemeinerung der URL URL lokalisiert URI identifiziert die Identifikation kann auch lokalisieren, sie muss aber nicht. Alle URLs sind URIs (aber nicht umgekehrt) URI Verwendung: als URL / zur Identifikation in div. XML-Technologien Beispiele: http://en.wikipedia.org/wiki/Uniform_Resource_Identifier tel:+1-816-555-1212 urn:isbn:0-395-36341-1 urn:oasis:names:specification:docbook:dtd:xml:4.1.2 URI Aufbau Scheme Name Beispiel : Schema-spezifischer Teil Verteilte Systeme urn : oasis:names:specification:docbook:dtd:xml:4.1.2 Th Letschert, FH Giessen 57 URI Uniform Resource Identifier URI Schemes Beispiele (http://www.iana.org/assignments/uri-schemes.html) URI Scheme Description Reference acap application configuration access protocol [RFC2244] cid content identifier [RFC2392] dns Domain Name System [RFC4501] fax fax [RFC3966] file Host-specific file names [RFC1738] ftp File Transfer Protocol [RFC1738] http Hypertext Transfer Protocol [RFC2616] https Hypertext Transfer Protocol Secure [RFC2818] imap internet message access protocol [RFC2192] info Information Assets with Identifiers in Public Namespaces [RFC4452] ldap Lightweight Directory Access Protocol [RFC4516] mailto Electronic mail address [RFC2368] news USENET news [RFC1738] nfs network file system protocol [RFC2224] nntp USENET news using NNTP access [RFC1738] pop Post Office Protocol v3 [RFC2384] tel telephone [RFC3966] telnet Reference to interactive sessions [RFC4248] urn Uniform Resource Names [RFC2141] Verteilte Systeme Th Letschert, FH Giessen 58 URI / URL / URN URI Uniform: Syntax entspricht RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax. Resource: Irgendetwas Identification: Identifizieren / Lokalisieren / Holen URL URN URI Entwicklung: Identifizieren / Lokalisieren Ausgangskonzept URL: Identifizieren / Holen URI : Verallgemeinerung von URL URN: Uniform Resource Name Identifikation einer Ressource unabhängig von Ort und Zugriffsmethode/Möglichkeit („Ein http-URI ist ein URL“) URN wird (eventuell) abgebildet auf URL-1, URL-2, ... URI seit 2001 (http://www.w3.org/TR/uri-clarification) URI ist Oberbegriff URL informales Konzept lokalisierbarer Ressourcen („Klick-bar“) URN ist Schema (hierachisch aufgebaut) (urn:xx:yy:zz) Resolution (Auflösung): nicht global geklärt (dns-URIs haben global definierte Auflösung, andere nicht) Verteilte Systeme Th Letschert, FH Giessen 59 URI in Java java.net Class URI java.net.URI Umschlagklasse für URIs (konstruieren / analysieren) Vergleich zur java.net.URL eher konform zu aktuellen WEB-Standards URI identifiziert nur: kein (direkter) Verbindungsaufbau relative und absolute URIs möglich Verteilte Systeme Th Letschert, FH Giessen 60 URI / URL / URLConnection Idee Schema -> Protokoll -> Protokoll-Handler Klassen „In the early days of Java, Sun promised that protocols could be installed at runtime from the server that used them. [...] However, the loading of prtocol handlers from web sites was never implemented, and Sun doesn't talk much about it anymore. Elliotte Rusty Harold in Java Network Programming, O'Reilly URL / URLStreamHandler / URLConnection ... definieren zusammen Protokoll-Handler Bewertung OK für vordefinierte Schemata (Protokolle) speziell für HTTP GET / POST (?) Neue Protokolle ~> müssen JVM bekannt gegeben werden Umständliche / Verwirrende API, kaum Mehrwert gegen Sockets Kaum genutzt Neue / Eigene Protokolle ~> Socket-Kommunikation Verteilte Systeme Th Letschert, FH Giessen 61 URI in Java / Beispiel get-Abfrage Verbindungsaufbau via URL public class URIViewer { public static void main(String[] args) { try { URI uri = new URI( "http", //Scheme null, //Authority "192.168.187.196", //Host 8080, //Port "/hg51WebApp/GetFactorizer", //Path "zahl=12&submit=los+gehts", //Query null //Fragment ); URL url = uri.toURL(); InputStream inS = url.openStream(); int c; while ( (c = inS.read()) != -1 ) { System.out.print((char)c); } } catch (MalformedURLException e){ e.printStackTrace(); } catch (URISyntaxException e) { e.printStackTrace(); } catch (IOException e) { e.printStackTrace(); } } } Verteilte Systeme Th Letschert, FH Giessen 62 URI in Java / Beispiel get-Abfrage / HTML als HTML anzeigen public class URIViewer { public static void main(String[] args) { try { URI uri = new URI( "http",null,"192.168.187.196", 8080,"/hg51WebApp/GetFactorizer", "zahl=12&submit=los+gehts",null); URL url = uri.toURL(); InputStream inS = url.openStream(); byte[] byteA = new byte[1024]; int c; int i = 0; while ( (c = inS.read()) != -1 ) { byteA[i++] = (byte)c; } JEditorPane jp = new JEditorPane(); jp.setContentType("text/html"); jp.setText(new String(byteA, 0, i, "UTF8")); JFrame jf = new JFrame("Result"); jf.setContentPane(jp); jf.setSize(512, 254); jf.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); jf.setVisible(true); } catch (MalformedURLException e){ e.printStackTrace(); } catch (URISyntaxException e) { e.printStackTrace(); } catch (IOException e) { e.printStackTrace(); } } } Verteilte Systeme Th Letschert, FH Giessen 63