Verteilte Systeme Kommunikation in verteilten Systemen Austausch

Kommunikation in verteilten Systemen
Jedes verteilte System erfordert Kommunikationsmöglichkeiten
Verteilte Systeme
Hochschule Regensburg
Vorlesung 2, 28.03.2012
Universitätsstraße 31, 93053 Regensburg
Prof. Dr. Jan Dünnweber
Die Kommunikation basiert auf der Nachrichtenübergabe auf
unterster Ebene (Netzwerk), da es nur selten einen
gemeinsamen Speicher gibt
Bei Tausenden/Millionen von Prozessen in einem großen
verteilten System, ist es unmöglich, verteilte Anwendungen
auf dieser niedrigen Abstraktionsebene zu entwickeln
Dazu ist das Netzwerk oft unzuverlässig, wie z. B. das Internet
Plan dieses Kapitels:
◮
◮
Netzwerke und Protokolle
Vier Modelle, die dem Benutzer eine abstraktere Sicht der
Kommunikation zur Verfügung stellen: RPC, RMI,
nachrichtenorientierte Middleware und Streams
Prof. Dr. Jan Dünnweber, Folie 2 von 45
Austausch von Nachrichten: Protokolle
Wenn zwei Maschinen in einem System kommunizieren,
müssen sie einander “verstehen” (Bsp.: A sendet einen frz.
Roman in EBCDIC-Kodierung, B erwartet eine dt.
Inventarliste in ASCII)
Die entsprechenden “Absprachen” nennt man Protokolle:
◮
◮
◮
◮
Verteilte Systeme
Protokollstapel in OSI
Das OSI-Modell enthält sieben Schichten (Protokollstapel)
Die Protokolle bilden einen Protokollstapel
Anmerkung: Die OSI-Schichten sind methodisch hilfreich, die
OSI-Protokolle wurden jedoch nie wirklich gebräuchlich
Wieviele Volt entsprechen einem 0-Bit bzw. 1-Bit
Wie erkennt man das letzte Bit einer Nachricht
Wie erkennt man, dass eine Nachricht verloren wurde
... und vieles mehr
Zwei wesentliche Arten von Protokollen:
Verbindungsorientiert (analog dem Telefon): Eine
Verbindung wird aufgebaut, benutzt und abgebaut.
Zustellungsgarantie, aber zeitaufwendig.
Verbindungslos (analog dem Briefkasten): Nachrichten
werden verschickt, ohne Verbindung aufzubauen. Keine
Zustellungsgarantie, dafür schneller.
Prof. Dr. Jan Dünnweber, Folie 3 von 45
Verteilte Systeme
Prof. Dr. Jan Dünnweber, Folie 4 von 45
Verteilte Systeme
Protokoll-Schichten, OSI-Modell
Das Schichtenmodell soll einen Überblick über das Ablaufen
der Kommunikation zwischen zwei Prozessen in einem VS
geben:
◮
◮
◮
Sender erzeugt eine Nachricht und übergibt sie an die
Applikationsschicht (z.B. Bibliotheksprozedur) auf seiner
Maschine
Die Software der App-Schicht fügt der Nachricht einen Header
zu und übergibt sie an die Darstellungsschicht
u. s. w. - jedesmal wird Header oder Trailer beigefügt
OSI-Schichten: Unterste Ebene
Bitübertragungsschicht: überträgt 0s und 1s. Das Protokoll
bestimmt unter anderem:
◮
◮
wieviele Bits pro Sekunde
eine oder beide Richtungen
Sicherungsschicht: gruppiert die Bits in Frames, erkennt
mögliche Übertragungsfehler und korrigiert sie:
◮
◮
Fügt jedem Frame seine Prüfsumme an und überprüft diese
Protokoll bestimmt den Verlauf der “Verhandlungen” zw.
Sender und Empfänger bei evtl. Fehlern über Nachsenden etc.
Vermittlungsschicht: wählt den Pfad im Netz (routing)
◮
Verteilte
Systeme
Ganz unten im Protokollstapel
überträgt
die
Bitübertragungsschicht die Nachricht mit allen Headern und
Trailern
Auf der Empfänger-Maschine wird die Nachricht von unten
nach oben weitergereicht
Dabei entfernt jede Schicht den für sie vorgesehenen
Header/Trailer und wertet ihn aus
Prof. Dr. Jan Dünnweber,
Folie 5 von 45
◮
◮
◮
Die Idee vonTransportprotokolle
Schichten mit eigenen Protokollen an einem
OSI-Schichten:
anschaulichen Beispiel:
Das gebräuchlichste Protokoll – verbindungsloses IP (Internet
Protocol)
Prof. Dr. Jan Dünnweber, Folie 6 von 45
Verteilte Systeme
TCP bei Client-Server:
Zwei Chefs und ihre Sekretärinnen
Die Sekretärinnen verwenden Fax als technisches Protokoll für
Bestellungen, ohne über Inhalt nachzudenken
◮ Die Chefs entscheiden über ihren Inhalt (telefonisch, beim
Transportschicht
dasdie
Netzwerk
dem Anwender
Golfen, etc.), macht
ohne über
Bestellungsabwicklung
nachzudenken
zugänglich
◮ Die beiden Protokolle können unabhängig voneinander
Sichert
verlustfreie Lieferung der Nachricht
ausgetauscht werden
◮
◮
Baut auf verbindungsorientierten oder -losen Netzwerkdiensten
Zwei wichtigste Transportprotokolle:
◮
◮
TCP (Transport Control Protocol): verbindungsorientiert
UDP (Universal Datagram Protocol): verbindungslos
TCP funktioniert zuverlässig, verursacht jedoch mehr
Overhead
Prof. Dr. Jan Dünnweber, Folie 7 von 45
Verteilte Systeme
Prof. Dr. Jan Dünnweber, Folie 8 von 45
Verteilte Systeme
OSI-Schichten: Höhere Ebene
Sitzungsschicht: Dialogmöglichkeit für Benutzer bei langen
Übertragungen
Darstellungsschicht: Formatierung der Nachrichten
In der Praxis werden die zwei o. g. Schichten kaum benutzt
Es werden hauptsächlich nur Applikationsprotokolle benutzt:
◮
◮
FTP (File Transfer Protocol): für Dateien zwischen Clients und
Servern
HTTP (HyperText Transfer Protocol): ursprünglich für
Webseiten, später auch z.B. in Java RMI (s. später)
Nun verlassen wir den expliziten Nachrichtenaustausch und
betrachten abstraktere Ansätze, um diesen zu verbergen
Prof. Dr. Jan Dünnweber, Folie 9 von 45
Verteilte Systeme
RPC: Konventioneller Prozeduraufruf
Entfernter Prozeduraufruf (RPC – Remote Procedure Call)
Die Idee von RPC: anstatt direkten Nachrichtenaustausch
zwischen Maschinen:
◮
◮
◮
◮
Es wird den Programmen erlaubt, Prozeduren auf anderen
Maschinen aufzurufen
Die Parameter werden zur ausführenden Maschine geschickt
Das Ergebnis wird an die aufrufende Maschine zurückgebracht
Die Kommunikation passiert implizit, d.h. unsichtbar für den
Programmierer
Potentielle Probleme bei RPC:
◮
◮
◮
Die involvierten Programme befinden sich in getrennten
Adressräumen
Die Maschinen können nicht identisch sein (heterogen)
Die Maschinen können abstürzen
Prof. Dr. Jan Dünnweber, Folie 10 von 45
Verteilte Systeme
RPC: Konventioneller Prozeduraufruf (Forts.)
RPC baut auf dem konventionellen Prozeduraufruf auf
Beispiel-Aufruf in C: count = read(fd, buf, bytes);
zum Einlesen bytes Bytes aus einer Datei fd und Abspeichern
im Array buf
count = read(fd, buf, bytes);
Call-by-value für Wertparameter: bytes und fd werden auf
den Stack kopiert
Call-by-reference für Zeiger und Arrays: es wird die Adresse
des Arrays buf abgelegt
Es wird dann ein Aufruf zur BS-Prozedur read erzeugt
Die Parameter werden auf den Stack gelegt
Prof. Dr. Jan Dünnweber, Folie 11 von 45
Verteilte Systeme
Prof. Dr. Jan Dünnweber, Folie 12 von 45
Verteilte Systeme
RPC: Client- und Server-Stubs
Ziel des RPC: Transparenz, d.h. entfernter Aufruf soll
möglichst wie lokaler aussehen
Man erreicht dies, indem eine spezielle Version von read, ein
sog. Client-Stub verwendet wird
Der Stub erzeugt wie im lokalen Fall einen Aufruf an das BS,
jedoch nicht zum Lesen der Datei, sondern zum Verpacken
und Abschicken der Parameter an den Server (sog.
Marshalling)
Prof. Dr. Jan Dünnweber, Folie 13 von 45
Verteilte Systeme
RPC: Client- und Server-Stubs (Forts.)
RPC: Client- und Server-Stubs (Forts.)
Im Server übergibt BS die Nachricht an den Server-Stub
Beispiel: Entfernter Aufruf von add(i,j):
Server-Stub packt die Parameter aus und führt einen lokalen
Aufruf auf dem Server aus
Prof. Dr. Jan Dünnweber, Folie 14 von 45
Verteilte Systeme
RPC: Parameterübergabe und IDL
Die Parameterübergabe bei RPC ist nicht unproblematisch:
Server-Stub erhält das Ergebnis, verpackt es in einer
Nachricht und schickt sie an den Client; anschließend wartet
er auf weitere eingehende Anforderungen
An der Client-Maschine wertet der Client-Stub die Nachricht
aus, packt das Ergebnis aus und kopiert es an seinen Aufrufet
Der Aufrufer erhält die Steuerung zurück, er weiß dass der
Aufruf erledigt ist, weiß aber nicht wie (bzw. dass entfernt
erledigt)
Einfache Datenelemente (Zahlen, Zeichen, etc.) haben
verschiedene Darstellungen auf unterschiedlichen
Maschinentypen: Zeichencode, Bytenummerierung, usw.
Eine Referenz (bzw. ein Zeiger):
◮
◮
◮
Fazit: Der Zugriff auf externe Dienste erfolgt bei RPC durch lokale
Prozeduraufrufe (nicht durch send/receive)! Alle Details der
Kommunikation werden in den beiden Stubs-Prozeduren verborgen
Prof. Dr. Jan Dünnweber, Folie 15 von 45
Verteilte Systeme
Gilt nur im “eigenen” Prozess-Adressraum, verliert ihren Sinn
auf entfernter Maschine
Für Arrays bekannter Größe: das Array in die Nachricht
kopieren, an den Server-Stub senden, der den Server mit einem
Zeiger auf das Array aufruft und dann zurückschickt
Das funktioniert nicht für Zeiger auf beliebige/dynamische
Datenstrukturen, z.B. komplexe Graphen
Fazit: Beide Seiten müssen dasselbe Protokoll verwenden,
inkl. Daten- und Nachrichtenformate. Das Erstellen von Stubs
wird mit IDL (Interface Definition Language) vereinfacht
Prof. Dr. Jan Dünnweber, Folie 16 von 45
Verteilte Systeme
RMI: Remote Method Invocation (Entfernter
Methodenaufruf)
RMI: Remote Method Invocation, Fortsetzung
Das RPC kann auf die Objektorientierung übertragen werden,
was seine Verteilungstranparenz zusätzlich verbessert:
◮
◮
◮
◮
Objekte kapseln Daten (Status) und Operationen (Methoden)
ein.
Methoden werden über eine Schnittstelle bereitgestellt
Die Unterscheidung “Schnittstelle vs. Objekt” erlaubt eine
Schnittstelle auf einer Maschine abzulegen und das eigentliche
Objekt auf einer anderen Maschine
Diese Anordnung wird als “verteiltes/entferntes Objekt”
bezeichnet, und bedeutet i.d.R. nicht, dass ein Objekt physisch
über mehrere Maschinen verteilt ist
Der Client muss sich zum entfernten Objekt binden, was in
vielen Systemen automatisch passiert
Prof. Dr. Jan Dünnweber, Folie 17 von 45
Verteilte Systeme
RMI: Remote Method Invocation, Fortsetzung
In den Adressraum wird ein Client-Stub (Proxy im Bild) – eine
Implementierung der Objekt-Schnittstelle – geladen
Client-Stub verpackt Methoden-Aufrufe in Nachrichten an den
Server
Prof. Dr. Jan Dünnweber, Folie 18 von 45
Verteilte Systeme
RMI: Objektreferenzen
RMI unterstützt systemübergreifende Objektreferenzen, um
Objekte als Parameter in Methodenaufrufen zu nutzen
Objektreferenzen können frei zwischen Maschinen übertragen
werden, z.B. als Parameter eines Methodenaufrufs
Server-Stub (Skeleton im Bild) packt Nachrichten aus und
ruft Methoden auf
Objektreferenz enthält Information zum Auffinden des
Objekts: Netzwerkadresse der Maschine, Port des Servers,
Hinweis auf das Objekt, etc.
Beachte: Der Status eines entfernten Objektes befindet sich
i.d.R. auf einer Maschine. Auch wenn er verteilt ist, wird dies
hinter den Schnittstellen des Objekts verborgen.
Die Adresse der Maschine schränkt die
Migrations-Transparenz ein, man verwendet oft flexiblere
Lösungen, die jedoch die Skalierbarkeit benachteiligen können
Damit ein Prozess mithilfe der Objektreferenz eine Methode
entfernt aufrufen kann, muss er sich zu dem Objekt binden
Prof. Dr. Jan Dünnweber, Folie 19 von 45
Verteilte Systeme
Prof. Dr. Jan Dünnweber, Folie 20 von 45
Verteilte Systeme
RMI: Parameterübergabe
RMI: Parameterübergabe, Forts.
Dank Objektreferenzen ist die Parameterübergabe in RMI
weniger eingeschränkt als bei RPC
Man kann Objektreferenzen als Parameter verwenden: wenn
ein Prozess eine Objektreferenz erhält, kann er sich bei Bedarf
an das entfernte Objekt binden
Effizienz halber unterscheidet man zwischen entfernten und
lokalen Objektreferenzen (s. nächste Folie):
◮
◮
bezieht sich eine Referenz auf entferntes Objekt, so wird sie
kopiert und als Wertparameter übergeben
bezieht sie sich auf ein lokales Objekt im Client, so wird das
Objekt selbst kopiert und übergeben
Prof. Dr. Jan Dünnweber, Folie 21 von 45
Verteilte Systeme
RMI: Unterschiede zu RPC
◮
Objektargumente werden zum Übertragen serialisiert
(Zeichenstrom erzeugt), mit Verweis darauf, wo sich die
Objektimplementierung befindet
Wegen Vererbung kann der Datentyp eines Parameters evtl.
erst zur Laufzeit bestimmt werden. Sollte die entsprechende
Klassendatei nicht vorhanden sein, so müssen die
Methodendefinitionen nachgeladen/übertragen werden
1
2
◮
RMI-Applikationen können per se nicht von Rechnern ohne
JVM oder von nicht-Java-Programmen benutzt werden
Dadurch ist keine IDL (Interface Definition Language) wie bei
RPC nötig. Mit Java IDL kann man allerdings Objekte jeder
Sprache benutzen, die den CORBA-Standard unterstützt
Prof. Dr. Jan Dünnweber, Folie 23 von 45
Verteilte Systeme
Definiere ein für Client und Server gemeinsames Ferninterface
(remote interface), in dem die Signaturen der entfernt
aufrufbaren Methoden enthalten sein müssen
Definiere die Server-Seite:
◮
◮
◮
◮
Javas Garbage Collection ist auf entfernte Objekte erweitert
Beispiel: Java RMI ist eine reine Java-Angelegenheit:
◮
Verteilte Systeme
Java RMI: Übersicht der wichtigsten Schritte
RMI erlaubt beliebige Objekte (dagegen: RPC nur einfache
Datentypen!) als Argumente eines entfernten Aufrufs:
◮
Prof. Dr. Jan Dünnweber, Folie 22 von 45
3
4
Die Basis von RMI ist ein Fernobjekt (remote object) – Instanz
der Server-Klasse – das vom Client aufgerufen werden kann
Die Server-Klasse muß ein Ferninterface implementieren
Fernobjekte müssen mit einem eindeutigen Namen bei einem
Namensdienst (registry) registriert werden
Ein solcher Namensdienst läuft im Hintegrund auf dem Server
und ist über eine bestimmte Dienstadresse (port number,
per default 1099) von Clients ansprechbar
Definiere die Client-Seite: Ein Client kann sich von der registry
eine Fernreferenz (remote reference) holen und über diese
Referenz ein Fernobjekt auf dem Server ansprechen
Kompiliere Server u. Client, führe (mit registry im
Hintegrund) aus
Prof. Dr. Jan Dünnweber, Folie 24 von 45
Verteilte Systeme
Verteilte Java RMI Struktur
Java RMI Programmierbeispiel: Interface
RMI
Client
registry
RMI
Server
RMI
URL
protocol
Beispiel: es soll eine Fernmethode twice implementiert
werden, die den ihr vom Client übergebenen ganzzahligen
Parameter- Wert verdoppelt und als Ergebnis an den Client
zurück iefert
Importieren benötigter Java-Klassenbibliotheken:
Web server
URL protocol
Web server
import java.rmi.∗;
import java.rmi.server.∗;
Client und Server: Definition der Fernschnittstelle:
Server assoziiert seine Fernobjekte mit Namen in der Registry
Registry stellt Referenzen auf Fernobjekte zur Verfügung
Client sucht nach dem Fernobjekt in der Registry, bekommt
eine Remote Reference auf das Fernobjekt und kann danach
die Methoden dieses Fernobjekts aufrufen
Bytecodes können zum dynamischen Nachladen zwischen
Client und Server übertragen werden, mittels URL-Protokollen
(http, ftp, etc.) vom jeweiligen Webserver
Prof. Dr. Jan Dünnweber, Folie 25 von 45
Verteilte Systeme
Beispiel: Implementierung des Fernobjekts im Server (1)
Implementierungsklasse im Server (Server-Klasse)
implementiert Ferninterface RmiExample, indem sie Methode
twice definiert
Java-Vereinbarung: Klassenname = InterfaceName + ”Impl”
public class RmiExampleImpl
extends UnicastRemoteObject implements RmiExample{
public RmiExampleImpl() throws RemoteException{
super();}//Konstruktor UnicastRemoteObject aufrufen
public int twice(int i) throws RemoteException{
return i∗2;}}
Die Implementierungsklasse muß Klasse
UnicastRemoteObject erweitern, derer Konstruktor die
Fernobjekte der Server-Klasse “exportiert”: sie “lauschen”
danach auf Anfragen von Clients, die das gleiche Ferninterface
kennen
Die Kommunikation zwischen Objekten erfolgt über
TCP-Sockets, transparent für den Benutzer!
Prof. Dr. Jan Dünnweber, Folie 27 von 45
Verteilte Systeme
◮
◮
Auf beiden Seiten ein Ferninterface einführen als Erweiterung
des Java Interfaces Remote (tag-interface ohne Methoden)
Das Ferninterface um die Signaturen der gewünschten Fernmethoden erweitern, in unserem Fall – Methode twice()
public interface RmiExample extends Remote {
public int twice(int i) throws RemoteException;}
◮
Jede entfernte Methode muß RemoteException werfen
können (um Netzwerk-spezifische Fehler abzufangen)
Prof. Dr. Jan Dünnweber, Folie 26 von 45
Verteilte Systeme
Beispiel: Implementierung des Fernobjekts im Server (2)
Der Konstruktor der Server-Klasse muß explizit definiert
werden und throws RemoteException beinhalten
Er ruft den Konstruktor von UnicastRemoteObject auf
Remote
"Interface"
UnicastRemoteObject
extends
RmiExample
"Interface"
extends
implements
RmiExampleImpl
Client und Server sind sich nun des Potentials für Fernaufrufe
bewußt:
Client kennt das Ferninterface und die (Fern)Methoden-Namen
Server implementiert die Fernmethoden dieses Interface
Prof. Dr. Jan Dünnweber, Folie 28 von 45
Verteilte Systeme
Beispiel: Erzeugen/Registrieren des Fernobjekts im Server
Registrierung/Suche der Fernobjekte übernimmt
rmiregistry (ein Java Utility Programm) das gleichzeitig
mit dem Server läut
Ein Fernobjekt wird als Instanz der Impl-Klasse erzeugt und
mittels Naming.rebind als TwiceServer auf dem Rechner
bolero registriert (wo die rmiregistry läuft)
public static void main(String[] args) {
RmiExampleImpl example = new RmiExampleImpl();
try {Naming.rebind("//bolero/TwiceServer", example);}
catch (RemoteException re){}}}
Die Klasse Naming gehört zum Package java.rmi
Die allgemeine Syntax ist: //host:port/remoteObjectName,
wobei 1099 die default Portnummer für rmiregistry ist
Zweites Argument von rebind, hier example, ist eine Ref auf
die Objektimplementierung, wo Fernmethoden aufgerufen
werden
Clients können nun nach TwiceServer auf dem Server suchen
Prof. Dr. Jan Dünnweber, Folie 29 von 45
Verteilte Systeme
Beispiel: Fernaufruf im Client
Beispiel: Registrierung – Fortsetzung
Aus Sicherheitsgründen darf bind/rebind nur auf registry des
gleichen Hosts passieren; dagegen darf lookup (Nachschauen
vom Client in registry) von jedem Host aus ausgeführt werden
Methode rebind ändert das Objekt, wenn der Name bereits
benutzt wurde, mit bind bleibt das alte Objekt registriert
Tip: Sobald ein Fernobjekt registriert ist, können seine
Methoden Referenzen auf weitere Fernobjekte liefern.
Dadurch wird mehrfaches Nachschauen vom Client in einer
(entfernten) registry vermieden (Factory Design Pattern)
Auf dem Client, z.B. in der main-Methode, muß der SecurityManager
gesetzt werden: System.setSecurityManager(new
RMISecurityManager());
Prof. Dr. Jan Dünnweber, Folie 30 von 45
Verteilte Systeme
Beispiel: Kompilieren
Alle Klassen mit javac kompilieren
Client erhält eine Fernobjektreferenz von registry und
konvertiert sie (casting) zu RmiExample (Interface, nicht
Klasse!). Danach kann er die im Ferninterface definierten
Methoden aufrufen
Die Server-Klasse RmiExampleImpl mit rmic kompilieren
(spezieller RMI-Compiler): rmic -v1.2 RmiExampleImpl
produziert eine sog. Stub Class:
RmiExampleImpl_Stub.class
import java.rmi.∗;
public class RmiExampleClient {
public void RemoteTwice() {
try{ // holen der Fernobjektreferenz von registry
// IP der registry evtl. Argument von main
RmiExample remintref =
(RmiExample)Naming.lookup("//bolero/TwiceServer");
// Aufruf der entfernten Methode
int ergebnis = remintref.twice(3);}
catch (RemoteException ex){}}
public static void main( String args[]){...}}
Der Client kommuniziert mit Stubs, die als Fernobjekt-Ersatz
dienen. Die Stub-Klasse muß dem Client zugänglich sein (z.B.
über die sog. Codebase auf einem serverseitigen Webserver)
Das Stub-Objekt leitet Client-Fernaufrufe ans RMI-System,
das notwendiges Networking organisiert
Option -v1.2 zeigt, daß wir mit Java2 arbeiten; in Java 1.1
hätte rmic zwei Klassen erzeugt : Stub und Skeleton
Skeleton ist seit Java 1.2 deprecated
Prof. Dr. Jan Dünnweber, Folie 31 von 45
Verteilte Systeme
Prof. Dr. Jan Dünnweber, Folie 32 von 45
Verteilte Systeme
Programmierbeispiel: Ausführen
Starte den Namensdienst im Server (per Default am Port
1099): rmiregistry läuft normalerweise im Hintergrund,
keine Reaktion vom System
Starte das Programm im Server: java RmiExampleImpl &
damit wird ein Fernobjekt erzeugt und bei der registry
registriert, die nun auf Anfragen wartet. Wir starten im
Hintergrund, da beim Erzeugen von UnicastRemoteObject
ein separater Thread gestartet wird, der unbestimmte Zeit
lang arbeitet
Starte das Programm im Client: java RmiExampleClient
Der Client kann so umprogrammiert werden, daß er die
IP-Adresse des Servers als Argument bekommt: java
RmiExampleClient 130.149.17.51
Nachrichtenorienrierte Kommunikation
RPC und RMI erhöhen zwar die Zugriffstranparenz, eignen
sich jedoch nicht für alle Situationen:
◮
◮
wenn nicht vorausgesetzt werden kann, dass beim Absetzen der
Anforderung der Empfänger gerade läuft (Persistenz)
wenn der Client für die Zeit der Bearbeitung nicht blockiert
werden soll (Asynchronität)
Beispiel: Ein Email-System braucht persistente
Kommunikation: Sender-Host und Empfänger-Host können
unabhängig voneinander ein- und ausgeschaltet werden
Beachte: Sogar wenn RMI auf einem Rechner getestet wird,
muß dieser eine aktive TCP/IP Anbindung haben!
Prof. Dr. Jan Dünnweber, Folie 33 von 45
Verteilte Systeme
Beispiel: ein verteiltes E-Mail-System
Prof. Dr. Jan Dünnweber, Folie 34 von 45
Verteilte Systeme
Beispiel: ein verteiltes E-Mail-System
Ein Host führt eine Mail-Applikation aus
Jeder Host ist mit einem Mail-Server verbunden
Mail-Applikation übergibt eine Nachricht an seinen Host, der sie
weiter an den lokalen Mail-Server leitet
Mail-Server nimmt eine Nachricht, schlägt das Ziel nach und erfährt
die Adresse des Ziel-Mail-Servers (Transportebene)
Prof. Dr. Jan Dünnweber, Folie 35 von 45
Verteilte Systeme
Prof. Dr. Jan Dünnweber, Folie 36 von 45
Verteilte Systeme
Beispiel: ein verteiltes E-Mail-System, Forts.
Kommunikationsformen: Persistenz und Synchronität
Mail-Server richtet eine Verbindung ein und übergibt die
Nachricht dem Ziel-Mail-Server
Ziel-Mail-Server speichert die Nachricht in einem Puffer für
den Empfänger (sog. Mailbox des Empfängers)
Ist der Ziel-Mail-Server vorübergehend nicht erreichbar, wird
die Nachricht weiterhin auf dem lokalen Mail-Server
gespeichert
Die Schnittstelle auf dem Empfänger-Host stellt einen Dienst
für das Mail-Programm bereit, mit dem dieser regelmässig
eingehende Mails überprüfen kann
Eingehende Nachrichten werden i.A. auf Mail-Servern,
manchmal auch auf den Hosts gepuffert
Die nächste Folie zeigt verschiedene mögliche Kombinationen von
Asynchronität und Persistenz
Prof. Dr. Jan Dünnweber, Folie 37 von 45
Verteilte Systeme
Transiente Kommunikation: Sockets
Sockets sind eine Schnittstelle direkt zur Transportebene
(TCP/IP) und können als eine Middleware-Lösung betrachtet
werden
Prof. Dr. Jan Dünnweber, Folie 38 von 45
Funktionen für Sockets
Funktion
Socket
Bind
Listen
Accept
Die Funktionen in der Abbildung (socket, bind, listen,
accept/connect, send/receive, close) sind auf der
nächsten Folie erklärt
Verteilte Systeme
Connect
Send
Receive
Close
Bedeutung
Erzeugt einen neuen Kommunikationsendpunkt
Ordnet einem Socket eine lokale Adresse zu
Kündigt die Bereitschaft an, dass Verbindungen akzeptiert werden
Blockiert den Aufrufer, bis eine Verbindungsaufforderung ankommt
Versucht aktiv, eine Verbindung einzurichten
Sendet Daten über die Verbindung
Empfängt Daten über die Verbindung
Gibt die Verbindung frei
Details und Praxis mit Sockets - in der Übung!
Prof. Dr. Jan Dünnweber, Folie 39 von 45
Verteilte Systeme
Prof. Dr. Jan Dünnweber, Folie 40 von 45
Verteilte Systeme
Stream-Orientierte Kommunikation
QoS (Quality of Service) = Dienstgüte
Nicht-funktionale Anforderungen (z.B. zeitabhängige) werden häufig als
QoS-Anforderungen ausgedrückt, z.B.:
Bisher hatten wir Kommunikation zu beliebigen Zeitpunkten
mit voneinander unabhängigen Informationseinheiten
Es gibt Anwendungen wo Timing eine wesentliche Rolle spielt:
◮
◮
Audio: Samples müssen in bestimmter Reihenfolge und mit
Intervallen von genau 1/44100 Sek abgespielt werden
Bei Videos sind die Anforderungen noch strenger
Für derartige Anwendungen werden Data-Streams –
Folgen der Dateneinheiten – gebraucht
Verlustsensibilität und Verlustintervall gibt an, welche maximale
Verlustrate akzeptabel ist, z.B. 1 byte/min
Spitzverlust: wieviele Einheiten nacheinander
verlorengehen dürfen
Min. feststellbare Verzögerung: wie lange das Netzwerk DatenAuslieferung verzögern kann, bevor der Empfänger dies erkennt
Maximale Verzögerungsabweichung: maximal tolerierter Jitter, d.h.
maximale Variation der Zeit, die bei der Auslieferung einer Folge
von Dateneinheitentoleriert wird (für Video und Audio)
Qualitätsgarantie: eine Zahl die angibt, wie ernst die
Dienstanforderungen genommen werden.
Die Anwender können ihre Anforderungen i.d.R. nicht genau formulieren,
deshalb werden sinnvolle Standardwerte bereitgestellt, z.B.: Audio/Video,
Qualität hoch/mittel/gering
Prof. Dr. Jan Dünnweber, Folie 41 von 45
Verteilte Systeme
Streamkommunikation: Synchronisierungsmechanismen
Prof. Dr. Jan Dünnweber, Folie 42 von 45
Verteilte Systeme
Streamkommunikation: Synchronisierungsmechanismen
Explizite Synchronisation auf der niedrigsten Ebene:
◮
◮
Ein Prozess führt Operationen auf den Streams aus und stellt
sicher, dass die Anforderungen erfüllt werden
Nachteil: Die Applikation ist für die Implementierung
verantwortlich, obwohl nur Funktionen auf niedrigster Ebene
zur Verfügung stehen
Synchronisation mit Multimedia-Middleware:
Middleware bietet verschiedene Schnittstellen, um Audio- und
Video-Streams zu steuern
Jedes Gerät hat eigene Schnittstellen, die vom Anwender in
Stream-Verarbeitungsroutinen benutzt werden
Prof. Dr. Jan Dünnweber, Folie 43 von 45
Verteilte Systeme
Prof. Dr. Jan Dünnweber, Folie 44 von 45
Verteilte Systeme
Zusammenfassung
Was haben wir heute gelernt:
Traditionelle Netzwerkapplikationen arbeiten mit
Nachrichtenübergabe auf der niedrigen Transportebene
Middleware-Systeme stellen eine höhere Abstraktionsebene für
Kommunikation bereit, z.B.:
◮
◮
RPC - ermöglicht Zugriffstransparenz, unterstützt jedoch kaum
Referenzen als Parameter
RMI - erweitert RPC auf verteilte Objekte, erlaubt
systemübergreifende Objektreferenzen als Parameter zu
übergeben
Nachrichtenorientierte Middleware-Modelle unterstützen
Persistenz und Asynchronität, die bei RPC/RMI fehlen
Streams: Für Anwendungen wie Audio/Video mit temporären
Beziehungen zwischen zwei aufeinanderfolgenden Nachrichten
Die Anforderungen werden als QoS (Quality of Service) –
Dienstgüte – formuliert
Prof. Dr. Jan Dünnweber, Folie 45 von 45
Verteilte Systeme