0���������� ��� ���������������0��0� 0��������

VorlesungVerteilte Anwendungen

Teil 2: Programmierung verteilter Anwendungen

Thorsten Strufe

Technische Universität Ilmenau

Fakultät für Informatik und Automatisierung

Institut Praktische Informatik und MedieninformatikFachgebiet Telematik

����������� ��� ���������������0��0� ���������

Koordinaten

Thorsten StrufeCC 440Tel. 03677/69-4552Email thorsten.strufe@tu-ilmenau.dehttp://eris.prakinf.tu-ilmenau.de/

����������� ��� ���������������0��0� ���������

Einordnung der Vorlesung

• Telematik 1&2 � Grundlagen

• Rechnernetze

• Öffentliche Netze

• Kommunikationssoftware

• Verteilte Anwendungen

– Sicherheit in Rechnernetzen

– Netzwerkmanagement

– Hochleistungskommunikationssysteme

– Multimediale Informationssysteme

����������� ��� ���������������0��0� ���������

Ziele der Vorlesung

• Wissen über die Programmierung verteilter Anwendungen– Einführung in die Thematik

– Abklopfen des Umfeldes

– Betrachtung besonderer Aspekte

• 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

• 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

• Alexander Schill. Das OSF Distributed Computing Environment: Grundlagen und Anwendung. Springer, 1997

• Troy Bryan Downing. Java RMI: remote method invocation. IDG BooksWorldwide, 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, 1999u.v.m.

����������� ��� ���������������0��0� ���������

Inhalt der Vorlesung

• Motivation und Einführung• Ausgewählte Aspekte• Client/Server-Modell• P2P-Modell• Sockets• Netzwerktransparente Entwicklung

– RPC, RMI

• Tools und RE‘s

• Verteilte Objektsysteme– CORBA (Object Management Group)

• Verteilte Komponentensysteme– Enterprise JavaBeans (EJB) / J2EE – CORBAComponents– Microsoft „ .NET“

• Web Services (SOAP, XML-based RPC)

����������� ��� ���������������0��0� ���������

Grober Ablauf der Veranstaltung

• 1. Veranstaltung– Grundlagen

– Adressierung

– Client/Server und P2P-Modell

• 2. Veranstaltung– Einführung Middleware

– RPC

– RMI

– Grundlagen verteilter Objektsysteme• CORBA

• 3. Veranstaltung– Rechnerübung RPC

• 4. Veranstaltung– Rechnerübung RMI

• 5. Veranstaltung– Rechnerübung CORBA

• 6. Veranstaltung– Verteilte Komponentenmodelle

– EJB/CorbaComponents

– Webservices

• 7. Veranstaltung– .Not

• 8. Veranstaltung– Klausur! ☺

����������� ��� ���������������0��0� ���������

Anwendungsfelder verteilter Anwendungen

VA

Webapps

EAI

Portale

Marktplätze

Online-BankingOnline-Buchung

SCM BackofficeInformations-

Kooperationssysteme

Ressourcen-anbindung

Steuern, Messen, Regeln

DB-Anbindung

Flugbuchung

GeldautomatenJ2EE

Konnektoren

„ .NET“

Plattformen

CORBASOAP

„Agentensysteme“

VerteilteSysteme

DSM

Vert.Filesysteme

Vert.BS

#Cruncher/Cluster

P2P-Computing

Meta-/ Distributed-/Internet-Computing

����������� ��� ���������������0��0� ���������

Was ist eigentlich verteilt?

• 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

• Benutzeran unterschiedlichen Standorten oder mit unterschiedlicher Funktion können gemeinsamen Zugriff auf gleiche Daten haben

����������� ��� ���������������0��0� ���������

Definition: Verteilte Anwendung

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

�0���������� ��� ���������������0��0� �0��������

Definition: Verteilte Systeme

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.

� Ein verteiltes System ist ein System, dessen Daten und dessen Funktions-komponenten 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).

� Mehrfache Existenz verschiedener autonomer, physisch und räumlich getrennter Funktionseinheiten, an welche Aufgaben delegiert werden

������������ ��� ���������������0��0� ����������

Architekturmodelle verteilter Anwendungen

Internet

Client/ServerPeer-to-Peer

RZ

RZ

Cluster

mgr.

Client

qmast.Internet

execD

Server

Kunden

Verteiltes Rechnen

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

�Verteilte Anwendungen stellen auf Basis der Netzwerke spezielle Dienste bereit

