Grundlagen verteilter Systeme

Transkript

1 Universität Augsburg Insitut für Informatik Prof. Dr. Bernhard Bauer Wolf Fischer Christian Saad Wintersemester 08/09 Übungsblatt 1: Lösungsvorschlag Grundlagen verteilter Systeme Lösungsvorschlag Aufgabe 1 Es liegt ein -system als Kommunikationssystem zwischen zwei Clients und zwei Servern vor: Abbildung 1: Kommunikationssystem a) Vervollständigen Sie den Aufbau des -systems aus Abbildung 1. (1,5 Punkte) b) Beim SMTP-Versand von s bestehen mehrere verschiedene Verbindungen: Die initiale Verbindung vom Client zum (Relay-)Server hat folgende Eigenschaften: Ist der (Relay-)Server nicht erreichbar, wird dies dem Benutzer mitgeteilt und weitere Verbindungsversuche nicht unternommen. Der Benutzer kann die dann löschen oder für einen späteren (manuellen) Versuch abspeichern. Ist die beim SMTP-Relay (Versandserver) angekommen, wird dort versucht, die an den Zielserver zuzustellen. Sofern dieser nicht erreichbar ist, wird die Nachricht gepuffert und regelmäßig erneut versucht, diese zuzustellen. Entscheiden Sie für diese beiden Fälle, ob die Kommunikation transient oder persistent ist und geben Sie eine kurze Begründung. (2 Punkte) c) Weisen Sie folgenden Protokollen jeweils zu, ob diese transient oder persistent sind: (1 Punkt) HTTP NTP d) Wir wollen uns nun für zwei Methoden überlegen ob sie synchron oder besser asynchron implementiert werden. Fest steht, dass beide Methoden entfernt (also nicht auf der lokalen Maschine) aufgerufen werden. Bei der ersten Funktion handelt es sich um eine Authentifizierungsmethode für einen gesicherten Bereich, der wir als Parameter einen Benutzernamen sowie ein Passwort übergeben. Wir 1

2 erwarten als Rückgabewert der Methode true oder f alse je nach Ausgang der Authentifizierung. Die zweite Methode soll der Übertragung einer Datei auf einen Drucker dienen. Als Rückgabewert erwarten wir ebenfalls einen Boolean-Wert, nämlich ob die Datei gedruckt werden konnte, oder nicht. Entscheiden Sie, welche Methode Sie wie implementieren würden und zeichnen Sie ein Diagramm wie im Script, in dem der Verlauf zwischen dem Client (aufrufenden Host) sowie Server dargestellt wird. (4 Punkte) 1. Sending und receiving Host sind Clients, die über die Kommunikationsserver ( -server) Nachrichten austauschen. 2. Der sog. MUA (Mail User Agent) ist für den Aufbau der ersten Verbindung verantwortlich. Dieser versucht eine TCP-Verbindung zu dem im MUA konfigurierten SMTP-Relay aufzubauen, das für den Versand festgelegt wurde. Praktisch alle diese MUAs (Microsoft Outlook, Mozilla Thunderbird/Seamonkey, etc.) brechen den Versand ab, wenn diese Verbindung nicht aufgebaut werden kann. Diese Verbindung ist also zunächst transient. Ab diesem Zeitpunkt ist das SMTP-Relay für den Versand der verantwortlich. Es versucht den für die Ziel-Domain verantwortlichen Host (MX-Server) zu erreichen. Sofern dies nicht möglich ist, weil das Zielsystem nicht erreichbar ist, wird die in eine Queue gelegt und die Zustellung periodisch wiederholt. Diese Verbindung ist also persistent! 3. HTTP ist das Hypertext Transfer Protocol. Damit werden Daten im WWW übertragen. Clients sind u.a. Browser wie Internet Explorer, Firefox, etc. Wie wir aus dem täglichen Umgang mit diesen wissen, wird nichts wiederholt wenn eine Verbindung nicht möglich ist. HTTP ist daher als transient anzusehen. NTP ist das Network Time Protocol und dient dem Abgleich von Uhrzeiten von Computern über ein Netzwerk. Es ist offensichtlich, dass zumindest der einfache Fall eines Uhrzeitabgleichs eine transiente Verbindung erfordert, um die Daten auszutauschen. 2

