Aufgabenblatt 2 Musterlösung

Transkript

1 Prof. Dr. rer. nat. Roland Wismüller Aufgabenblatt 2 Musterlösung Vorlesung Verteilte Systeme Sommersemester 2017 Aufgabe 1: -Implementierung a) Im single-threaded Fall dauert ein Cache-Treffer 15 und ein Cache-Fehler 90 Millisekunden. Der gewichtete Mittelwert ist 2/3*15 + 1/3*90. Die durchschnittliche Anforderung dauert also 40 Millisekunden und der kann 25 pro Sekunde verarbeiten. Für einen Multithreaded- überlappt sich das Warten auf die Festplatte, somit dauert jede Anforderung 15 Millisekunden und der kann 66 2/3 Anforderungen pro Sekunde verarbeiten. b) Ja, aus zwei Gründen: Erstens, Threads brauchen Speicher für die Einrichtung ihres eigenen, privaten Stacks. Demzufolge können sehr viele Threads so viel Speicher belegen, dass der nicht mehr korrekt arbeitet. Ein weiterer, ernsthafter Grund ist, dass unabhängige Threads für ein Betriebssystem auf chaotische Weise ausgeführt werden. In einem virtuellen Speichersystem kann es schwierig sein, eine relativ stabile Arbeitsmenge zu erstellen, was zu vielen Seitenfehlern und damit vielen Ein- und Ausgaben führt. Die Verwendung vieler Threads kann also zu einer Leistungsverschlechterung führen, welche aus dem Seiten-Thrashing entsteht. Aufgabe 2: Datenformat-Konvertierung Die Daten müssen deshalb konvertiert werden, weil ein verteiltes System im allgemeinen heterogen aufgebaut sein kann. Daher kann die interne Darstellung der Daten auf den einzelnen Knoten des Systems unterschiedlich sein. Die wichtigste Art der Heterogenität ist hier der Einsatz unterschiedlicher Prozessoren und Betriebssysteme. Damit die verschiedenen Prozesse sich trotzdem verstehen, werden die Daten vor dem Verschicken in der Regel in ein gemeinsames (kanonisches) Netzwerk-Datenformat konvertiert und beim Empfänger entsprechend wieder zurückgewandelt. Wichtige Aspekte für verschiedene Datentypen: Ganzzahltypen: Das häufigste Problem hier ist das der Byte Order, also der Reihenfolge, in der die einzelnen Bytes eines größeren Ganzzahltytps im Speicher abgelegt sind. Man unterscheidet hier big endian und little endian. Würde keine Konvertierung durchgeführt, so würde die (vorzeichenlose) big endian 16-Bit-Zahl 3 auf einem little endian- System zur Zahl Hier reicht also in der Regel, sich auf eines der beiden Formate zu einigen und ggf. zu konvertieren. Floating-Point: Hier ist die Lage etwas komplizierter, da Gleitkommazahlen nicht so einfach aufgebaut sind. Wesentlichie Probleme sind hier unterschiedliche Bit-Anzahlen bei Mantisse oder Exponent. Weiterhin können die Zahlen zu unterschiedlichen Basen abgespeichert sein, am häufigsten sind Zahlen zur Basis 2 und 10. I.A. ist keine exakte 1-zu-1-Abbildung aller Fließkomamzahlen eines Systems zu denen eines anderen Systems durchführbar. Heute arbeiten allerdings die meisten Rechner mit der standardisierten Darstellung nach IEEE 754. Strings: Hier ist eine Konvertierung zwischen unterschiedlichen Zeichensätzen notwendig, weil ein Byte oder Wort in verschiedenen Zeichensätzen als unterschiedliche Zeichen interpretiert wird. Manche Zeichen fehlen in einigen Zeichensätzen sogar komplett. Zudem gibt es Zeichensätze mit 8-Bit- (z.b. ASCII, ISO ), 16-Bit (z.b. Java: Unicode) und 32-Bit-Zeichen. 1

