Verteilte Systeme - Proteus

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 : ein Blick zurück 


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: 

● X25 

– Protokoll in Novell-Netzen, bis Mitte der 1990er Markt-beherrschend 

– basierend auf Xerox Internetworking Protokollen 

– geroutetes Protokoll ähnlich zu TCP/IP 

– 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 


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 


Plattformen der Verteiltheit – 1980er 

Anwendungsplattform 

Beispiel: Datenpaket unter IPX empfangen 

● Interrupt-Handler schreiben (in Assembler) 

– 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 

● Empfangs-Routine in C schreiben 

– System-Kontext: Kein User-Stack 

– Grobe Analyse des ECB 

– Ablage der Daten im Userspace 

● Anwendungs-Programm 

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


Plattformen der Verteiltheit – Ende 1980er 

Plattformen der Verteiltheit ~ Ende 1980-er 

– Protokolle 

● BS mit integriertem Protokoll-Stack 

– 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 

● installierbare Protokolle 

– 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 


Plattformen der Verteiltheit – Frühe 1990er 

Plattformen der Verteiltheit ~ Frühe 1990-er 


● BS mit integriertem Protokoll-Stack 

– 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 

● installierbare Protokolle 

– 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 


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 


Plattformen der Verteiltheit – Mitte 1990er 

Plattformen der Verteiltheit ~ Mitte 1990-er 


● 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 

● z.B. OSI: Presentation- / Session-Layer 

– Unterstützung durch spezielle Dienste 

● z.B. Namensdienste 

– Standard-Code-Bausteine (generiert / bereit gestellt) 

● z.B. RPC 

– Bereitstellung von Standardlösungen in Bibliotheken 

● z.B. XDR 

– Integration in Programmiersprachen 

Middleware, 

SOA, 

.... 


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: 

– Fortsetzung der Integration in das BS (transparente Verteiltheit) 

● Praxis: Beginn der Middleware 

– Bibliotheken 

– Generierungs-Werkzeuge 

– Standard-Dienste 

zur Unterstützung der Entwickler / Entlastung von Standard- 

Aufgaben 

Nicht erfolgreich 

(Warum?) 



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 


Protokolle: OSI / Internet 

Schicht 7 

Schicht 6 

Schicht 5 

Schicht 4 

Schicht 3 

Schicht 2 

Schicht 1 

Protokoll - (De-) Multiplexing 

Anwendungs-Protokolle 

Session/Presentation -> Middleware-Protokolle 

Internet-Protokolle 

ISO/OSI 

Protokolle 

Rahmen- / Paket-Struktur 


Schicht-4 Service Access Point (SAP) : Sockets 

System 

FTP 

Anwendungen 

... 

SMTP 

verbindungsorientiert 

P-ID 

Ethernet 

Port 

TCP P-ID UDP 

IP 

TFTP 

verbindungslos 

Token-Ring Seriell 

Verteilte Systeme Th Letschert, FH Giessen 15 

... 

NFS 

Socket-API 

(De-)Multiplexing

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 


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

● Server: 

autom: ferne Adr 

Komminikation 

C# (Namespace system.net) 

● low-level: 

● Socket 

● IPEndPoint, IPAddress,... 

● high-level: 

● TCP-Client 

● TCP-Listener 

andere: Perl, TCL, Python, ... 

als Klassenbibliotheken 

z.B. C++: ACE (Adapitve 

Communication 

Environment) 

etc.: diverse andere 


Prozesse / Threads: Nebenläufigkeit in Komponenten 

Verteilte Systeme 

bestehen aus Komponenten, 

die durch Nachrichten 

kommunizieren 

Komponenten sind in der Regel 

nebenläufige Systeme, die 

aus Threads und/oder 

Prozessen bestehen 

Prozesse/ 

Threads 

Nebenläufige 

Komponente 

Verteiltes System 



Verteilte Systeme als interagierende Prozesse: 

Struktur der Komponenten / Server 


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 


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 


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 

● 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 

synchrones 

Protokoll 

asynchrones 

Protokoll 


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. 


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 

● dynamisch zum Server gebunden 

● externer Dienst 

– 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 



● 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 



● 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 


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 


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) 


Verbindung / Session : Beispiel HTTP 

Beispiel HTTP 

basiert auf TCP-Verbindung 

Request-Response 

Kommunikation 

Session nach HTTP- 

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


Verbindung / Session : Multiplexing 

Verbindungen und Sitzungen 

Client-Threads 

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 Sitzungen 

TCP-Verbindung 

Server-Threads 

Client-Threads Server-Threads 

TCP-Verbindungen 


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 


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 


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 



Struktur: Thread pro Session / Verbindung 

do for ever { 

handle = accept new connection; 

thread = get SessionThread(handle); 

thread.start(); 

} 

Client C 

Client B 

Client A 

Clients 

while ( ! finished ) { 

msg = handle.getMsg(); 

answer = preform service 

handle.send(answer) 

} 

Connection-Handler Protocol / Session=-Handler 

neuer 

Client 

Protocol/Session-Handler 

Connection-Handler 

Server 



Struktur: Thread pro Aufgabe: Leader / Follower 

do for ever { 

handle = accept new connection; 

thread = get LeaderThread(handle); 

thread.activate(handle); 

} 

Connection-Handler 

Clients 

Conn.- 

Handler 

Worker 

Leader 

Followers 

Synchronzier 

Leader / Followers Muster, synchron 

request = handle.getMsg(); 

answer = preform service 

handle.send(answer) 

if ( ! finished ) { 

followerThread = Synchronizer.getThread (); 

followerThread.activate(handle); 

} 

Worker-Tread 

Leader nimmt die Anfrage an, 

