CS5001 Verteilte Systeme

Transkript

1 Prof. Dr. Th. Letschert CS5001 Master of Science (Informatik) - Netzwerkprogrammierung - Th Letschert FH Gießen-Friedberg

2 Plattformen der Verteiltheit Netzwerk-Programmierung : als interagierende Prozesse Themen: ein Blick zurück Socket-API Server-Struktur einfache Abstraktionen oberhalb der Socket-Ebene in Java 2

3 Plattformen der Verteiltheit Plattformen der Verteiltheit : ein Blick zurück 3

4 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 kommerziell (fast) bedeutungslos Einsatz (fast) nur in Fern-Netzen von Universitäten und Forschungsinstituten 4

5 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 5

6 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 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,... 6

7 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 7

8 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 8

9 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 9

10 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 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 10

11 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 11

12 Plattformen der Verteiltheit Plattformen der Verteiltheit : als interagierende Prozesse 12

13 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 13

14 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 14

15 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 Token-Ring Seriell 15

16 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 16

17 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,... 17

18 Prozesse / Threads: Nebenläufigkeit in Komponenten Prozesse/ Threads 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 18

19 als interagierende Prozesse als interagierende Prozesse: Struktur der Komponenten / Server 19

20 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 20

21 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 21

22 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 22

23 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. 23

24 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 24

25 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 25

26 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 26

27 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 27

28 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) 28

29 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 29

30 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 Server-Threads TCP-Verbindungen 30

31 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 31

32 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 32

33 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 33

34 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 34

35 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 35

36 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 36

37 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) 37

38 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 38

39 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. 39

40 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 40

41 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 ~ Last ~ aktuelle Länge der Warteschlange der Anfragen 41

42 Serverarchitektur: Thread-Management Bei Bedarf erzeugen (on demand spawning) Vorteil Ressourcen-Schonung einfacher Nachteil Schlecht konfigurierbar Performance Probleme längere Reaktionszeit 42

43 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

44 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. Ereignisbehandlung konfigurierbar (Wichtigkeit,...) 44

45 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 45

46 Plattformen der Verteiltheit Plattformen der Verteiltheit : Einfache Abstraktionen über der Socket-Ebene in Java 46

47 Abstraktionen oberhalb der Socket-Ebene in Java Einfache Abstraktionen über der Socket-Ebene in Java: URL 47

48 URL Uniform Resource Locator Ein URL lokalisiert Web-Ressourcen: Wo und wie finde ich etwas Beispiele: shttp://meine.bank.de URL Aufbau Beispiel Scheme (Protocol) Zugriffsprotokoll http Authority Besitzer 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 48

49 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! 49

50 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 50

51 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 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

52 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 52

53 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: <!doctype html public "-//w3c//dtd html 4.0 transitional//en" " <html> <head> <meta http-equiv="content-type" content="text/html; charset=iso "> <title>apache Tomcat/5.0</title>... etc... 53

54 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 54

55 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(); } } } Eingabe: Ausgabe: null text/html;charset=iso InputStream found 55

56 Abstraktionen oberhalb der Socket-Ebene in Java Einfache Abstraktionen über der Socket-Ebene in Java: URI 56

57 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: tel: urn:isbn: urn:oasis:names:specification:docbook:dtd:xml:4.1.2 URI Aufbau Scheme Name Beispiel : Schema-spezifischer Teil urn : oasis:names:specification:docbook:dtd:xml:

58 URI Uniform Resource Identifier URI Schemes Beispiele ( 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] 58

59 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 ( 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) 59

60 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 60

61 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 61

62 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 " ", //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(); } } } 62

63 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," ", 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(); } } } 63