Vorlesung Verteilte Anwendungen Koordinaten Einordnung der

Vorlesung
Verteilte Anwendungen
Koordinaten
Teil 2: Programmierung verteilter Anwendungen
Thorsten Strufe
CC 440
Tel.
03677/69-4552
Email
[email protected]
http://eris.prakinf.tu-ilmenau.de/
Thorsten Strufe
Technische Universität Ilmenau
Fakultät für Informatik und Automatisierung
Institut Praktische Informatik und Medieninformatik
Fachgebiet Telematik
0 0
0
0 0
Einordnung der Vorlesung
•
Telematik 1&2 Grundlagen
•
•
•
•
Rechnernetze
Öffentliche Netze
Kommunikationssoftware
Verteilte Anwendungen
–
–
–
–
Ziele der Vorlesung
•
Wissen über die Programmierung verteilter Anwendungen
– Einführung in die Thematik
– Abklopfen des Umfeldes
– Betrachtung besonderer Aspekte
•
Sicherheit in Rechnernetzen
Netzwerkmanagement
Hochleistungskommunikationssysteme
Multimediale Informationssysteme
0 0
Vorstellung von Technologien für verteilte Anwendungen
–
–
–
–
–
–
–
Interprozesskommunikation
Sockets (als Grundlage)
RPC, DCE (aus der Geschichte)
RMI
Middleware-Plattformen (CORBA, J2EE, .NET)
Komponentenmodelle (CORBAComponents, EJB)
Web-Services
0 0
Literatur
•
•
•
•
•
•
•
•
•
•
Inhalt der Vorlesung
Krüger, Reschke. Lehr- und Übungsbuch Telematik. Fachbuchverlag Leipzig im Carl
Hanser Verlag, 3. Auflage, 2004
W. Richard Stevens. Programmieren von Unix-Netzen. Carl Hanser und Prentice-Hall,
1992
George Coulouris, Jean Dollimore, Tim Kindberg: Distributed Systems, Concept and
Design. Addison Wesley, 2002
Andrew S. Tanenbaum, Maarten van Steen: Distributed Systems, Principles and
Paradigms. Prentice Hall, 2002
Marko Boger: Java in verteilten Systemen. dpunkt-Verlag, 1999
•
•
•
•
•
•
Motivation und Einführung
Ausgewählte Aspekte
Client/Server-Modell
P2P-Modell
Sockets
Netzwerktransparente Entwicklung
•
Tools und RE‘s
•
Verteilte Objektsysteme
•
Verteilte Komponentensysteme
–
–
Alexander Schill. Das OSF Distributed Computing Environment: Grundlagen und Anwendung.
Springer, 1997
Troy Bryan Downing. Java RMI: remote method invocation. IDG Books Worldwide, 1998
Jens-Peter Redlich. CORBA 2.0: praktische Einführung für C++ und Java. Addison-Wesley, 1996
Siegel, Jon. CORBA 3 Fundamentals and Programming. Wiley, 2000
Andreas Vogel, Madhavan Rangarao: Programming with Enterprise JavaBeans, JTS and OTS:
building distributed transactions with Java and C++. Wiley, 1999
u.v.m.
–
–
–
•
RPC, RMI
CORBA (Object Management Group)
Enterprise JavaBeans (EJB) / J2EE
CORBAComponents
Microsoft „.NET“
Web Services (SOAP, XML-based RPC)
0 0
0 0
Grober Ablauf der Veranstaltung
•
1. Veranstaltung
•
– Grundlagen
– Adressierung
– Client/Server und P2P-Modell
•
•
5. Veranstaltung
– Rechnerübung CORBA
•
Einführung Middleware
RPC
RMI
Grundlagen verteilter Objektsysteme
P2PComputing
Webapps
Marktplätze
VA
Online-Banking
Online-Buchung
•
7. Veranstaltung
•
8. Veranstaltung
Meta-/ Distributed-/
Internet-Computing
Plattformen
Ressourcenanbindung
Geldautomaten
EAI
– .Not
3. Veranstaltung
– Rechnerübung RPC
– Klausur! ☺
Steuern,
Messen, Regeln
SOAP
DSM
#Cruncher/
Cluster
Vert.
BS
Vert.
Filesysteme
J2EE
Konnektoren
CORBA
„.NET“
„Agentensysteme“
Backoffice
DB-Anbindung
Flugbuchung
0 0
Verteilte
Systeme
6. Veranstaltung
– Verteilte Komponentenmodelle
– EJB/Corba Components
– Webservices
• CORBA
•
Portale
– Rechnerübung RMI
2. Veranstaltung
–
–
–
–
4. Veranstaltung
Anwendungsfelder verteilter Anwendungen
SCM
InformationsKooperationssysteme
0 0
Was ist eigentlich verteilt?
•
Definition: Verteilte Anwendung
Daten
– Aus administrativen Gründen oder der Zuordnung zu einem Nutzer oder einer
Quelle (Aktualisierung!)
– Aufgrund zentraler Datenhaltung (DB-System)
•
Ausführung
– Parallele Ausführung auf mehreren Prozessoren/Rechnern
– Auf unterschiedlichen Rechnertypen/Rechnern mit Zugriff auf spezielle Peripherie
•
Benutzer
Der Begriff der Verteiltheit ist sowohl auf Software als auch auf Hardware
beziehbar.
Eine verteilte Anwendung besteht aus mehreren nebenläufigen, untereinander
kommunizierenden Prozessen, die gemeinsam die Leistung der verteilten
Anwendung erbringen.
•
Beispiele verteilter Anwendungen:
Bank-und Buchungssysteme, Dienstleistungssysteme,
Informations- und Konferenzsysteme, (Netz-) Managementsysteme
an unterschiedlichen Standorten oder mit unterschiedlicher Funktion können
gemeinsamen Zugriff auf gleiche Daten haben
0 0
0 0
Architekturmodelle verteilter Anwendungen
Definition: Verteilte Systeme
Peer-to-Peer
Client/Server
Nach Lamport: ein verteiltes System ist ein System, in dem ich durch den Ausfall
einer Komponente, von der ich vorher nichts wusste, in meiner Arbeit
beeinträchtigt werde.
Internet
Ein verteiltes System ist ein System, dessen Daten und dessen Funktionskomponenten auf mehrere, zu einem Netz zusammengeschlossene Rechner
verteilt sind.
Praktisch existieren in einem verteilten System mehrere nebenläufige Prozesse
(verteilt auf Rechnerknoten), die über das Netzwerk interagieren (echt parallel
im Gegensatz zu nebenläufigen Prozessen auf einem Host mit einer CPU, die
quasiparallel abgearbeitet werden).
Cluster
Verteiltes Rechnen
execD
mgr.
Internet
Mehrfache Existenz verschiedener autonomer, physisch und räumlich getrennter
Funktionseinheiten, an welche Aufgaben delegiert werden
qmast.
Server
RZ
Kunden
0 0
0
RZ
Client
0 0
Aufgaben, Anforderungen und Ziele verteilter
Anwendungen
•
•
•
Aufgaben: Dezentralisierung von Programmsystemen
– Dezentralisierung der Datenverwaltung
– Dezentrale Verarbeitung von Daten
– Entfernter Zugriff auf Daten
– Entfernter Eingriff auf die Datenverarbeitung
– Unterstützung der Anwenderkommunikation
Anforderungen:
– Zuverlässigkeit
– Geschwindigkeit
– Transparenz
– Sicherheit
Ziele:
– Ressourcen-Sharing
– Informations-Sharing
Voraussetzungen zur Erstellung verteilter
Anwendungen
•
•
•
Physikalische Vernetzung
Unterstützung durch Betriebssysteme und
Einbindung in Kommunikationssysteme (das bedeutet:)
– Einbindung in Netzwerkumgebung (z.B. Internet → TCP/IP)
– Zugang zu anwenderprogrammierbaren Netz-Interfaces (API‘s)
– möglichst multitaskingfähiges Betriebssystem oder Programmierumgebung,
die Quasi-Parallelität unterstützt
– Kommunikations- und Betriebssysteme ermöglichen:
• Datentransfer: Interprozeßkommunikation zwischen entfernten
Prozessen
• Verwaltung: Management logischer Kommunikationsverbindungen der
Prozesse
Verteilte Anwendungen stellen auf Basis der Netzwerke spezielle Dienste bereit
0 0
0 0
Strukturmodell für Host-Systeme im Netzwerk
Modelle Verteilter Anwendungen
im Vergleich
Applikationen
Verteilte Anwendungen
UI
application
App
NetzwerkManagement
application
Plattformen für verteilte Anwendungen
Middleware
(Verteilte Systeme)
DB
presentation
session
App.-protokolle
transport
Transportschicht
Betriebssystem
Netzwerk
Protokolle
Betriebssystem
Hardware
3-Tier
Hardware
0 0
0 0
internet
transport
network
Data link
Network
interface
TCP/IP
physical
ISO/OSI
Beschreibungsmodelle
Einstieg ins Netzwerken
für verteilte Anwendungen / Systeme
•
Architekturmodelle (Systemarchitekturen)
Grundlagen:
•
Fundamentale Modelle:
„Netzwerken“
–
–
–
–
–
–
–
–
–
•
Kommunikations-/ Interaktionsmodell
Rollenmodell
Informationsmodell
Funktionsmodell
Zeitmodell
Fehlermodell
Sicherheitsmodell
Namensmodell
Datenmodell
Adressieren
Rechner, Prozess
FG BS: (Organisations-/Informations-/Kommunikations-/Funktionsmodell)
0 0
0 0
Belange der Netzwerke und Betriebssysteme
Hierarchischer Adressraum im Internet
Jeder Prozeß, der an der Kommunikation in einem Netz teilhaben will, muß global in der
gesamten Netzstruktur (z.B. Internet) eindeutig adressierbar sein.
3 Unterteilungsstufen Erleichterung
–
–
–
Das bedeutet:
–
–
der Host muß eine eindeutige Adresse erhalten und
der Prozeß im Host erhält einen eindeutigen Identifikator.
Der Prozessidentifikator allein reicht nicht aus, da sie über Hostgrenzen hinaus nicht eineindeutig sind.
Die eindeutige Adressvergabe für jede Netz-Interface-Karte erfolgt über den Hersteller.
Adressierung des Hosts im Subnetz
(1)
(2)
Diese Adresse ist für die Netzwerkverwaltung ungeeignet.
(3)
hierarchische Staffelung für die
des Netzwerkmanagements
globale Netzadresse
Subnetzadresse
Host-Adresse
Zentrale Vergabe der globalen Netzadresse (für Firmen oder
Institutionen) durch internationales Gremium
Administrative Vergabe der Subnetzadresse von lokaler
(firmeninterner) Netzwerkadministration
Administrative Vergabe der Host-Adresse im Subnetz
Es wird ein hierarchischer Adressraum mit logischen Adressen eingeführt. (IP!)
0 0
0 0
Adressklassen im Internet (IP)
(Wird so nicht mehr gemacht!)
•
•
Semantik der Adressklassen
Adresslänge 32 Bit
Unterteilung in 5 Klassen
– Die ersten Bits dienen der Unterscheidung der Adressklasse.
K
l
a
s
s
e
•
0
2
1
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
• (Hostadresse für das Routing im Internet nicht entscheidend)
A 0 7 Bit Netz ID
B 1 0
E 1 1 1 1 0
8 Bit Host ID
•
28 Bit Multicast-Adresse
27 Bit (für die Zukunft reserviert)
0 0
0
Klassenlose Adressierung:
Classless Inter-Domain Routing (CIDR)
um die interne Strukturierung von IP-Netzwerken effektiver zu unterstützen
•
VLSM bedeutet, daß der erweiterte Netzwerkpräfix innerhalb des Netzwerkes
einer Einrichtung eine unterschiedliche Länge haben kann.
•
Der Einsatz von Subnetzmasken variabler Länge ermöglicht eine effizientere
Ausnutzung des vorgegebenen Adreßraumes, weil der zuständige
Netzwerkadministrator die Länge des erweiterten Netzwerkpräfix flexibler an die
unterschiedlichen Anforderungen der einzelnen Teilnetze anpassen kann.
Weiterhin besteht die Möglichkeit, mit Hilfe der Subnetzmasken variabler Länge
mehrstufige Hierarchien von Subnetzen einzuführen und damit die Größe der
Routingtabellen im Backbone-Bereich des Netzwerkes einer Einrichtung zu
reduzieren. Dieses Vorgehen wird auch als Aggregation von Routen bezeichnet.
0 0
Adressierung in Punktnotation
Namen: nero.prakinf.tu-ilmenau.de
punktierte Dezimaldarstellung: 141.24.32.22
0 0
Variable Length Subnet Masks
•
Besonderheiten von Klasse B
– Zusätzliches Level in der Netzadressierung:
Von der Host ID werden Bits für die Subnetzadressierung abgeteilt.
Netzwerk ID Subnetz ID Host ID
16 Bit Host ID
21 Bit Netz ID
D 1 1 1 0
•
24 Bit Host ID
14 Bit Netz ID
C 1 1 0
•
Die Kennung in den ersten Bits ist wichtig für das Routing, da
– die Adreßklasse ermittelt wird und
– sich aus der Adressklasse die für die Netzadresse relevanten Bytes ergeben.
3
mehr Flexibilität bei der Vergabe von Adressen
Die Vergabe einer 32-Bit-Netzwerkadresse ist dann immer mit einer
korrespondierenden 32-Bit-Maske verbunden, deren auf 1 gesetzte Bits, ähnlich
wie bei der Subnetz-Maske, die Anzahl der für die Identifikation des Netzwerks
reservierten Bits bestimmen.
•
Die Angabe der 32-Bit-Maske erfolgt als Präfixlänge im Zusammenhang mit der
Netzwerkadresse.
•
So kann zum Beispiel das Klasse-B-Netz 128.1.0.0 auch durch eine klassenlose
Netzwerkadresse mit einer 32-Bit-Maske von 255.255.0.0 in der Form
128.1.0.0/16 spezifiziert werden.
Die Verwendung klassenloser Adressen erfordert auch klassenloses Routing.
0 0
Prozeßidentifikatoren
•
Da nicht alle Prozesse eines Hosts Kommunikationsbeziehungen unterhalten, die
Prozeß-ID‘s des Betriebssystems nicht geeignet sind (dynamische Vergabe,
Kommunikationsbelange nicht berücksichtigt), werden Portnummern
(Transportschichtselektoren) vergeben.
•
Generelle Nutzung von 2 Byte langen Portnummern
•
Zwei Arten von Ports:
–
Portzuweisung
•
Statische Portvergabe
Vom Programmierer wird die zu nutzende Portnummer im Programm festgelegt.
Zu jedem Programmaufruf wird dieselbe Portnummer genutzt. Ist die
Portnummer bereits vergeben, so wird das Programm vom System abgebrochen
(oder blockiert), da jede Portnummer nur exklusiv von aktiven Prozessen genutzt
werden kann.
•
Dynamische Portvergabe
Das Hostsystem weist dem Prozeß eine freie (die nächste freie) Portnummer zu.
Somit können keine Programmunterbrechungen wegen Mehrfachanforderung ein
und derselben Portnummer auftreten. Neben dem Vorteil der flexiblen
Portvergabe hat die dynamische Portvergabe den entscheidenden Nachteil, daß
vor Kommunikationsaufnahme zwischen zwei Prozessen die Portnummern
bekannt gegeben werden müssen.
Well Known: allgemein bekannte Portnummern
Sie sind global eindeutig für bestimmte Standard-Netzwerkdienste festgelegt.
Ephemeral (short lived): kurzzeitig vergebene Ports
Die Portnummer wird einem Prozeß für seine aktive Lebenszeit „geliehen“. Nachdem
der Prozeß beendet ist, kann die Portnummer an einen neuen Prozeß vergeben werden.
–
In der Praxis werden beide Verfahren parallel nebeneinander genutzt. Das zugehörige
Laufzeitsystem überprüft, ob eine Portnummer schon vergeben ist und übergibt dem
anfordernden Prozeß eine beliebige oder die gewünschte Portnummer.
0 0
0 0
Binding
Portaufteilung bei TCP/IP bzw. UDP/IP
•
Reserviert: Portnummer 1 - 1023
–
davon:
Portnummer 1 - 511
für spezielle global zugängliche Dienste
Portnummer 512 - 1023
nur mit Superuser-Rechten zuweisbar
•
Automatisch vom System zugewiesen: 1024 - 5000
•
Hinweis:
gesamter Portnummernbereich exklusiv für TCP sowie
exklusiv für UDP
Beispiel: Portzuweisung für globalen Dienst
–
•
FTP
•
Als Binding bezeichnet man die vollständige Ermittlung der Adresse (InternetAdresse + Portnummer) des entfernten Kommunikationspartners. Der Client
ermittelt die Adresse des gewünschten Server-Prozesses.
•
Vor dem Austausch von Nachrichten muß der Client-Prozeß eine BindingAktivität ausführen, die aus zwei Stufen besteht:
Portzuweisung mit „normalen“ Nutzerrechten möglich
Port Nr. 21/TCP (Commands)
Port Nr. 20/TCP (Data)
(1) Ermittlung des entfernten Hosts, auf dem der Server residiert
(2) Ermittlung der Portnummer, unter der der Server-Prozeß beim Ziel-Host erreichbar ist
•
Ziel des Bindings ist ein voll spezifiziertes Client-Server-Adreßpaar mit Angabe
des zu benutzenden Transportdienstes (Stream/Datagramm).
Fünfertupel:
[lokale Host-Internet ID, lokale Portnummer,
entfernte Host-Internet ID, entfernte Portnummer,
Transportdienst]
0 0
0 0
Probleme beim dynamischen Binden
Einstieg in die verteilten Anwendungen
•
•
–
–
–
–
Konsistenzerhaltung der Portmapper- und Directory-Server-Datenbasen
– Serverprozesse können terminieren Abmeldung erforderlich
– Serverabsturz Portmapper und Directory-Server müssen nach
festgelegten Zeitintervallen die Verfügbarkeit der Server überprüfen
•
Verfügbarkeit des Portmapper- und des Directory-Server-Daemons
– Absturz der Komponenten Replizierung
– Netzpartitionierung Replikate im Netz, die im beschränkten Maße die
Arbeitsfähigkeit in den entstandenen Partitionen erhalten
•
•
•
•
•
•
Client / Server- Modell
Grundlagen
Fehlerverhalten (Client/Server)
Serverformen
Prozeß- vs. Thread-Konzept
•
Peer-to-Peer-Modell
•
API‘s zur Programmierung von VA
0 0
0 0
Client/Server-Modell
Allgemeines Client/Server-Prozeß-Modell
Standardmodell für Netzwerkanwendungen
im Netz unterschiedliche, zum Teil kostenintensive (exklusive) Geräte
und Ressourcen
Verfügbarkeit der Ressourcen für mehrere Anwender nötig (Auslastung)
oder Zugriff auf exklusiv vorhandene Informationen
software-technische Aspekte
Strategie
– Unterteilung der Aufgabe in Dienstnutzer (Client) und Diensterbringer
(Server), die räumlich getrennt sein können, aber über das Netzwerk
untereinander erreichbar sind
– Der Server bietet seinen Dienst über eine definierte Schnittstelle an.
– Jeder Client, der den Dienst nutzen will, kann eine Anforderung an den
Server stellen.
– Der Server entscheidet über die Ausführung der Anforderung.
0 0
•
•
•
0
Die Aufteilung der bestehenden Aufgaben erfolgt in zwei unabhängige,
eigenständige Prozesse: einen, der den Dienstnutzer (Client) repräsentiert, den
anderen, der den Diensterbringer (Server) darstellt. Beide Prozesse können auf
räumlich getrennten Hosts laufen.
Für den Server-Prozeß muß allgemeine Verfügbarkeit bestehen, das heißt, der
Serverprozeß wird im allgemeinen beim Systemstart des Rechners erzeugt und
terminiert entweder erst bei System-Shutdown oder bei explizitem Abbrechen
(Systemverwalter).
Für den Client-Prozeß besteht keine allgemeine Verfügbarkeit, er wird vom
Anwender/Systemverwalter bei Bedarf initiiert, muß aber, um einen Dienst
anzufordern, auf einen aktiven Server zugreifen können.
0 0
Ortseinfluss auf die Kommunikation zwischen Client
und Server (IPC - Interprozesskommunikation)
•
Kommunikations-Modell zwischen Client und Server
Client und Server lokal an einem Host:
–
IPC lokal: z.B. über Semaphore, Shared Memory, Message Queue
Client
•
•
Server
Nutzerprozeß
Nutzerprozeß
Host
Die Kommunikation erfolgt in Form von Frage-Antwort-Paaren.
Es besteht eine asymmetrische Kommunikationsbeziehung, die sich im
Prozeßkonzept widerspiegelt.
a) Der Client schickt eine Anforderung (Request) an einen Server.
b) Der Server behandelt die Anforderung und schickt eine Antwort (Response)
mit Ergebnis.
Betriebssystem-Kernel
Request
•
Client und Server auf entfernten Hosts:
-
Client
IPC entfernt: über Messages; Streams und Datagramme
Server
Response
Host A
Client
Server
Nutzerprozeß
Nutzerprozeß
Betriebssystem-Kernel
Transfersystem
Asymmetrie auch in der Kommunikationsform:
Der Client überliefert asynchron (zu einem beliebigen Zeitpunkt) eine
Anforderung an einen Server.
Der Server antwortet synchron (in einem bestimmten Zeitintervall).
Host B
Betriebssystem-Kernel
0 0
0 0
Zusammenhang Server-Aufgaben und
Zuverlässigkeit
Problem der Zuverlässigkeit und Robustheit
•
•
– idempotent lösbare Aufgaben, das heißt,
die Anzahl der Ausführungen der Aufgaben ist unbegrenzt und führt zu
keiner Änderung des Status‘ beziehungsweise des Datenbestandes des
Servers (Testaufgaben)
– nicht idempotent lösbare Aufgaben, das heißt,
die Aufgabe beeinflußt den Status/Datenbestand des Servers, sie darf nur
genau einmal ausgeführt werden
zwei Fehlerquellen:
– Rechnerabsturz
– Netzwerkzusammenbruch
•
Zwei Aufgabenformen:
drei unmittelbare Auswirkungen:
– Server-/ Client-Prozeß nicht mehr verfügbar
– Netzwerkverbindung unzuverlässig
0 0
Zuverlässigkeit spielt bei Aufgaben mit idempotenten Charakter eine
untergeordnete Rolle.
Für nicht idempotente Aufgaben ist sie zwingend erforderlich.
Zuverlässigkeit und Aufgabe führen zu unterschiedlichen Client- und
Server-Semantiken sowie Implementierungsvarianten.
0 0
Ausführungsgrad von Client-Anforderungen
(Wiederholungen)
Client-Semantik gegenüber Netzwerkfehlern
und Server-Absturz
•
•
•
Gar nicht berücksichtigen
– Der Client wartet für immer und ewig auf eine Antwort, die aber nicht
eintreffen kann.
•
•
Timeout und Fehlerbehandlung
– Der Client erkennt über Timeout einen Fehler und leitet ein ExceptionHandling ein beziehungsweise gibt eine Fehlermeldung aus.
•
•
Timeout, Fehlerbehandlung und erneute Anforderung
– Der Client erkennt über Timeout einen Fehler, behandelt diesen und sendet
erneut eine Anforderung an den Server.
Ob der Client eine Anforderung erneut senden kann, hängt davon ab, ob
die Aufgabe idempotent oder nicht idempotent ist.
•
Egal (idempotent), beliebig oft wiederholbar
(z.B. Test des Kontostandes)
Genau einmal (exactly once)
Aufgabe muß genau einmal ausgeführt werden, da nach einem Server-Absturz
nicht immer feststellbar ist, ob das Ziel erreicht wurde
(z.B. Gehaltsauszahlung)
Höchstens einmal (at most once)
Aufgabe darf nur einmal oder gar nicht ausgeführt werden, wenn erfolgreich
alles OK, bei Server-Absturz gibt Client jedoch auf
(z.B. Rechnung überweisen)
Wenigstens einmal (at least once)
Client wiederholt solange, bis eine richtige Antwort zurückkommt
(z.B. „Taschengeld für Sie“)
Letzte von vielen (last of many)
Alle Anforderungen besitzen eine Transaktionskennung, somit ist die letzte
Antwort, die die Transaktionskennung der letzten erfolgreich übertragenen
Anforderung besitzt ermittelbar und wird verwendet
(z.B. Auktion)
0 0
0 0
Behandlung/Entsorgung von Waisen
(Server-Prozesse)
Server-Verhalten bei Client-Absturz
•
•
Problem: Der Client konnte erfolgreich den Auftrag absetzen. Während
der Bearbeitung der Aufgabe beim Server bricht das Netzwerk oder der
Client-Prozeß zusammen. Der Server bleibt als Waise bestehen.
Methoden zur Behandlung des Absturzes eines Clients, der vor Absturz
noch eine aktive Verbindung (Auftrag) zu einem Server besaß,
erfordern
– persistente Datenhaltung von Informationen, die den Status der Verbindung
vor einem Absturz widerspiegeln
– Mehraufwand an Kommunikation, um die Verfügbarkeit des Auftraggebers
abzutesten
– Tracing-Mechanismen, um die Aufrufkette von
Client Server (Client
Server (Client
...))
- Aktionen zu verfolgen.
0 0
Ziel: Beenden und Rücksetzen des Status‘ des Server-Programms
•
Ausrottung (extermination)
– Der Client protokolliert alle seine Verbindungen zu Servern über eine
persistente Datenbasis.
– Bei Neustart nach Zusammenbruch überprüft der Client, ob noch aktive
Serverprozesse zu alten Verbindungen gehören, um diese abzubrechen.
•
Verfallszeit (expiration)
– Nach der Anforderung verbleibt dem Server ein Zeitintervall zum
Abarbeiten. Reicht dieses Intervall nicht aus, so muß vom Client ein neues
Zeitintervall angefordert werden. Erhält der Server kein neues Intervall,
suspendiert er sich.
0 0
Behandlung/Entsorgung von Waisen
(Server-Prozesse)
•
Hohe Verfügbarkeit von Softwarekomponenten
und Parallelität: Prozeß- und Thread-Konzept
Wiedergeburt (reincarnation)
– Es werden Epochen im Netz eingeführt, da bei Netzausfall nicht alle Waisen
erreichbar sind (bei Ausrottungsmechanismen).
– Nach dem Zusammenbruch von Hosts beziehungsweise des Netzes bricht
eine neue Epoche an. Alle Messages mit alter Kennung werden verworfen.
Auch ungestörte Verbindungen sind betroffen!
•
Sanfte Wiedergeburt (gentle reincarnation)
– Dies geschieht ebenfalls unter Verwendung von Epochen. Es werden aber
nur alle rechnerentfernten Aktivitäten abgebrochen, wenn in eine neue
Epoche übergegangen wird.
– Der Server versucht den Client, der die Aktivität veranlaßt hat, zu
kontaktieren. Gelingt dies nicht suspendiert er sich.
0 0
•
Für Hosts im Netz bestehen gleichzeitig mehrere Aufgaben:
–
–
–
–
vom Netzwerk
Gefordert
host-seitig
gefordert
Das Betriebssystem des Hosts muß multitaskingfähig sein, um (quasi-) parallel
mehrere nebenläufige Aktivitäten unterstützen zu können.
0
0 0
Iterativer Server
Server-Formen
•
•
Die Serverformen sind
• vom zugrundeliegenden Kommunikationsdienst
Kommunikationsprotokollaufgaben
Netzwerkmanagementaufgaben
Betriebssystemaufgaben
Anwendungsaufgaben
•
Zu jeder Zeit kann nur ein Client-Request abgearbeitet werden.
Mehrere Client-Requests werden sequentiell in der Reihenfolge ihres
Eintreffens abgearbeitet oder abgelehnt.
Beispiel: Mailbox unter Remote Access 2.0 und MS DOS
t
– Datagrammverkehr (verbindungslos) unzuverlässig
– Streamverkehr (verbindungsorientiert) zuverlässig
•
und der Multitaskingfähigkeit des Betriebssystems
beziehungsweise der Programmierumgebung
– Prozeß-/Thread-Konzept
Client-Request 1
Bearbeitung
Client-Request 2
abhängig.
Zwei grundlegende Server-Formen:
Server-Response 1
– Iterativer Server
– Gleichlaufender (Concurrent) Server
0 0
Bearbeitung
Server-Response 2
0 0
Gleichlaufender Server
Bevorzugte Server-Formen
(concurrent)
•
•
•
Iterativer
Server
Im Server-Prozeß ist ein Haupt-Task für die Annahme von ClientRequests verantwortlich.
Bei Eintreffen eines Client-Requests wird ein neuer Task erzeugt, dem
der Request zur Bearbeitung übergeben wird. Der Haupt-Task ist somit
für den Empfang weiterer Requests frei.
Die Tasks für die Bearbeitung der Requests übergeben die Ergebnisse
den zugehörigen Clients und terminieren.
Verbindungslose
Kommunikation
1
Verbindungsorientierte
Kommunikation
t
Konkurrenter
Server
2
Client-Request 1
Bearbeitung
(1) Schnelle Antwortzeiten bei kurzer Auftragserfüllung vom Server, sicherer
Dienst nicht erforderlich (z.B. Statusabfrage entfernter Ressourcen)
fork()
Client-Request 2
fork()
Bearbeitung
Server-Response 1
(2) Server soll parallel mehrere Client-Anforderungen mit akzeptabler
Reaktionszeit erfüllen, sicherer Dienst erforderlich, Server muß zuverlässig
umfangreiche Aufgaben erfüllen (z.B. Datenbank-Server)
Server-Response 2
0 0
0 0
Prozeßkonzept (Anwendungssicht)
•
•
Jedem Client und Server wird in Multitasking-Umgebungen ein eigener
Prozeß zugeordnet.
Problem:
– erhöhte Anzahl von Prozessen, die das Betriebssystem verwalten muß, egal ob
Server-Aktivitäten angefordert werden oder nicht
(ständiges Abfragen der Server-Schnittstelle nach Client-Requests)
– kostet CPU-Ressourcen bei Scheduling
(ständiger aufwendiger Prozeßwechsel, Kontextwechsel nötig)
Bestrebungen zur Erhöhung der Effizienz
0 0
Erhöhung der Effizienz: Superserver
•
•
•
Ein einziger Superserver horcht die Interfaces (Ports) mehrerer Server
ab. Für die eigentlichen Server sind keine Prozesse zu unterhalten,
solange kein Request erfolgt.
Beim Eintreffen eines Requests für einen bestimmten Server initiiert der
Superserver einen neuen Prozeß für den gewünschten Dienst und
übergibt ihm die Anforderung.
Nach Erfüllung der Anforderung terminiert der vorher gewünschte
Server-Prozeß.
0 0
Interprozeß-/Interthread-Kommunikation
Erhöhung der Effizienz: Threadkonzept
P1
•
•
•
•
•
Betriebssystem
Scheduling
Policy
In einem einzigen Prozeß existiert mindestens ein Thread
(Point of Execution).
Bei Bedarf werden mehrere nebenläufige Threads erzeugt, die (quasi-) parallel
innerhalb des Prozesses mit eigenständigen Scheduling-Mechanismen ablaufen
(Multiple Points of Execution).
Die Scheduling-Mechanismen sind frei vom Programmierer (von der
Programmierumgebung) wählbar (FiFo, RR, Time-Sliced), unabhängig vom
Scheduling-Verfahren der Betriebssystemumgebung.
Die Kommunikation zwischen Threads eines Prozesses erfolgt über einen
gemeinsamen Datenbereich (Shared Variables).
Die Synchronisation der Threads erfolgt über Bedingungsvariablen und Mutexes
sowohl für den Datenbereich als auch für Funktions- und Prozeduraufrufe.
Erreichtes Ziel: Reduzierung der Anzahl der vom Betriebssystem verwalteten
Prozesse und damit eine bessere Auslastung der Rechnerressourcen
P4
T1
T3
P3
P2
P5
ITC über
Shared
Variables
T2
ITC über
Shared
Variables
T1
IPC
Thread-Scheduling
Policy
0 0
IPC über
Shared Queues, Semaphore, ...
unter Einbeziehung des
Betriebssystemkerns
T3
T2
Thread-Scheduling
Policy
0 0
Gegenüberstellung von Prozeß- und Thread-Konzept
Erweitertes Client-/Server-Modell
Erweiterung des reinen Client-Server-Modells auf mehr als zwei Teilnehmer:
•
Vorteile des Thread-Konzepts:
– Verbesserung der Ressourcenausnutzung durch Programme
• Vermeidung häufiger Kontextwechsel (Prozeßumgebung)
• keine Zuteilung von globalem Speicher für ITC
– Vereinfachung der Kommunikation zwischen Threads eines Prozesses
•
•
Delegation von Teilaufgaben
Nachrichtenketten
•
Definition des Clients bleibt bestehen:
Ein Client ist die auf einen Dienst bezogene originäre/ursprüngliche Quelle der
Anfrage und letzte Senke der Antwort.
•
Achtung!:
DNS-Aufrufe oder ähnliche systemfremde Hilfsmittel gehören nicht in die
Betrachtung des Modells!
• Zugriff auf lokale Variablen im Speicherbereich des Programms
Einfachere, übersichtlichere Lösung komplexer Probleme
•
Probleme des Thread-Konzepts:
– Systemrufe
• Systemrufe (eigener Kernel-Prozeß) sind nicht thread-reentrant.
• Ein blockierender Systemruf blockiert nicht nur den aufrufenden Thread, sondern
den gesamten Prozeß.
0 0
0
0 0
•
Peer-to-Peer
Peer-to-Peer
Idee
Definition
Zuletzt häufig genutzter Name ( Buzzword… )
•
•
Kommunikationsmodell asynchron (request-response)
Rollenmodell: nur eine Rolle
– symmetrisches Verhalten, alle Teilnehmer können prinzipiell das gleiche
•
Name „flacher“ / „anarchistischer“ Systeme
•
Organisationsmodell: vollkommen unstruktiert
– ausser Bootstrapping-Punkt kein Kontextwissen und keine bekannte Struktur
•
Eigentlich eine Systemarchitektur (CDK: „Peer-Process“)
•
•
Per se keine Bezeichner, lediglich Namen
– Bezeichner können verteilt-algorithmisch eingeführt werden (Hashwerte...)
– Strukturen können verteilt-algorithmisch eingeführt werden (dynamische
Supernodes...).
Zentrale Probleme:
– Finden von Ressourcen (Lokalisierung):
• Andere Knoten
• Dienste anderer Knoten
– Sinnvolle Weiterleitung von Anfragen/Daten (Routing)
•
Bessere Bezeichnungen:
– Collaborative Systems, dezentrale verteilte Systeme, kooperative Systeme
0 0
0 0
Netzwerkunterstützung:
Schnittstellen zur Programmierung verteilter
Anwendungen
Peer-to-Peer
Ausprägungen
•
Grundsätzlich:
– Pures Peer-to-Peer skaliert nicht.
Algorithmische Ordnung notwendig, um Nachrichtenexplosion zu vermeiden
•
Gnutella, Fasttrack, Ilmtella, CHORD, CAN, Kademlia, Pastry
Berkeley Sockets
– Orientierung an Unix-Dateiarbeit: Arbeit über Deskriptoren
– Ein-/Ausgabe über das Prinzip: create, open, read, write, close
– Unterstützung verbindungsloser und verbindungsorientierter Kommunikation
Sinnvolle Klassifikation nach
– Auflösung (Namen/ Bezeichner)
– Struktur (Hierarchie, DHT)
– Weiterleitung/Message Routing (Query Index, DHT, Hierarchie)
•
•
•
X/Open Transport Interface (XTI)
– (alternative) Schnittstelle zu Netzwerkfunktionen der Transportebene (Ebene 4
des ISO/OSI-Referenzmodells)
– ursprünglich von AT&T für das UNIX System V entwickelt
– angelehnt an die ISO Transport Service Definition (ISO 8072)
– Die XTI-Funktionen greifen über Systemrufe auf Streams-Treiber zu, die den
Zugriff auf das Netzwerk ermöglichen (als Transport Provider agieren).
In der Praxis hat sich die Socket-Programmierung durchgesetzt.
0 0
0 0
Berkeley-Socketinterface
Socket - API
API für verteilte Anwendungen
⇒ zur Einordnung der Socket-API
•
•
Applikation
– Systemrufe
– Bibliotheksfunktionen
Anwendungsprotokolle
Transport
Die Netzwerkfunktionalität ist im allgemeinen in das UNIX-System integriert.
Die Socket-API stellt entsprechende API-Funktionen bereit.
Socket-API
•
Orientierung an Unix-Dateiarbeit
Internet Protokoll
– Arbeit über Deskriptoren
– Ein-/Ausgabe über das Prinzip: create, open, read, write, close
Netzwerk Schnittstelle
– Ein-/Ausgabe über das Netz aber komplizierter als
Datei-Ein-/Ausgabe, da Interaktion zwischen zwei getrennten Prozessen
•
Unterstützung verbindungsloser und verbindungsorientierter Kommunikation
0 0
0 0
Socket – API (II)
•
•
Ein Socket ist ein Kommunikationsendpunkt innerhalb eines
Kommunikationsbereiches.
Ein Kommunikationsbereich spezifiziert eine Adressstruktur und ein Protokoll.
–
–
•
•
•
Kommunikation über das Socket-Interface
Adreßstruktur: z.B. Internet → Host/Port
Protokoll: z.B. TCP, UDP
Die Kommunikationsverbindung zwischen zwei Sockets ist durch ein SocketPaar gekennzeichnet.
Ein Datenaustausch erfolgt zwischen zwei Sockets desselben
Kommunikationsbereiches.
Eine Kommunikationsbeziehung ist immer durch folgendes Fünfertupel
definiert:
(protocol, local-addr, local-process, foreign-addr, foreign-process)
0 0
•
Asymmetrische Kommunikationsbeziehung zwischen zwei Prozessen
–
–
Unterteilung in Client und Server
Einteilung nach der Kommunikationsart (verbindungslos/verbindungsorientiert)
Spezifische Systemrufe bzw. Bibliotheksfunktionen, die von der Rolle des Prozesses
und der unterstützten Kommunikationsart abhängig sind
0 0
Adressstrukturen (II)
Adressstrukturen
•
•
Socket-Adressstruktur für die Internet-Familie:
⇒ in Anwendungsprogrammen genutzt
Socket-Adressstruktur:
⇒ vom Kernel zur Speicherung von Adressen genutzt
⇒ vom Programmierer als generische Adreßstruktur verwendet
(Pointer Cast)
#include <netinet/in.h>
#include <sys/socket.h>
struct sockaddr {
uint8_t
sa_len;
sa_family_t sa_family;
char
sa_data[14];
};
struct sockaddr_in {
uint8_t
sin_len;
sa_family_t
sin_family;
in_port_t
sin_port;
struct in_addr sin_addr;
char
sin_zero[8];
};
/* Adreßfamilie */
/* protokollspez. Adresse */
0
0 0
/*
/*
/*
/*
AF_INET */
16-Bit Port-Nummer */
32-Bit-Internet-Adresse */
unbenutzt */
0 0
bind
Socket-Systemrufe bzw. Bibliotheksfunktionen
socket
int bind (int sockfd, struct sockaddr *myaddr, int addrlen);
int socket (int family, int type, int protocol);
•
erzeugt einen Socket und gibt einen Socket-Deskriptor zurück
•
– family spezifiziert die Adreßfamilie, z.B AF_INET
– type gibt die Art der Kommunikation an, z.B. für AF_INET folgende
Typen: SOCK_STREAM, SOCK_DGRM, SOCK_RAW
– protocol wird für die meisten Benutzeranwendungen auf Null gesetzt,
da family und type den Protokolltyp bis auf Ausnahmen spezifizieren:
Family
AF_INET
AF_INET
AF_INET
•
Type
SOCK_STREAM
SOCK_DGRAM
SOCK_RAW
Protocol
IPPROTO_TCP
IPPROTO_UDP
IPPROTO_ICMP
Die socket() - Funktion spezifiziert lediglich das Element protocol
im Fünfertupel einer Kommunikationsbeziehung.
0 0
Die bind() - Funktion meldet den noch unbekannten Socket am lokalen
System unter Adreßangabe des lokalen Prozesses an.
– *myaddr ist ein Zeiger auf eine protokollspezifische Adreßstruktur
(sockaddr_in), deren sin_addr - Anteil auf Null gesetzt wird
(INADDR_ANY) und deren sin_port - Anteil auf eine bestimmte PortNummer gesetzt wird, oder wenn die Port-Nummer vom System zugewiesen
werden soll, auf Null gesetzt wird (dynamische Portzuweisung).
– addrlen gibt die Länge der myaddr - Struktur an
•
•
•
Bei Rückkehr des Systemrufes werden die mit Null angegebenen
Adreßanteile der myaddr - Struktur aktualisiert.
Jeder Server muß seinen Socket beim System anmelden.
Die bind() - Funktion spezifiziert local-addr und local-process im
Fünfertupel der Kommunikationsbeziehung.
0 0
Client-Ablauf
connect
int connect (int sockfd, struct sockaddr *servaddr, int addrlen);
•
Ein verbindungsorientierter Client muß nicht bind() vor connect()
aufrufen, da connect() auch die lokale Adresse des Clients
automatisch zuweist. Im Fünfertupel werden local-addr, local-process,
foreign-addr und foreign-process spezifiziert.
•
Ein verbindungsloser Client nutzt die connect() - Funktion zur
lokalen Spezifikation des entfernten Servers. Es wird keine Verbindung
aufgebaut. Für den Datenaustausch liegt aber die Adresse des Servers
immer vor und braucht nicht explizit angegeben zu werden. Im
Fünfertupel der Kommunikationsbeziehung werden nur
foreign-addr und foreign-process spezifiziert.
• connect() ist eine Funktion, die von einem Client zum Initiieren einer
Verbindung aufgerufen wird.
– *servaddr ist eine protokollspezifische Adreßstruktur, deren Elemente
sin_addr die Netzwerk-ID und Host-ID des Servers und sin_port die
aktuelle Portnummer des Servers vor dem Aufruf von connect()
zugewiesen bekommen müssen.
– addrlen gibt die Länge der servaddr - Struktur an.
•
Die connect() - Funktion richtet eine Verbindung vom lokalen zum
fernen System ein.
0 0
0 0
listen
accept
int accept (int sockfd, struct sockaddr *peer, int *addrlen);
•
Die accept() - Funktion nimmt die erste Client-Anforderung aus der
Warteschlange und generiert einen neuen Socket mit den gleichen Eigenschaften
wie sockfd.
•
Wenn sich keine Anforderung in der Warteschlange befindet, blockiert die Funktion,
bis ein Client eine Verbindung zum Server aufbauen will.
peer und addrlen verweisen auf die Adreßelemente des Partnerprozesses. Nach
der Rückkehr der accept() - Funktion enthält die peer - Struktur die InternetAdresse und das Port des Client-Prozesses.
accept() spezifiziert serverseitig alle fünf Werte im Fünfertupel der
Kommunikationsbeziehung für den neuen Socket-Deskriptor. Für den alten SocketDeskriptor bleiben foreign-addr und foreign-process unspezifiziert, um den
Deskriptor für weitere Verbindungen zu nutzen.
Serverseitig wird kein neues Port für die neue Verbindung bereitgestellt, da diese
durch das Fünfertupel eindeutig spezifiziert ist.
int listen (int sockfd, int backlog);
•
•
•
Die listen() - Funktion signalisiert die Bereitschaft eines
verbindungsorientierten Servers eine Verbindung anzunehmen.
Sie wird nach der socket() - und bind() - Funktion verwendet.
•
backlog spezifiziert die Anzahl von anstehenden Client-Anforderungen, die
gleichzeitig in einer Warteschlange verwahrt werden können.
•
•
0 0
0 0
send/recv
•
int send
int recv
int sendto
(int sockfd, char *buff, int nbytes, int
(int sockfd, char *buff, int nbytes, int
(int sockfd, char *buff, int nbytes, int
struct sockaddr *to, int addrlen);
int recvfrom (int sockfd, char *buff, int nbytes, int
struct sockaddr *from, int *addrlen);
flags);
flags);
flags,
•
flags,
Die Funktionen send(), sendto(), recv(), recvfrom() sind ähnlich
den Standardsystemrufen read() und write(), benötigen aber zusätzliche
Argumente.
• buff spezifiziert den Ein- bzw. Ausgabepuffer.
• nbytes gibt die Menge der auszugebenden bzw. einzubindenden Daten an.
• flags ist für den normalen Transfer auf Null gesetzt oder auf MSG_OOB für
zusätzliche, im Datenstrom mitgeführte Out-of-Band-Daten.
send() und recv() stehen für die verbindungsorientierte Übertragung zur
Verfügung. Werden die Partner bei verbindungsloser Kommunikation mit
connect() spezifiziert, sind send() und recv() auch bei verbindungsloser
Kommunikation nutzbar, da die Partner vorher angegeben wurden.
sendto() benötigt immer explizit die Angabe des Partners (*to).
recvfrom() übergibt dem Kommunikationsprozeß die Adresse des Partners
(*from), von dem die verbindungslos übertragenen Daten kommen.
•
int close (int sockfd);
Die close() - Funktion schließt den Socket und veranlaßt die Freigabe des vom
System zugewiesenen Ports.
Bei verbindungsorientierter Kommunikation muß der Kernel trotz aufgerufenem
close() sichern, daß noch nicht gesendete Daten und Bestätigungen, die im Kernel
gepuffert sind, ausgegeben werden.
0 0
0 0
Socket-Funktionen bei verbindungsorientierter
Kommunikation
Struktur der Socket-Systemaufrufe bei
verbindungslosem Protokoll
Server
Client
Server
Client
socket()
socket()
socket()
socket()
bind()
bind()
recvfrom()
sendto()
sendto()
recvfrom()
close()
close()
bind()
listen()
accept()
connect()
read()
write()
write()
read()
close()(accept)
close()
close()(socket)
0 0
0
0 0
Struktur der Socket-Systemaufrufe bei
verbindungslosem Protokoll mit connect ()
Client
Server
socket()
socket()
bind()
bind()
connect()
recvfrom()
send()
sendto()
recv()
close()
close()
0 0