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