Middleware and Distributed Systems
Dr. Martin v. Löwis
Wintersemester 2011/2012
Die Vorlesung am 26.1. beginnt ca. 30 Minuten später.
Die vorläufigen Prüfungstermine sind: 17.2., 23.2., (je A-2.1) 20.3., 21.3., 22.3., 23.3 (je HE-52).
Die Online-Anmeldung zur Prüfung ist mit den per Email versandten
Passwörtern möglich.
Am 3.2. wird um 9:15 in HS3 eine ausgefallene Vorlesung nachgeholt.
Die Donnerstags-Vorlesung findet in Hörsaal 3 statt, die Montags-Vorlesung in Hörsaal 2.
In der Vorlesung liegt der Fokus auf der Vermittlung grundlegender
Wirkmechanismen in Middleware-basierenden verteilten Systemen.
Ausgehend von der Darstellung grundlegender Ansätze (z.B.
Arten der Interprozesskommunikation) sollen die Gemeinsamkeiten
moderner verteilter Infrastrukturen praktisch verdeutlicht werden.
Studenten sollen in die Lage versetzt werden, mit dem Wissen
aus der Vorlesung eigene komplexe verteilte Anwendungen, oder
auch eigene Middleware-Komponenten optimal entwerfen und entwickeln
zu können.
Behandelt werden u.a. folgende Themen:
- Interprozesskommunikation (Schnittstellenbeschreibung, RPC, MOM, strombasierende Kommunikation)
- Entwurfsmuster und Algorithmen in verteilten Infrastrukturen (MDA, Ressourcenmanagement, Microkernel)
- Namensdienste (JNDI, DNS, X.500)
- Registries (UDDI, Corba)
- Architekturmuster (OMA, ESB, SOA)
- Adaptive Middleware
- Sicherheit (u.a. X.509, Kerberos)
- Koordination verteilter Aktivitäten (u.a. Gruppenkommunikation)
- Peer-to-peer-Systeme
- Uhrensynchronisation
- Transaktionen
- Weitverteilte Systeme (Cluster / Grid Computing)
Begleitet wird die Veranstaltung von einem Praktikum, in dem die
Teilnehmer selber Middleware entwickeln. Diese Projekte können allein
oder zu zweit bearbeitet werden; es gibt im Laufe des Semesters
4 Teilaufgaben.
Termine:
Montag, 13:30 - 15:00 Uhr, A-2.1
Donnerstag, 9:15 - 10:45 Uhr, A-2.1
Literatur
- George Coulouris, Jean Dollimore, Tim Kindberg. Distributed Systems
- Andrew S. Tanenbaum. Distributed Operating Systems
Vorlesungen
- Introduction (14.10.2011 19:29:55)
- System Models (14.10.2011 19:26:51)
- Messaging and Remote Procedures (26.10.2011 16:04:36)
- Message-Oriented Middleware (05.12.2011 11:20:19)
- Inter-Prozess Communication With XML (05.12.2011 11:21:25)
- Naming and Directory Services (05.12.2011 11:22:22)
- Patterns (05.12.2011 11:25:16)
- Time (22.02.2012 12:55:21)
- Security (23.01.2012 13:30:08)
- P2P Systems (30.01.2012 13:27:35)
- Fault Tolerance (02.02.2012 08:56:41)
- Transactions (02.02.2012 08:58:09)
- Design of Scalable Server (16.02.2012 16:12:16)
Übungen
Inhalt der Übungen ist die Beschäftigung mit TWP 3.
1. Übung
Vorstellungstermin: 14. 11. 2011 (Anmeldung)
- Implementieren Sie einen Klienten, der das Echo-Protokoll implementiert,
welches wie folgt definiert wird:
protocol Echo = ID 2{
message Request=0{
string text;
}
message Reply=1{
string text;
int number_of_letters;
}
}
In diesem Protokoll sendet der Klient eine Folge von Request-Nachrichten, auf die der
Server mit passenden Reply-Nachrichten antwortet.
- Testen Sie Ihren Klienten gegen den Server, der auf www.dcl.hpi.uni-potsdam.de:80 läuft.
Für diesen Server ist auch ein Logfile verfügbar.
- Extrahieren Sie aus Ihren Klienten eine Bibliothek, die zur Entwicklung von Klienten
und Servern beliebiger Protokolle geeignet sind.
- Wählen Sie ein Compiler-Framework (Empfehlung:
ANTLR), und formulieren Sie in diesem Framework einen Akzeptor für TDL.
- Zusatzaufgabe: Testen Sie Ihren Klienten auch für IPv6 (gegen www.dcl.hpi.uni-potsdam.de:80)
- Hinweis: eine erfolgreiche Kommunikation führt zu diesem Logfile.
2. Übung
Vorstellungstermin: 12. 12. 2011 (Anmeldung)
- Vervollständigen Sie Ihren TDL-Akzeptor zu einem Compiler,
mit dessen Hilfe beliebige TDL-Protokolle implementiert werden
können.
- Implementieren Sie einen Server für das Echo-Protokoll
- Implementieren Sie einen Klienten für die TFS-RPC-Schnittstelle
(TFS=The File System); TFS basiert auf dem TWP-Protokoll 1 (RPC) und
kann durch folgende OMG-IDL-Schnittstelle definiert werden.:
typedef sequence<string> path;
typedef sequence<string> filelist;
struct list_result{
filelist directories;
filelist files;
};
struct stat_result{
long size;
long mtime; /* seconds since the Unix epoch */
long atime;
};
typedef long filehandle;
typedef long monitor_handle;
typedef sequence<octet> binary;
typedef sequence<octet, 16> IPAddress; // length must be 4 or 16
interface TFS{
#pragma version "2.5.08"
/* File reading and writing */
/* path: root directory is an empty sequence */
/* mode: 0 - read-only, 1 - truncate-and-write, 2 - append-write */
filehandle open(in path directory, in string file, in long mode);
binary read(in filehandle fh, in long count);
void write(in filehandle fh, in binary data);
void seek(in filehandle fh, in long offset);
oneway void close(in filehandle fh);
/* File and directory information */
list_result listdir(in path directory);
stat_result stat(in path directory, in string file);
/* File and directory manipulation */
void mkdir(in path directory);
void rmdir(in path directory);
void remove(in path directory, in string file);
/* FAM */
/* recursive: 0 - only this directory, 1 - also subdirectories */
monitor_handle monitor(in path directory, in long recursive,
in IPAddress host, in long port);
void stop_monitoring(in monitor_handle h);
};
Die Implementierung eines TFS-Servers steht Ihnen frei.
- Implementieren Sie eine Version von du(1) für TFS. Testen
Sie Ihren TFS-Klienten gegen www.dcl.hpi.uni-potsdam.de:80
- Implementieren Sie einen Konsumenten für TFS-FAM
(FAM=File Alteration Monitor), welches wie folgt definiert ist:
protocol FAM = ID 4 {
sequence<string> path;
/* Messages sent for file creation, deletion, and change. */
message Changed = 0 {
path directory;
string filename;
}
message Deleted = 1 {
path directory;
string filename;
}
message Created = 2{
path directory;
string filename;
}
/* Messages sent when a file is being executed on the operating system */
message StartExecuting = 3 {
path directory;
string filename;
}
message StopExecuting = 4 {
path directory;
string filename;
}
}
3. Übung
Vorstellungstermin: 16. 1. 2012
Die Vorstellung findet in Form eines Interoperabilitätsworkshops statt.
Die Ergebnisse werden in einem
Spreadsheet
festgehalten.
- Ändern Sie Ihren TFS-Klienten derart, dass die Verbindung zum Server
auf Grund des DNS-SRV-Eintrags für tfs.dcl.hpi.uni-potsdam.de erstellt wird.
Verwenden Sie dazu eine geeignete DNS-Bibliothek oder entwickeln Sie
einen eigenen DNS-Klienten.
- Fügen Sie in einen öffentlich sichtbaren DNS-Server Ihrer Wahl
einen Datensatz Ihrer Wahl ein.
-
Definieren und registrieren Sie eine TWP-Erweiterung zur Kommunikation
logischer Thread-Kennungen. Diese Thread-Kennungen sollen zur Verfolgung
von RPC-Aufrufen im verteilten System, insbesondere zur Erkennung von
Rekursionen geeignet sein. Zur Registrierung benötigen Sie ein
DFN-Zertifikat (bevorzugter Termin für die Ausweiskontrolle: Fr, 6.1.12, 14:00-16:00).
Die HPI Pub CA ist gegenwärtig außer Funktion.
-
Implementieren Sie Server und Client für das Calculator-Protokoll,
und berechnen Sie mit Hilfe Ihrer Implementierung (6!+3)*4. Beachten Sie insbesondere die
Unterstützung extern implementierter Operationen.
Zur Vereinfachung der Interoperabilität werden für den Workshop die folgenden Well-Known Ports
vorgeschlagen:
+ 9001
* 9002
! 9003
- 9004
/ 9005
pow 9006
sin 9007
cos 9008
tan 9009
pi 9010
e 9011
sqrt 9012
*(-1) 9013
Bestehende Dienste sollten diese Ports benutzen, allerdings ist die Implementierung aller
Dienste nicht erforderlich.
-
Erweitern Sie Ihre Server-Implementierung um logische Thread-Kennungen, und
um eine Trace-Funktionalität, die einen gegebenen
Logging-Dienst
mit Daten beliefert. Wahlweise können Sie Ihren eigenen Logging-Dienst realisieren,
oder den auf www.dcl.hpi.uni-potsdam.de:80 vorhandenen verwenden
(Logfile). Jeder Logging-Dienst stellt den
Zusammenhang multipler Datensätze anhand logischer Thread-Kennungen dar.
- Zusatzaufgabe (TWP-Shootout): Messen Sie die Laufzeit (wall-clock time)
er folgenden Szenarien des Echo-Protokolls, auf einem Testsystem Dell XXX
(z.B. in C-1.15):
- 100000 EchoRequests mit Leerstring an einen lokalen Server
- 1000 EchoRequests mit Leerstring an www.dcl.hpi.uni-potsdam.de
- 10000 EchoRequests mit Strings von 10000 Leerzeichen an einen lokalen Server
(Antwort: gleicher String, 0 als Zahl der Buchstaben, muss nicht berechnet werden.
Senden Sie Ihre Messergebnisse an martin.vonloewis@hpi.uni-potsdam.de; die
Veröffentlichung der Ergebnisse
erfolgt am Abgabetag.
4. Übung
Vorstellungstermin: 9. 2. 2011 (Anmeldung)
- Erweitern Sie ihre TWP-Protokollimplementierung derart, dass die Signierung ganzer TWP-Nachrichten unterstützt wird.
Ein Client sendet dafür vor der eigentlichen Nachricht das Zertifikat als
eigene Extension-Nachricht.
Es können mehrere Zertifkate gesendet werden, in diesem Fall wird
das letzte Zertifikat verwendet. Die Signatur
wird aus den kodierten TWP-Daten der Nachrichtenfelder ermittelt.
Berücksichtigen Sie die möglichen
Authentifizierungsfehler.
Um die Kompatibilität der verwendeten PKI-Bibliothek zu prüfen, stehen Ihnen Testdaten zur Verfügung:
Zertifikat (Passphrase: <Leerstring>),
Klartext-Daten,
Korrekte Signatur
- Integrieren Sie die Überprüfung von Signaturen in Ihren TCP-Server,
und testen Sie Signatur von Calculator-Request-Nachrichten.
- Testen sie Ihre Implementierung mit dem Echo-Server auf www.dcl.hpi.uni-potsdam.de:80.
Der Server akzeptiert nur Zertifikate, die entweder von der "HPI Pub CA"
oder von der "Universitaet Potsdam CA - G01" ausgestellt wurden.
|