3 4. Die erste der beiden Methoden zur Authentifizierung sollte synchron implementiert sein. Der aufrufende Host wartet nach Aufruf der Methode auf das Ergebnis und fährt erst danach fort. Begründung: Ohne die Bestätigung ob die Authentifizierung erfolgreich war, macht eine weitere Bearbeitung im Client keinen Sinn. Unter Umständen würde ein Fortfahren zu Sicherheitsrisiken führen falls den Benutzer nicht berechtigt war. In jedem Fall wäre ein Fortfahren auch eine unnötige Verschwendung von Ressourcen für den Fall einer erfolglosen Authentifizierung. Die zweite Methode zur Datenübertragung an einen Drucker wäre hingegen besser asynchron implementiert, um Folgeaufträge verarbeiten zu können auch wenn der Drucker noch nicht mit vorherigen Aufträgen fertig ist, beispielsweise weil sich dieser noch in einer Aufwärmphase befindet. Für den Fall dass der Druckauftrag nicht entgegengenommen werden kann, müssen dafür alle relevanten Daten beim aufrufenden Host gesichert werden. Antwortet die Empfangsstelle positiv (durch ein returnierendes,,true ), können diese Daten gelöscht werden. Aufgabe 2 a) Welche initialen drei (Berkley-Sockets-) Methoden müssen auf einem Server ausgeführt werden, bevor ein Client eine Verbindung zu diesem aufbauen kann? Wie heisst diese Methode zum Annehmen einer Client-Verbindung? (2 Punkte) b) Nennen Sie Nachteile des OSI-Schichtenmodells und überlegen Sie, welche dieser Probleme auf welche Weise durch MPI und MOM zum Teil gelöst wurden. (2 Punkte) c) Erläutern Sie die vier Kombinationen locker gekoppelter Kommunikation in einer MOM. Beziehen Sie Router in Ihre Überlegungen mit ein. (5 Punkte) d) Transparenz ist eines der zentralen Konzepte in verteilten Systemen. Nennen Sie das Hauptziel von Transparenz für den Benutzer sowie die vier Transparenz-Features einer Middleware. (3 Punkte) e) Erläutern Sie die Funktionsweise eines Message Channel Agent wie auch den Einsatz einer Alias-Tabelle innerhalb eines Warteschlangenmanagers der IBM MQSeries. (3 Punkte) 1. Erstellen eines Socket als Endpunkt einer Verbindung ( socket ) Übergeben des Ports, auf dem zu hören ist ( bind ) Aktivieren des Abhörens ( listen ) Die Methode zum Akzeptieren einer Verbindung heisst accept 3

4 2. Berkley Sockets liegen auf einer niedrigeren Abstraktionsebene als MPI und MOM und stellen grundlegende Funktionen der Nachrichtenübertragung bereit. Für viele Anwendungen benötigt man wiederkehrende Funktionalitäten, die in Bibliotheken wie MPI oder MOM wiederholt eingebunden werden können. Beispielsweise kann MPI an einer Teilnahme registrierte Prozesse in Gruppen sortieren. Mit Berkley-Sockets wäre das natürlich auch möglich, allerdings schlicht mehr zu tun. Berkley-Sockets sind auf die Kommunikation über TCP/IP oder UDP/IP ausgelegt und können nicht mit proprietären Protokollen verbunden werden. Daher wurde für die transiente Kommunikation zwischen parallelen Applikationen MPI entwickelt, dass auch andere darunter liegende Protokolle zur Kommunikation verwenden kann. MOM biete im Gegensatz zu MPI und Berkley-Sockets persistente und asynchrone Kommunikation, wodurch weder Sender oder Empfänger bei der Nachrichtenübertragung aktiv sein müssen. Vor- und Nachteile des OSI-Schichtenmodells: Vorteile: Hoher Abstraktionsgrad: Die Applikation muss sich nicht um die Aufgaben der anderen Schichten kümmern, sondern kann die Schnittstelle der unteren Schicht benutzen. Austauschbarkeit und Wiederverwendbarkeit: Protokolle auf Ebene n sind völlig autark von den Schichten n + 2 bzw. n 2. So können Schichten ohne allzu großen Änderungen ausgetauscht werden. Beispiel: Ein Programm auf OSI-Schicht 7 (z.b. -Client) muss natürlich nicht geändert werden, wenn sich beispielsweise die Schicht 1/2 ändert. Reduzierung eines schwer lösbaren Problems auf einfachere Teilprobleme. Nachteile: Protokoll-overhead pro Schicht: SMTP, TCP, IP, Ethernet, etc. Kann für gewisse Applikationen zu langsam sein. 3. Sender/Empfänger aktiv: Durch put werden Nachrichten in den Puffer des Senders geschrieben und an den Eingangspuffer eines Relays übertragen. Falls der Relay (Router) den Empfänger nicht direkt kennt, wird die Nachricht anhand von Routingtabellen über einen Ausgangspuffer an weitere Router weitergeleitet, bis der Empfänger bekannt ist. Der Empfänger kann sich sich über neue Nachrichten benachrichtigen lassen (notify) oder den Puffer blockierend (get) und nicht blockierend (poll) abfragen und somit die Nachricht empfangen. Sender aktiv: Nachrichten können, wie beschrieben, an den nachliegenden Router des Empfängers weitergeleitet werden und bleiben dort gespeichert, bis der Empfänger aktiv wird. Empfänger aktiv: Es werden keine neuen Nachrichten an das System übergeben. Der Empfänger kann allerdings die Nachrichten, wie oben beschrieben, aus dem System entnehmen. Sender/Empfänger inaktiv: In diesem Fall werden die Nachrichten an die passenden Router und Puffer gesendet. Es werden keine neuen Nachrichten erzeugt und keine aus dem System entnommen. 4