gibt sie an den Follower weiter 

der damit zum Leader wird 


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 



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



● Struktur 

– Warte auf I/O-Ereignis an einem von mehreren Handlern (select) 

– Verarbeite Ereignis 

Clients 

synchroner Event-Demultiplexer 

BS: select-System-Call 

Java: SocketChannel 

Server 

Reaktiver Server 

Client-spezifische 

Kontexte 



● Reaktor-Muster 

Gestaltung reaktiver Server 

beobachtet 

channel 

z.B. channel 

bearbeitet 

I/O-Ereignis 

Nach Douglas C. Schmidt: Reactor, An Object Behavioral Pattern for 

Demultiplexing and Dispatching Handles for Synchronous Events. 


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 

Clients 

IO-Thread 

Worker 

Queue 

Leader 

Followers 

Synchronzier 

Worker 

Half-Sync / Half-Async 

mit Task-Queue 

Half-Sync / Half-Async 

mit Leader- und Follower-Threads 

Struktur 


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 



● Bei Bedarf erzeugen (on demand spawning) 

– Vorteil 

● Ressourcen-Schonung 

● einfacher 

– Nachteil 

● Schlecht konfigurierbar 

● Performance Probleme 

● längere Reaktionszeit 



● Task-basierte Thread-Zuteilung 

– pro Aufgabe ein Thread 

IO-Thread Task-1 Task-2 

Message 

– Nachrichten-basierte Thread-Zuteilung 

● pro Nachricht / Session / Verbindung ein 

Thread 

Message 

Message 

Task-1 

Task-2 

... 

Task-1 

Task-2 

... 

Verteilte Systeme Th Letschert, FH Giessen 43 

... 

Muster z.B.: 

Pipes and Filters 

Muster z.B.: 

Half-sync / Half-Async

Server-Architektur: Threading-Strategie 

Threading-Strategie 

– ein Thread 

● select 

● Bedienen der Ereignisse 

● andere Aktivitäten 

– zwei Threads 

● select / Ereignise bedienen 

● andere Aktivitäten 

– Thread-Pool 

● Thread: select 

● Thread-Pool: Ereignisse bedienden 

– Mehrere Threads / Thread-Pools 

● Thread: select 

● Thread(-Pool) A: Ereignisklasse A 

● Thread(-Pool) B: Ereignisklasse B 

● etc. 

Schlecht: select blockiert 

OK bei 1-Prozessor System 

(welcher Server ist das noch?) 

Anpassbar an System 

Ereignisbehandlung 

konfigurierbar (Wichtigkeit, ...) 


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 



Plattformen der Verteiltheit : 

Einfache Abstraktionen über der Socket-Ebene in Java 


Abstraktionen oberhalb der Socket-Ebene in Java 

Einfache Abstraktionen über der Socket-Ebene in Java: 

URL 


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:anonymous@fileserver.irgend.wo/downloads 

mailto://admin@mailserv.fh-giessen.de 

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 


URL Uniform Resource Locator 

Syntax / Beispiel (aus RFC 3986): 

foo://example.com:8042/over/there?name=ferret#nose 

Zeichensatz: 

foo Schema 

example.com:8042 Authority 

/over/there Path 

name=ferret Query 

nose Fragment 

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! 


URL in Java 

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 

java.net Class URL 


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

https is OK 

ftp is OK 

mailto is OK 

telnet is not supported 

file is OK 

ldap is not supported 


Zugriff auf URL-Ressource 

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 

java.net Class URL 


Zugriff auf URL-Ressource / Beispiel openStream 

public class URLViewer { 


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 

 

 

 

 

Apache Tomcat/5.0 

.... etc ... 


Zugriff auf URL-Ressource / Beispiel getContent 

public class URLContentGetter { 




Class[] urlTypes = { String.class, Image.class, InputStream.class }; 

try { 


} 

} 

Eingabe: 

Ausgabe: 

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

file:///home/thomas/Documents/Pictures/applelogo.gif 

Image found at file:///home/thomas/Documents/Pictures/applelogo.gif 


Zugriff auf URL-Ressource / Beispiel openConnection 

public class ConnectionOpener { 




try { 


} 

} 

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


Eingabe: 

Ausgabe: 

http://127.0.0.1:8080 

null 

text/html;charset=ISO-8859-1 

InputStream found 


Abstraktionen oberhalb der Socket-Ebene in Java 

Einfache Abstraktionen über der Socket-Ebene in Java: 

URI 


URI Uniform Resource Identifier 

Ein URI identifiziert eine Ressource 

Verallgemeinerung der URL 

Beispiele: 

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 

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 Beispiel 

Scheme Name : urn : 

Schema-spezifischer Teil oasis:names:specification:docbook:dtd:xml:4.1.2 


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] 


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) 


URI in Java 

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 

java.net Class URI 


URI / URL / URLConnection 

Idee 

Schema -> Protokoll -> Protokoll-Handler 

Klassen 

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 

„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 


URI in Java / Beispiel get-Abfrage Verbindungsaufbau via URL 

public class URIViewer { 


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


int c; 


System.out.print((char)c); 

} 

} catch (MalformedURLException e){ e.printStackTrace(); 

} catch (URISyntaxException e) { e.printStackTrace(); 


} 

} 


URI in Java / Beispiel get-Abfrage / HTML als HTML anzeigen 

public class URIViewer { 


try { 

URI uri = new URI( "http",null,"192.168.187.196", 

8080,"/hg51WebApp/GetFactorizer", 

"zahl=12&submit=los+gehts",null); 

URL url = uri.toURL(); 


byte[] byteA = new byte[1024]; 

int c; int i = 0; 


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


} 

}

Verteilte Systeme - Proteus

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?