2 Aufgabe 3: Semantik der Client/-Kommunikation a) Die folgende Abbildung zeigt Zustandsdiagramme für Client und bei einer Implementierung der at most once Semantik: Client Auftrag an Sende Anfrage Antwort Empfang Wait Timeout Err Anfrage Empfang Bearbeite Auftrag Proc Sende Antwort Der bleibt hier unverändert. Der Client terminiert jedoch auch schon bei einem Timeout-Ereignis. In diesem Fall ist nicht sicher, ob der Auftrag auf dem abgearbeitet wurde, oder ob bereits die Anfrage-Nachricht zum verloren ging. Die folgende Abbildung zeigt die Zustandsdiagramme für Client und bei einer Implementierung der exactly once Semantik: Auftrag an Client Seq erzeuge Sequenznr. Anfrage Empfang bekannte Sequenznr. NegAck Anfrage Empfang, neue Sequenznr. Bearbeite Auftrag Proc Sende Antwort Timeout Wait Sende Anfrage, Sequenznr. Antwort neg. Antwort Err Hier wird jeder gesendete Auftrag mit einer eindeutigen Sequenznummer versehen, die auch bei Wiederholungen gleich bleibt. Der Client verhält sich wie bei der Implementierung der at least once Semantik: er wiederholt solange den Auftrag an den, bis er eine Antwort erhält. Der hingegen prüft beim Eintreffen einer Anfrage, ob er die Anforderung mit dieser Sequenznummer noch nicht bearbeitet hat. Ist dies der Fall, so wird der Auftrag bearbeitet und das Ergebnis dem Client geschickt. Wenn die Sequenznummer jedoch schon bekannt ist, dann wird im einfachsten Fall direkt eine negative Antwort an den Client geschickt, ohne der Auftrag neu auszuführen. Im Allgemeinen sollte aber die ursprünglich berechnete Antwort zwischengespeichert werden, um sie dem Client dann erneut zu senden. Dazu muß der jedoch für jeden Client die jeweils letzte Antwort (auf unbestimmte Zeit) zwischenspeichern. Erst bei Eintreffen der nächsten Anfrage vom gleichen Client kann der davon ausgehen, daß dieser Client die letzte Antwort erhalten hat. b) at least once Semantik at most once Semantik das Drücken eines Aufzugknopfs das Übersetzen eines Programms einen Kontoauszug holen Daten in einer Datei schreiben/anhängen das Bestellen einer Pizza eine elektronische Überweisung tätigen eine Stimme abgeben in einem elektronischen Wahlservice Aufgabe 4: Architektur bekannter Client/-Anwendungen WEB: 2

3 HTTP DNS DNS Browser HTTP WEB DNS Browser HTTP Proxy Proxy HTTP WEB Browser sind Clients der Domain-Name- (DNS) und der Web-. Manche Intranets sind so konfiguriert, dass ein Proxy- dazwischengeschaltet ist. Proxy- verringern Netzverzögerungen und Netzverkehr, wenn sie sich am gleichen Ort wie der Client befinden. Wenn sie am gleichen Ort wie der sind, bilden sie eine Sicherheits- Kontrollstelle und können die Last auf dem verringern. Die Verantwortlichkeit für die Datenkonsistens liegt bei den Proxy-n sie prüfen periodisch die Modifikationszeit der Seiten beim Ursprungs-Web-. Webseiten werden im lokale Filesystem des s gespeichert. Die gesamte Information im Web ist daher auf viele Web- verteilt. Replikation ist kein Teil des Web-Protokolls, aber eine häufig besuchte Web-Site kann mehrere mit identischen Kopien des Dateisystems versorgen. HTTP-Anfragen können zwischen diesen n aufgeteilt werden (z.b. über DNS Lastverteilung). Zusätzlich unterstützen Proxy- die Replikation durch Caching zuletzt benutzter Seiten, ebenso wie auch Web-Browser. DNS- können auch in alle Anwendungs-Architekturen, die unten beschrieben sind, miteinbezogen werden, sind aber zur Vereinfachung der Diskussion ausgelassen. senden Intranet des Absenders Local File Intranet Mailhost der Empfängers lesen NFS POP POP Local File NFS IMAP IMAP NFS Intranet Mailhost der Empfängers Nachrichten senden: Der (das Anwender-Programm zum Versenden von s) ist ein Client eines lokalen -s und übergibt jede abgehende Nachricht dem - für die Auslieferung. Der lokale - verwendet -Routingtabellen, um einen Weg für jede Nachricht festzustellen und leitet dann auf dem gewählten Weg die Nachricht an den folgenden - weiter. Jeder - verarbeitet und schickt jede ankommende 3