������������ ��� ���������������0��0� ����������

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

������������ ��� ���������������0��0� ����������

Strukturmodell für Host-Systeme im Netzwerk

Netzwerk-Management

Hardware

BetriebssystemTransportschicht

Applikationen

������������ ��� ���������������0��0� ����������

Modelle Verteilter Anwendungenim Vergleich

Hardware

Betriebssystem

Plattformen für verteilte AnwendungenMiddleware

(Verteilte Systeme)

Verteilte Anwendungen

physical

Data link

network

transport

session

presentation

application

Networkinterface

internet

transport

application

ISO/OSITCP/IP

UI

App.-protokolle

App

DB

NetzwerkProtokolle

3-Tier

������������ ��� ���������������0��0� ����������

Beschreibungsmodellefür verteilte Anwendungen / Systeme

• Architekturmodelle (Systemarchitekturen)

• Fundamentale Modelle:– Kommunikations-/ Interaktionsmodell– Rollenmodell– Informationsmodell– Funktionsmodell– Zeitmodell– Fehlermodell– Sicherheitsmodell– Namensmodell– Datenmodell

• FG BS: (Organisations-/Informations-/Kommunikations-/Funktionsmodell)

������������ ��� ���������������0��0� ����������

Einstieg ins Netzwerken

Grundlagen:

�„Netzwerken“ �Adressieren

�Rechner, Prozess

������������ ��� ���������������0��0� ����������

Belange der Netzwerke und Betriebssysteme

Jeder Prozeß, der an der Kommunikation in einem Netz teilhaben will, muß global in der

gesamten Netzstruktur (z.B. Internet) eindeutig adressierbar sein.

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 SubnetzDiese Adresse ist für die Netzwerkverwaltung ungeeignet.

Es wird ein hierarchischer Adressraum mit logischen Adressen eingeführt. (IP!)

������������ ��� ���������������0��0� ����������

Hierarchischer Adressraum im Internet

3 Unterteilungsstufen � hierarchische Staffelung für die Erleichterung des Netzwerkmanagements

– globale Netzadresse

– Subnetzadresse

– Host-Adresse

(1) Zentrale Vergabe der globalen Netzadresse (für Firmen oder Institutionen) durch internationales Gremium

(2) Administrative Vergabe der Subnetzadresse von lokaler (firmeninterner) Netzwerkadministration

(3) Administrative Vergabe der Host-Adresse im Subnetz

�0���������� ��� ���������������0��0� �0��������

Adressklassen im Internet (IP)(Wird so nicht mehr gemacht!)

• Adresslänge 32 Bit

• Unterteilung in 5 Klassen– Die ersten Bits dienen der Unterscheidung der Adressklasse.

B

C

D

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

0 1 2 3

0 7 Bit Netz ID 24 Bit Host IDA

1 0 14 Bit Netz ID 16 Bit Host ID

1 1 0 21 Bit Netz ID 8 Bit Host ID

1 1 1 0 28 Bit Multicast-Adresse

Klasse

E 1 1 1 1 27 Bit (für die Zukunft reserviert)0

������������ ��� ���������������0��0� ����������

Semantik der Adressklassen

• 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.• (Hostadresse für das Routing im Internet nicht entscheidend)

• 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

• Adressierung in PunktnotationNamen: nero.prakinf.tu-ilmenau.depunktierte Dezimaldarstellung: 141.24.32.22

������������ ��� ���������������0��0� ����������

Variable Length Subnet Masks

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

Klassenlose Adressierung:Classless Inter-Domain Routing (CIDR)

� 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:– 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.

������������ ��� ���������������0��0� ����������

Portzuweisung

• Statische PortvergabeVom 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 PortvergabeDas 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.

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

Portaufteilung bei TCP/IP bzw. UDP/IP

• Reserviert: Portnummer 1 - 1023– davon: Portnummer 1 - 511

für spezielle global zugängliche DienstePortnummer 512 - 1023nur mit Superuser-Rechten zuweisbar

• Automatisch vom System zugewiesen: 1024 - 5000– Portzuweisung mit „normalen“ Nutzerrechten möglich

• Hinweis: gesamter Portnummernbereich exklusiv für TCP sowie exklusiv für UDP

• Beispiel: Portzuweisung für globalen Dienst

FTP Port Nr. 21/TCP (Commands)Port Nr. 20/TCP (Data)

������������ ��� ���������������0��0� ����������

Binding

