Slide 1 Slide 2 Zwei wesentliche Arten von Protokollen

2. KOMMUNIKATION
IN VER TEILTEN
P ROTOKOLLSTAPEL
S YSTEMEN
OSI
➜ Das OSI-Modell enthält sieben Schichten (Protokollstapel)
➜ Anmerkung: Die OSI-Schichten sind methodisch hilfreich, die
OSI-Protokolle wurden jedoch nie wirklich gebräuchlich
➜ Jedes verteilte System erfordert Kommunikationsmöglichkeit
➜ Die Kommunikation basiert auf der Nachrichtenübergabe auf
unterster Ebene (Netzwerk), da es nur selten einen
gemeinsamen Speicher gibt
Slide 1
IN
➜ Bei Tausenden/Millionen von Prozessen in einem großen
verteilten System, ist es unmöglich, verteilte Anwendungen auf
dieser niedrigen Abstraktionsebene zu entwickeln
Slide 3
➜ Dazu ist das Netzwerk oft unzuverlässig, wie z. B. 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
AUSTAUSCH
VON
N ACHRICHTEN : P ROTOKOLLE
P ROTOKOLL -S CHICHTEN , OSI-M ODELL
➜ Das Schichtenmodell soll einen Überblick über das Ablaufen der
Kommunikation zwischen zwei Prozessen in einem VS geben:
➜ 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:
Slide 2
•
•
•
•
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
Slide 4
• 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
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.
c
2006
BY
S ERGEI G ORLATCH · U NI M ÜNSTER · V ERTEILTE S YSTEME · VORLESUNG 2
1
c
2006
BY
S ERGEI G ORLATCH · U NI M ÜNSTER · V ERTEILTE S YSTEME · VORLESUNG 2
2
• Ganz unten im Protokollstapel überträgt die Bitübertragungsschicht die Nachricht mit allen Headern und Trailern
OSI-S CHICHTEN : T RANSPOR TPROTOKOLLE
• Auf der Empfänger-Maschine wird die Nachricht von unten
nach oben weitergereicht
➜ Transportschicht macht das Netzwerk dem Anwender
zugänglich
• Dabei entfernt jede Schicht den für sie vorgesehenen
Header/Trailer und wertet ihn aus
Slide 5
➜ Sichert verlustfreie Lieferung der Nachricht
➜ Die Idee von Schichten mit eigenen Protokollen an einem
Beispiel aus der Wirtschaft:
➜ Baut auf verbindungsorientierten oder -losen Netzwerkdiensten
Slide 7
• Zwei Chefs und ihre Sekretärinnen
➜ Zwei wichtigste Transportprotokolle:
• TCP (Transport Control Protocol): verbindungsorientiert
• Die Sekretärinnen verwenden Fax als technisches Protokoll
für Bestellungen, ohne über Inhalt nachzudenken
• UDP (Universal Datagram Protocol): verbindungslos
➜ TCP funktioniert zuverlässig, verursacht jedoch mehr Overhead
• Die Chefs entscheiden über ihren Inhalt (telefonisch, beim
Golfen, etc.), ohne über die Bestellungsabwicklung
nachzudenken
➜ TCP bei Client-Server:
• Die beiden Protokolle können unabhängig voneinander
ausgetauscht werden
OSI-S CHICHTEN : U NTERSTE E BENE
➜ Bitübertragungsschicht: überträgt 0s und 1s. Das Protokoll
bestimmt unter anderem:
• wieviele Bits pro Sekunde
• eine oder beide Richtungen
Slide 6
➜ Sicherungsschicht: gruppiert die Bits in Frames, erkennt
mögliche Übertragungsfehler und korrigiert sie:
Slide 8
• 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)
• Das gebräuchlichste Protokoll – verbindungsloses IP (Internet
Protocol)
c
2006
BY
S ERGEI G ORLATCH · U NI M ÜNSTER · V ERTEILTE S YSTEME · VORLESUNG 2
3
c
2006
BY
S ERGEI G ORLATCH · U NI M ÜNSTER · V ERTEILTE S YSTEME · VORLESUNG 2
4
RPC: KONVENTIONELLER P ROZEDURAUFRUF
OSI-S CHICHTEN : H ÖHERE E BENE
➜ 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
➜ 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:
Slide 9
Slide 11
• 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
E NTFERNTER P ROZEDURAUFRUF (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 auf den Stack gelegt
• Die Parameter werden zur ausführenden Maschine geschickt
Slide 10
• Das Ergebnis wird an die aufrufende Maschine
zurückgebracht
Slide 12
• Die Kommunikation passiert implizit, d.h. unsichtbar für den
Programmierer
➜ 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
➜ 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
c
2006
BY
S ERGEI G ORLATCH · U NI M ÜNSTER · V ERTEILTE S YSTEME · VORLESUNG 2
5
c
2006
BY
S ERGEI G ORLATCH · U NI M ÜNSTER · V ERTEILTE S YSTEME · VORLESUNG 2
6
RPC: C LIENT-
UND
S ERVER -S TUBS
➜ Ziel des RPC: Transparenz, d.h. entfernter Aufruf soll möglichst
wie lokaler aussehen
➜ 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
Slide 13
Slide 15
➜ An der Client-Maschine wertet der Client-Stub die Nachricht
aus, packt das Ergebnis aus und kopiert es an seinen Aufrufer
➜ Der Aufrufer erhält die Steuerung zurück, er weiß dass der Aufruf
erledigt ist, weiß aber nicht wie (bzw. dass entfernt erledigt)
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
➜ 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)
➜ Im Server übergibt BS die Nachricht an den Server-Stub
RPC: PARAMETER ÜBERGABE
➜ Beispiel: Entfernter Aufruf von add(i,j):
UND
IDL
Die Parameterübergabe bei RPC ist nicht unproblematisch:
➜ Einfache Datenelemente (Zahlen, Zeichen, etc.) haben
verschiedene Darstellungen auf unterschiedlichen
Maschinentypen: Zeichencode, Bytenummerierung, usw.
➜ Eine Referenz (bzw. ein Zeiger):
Slide 16
Slide 14
➜ Fazit: Beide Seiten müssen dasselbe Protokoll verwenden, inkl.
Daten- und Nachrichtenformate. Das Erstellen von Stubs wird
mit IDL (Interface Definition Language) vereinfacht
➜ Server-Stub packt die Parameter aus und führt einen lokalen
Aufruf auf dem Server aus
c
2006
BY
S ERGEI G ORLATCH · U NI M ÜNSTER · V ERTEILTE S YSTEME · VORLESUNG 2
• 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
7
c
2006
BY
S ERGEI G ORLATCH · U NI M ÜNSTER · V ERTEILTE S YSTEME · VORLESUNG 2
8
RMI: Remote Method Invocation (E NTFERNTER M ETHODENAUFRUF )
➜ Das RPC kann auf die Objektorientierung übertragen werden,
was seine Verteilungstranparenz zusätzlich verbessert:
Implementierung der Objekt-Schnittstelle – geladen
• Objekte kapseln Daten (Status) und Operationen
(Methoden) ein.
Slide 17
• Client-Stub verpackt Methoden-Aufrufe in Nachrichten an
den Server
• Methoden werden über eine Schnittstelle bereitgestellt
Slide 19
• Die Unterscheidung “Schnittstelle vs. Objekt” erlaubt eine
Schnittstelle auf einer Maschine abzulegen und das
eigentliche Objekt auf einer anderen Maschine
• Server-Stub (Skeleton im Bild) packt Nachrichten aus und ruft
Methoden auf
➜ 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.
• Diese Anordnung wird als “verteiltes/entferntes Objekt”
bezeichnet, und bedeutet i.d.R. nicht, dass ein Objekt
physisch über mehrere Maschinen verteilt ist
RMI: O BJEKTREFERENZEN
➜ 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
Slide 20
Slide 18
➜ Objektreferenz enthält Information zum Auffinden des Objekts:
Netzwerkadresse der Maschine, Port des Servers, Hinweis auf
das Objekt, etc.
➜ 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
➜ Der Client muss sich zum entfernten Objekt binden, was in vielen
Systemen automatisch passiert:
• In den Adressraum wird ein Client-Stub (Proxy im Bild) – eine
c
2006
BY
S ERGEI G ORLATCH · U NI M ÜNSTER · V ERTEILTE S YSTEME · VORLESUNG 2
9
c
2006
BY
S ERGEI G ORLATCH · U NI M ÜNSTER · V ERTEILTE S YSTEME · VORLESUNG 2
10
RMI: U NTERSCHIEDE
RPC
➜ RMI erlaubt beliebige Objekte (dagegen: RPC nur einfache
Datentypen!) als Argumente eines entfernten Aufrufs:
RMI: PARAMETER ÜBERGABE
➜ 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
Slide 21
ZU
Slide 23
➜ Effizienz halber unterscheidet man zwischen entfernten und
lokalen Objektreferenzen (s. nächste Folie):
• 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
➜ Javas Garbage Collection ist auf entfernte Objekte erweitert
➜ Beispiel: Java RMI ist eine reine Java-Angelegenheit:
• 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
• 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
JAVA RMI: Ü BERSICHT
DER WICHTIGSTEN
S CHRITTE
➀ Definiere ein für Client und Server gemeinsames Ferninterface
(remote interface), in dem die Signaturen der entfernt
aufrufbaren Methoden enthalten sein müssen
Slide 22
Slide 24
➁ Definiere die Server-Seite:
➜ 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
c
2006
BY
S ERGEI G ORLATCH · U NI M ÜNSTER · V ERTEILTE S YSTEME · VORLESUNG 2
11
c
2006
BY
S ERGEI G ORLATCH · U NI M ÜNSTER · V ERTEILTE S YSTEME · VORLESUNG 2
12
V ER TEILTE JAVA RMI S TRUKTUR
RMI
Client
B EISPIEL : I MPLEMENTIERUNG
RMI
Web server
URL protocol
RMI
URL
protocol
IM
S ERVER (1)
public c l a s s RmiExampleImpl
extends UnicastRemoteObject implements RmiExample {
public RmiExampleImpl ( ) throws RemoteException {
Web server
Slide 25
super ( ) ; } / / K o n s t r u k t o r UnicastRemoteObject aufrufen
Slide 27
➜ 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
public i n t twice ( i n t 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!
JAVA RMI P ROGRAMMIERBEISPIEL : I NTERFACE
B EISPIEL : I MPLEMENTIERUNG
➜ Beispiel: es soll eine Fernmethode twice implementiert werden,
die den ihr vom Client übergebenen ganzzahligen ParameterWert verdoppelt und als Ergebnis an den Client zurück iefert
➜ Importieren benötigter Java-Klassenbibliotheken:
DES
F ERNOBJEKTS
IM
S ERVER (2)
➜ Der Konstruktor der Server-Klasse muß explizit definiert werden
und throws RemoteException beinhalten
➜ Er ruft den Konstruktor von UnicastRemoteObject auf
import java . rmi . ∗ ;
Remote
"Interface"
import java . rmi . s e r v e r . ∗ ;
Slide 26
F ERNOBJEKTS
➜ Implementierungsklasse im Server (Server-Klasse) implementiert
Ferninterface RmiExample, indem sie Methode twice definiert
➜ Java-Vereinbarung: Klassenname = InterfaceName + ”Impl”
registry
Server
DES
➜ Client und Server: Definition der Fernschnittstelle:
Slide 28
• Auf beiden Seiten ein Ferninterface einführen als Erweiterung
des Java Interfaces Remote (tagging interf. ohne Methoden)
• Das Ferninterface um die Signaturen der gewünschten Fernmethoden erweitern, in unserem Fall – Methode twice()
UnicastRemoteObject
extends
RmiExample
"Interface"
extends
implements
RmiExampleImpl
public interface RmiExample extends Remote {
public i n t twice ( i n t i ) throws RemoteException ; }
➜ Client kennt das Ferninterface und die (Fern)Methoden-Namen
• Jede entfernte Methode muß RemoteException werfen
können (um Netzwerk-spezifische Fehler abzufangen)
c
2006
BY
S ERGEI G ORLATCH · U NI M ÜNSTER · V ERTEILTE S YSTEME · VORLESUNG 2
Client und Server sind sich nun des Potentials für Fernaufrufe bewußt:
➜ Server implementiert die Fernmethoden dieses Interface
13
c
2006
BY
S ERGEI G ORLATCH · U NI M ÜNSTER · V ERTEILTE S YSTEME · VORLESUNG 2
14
B EISPIEL : E RZEUGEN /R EGISTRIEREN
DES
F ERNOBJEKTS
IM
S ERVER
B EISPIEL : F ERNAUFRUF
➜ 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)
import java . rmi . ∗ ;
public c l a s s RmiExampleClient {
public void RemoteTwice ( ) {
RmiExampleImpl example = new RmiExampleImpl ( ) ;
t r y {Naming . rebind ( ” / / bolero / TwiceServer ” , example ) ; }
try{
Slide 31
RmiExample r e m i n t r e f =
➜ Die Klasse Naming gehört zum Package java.rmi
( RmiExample )Naming . lookup ( ” / / bolero / TwiceServer ” ) ;
➜ Die allgemeine Syntax ist: //host:port/remoteObjectName,
wobei 1099 die default Portnummer für rmiregistry ist
/ / Aufruf der entfernten Methode
i n t ergebnis = r e m i n t r e f . twice ( 3 ) ; }
➜ Zweites Argument von rebind, hier example, ist eine Ref auf die
Objektimplementierung, wo Fernmethoden aufgerufen werden
catch ( RemoteException ex ){}}
public s t a t i c void main( S t r i n g args [ ] ) { . . . } }
➜ Clients können nun nach TwiceServer auf dem Server suchen
B EISPIEL : KOMPILIEREN
B EISPIEL : R EGISTRIERUNG – F OR TSETZUNG
➜ Alle Klassen mit javac kompilieren
➜ 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
➜ Die Server-Klasse RmiExampleImpl mit rmic kompilieren
(spezieller RMI-Compiler):
➜ Methode rebind ändert das Objekt, wenn der Name bereits
benutzt wurde, mit bind bleibt das alte Objekt registriert
rmic -v1.2 RmiExampleImpl
produziert eine sog. Stub Class: RmiExampleImpl_Stub.class
➜ 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)
Slide 32
➜ 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
System.setSecurityManager(new RMISecurityManager());
BY
S ERGEI G ORLATCH · U NI M ÜNSTER · V ERTEILTE S YSTEME · VORLESUNG 2
➜ 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
Auf dem Client, z.B. in der main-Methode, muß der
SecurityManager gesetzt werden:
c
2006
/ / holen der Fernobjektreferenz von r e g i s t r y
/ / I P der r e g i s t r y e v t l . Argument von main
catch ( RemoteException re ){}}}
Slide 30
C LIENT
➜ 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
public s t a t i c void main( S t r i n g [ ] args ) {
Slide 29
IM
15
c
2006
BY
S ERGEI G ORLATCH · U NI M ÜNSTER · V ERTEILTE S YSTEME · VORLESUNG 2
16
B EISPIEL :
P ROGRAMMIERBEISPIEL : AUSF ÜHREN
Slide 33
EIN VER TEILTES
E-M AIL -S YSTEM
➜ Starte den Namensdienst im Server (per Default am Port 1099):
rmiregistry &
➜ Ein Host führt eine Mail-Applikation aus
läuft normalerweise im Hintergrund, keine Reaktion vom System
➜ Starte das Programm im Server:
java RmiExampleImpl &
➜ Mail-Applikation übergibt eine Nachricht an seinen Host, der sie
weiter an den lokalen Mail-Server leitet
➜ Jeder Host ist mit einem Mail-Server verbunden
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:
Slide 35
java RmiExampleClient 130.149.17.51
➜ Beachte: Sogar wenn RMI auf einem Rechner getestet wird,
muß dieser eine aktive TCP/IP Anbindung haben!
➜ Mail-Server nimmt eine Nachricht, schlägt das Ziel nach und
erfährt die Adresse des Ziel-Mail-Servers (Transportebene)
➜ Mail-Server richtet eine Verbindung ein und übergibt die
Nachricht dem Ziel-Mail-Server
N ACHRICHTENORIENRIER TE KOMMUNIKATION
➜ RPC und RMI erhöhen zwar die Zugriffstranparenz, eignen sich
jedoch nicht für alle Situationen:
Slide 34
➜ Ziel-Mail-Server speichert die Nachricht in einem Puffer für den
Empfänger (sog. Mailbox des Empfängers)
• wenn nicht vorausgesetzt werden kann, dass beim Absetzen
der Anforderung der Empfänger gerade läuft (Persistenz)
Slide 36
• 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
➜ 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
c
2006
BY
S ERGEI G ORLATCH · U NI M ÜNSTER · V ERTEILTE S YSTEME · VORLESUNG 2
17
c
2006
BY
S ERGEI G ORLATCH · U NI M ÜNSTER · V ERTEILTE S YSTEME · VORLESUNG 2
18
F UNKTIONEN
Slide 37
Slide 39
F ÜR
S OCKETS
Funktion
Bedeutung
Socket
Erzeugt einen neuen Kommunikationsendpunkt
Bind
Ordnet einem Socket eine lokale Adresse zu
Listen
Kündigt die Bereitschaft an, dass Verbindungen
akzeptiert werden
Accept
Blockiert den Aufrufer, bis eine Verbindungsaufforderung ankommt
Connect
Versucht aktiv, eine Verbindung einzurichten
Send
Sendet Daten über die Verbindung
Receive
Empfängt Daten über die Verbindung
Close
Gibt die Verbindung frei
T RANSIENTE KOMMUNIKATION : S OCKETS
➜ Sockets sind eine Schnittstelle direkt zur Transportebene (TCP/IP)
und können als eine Middleware-Lösung betrachtet werden
S TREAM -O RIENTIER TE KOMMUNIKATION
➜ Bisher hatten wir Kommunikation zu beliebigen Zeitpunkten mit
voneinander unabhängigen Informationseinheiten
➜ Es gibt Anwendungen wo Timing eine wesentliche Rolle spielt:
Slide 38
Slide 40
• 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
➜ Die Funktionen in der Abbildung (socket, bind, listen,
accept/connect, send/receive, close) sind auf der
nächsten Folie erklärt
➜ Details und Praxis mit Sockets - in der Übung!
c
2006
BY
S ERGEI G ORLATCH · U NI M ÜNSTER · V ERTEILTE S YSTEME · VORLESUNG 2
19
c
2006
BY
S ERGEI G ORLATCH · U NI M ÜNSTER · V ERTEILTE S YSTEME · VORLESUNG 2
20
Q O S (Q UALITY
OF
S ERVICE ) = D IENSTG ÜTE
Nicht-funktionale Anforderungen (z.B. zeitabhängige) werden
häufig als QoS-Anforderungen ausgedrückt, z.B.:
➜ Verlustsensibilität und Verlustintervall gibt an, welche maximale
Verlustrate akzeptabel ist, z.B. 1 byte/min
➜ Spitzverlust: wieviele Einheiten nacheinander verlorengehen dürfen
Slide 41
➜ Min. feststellbare Verzögerung: wie lange das Netzwerk DatenAuslieferung verzögern kann, bevor der Empfänger dies erkennt
Slide 43
➜ 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.
• Middleware bietet verschiedene Schnittstellen, um Audiound Video-Streams zu steuern
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
• Jedes Gerät hat eigene Schnittstellen, die vom Anwender in
Stream-Verarbeitungsroutinen benutzt werden
Z USAMMENFASSUNG
Was haben wir heute gelernt:
➜ Traditionelle Netzwerkapplikationen arbeiten mit
Nachrichtenübergabe auf der niedrigen Transportebene
S TREAMKOMMUNIKATION : S YNCHRONISIERUNGSMECHANISMEN
➜ Middleware-Systeme stellen eine höhere Abstraktionsebene für
Kommunikation bereit, z.B.:
➜ Explizite Synchronisation auf der niedrigsten Ebene:
• Ein Prozess führt Operationen auf den Streams aus und stellt
sicher, dass die Anforderungen erfüllt werden
Slide 42
Slide 44
• Nachteil: Die Applikation ist für die Implementierung
verantwortlich, obwohl nur Funktionen auf niedrigster Ebene
zur Verfügung stehen
• 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
➜ Synchronisation mit Multimedia-Middleware:
➜ 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
c
2006
BY
S ERGEI G ORLATCH · U NI M ÜNSTER · V ERTEILTE S YSTEME · VORLESUNG 2
21
c
2006
BY
S ERGEI G ORLATCH · U NI M ÜNSTER · V ERTEILTE S YSTEME · VORLESUNG 2
22