4 Nachricht weiter, bis der Domain-Name in der Nachrichtadresse der lokalen Domain entspricht. Im diesem Fall versucht er, die Nachricht an lokale Empfänger auszuliefern, indem er sie in eine Mailbox-Datei auf einer lokalen Festplatte oder einem File- speichert. - müssen nicht notwendigerweise -Routingtabellen für alle Ziele haben. Stattdessen geben sie Nachrichten für unbekannte Ziele an einen anderen weiter, der wahrscheinlich eine passende Routingtabelle besitzt. Nachrichten werden nur an ihrem Ziel (permanent) gespeichert. D.h., der -Dienst basiert nur auf Partitionierung, auch wenn eine Nachricht mit mehreren Empfängern auf mehreren Zierechnern repliziert wird. Nachrichten empfangen: Der (der Mail-Reader des Benutzers) ist entweder ein Client des lokalen File-s oder ein Client eines -Zustellungs-s wie ein POP- oder IMAP-. Im ersten Fall liest der die Nachrichten direkt von der Mailbox-Datei. Im letzten Fall bittet der um Informationen über den Inhalt der Mailbox-Datei des Benutzers von einem POP- oder IMAP- und empfängt die Nachrichten von diesem für die Darstellung zum Benutzer. POP und IMAP sind Protokolle, die spezifisch entworfen sind, um den zugang über WAN und langsame Netzverbindungen zu unterstützen. News: Artikel posting/publizieren: (lokal) Artikel browsing/lesen: Posten von News-Beiträgen: Der (das Anwender-Programm zum Erstellen und Versenden von News) ist ein Client eines lokalen -s und übergibt jeden abgehenden Artikel zum - für die Auslieferung. Jedem Artikel wird ein eindeutiger Bezeichner zugewiesen. Jeder hält eine Liste anderer -, für die er ein News-Erzeuger ist sie sind registriert, um Artikel von ihm zu empfangen. Periodisch kontaktiert er alle registrierten, liefert alle neuen Artikel an sie und verlangt alle, die sie schon haben, aber er noch nicht (der eindeutige Bezeichner hilft festzustellen, welche das sind). Damit werden die Artikel einer Newsgroup auf allen n repliziert, die sie benötigen. Lesen von News-Beiträgen: Der (das Newsleseprogramm des Benutzers) ist ein Client eines lokalen - s. Der bittet um Updates für alle Newsgroups, für die der Benutzer sich registriert hat, und stellt die News dar. Aufgabe 5: Request/Reply-Protokoll Es müssen die drei Operationen dooperation, getrequest und sendreply auf Basis von send und recv implementiert werden. Da keine Fragmentierung von Nachrichten notwendig ist, muss pro Nachricht nur genau ein Paket versendet werden. Um das Protokoll wie gefordert möglichst overheadfrei zu halten, ist die prinzipielle Idee Folgende: Für einen kompletten request-reply-zyklus werden genau 2 Pakete geschickt, nämlich die Anfrage des Clients selbst und dann die Antwort des s darauf. Die Antwort dient gleichzeitig als implizite Bestätigung des Erhalts der Nachricht. Wenn innerhalb einer bestimmten Zeitspanne eine Antwort ausbleibt, wird davon ausgegagen, dass das Paket verlorengegangen ist, und es muss neu verschickt werden. Damit Anfragen und Antworten zugeordnet werden können, werden eindeutige Sequenznummern erzeugt und an die Nachrichten angehängt. Folgender Pseudo-Code-Auszug zeigt einen ty- 4

5 pischen Ablauf im Client. Dieser besorgt sich die Adresse des s (z.b. von einem Namensdienst) und erzeugt eine Request-Nachricht. Dann stellt er die Anfrage an den und verarbeitet die Antwort: severaddr = getaddr(); request = createrequest(); dooperation(serveraddr, request, repl); handlereply(repl); Der läuft typischerweise in einer losschleife, in der er beliebige Anfragen entgegennimmt, diese bearbeitet und schließlich eine entsprechende Antwort zurückschickt. for ( ; ; ) getrequest(clientaddr, request); repl = handlerequest(request); sendreply(clientaddr, repl); Es folgen beispielhafte Implementierungen der drei geforderten Operationen: a) Die dooperation Operation wird implementiert, indem das Paket mittels send verschickt wird und anschließend auf eine Antwort gewartet wird. Bleibt diese innerhalb einer bestimmten Zeit aus (hier 5s), so wird das Paket erneut gesendet. Eine ernsthafte Feherbehandlung sollte nach einer maximalen Anzahl von Wiederholungen aufgeben. dooperation(in s_address, in request, out reply) ok = false; while (! ok) send(s_address, request); ok = recv(s_address, reply, 5s); b) getrequest ist die aufwendigste Funktion. Sie wartet auf das Eintreffen einer beliebigen Nachricht. Im Regelfall wird diese Nachricht mittels recv entgegengenommen und die Nachricht-Id in einem assoziativen Array (Map) gespeichert. Die Funktion kehrt dann zurück. Wird jedoch eine Anfrage wiederholt empfangen (d.h. sie ist in der Map bereits eingetragen), dann wird überprüft, ob schon eine Antwort generiert wurde. Ist dies der Fall, wird diese erneut gesendet. Wenn nicht, wird die Nachricht ignoriert. getrequest(out address, out request) newrequest = false; while (! newrequest) recv(address, request, -1); if (map.lookup(request.id, reply)) if (reply!= 0) sendreply(address, reply); else newrequest = true; map.store(request.id, 0); // no timeout 5

6 c) sendreply wird umgesetzt, indem ganz einfach das Antwortpaket gesendet wird. Anschließend wird die Antwort in dem schon vorhandenen Eintrag der Map gespeichert, damit diese bei Verlust des Paketes im Netz ereneut gesendet werden kann. sendreply(in address, in reply) send(address, reply); map.store(reply.id, reply) // store reply in a map 6