• Als Binding bezeichnet man die vollständige Ermittlung der Adresse (Internet-Adresse + Portnummer) des entfernten Kommunikationspartners. Der Client ermittelt die Adresse des gewünschten Server-Prozesses.

• Vor dem Austausch von Nachrichten muß der Client-Prozeß eine Binding-Aktivität ausführen, die aus zwei Stufen besteht:

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

Probleme beim dynamischen Binden

• 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

������������ ��� ���������������0��0� ����������

Einstieg in die verteilten Anwendungen

• 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

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

Allgemeines Client/Server-Prozeß-Modell

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

• Client und Server lokal an einem Host:– IPC lokal: z.B. über Semaphore, Shared Memory, Message Queue

• Client und Server auf entfernten Hosts:- IPC entfernt: über Messages; Streams und Datagramme

HostNutzerprozeß Nutzerprozeß

Client Server

Betriebssystem-Kernel

Host BNutzerprozeß Nutzerprozeß

Client Server

Betriebssystem-KernelBetriebssystem-Kernel

Host A

Transfer-

system

������������ ��� ���������������0��0� ����������

Kommunikations-Modell zwischen Client und Server

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

Client

Request

ServerResponse

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

������������ ��� ���������������0��0� ����������

Problem der Zuverlässigkeit und Robustheit

• zwei Fehlerquellen:– Rechnerabsturz

– Netzwerkzusammenbruch

• drei unmittelbare Auswirkungen:– Server-/ Client-Prozeß nicht mehr verfügbar

– Netzwerkverbindung unzuverlässig

������������ ��� ���������������0��0� ����������

Zusammenhang Server-Aufgaben und Zuverlässigkeit

• Zwei Aufgabenformen:– 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

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

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

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

������������ ��� ���������������0��0� ����������

Ausführungsgrad von Client-Anforderungen (Wiederholungen)

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

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

Behandlung/Entsorgung von Waisen (Server-Prozesse)

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

Behandlung/Entsorgung von Waisen (Server-Prozesse)

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

Hohe Verfügbarkeit von Softwarekomponenten und Parallelität: Prozeß- und Thread-Konzept

• Für Hosts im Netz bestehen gleichzeitig mehrere Aufgaben:– Kommunikationsprotokollaufgaben

– Netzwerkmanagementaufgaben

– Betriebssystemaufgaben

– Anwendungsaufgaben

� Das Betriebssystem des Hosts muß multitaskingfähig sein, um (quasi-) parallel mehrere nebenläufige Aktivitäten unterstützen zu können.

vom NetzwerkGefordert

host-seitiggefordert

������������ ��� ���������������0��0� ����������

Server-Formen

Die Serverformen sind • vom zugrundeliegenden Kommunikationsdienst

– Datagrammverkehr (verbindungslos) unzuverlässig– Streamverkehr (verbindungsorientiert) zuverlässig

• und der Multitaskingfähigkeit des Betriebssystems beziehungsweise der Programmierumgebung

– Prozeß-/Thread-Konzept

abhängig.

� Zwei grundlegende Server-Formen:– Iterativer Server– Gleichlaufender (Concurrent) Server

������������ ��� ���������������0��0� ����������

Iterativer Server

• Zu jeder Zeit kann nur ein Client-Request abgearbeitet werden.

• Mehrere Client-Requestswerden sequentiell in der Reihenfolge ihres Eintreffens abgearbeitet oder abgelehnt.

• Beispiel: Mailbox unter RemoteAccess 2.0 und MS DOS

t

Client-Request 1

BearbeitungClient-Request 2

Server-Response 1

Bearbeitung

Server-Response 2

������������ ��� ���������������0��0� ����������

Gleichlaufender Server(concurrent)

• Im Server-Prozeß ist ein Haupt-Task für die Annahme von Client-Requestsverantwortlich.

• Bei Eintreffen eines Client-Requestswird 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.

Client-Request 1

BearbeitungClient-Request 2

Server-Response 1

Bearbeitung

Server-Response 2

t

fork()

fork()

������������ ��� ���������������0��0� ����������

Bevorzugte Server-Formen

VerbindungsloseKommunikation

VerbindungsorientierteKommunikation

IterativerServer

KonkurrenterServer

2

(1) Schnelle Antwortzeiten bei kurzer Auftragserfüllung vom Server, sicherer Dienst nicht erforderlich (z.B. Statusabfrage entfernter Ressourcen)

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

1

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