5 4. Transparenz in verteilten Systemen sorgt dafür, dass dem Benutzer verborgen wird, dass die Ausführung von Operationen (möglicherweise physikalisch) verteilt erfolgt. Die vier Features einer Middleware zur Herstellung von Transparenz lauten: Transparenz bzgl. der Lokalität Transportprotokoll-Transparenz Transparenz der Hardware sowie Betriebssystemen Transprenz bzgl. der verwendeten Programmiersprachen 5. Alias: Da Warteschlangen-Manager einen systemübergreifenden eindeutigen Namen haben müssen, kommt es beim Austausch und oder Namensänderung eines Warteschlangen- Managers zu Auswirkungen auf alle die Nachrichten an ihn senden. Durch lokale Aliasse wird dies abgemildert, indem nur ein Eintrag in einer Routingtabelle geändert werden muss und dementsprechend der Alias gesetzt wird. Alias = alter Name und wird mit dem neuen Namen in die Tabelle eingetragen. Aufgabe 3 MCA: Jedes der beiden Enden eines Nachrichtenkanals wird durch einen Message Channel Agent (MCA) verwaltet. Der sendende MCA überprüft ständig die Sende-Warteschlangen und verpackt sie entsprechend der Transportebene und sendet das Paket über die Verbindung an den empfangenden MCA. Dieser wartet auf eingehenden Pakete, entpackt sie und speichert sie in der entsprechenden Warteschlange. Die Datenübertragung in einem verteilten System kann auf verschiedene Arten stattfinden. In Abbildung 2 ist ein System dargestellt, dessen Datenübertragung durch eine Middleware für nachrichtenorientierte Kommunikation realisiert ist. Gehen Sie davon aus, dass Applikation 1 (App1) eine Nachricht an Applikation 3 (App3) schickt und so lange blockiert, bis sie eine Rückantwort erhält. Die von Applikation 1 gesendete Nachricht hat folgenden Pseudoaufbau: WM3 A Request 1. Geben Sie den Weg der Nachricht ausgehend von App1 sowie die Rückantwort textuell an. (Bsp.: App2, WM2, WS2, WM3, A, App3) (2 Punkt) 2. Geben Sie die Antwortnachricht im gleichen Pseudoformat wie den Request an (1 Punkte) 3. Gehen Sie davon aus, dass der Warteschlangenmanager 3 (WM3) in WM5 umbenannt wird. Welches Problem entsteht? Kann das Problem gelöst werden? Wenn ja, wie? (2 Punkte) 4. Um welche Art der nachrichtenorientierten Kommunikation handelt es sich bei der skizzierten Kommunikation? (2 Punkte) 1. Wege: Hinweg: App1, WM1, WS2, WM3, A, App3 Rückweg: App3, WM3, WS1, WM2, WS1, WM1, B, App1 5

6 Abbildung 2: MOM 2. Antwortnachricht WM1 B Response 3. Änderungsaufwand in jeder Applikation, die Nachrichten an Applikation 3 schickt. Lösung: lokale Alias-Tabelle. Applikation kennt nur Alias eines Warteschlangenmanagers. Bei Veränderung des Namens muss nur die Tabelle und nicht die Applikation angepasst werden. 4. Antwortbasierte persistente synchrone Kommunikation. Aufgabe 4 a) Diskutieren Sie den Einsatz eines Warteschlangensystems für Multimedia- und Daten-Streams. Bedenken Sie dabei vor allem die Timing-Aspekte bei genannten Streams. (3 Punkte) b) Ordnen Sie den folgenden Streams ihren Übertragungsmodus zu und geben Sie eine kurze Begründung an: (je 0,5 Punkte) Film (getrennte Streams, davon 2 Audio (mono) Streams) Musik (mono) Datei Diashow Diashow mit Musik (stereo) 1. Warteschlangensysteme können für Streams mit asynchronen Übertragungsmodus eingesetzt werden, da keine weiteren Timing Aspekte gefordert werden, sondern nur die Reihenfolge 6

7 berücksichtigt werden muss. Die FIFO-Wartenschlangen garantieren unter einem fehlerfreien System die korrekte Auslieferung hinsichtlich der Reihenfolge. Beim synchronen und isochronen Übertragungsmodus sind Timing Aspekte entscheidend, wodurch Warteschlangensysteme nicht ohne weiteres eingesetzt werden können. 2. Film (getrennte Streams, davon 2 Audio (mono) Streams): isochroner Übertragungsmodus, aufgrund der Timing Aspekte zwischen den beiden Audio-Streams und dem Movie- Stream. Musik (mono): synchroner Übertragungsmodus, da zwar eine obere Zeitschranke erreicht sein muss, allerdings keine Timing Aspekte zu anderen Streams vorliegen. Zu schnell übertragene Pakete werden gepuffert. Datei: asynchroner Übertragungsmodus, da keine Timing Aspekte berücksichtigt werden müssen. Diashow: synchroner Übertragungsmodus, da die Bilder in einer bestimmten Frequenz angezeigt werden sollen. Zu schnell übertragene Pakete werden gepuffert. Diashow mit Musik (stereo): isochroner Übertragungsmodus, da Timing Aspekte zwischen den Streams bestehen. 7