Erhöhung der Effizienz: Threadkonzept

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

������������ ��� ���������������0��0� ����������

Interprozeß-/Interthread-Kommunikation

P1

P2P3

IPC überShared Queues, Semaphore, ...

unter Einbeziehung desBetriebssystemkerns

T1

T2T3

ITC überShared

Variables

Thread-SchedulingPolicy

P4T1

T2T3

ITC überShared

Variables

Thread-SchedulingPolicy

P5

IPC

BetriebssystemScheduling

Policy

�0���������� ��� ���������������0��0� �0��������

Gegenüberstellung von Prozeß- und Thread-Konzept

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

Erweitertes Client-/Server-Modell

Erweiterung des reinen Client-Server-Modells auf mehr als zwei Teilnehmer:

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

������������ ��� ���������������0��0� ����������

Peer-to-PeerIdee

• Zuletzt häufig genutzter Name ( Buzzword… )

• Name „ flacher“ / „anarchistischer“ Systeme

• Eigentlich eine Systemarchitektur (CDK: „Peer-Process“)

• Zentrale Probleme:– Finden von Ressourcen (Lokalisierung):

• Andere Knoten

• Dienste anderer Knoten

– Sinnvolle Weiterleitung von Anfragen/Daten (Routing)

������������ ��� ���������������0��0� ����������

Peer-to-PeerDefinition

• Kommunikationsmodell asynchron (request-response)

• Rollenmodell: nur eine Rolle – symmetrisches Verhalten, alle Teilnehmer können prinzipiell das gleiche

• Organisationsmodell: vollkommen unstruktiert– ausser Bootstrapping-Punkt kein Kontextwissen und keine bekannte Struktur

• 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...).

• Bessere Bezeichnungen:– CollaborativeSystems, dezentrale verteilte Systeme, kooperative Systeme

������������ ��� ���������������0��0� ����������

Peer-to-PeerAusprägungen

• Grundsätzlich:– Pures Peer-to-Peer skaliert nicht.

� Algorithmische Ordnung notwendig, um Nachrichtenexplosion zu vermeiden

• Sinnvolle Klassifikation nach – Auflösung (Namen/ Bezeichner)

– Struktur (Hierarchie, DHT)

– Weiterleitung/MessageRouting (Query Index, DHT, Hierarchie)

• Gnutella, Fasttrack, Ilmtella, CHORD, CAN, Kademlia, Pastry

������������ ��� ���������������0��0� ����������

Netzwerkunterstützung:Schnittstellen zur Programmierung verteilter

Anwendungen

• Berkeley Sockets– Orientierung an Unix-Dateiarbeit: Arbeit über Deskriptoren

– Ein-/Ausgabe über das Prinzip: cr eat e, open, r ead, wr i t e, cl ose

– Unterstützung verbindungsloser und verbindungsorientierter Kommunikation

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

⇒ zur Einordnung der Socket-API

Applikation

Transport

Internet Protokoll

Netzwerk Schnittstelle

Socket-APIAnwendungsprotokolle

Berkeley-SocketinterfaceAPI für verteilte Anwendungen

������������ ��� ���������������0��0� ����������

Socket - API

• Die Netzwerkfunktionalität ist im allgemeinen in das UNIX-System integriert.

• Die Socket-API stellt entsprechende API-Funktionen bereit.– Systemrufe

– Bibliotheksfunktionen

• Orientierung an Unix-Dateiarbeit– Arbeit über Deskriptoren– Ein-/Ausgabe über das Prinzip: cr eat e, open, r ead, wr i t e, cl ose

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

Socket – API (II)

• Ein Socket ist ein Kommunikationsendpunkt innerhalb eines Kommunikationsbereiches.

• Ein Kommunikationsbereich spezifiziert eine Adressstruktur und ein Protokoll.– Adreßstruktur: z.B. Internet → Host/Port

– Protokoll: z.B. TCP, UDP

• Die Kommunikationsverbindung zwischen zwei Sockets ist durch ein Socket-Paar gekennzeichnet.

• Ein Datenaustausch erfolgt zwischen zwei Sockets desselben Kommunikationsbereiches.

• Eine Kommunikationsbeziehung ist immer durch folgendes Fünfertupeldefiniert:

� (protocol, local-addr, local-process, foreign-addr, foreign-process)

������������ ��� ���������������0��0� ����������

Kommunikation über das Socket-Interface

• 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��0� �0��������

Adressstrukturen

• Socket-Adressstruktur:⇒ vom Kernel zur Speicherung von Adressen genutzt

⇒ vom Programmierer als generische Adreßstruktur verwendet(Pointer Cast)

#i ncl ude <sys/ socket . h>

st r uct sockaddr {

ui nt 8_t sa_l en;

sa_f ami l y_t sa_f ami l y; / * Adreßfamilie * /

char sa_dat a[ 14] ; / * protokollspez. Adresse * /

} ;

������������ ��� ���������������0��0� ����������

• Socket-Adressstruktur für die Internet-Familie:⇒ in Anwendungsprogrammen genutzt

#i ncl ude <net i net / i n. h>

st r uct sockaddr _i n {ui nt 8_t s i n_l en;sa_f ami l y_t s i n_f ami l y; / * AF_INET * /i n_por t _t s i n_por t ; / * 16-Bit Port-Nummer * /st r uct i n_addr si n_addr ; / * 32-Bit-Internet-Adresse * /char si n_zer o[ 8] ; / * unbenutzt * /

} ;

Adressstrukturen (II)

������������ ��� ���������������0��0� ����������

Socket-Systemrufebzw. Bibliotheksfunktionensocket

• erzeugt einen Socket und gibt einen Socket-Deskriptor zurück– family spezifiziert die Adreßfamilie, z.B AF_I NET

– type gibt die Art der Kommunikation an, z.B. für AF_I NET 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 Type ProtocolAF_I NET SOCK_STREAM I PPROTO_TCPAF_I NET SOCK_DGRAM I PPROTO_UDPAF_I NET SOCK_RAW I PPROTO_I CMP

• Die socket() - Funktion spezifiziert lediglich das Element protocolim Fünfertupel einer Kommunikationsbeziehung.

int socket (int family, int type, int protocol);

������������ ��� ���������������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 _i n), deren si n_addr - Anteil auf Null gesetzt wird (I NADDR_ANY) und deren si n_por t - Anteil auf eine bestimmte Port-Nummer 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.

int bind (int sockfd, struct sockaddr *myaddr, int addrlen);

bind

������������ ��� ���������������0��0� ����������

• connect() ist eine Funktion, die von einem Client zum Initiieren einer Verbindung aufgerufen wird.

– *servaddr ist eine protokollspezifische Adreßstruktur, deren Elemente si n_addr die Netzwerk-ID und Host-ID des Servers und si n_por t 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.

int connect (int sockfd, struct sockaddr *servaddr, int addrlen);

connect

������������ ��� ���������������0��0� ����������

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

Client-Ablauf

������������ ��� ���������������0��0� ����������

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

int listen (int sockfd, int backlog);

listen

������������ ��� ���������������0��0� ����������

• 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 Internet-Adresse 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 Socket-Deskriptor 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 accept (int sockfd, struct sockaddr *peer, int *addrlen);

accept

������������ ��� ���������������0��0� ����������

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

int send (int sockfd, char *buff, int nbytes, int flags);int recv (int sockfd, char *buff, int nbytes, int flags);int sendto (int sockfd, char *buff, int nbytes, int flags,

struct sockaddr *to, int addrlen);int recvfrom (int sockfd, char *buff, int nbytes, int flags,

struct sockaddr *from, int *addrlen);

send/recv

������������ ��� ���������������0��0� ����������

• 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 Kernelgepuffert sind, ausgegeben werden.

�0���������� ��� ���������������0��0� �0��������

Socket-Funktionen bei verbindungsorientierter Kommunikation

socket ( )

bi nd( )

r ead( )

cl ose( ) ( accept )

Server Client

socket ( )

wr i t e( )

r ead( )

cl ose( )

connect ( )

wr i t e( )

l i st en( )

accept ( )

cl ose( ) ( socket )

������������ ��� ���������������0��0� ����������

Struktur der Socket-Systemaufrufebei verbindungslosem Protokoll

socket ( )

bi nd( )

r ecvf r om( )

sendt o( )

c l ose( )

socket ( )

bi nd( )

r ecvf r om( )

sendt o( )

c l ose( )

Server Client

������������ ��� ���������������0��0� ����������

Struktur der Socket-Systemaufrufebei verbindungslosem Protokoll mit connect ()

socket ( )

bi nd( )

r ecvf r om( )

c l ose( )

Server

sendt o( )

Client

socket ( )

bi nd( )

send( )

r ecv( )

c l ose( )

connect ( )