Präsenzübung 10. Konzepte und Methoden der Systemsoftware. Sommersemester vom bis

Transkript

1 Sommersemester 2010 Konzepte und Methoden der Systemsoftware Universität Paderborn Fachgebiet Rechnernetze Präsenzübung 10 vom bis Aufgabe 1: Kommunikation via Kanalobjekt Betrachten Sie ein System aus je einem Client und einem Server. Client und Server sind über ein Kanalobjekt miteinander verbunden. Der Server kommuniziere asynchron über das Kanalobjekt. Das Kanalobjekt, das Client und Server verbindet, habe folge Eigenschaften: Die Datenrate liegt bei 1000 Byte/s. Die Verzögerung beträgt 100 ms. Die Kapazität des Kanalobjektes ist unbeschränkt. 1. Der Client set direkt nacheinander zwei Aufträge an den Server. Zeichnen Sie die beiden Weg- Zeit-Diagramme für einen synchronen und einen asynchronen Clienten. Nehmen Sie an, dass die Bearbeitung der Aufträge serverseitig sehr lange dauert und immer nur ein Auftrag gleichzeitig bearbeitet werden kann. Beachten Sie, dass die Kommunikation der beiden Teilnehmer mit dem Kanalobjekt Zeit benötigt. 2. Die beiden Aufträge aus Teilaufgabe 1 seien nun jeweils 1000 Byte groß. Die Antworten des Servers seien 100 Byte groß. Die Bearbeitung eines Auftrages durch den Server benötige 2 Sekunden. Die benötigte Zeit für Kommunikation der Client- und Serverprozesse mit dem Kanalobjekt sei vernachlässigbar. Berechnen Sie sowohl für den synchronen als auch für den asynchronen Clienten, wie lange es dauert, bis der Client die Antwort auf seinen zweiten Auftrag erhalten hat. 3. Da der Server asynchron kommuniziert, kann es passieren, dass währ der Abarbeitung eines Auftrages ein weiterer Auftrag eintrifft (bei synchronem Clienten von einem anderen Clienten, bei asynchronem Clienten möglicherweise von dem selben Clienten). Welche Möglichkeiten hat ein Server, mit solchen Anfragen umzugehen? Gehen sie davon aus, dass der Server weiterhin nur eine Aufgabe zur selben Zeit bearbeiten kann, und dass die aktuell laufe Aufgabe beet werden muss, bevor eine neue Aufgabe begonnen werden kann. Musterlösung zu Aufgabe 1: Vorschlag Vorrechnen: Einen Punkt für Teilaufgaben 1 und 2, einen für die 3 (da muss man dann aber schon eine nette Erklärung und Diskussion der Vor- und Nachteile bringen). 1. Achtung: In diesen Diagrammen ist nicht deutlich, dass die Nachrichten eine Länge > 0 haben. Dies ist allerdings für den Kontext der Aufgabe (Unterschied synchron, asynchron) auch nicht ganz so wichtig. KMS Sommersemester 2010 Präsenzübung 10 1

2 Client Client-Tor Server-Tor Server Asynchron: Client Client-Tor Server-Tor Server Synchron: 2. Das Übertragen eines Auftrages an den Server dauert 1.1 Sekunden, das Übertragen einer Antwort dauert 0.2 Sekunden. Bei diesen Zeiten kommen auch tatsächlich die prinzipiellen Weg- Zeit-Diagramme aus Aufgabenteil 1 zustande. Da wir die Kommunikationszeit zwischen Tor und Prozess vernachlässigen, erhalten wir folge Zeiten: = 5.3 Sekunden (asynchron) 2 ( ) = 6.6 Sekunden (synchron) 3. Es gibt unter anderem (man kann sich gerne mehr ausdenken) folge Möglichkeiten: Der Serverprozess bearbeitet seinen aktuellen Auftrag zu Ende, set das Ergebnis und holt dann den neuen Auftrag vom Kanalobjekt. KMS Sommersemester 2010 Präsenzübung 10 2

3 Der Nachteil ist, dass das Übergeben des Ergebnisses an das Kanalobjekt und das Holen des neuen Auftrages vom Kanal einige Zeit brauchen. Der Server ist währ dieser Zeit blockiert, die Zeit ist also für die Auftragsbearbeitung verloren. Der Vorteil liegt in der einfachen Implementierung (bei einfachen, eher schwach ausgelasteten Servern und ad-hoc Implementationen vielleicht nützlich). Der Server unterbricht kurz seinen aktuellen Auftrag, holt den neuen Auftrag und fügt ihn in eine (Server-interne) Queue ein. Der Nachteil ist hier der selbe wie bei der ersten Möglichkeit, nur wird die Zeit währ des Holens eines Auftrages währ der Abarbeitung eines anderen Auftrages aufgebracht. Dies erhöht die Antwortzeit für den anderen Auftrag, was unerwünscht sein kann. Der Vorteil ist hier, dass der interne Puffer des Kanalobjektes eventuell kleiner sein kann (im Idealfall muss dieser Puffer nur einen Auftrag enthalten können). Man könnte eine der ersten beiden Möglichkeiten nutzen, aber Nebenläufigkeit einführen. Ein separater Thread (oder Hilfsprozess) holt die Aufträge vom Kanal und fügt sie in eine Queue ein. Vorteil: Schnell, wenn der Thread wirklich parallel läuft oder das Holen der Daten von einem DMA-Gerät erledigt wird. Nachteil: Kein Zeitgewinn, wenn der Zugriff auf den Kanal nicht per DMA möglich ist und man nur einen Prozessor zur Verfügung hat. Hat man mehrere Prozessoren und kein DMA zur Verfügung, so braucht man auch mehrere davon, geht also nicht sonderlich sparsam mit den Ressourcen um. Der neue Auftrag ist in einem Puffer des Kanalobjektes gespeichert (asynchron!). Dieser Puffer liegt üblicherweise irgwo im Arbeitsspeicher der Teilnehmer. Man kann also einfach einen zweiten Puffer (der selben Größe) nehmen und diesen gegen den aktuellen Puffer des Kanalobjektes austauschen. Diese Operation besteht im Wesentlichen aus dem Tausch zweier Pointer (falls nötig synchronisiert), ist also sehr schnell durchführbar. Damit ist dann folges Vorgehen möglich: Der Server unterbricht kurz die Bearbeitung des aktuellen Auftrages, tauscht den Puffer für eingehe Nachrichten aus, und arbeitet weiter. Das selbe Verfahren kann für das Sen der Antwort genutzt werden. Natürlich kann dieses Verfahren für mehr als zwei Puffer erweitert werden. Der Nachteil ist zum Einen der erhöhte Speicherverbrauch, zum Anderen, dass in diesem Verfahren die Abstraktion Kanalobjekt durchbrochen wird. Man nimmt ein Kanalobjekt nicht mehr einfach als Blackbox an, sondern muss einiges über seine Interna voraussetzen: Die Puffer des Kanals müssen lokal vorhanden sein und müssen austauschbar sein. Ausserdem muss dem Server bekannt sein, auf welche Art die Puffer organisiert sind, und das Sen und Empfangen des Kanals darf keine Rechenzeit des Servers verlangen. Dies alles hat zur Folge, dass ein Tausch des Kanalobjektes oder Änderungen am Kanalobjekt nicht mehr so einfach durchzuführen sind. Der Vorteil ist offensichtlich die erhöhte Effizienz. Der Server kann potentiell fast ohne Pause arbeiten. Ausserdem muss (wie bei der vorherigen Möglichkeit) der Puffer des Kanalobjektes nicht allzugroß sein. Eine Anwung dieses Verfahrens findet sich in Grafikkarten (eine Umgebung, in der Effizienz das Maß aller Dinge ist). Es gibt meist zwei Puffer: Den frontbuffer und den backbuffer. Beide enthalten Farbinformationen für den Monitor ( Pixel (x,y) hat Farbe z ). Der frontbuffer ist derjenige, der gerade vom Monitor angezeigt wird, in den backbuffer wird das Bild für denn nächsten Frame geschrieben. Sobald der nächste Frame an der Reihe ist, werden front- und backbuffer getauscht. Diese Aufgabe wurde benutzt: Neu (angelehnt an diverse Aufgaben von früher) Aufgabe 2: RPC KMS Sommersemester 2010 Präsenzübung 10 3

4 Betrachten Sie eine Funktion mit folger Signatur: int f(int x, int y). Diese soll als entfernte Prozedur aufgerufen werden. 1. Schreiben Sie Client- und Serverstub für den entfernten Aufruf (in Pseudocode). Gehen Sie dabei davon aus, dass die Parameter by value übergeben werden und dass bereits ein Kanalobjekt K mit Operationen s und receive für die Kommunikation bereit steht. 2. Nehmen Sie nun an, dass die Parameterübergabe (für die lokale Funktion) by reference passiert, die Signatur (in C) ist also jetzt int f(int* p_x, int* p_y). Modifizieren Sie ihre Stubs so, dass die Parameterübergabe an den Server by-copy/restore 1 passiert, um Call-By-Reference zu simulieren. 3. Finden Sie den Fehler in der Implementation aus Teilaufgabe 2 und beheben Sie ihn. 4. Welche Fehler (in der Kommunikation) können bei dem Aufruf einer entfernten Prozedur auftreten? Wie können diese Fehler behandelt werden? Beschreiben Sie kurz die Modifikationen, die an Ihren Stubs zur Fehlerbehandlung eingeführt werden könnten. Musterlösung zu Aufgabe 2: 1. Der Client schickt einfach die Parameter x und y an den Server, dieser ruft f mit den Parametern auf und schickt das Ergebnis zurück. // Client stub: int f(int x, int y) s(k, x); s(k, y); int result = receive(k); return result; // Server stub: void stub() while (true) int y = receive(k); s(k, f(x, y)); while 2. Hier müssen neben dem Ergebnis noch die lokalen Kopien der Parameter (die aus dem Serverstub) an den Clienten zurückgeschickt werden, denn die Parameter könnten sich verändert haben. // Client stub: int f(int* p_x, int* p_y) s(k, *p_x); s(k, *p_y); int result = receive(k); *p_x = receive(k); 1 in Grundlagen der Programmiersprachen auch Call-by-value-and-result genannt: de/lehre/material/gps/folien/folie606.html KMS Sommersemester 2010 Präsenzübung 10 4

5 *p_y = receive(k); return result; // Server stub: void stub() while (true) int y = receive(k); int result = f(&x, &y); s(k, result); s(k, x); s(k, y); while 3. Bei einem Aufruf wie f(a, a) weicht das Verhalten der entfernt aufgerufenen Prozedur eventuell von dem Verhalten einer lokalen aufgerufenen Prozedur ab. Der Grund ist, dass bei der RPC- Variante die Variable a auf der Server-Seite zu zwei Variablen wird. Ein einfaches Beispiel für das Auftreten von Problemen in dieser Situation liefert folge Funktion f: int f(int a, int b) a += 1; b += 2; return a + b; Eine einfache Korrekturmöglichkeit ist es, die beiden Pointer p_x und p_y im Clientstub auf Gleichheit zu testen und bei Gleichheit nur einen der beiden Werte (die ja gleich sind) zu übertragen, zusammen mit der Information, dass die beiden Parameter die selbe Variable sind. Der Server übergibt dann nur eine lokale Variable an die Funktion und schickt nach dem Aufruf nur den Wert dieser Variablen zurück. Dies könnte in einer Implementation so aussehen: // Client stub: int f(int* p_x, int* p_y) int result; if (p_x == p_y) // Dem Server mitteilen, dass nur ein // Parameter existiert: s(k, true); // Nur einen Parameter sen: s(k, *p_x); result = receive(k); // Nur einen der beiden Werte ueberschreiben: *p_x = receive(k); else // Dem Server mitteilen, dass nur ein // Parameter existiert: KMS Sommersemester 2010 Präsenzübung 10 5

6 s(k, false); // Ab hier wie vorher bei Call-by-Copy/Restore s(k, *p_x); s(k, *p_y); result = receive(k); *p_x = receive(k); *p_y = receive(k); if return result; // Server stub: void stub() while (true) bool oneparameter = receive(k); if (oneparameter) // Nur ein Parameter wird vom Client geschickt: int result = f(&x, &x); s(k, result); // Nur einen Parameter zuruecksen: s(k, x); else // Alles wie vorher bei Call-by-Copy/Restore int y = receive(k); int result = f(&x, &y); s(k, result); s(k, x); s(k, y); if while Solche Implementierungen sind allerdings bei drei oder mehr Parametern schon fast nicht mehr mit der Hand zu erledigen, darum lässt man sich die Stubs von einem Codegenerator aus den Prozedursignaturen erzeugen. 4. Fehler können im Wesentlichen sein: Eine der Auftragsnachrichten geht verloren. Der Client wird irgwann durch einen Timeout merken, dass die Nachricht wahrscheinlich nicht angekommen ist, und schickt diese einfach noch einmal. Eine der Antwortnachrichten geht verloren. Auch diese Situation wird dem Clienten durch einen Timeout auffallen, er ruft die Funktion einfach noch einmal auf. Der Server wird dann - je nach gewünschter Semantik - die Funktion noch einmal ausführen, oder aber das Ergebnis des ersten Auftrages noch einmal schicken. KMS Sommersemester 2010 Präsenzübung 10 6

7 Diese beiden Möglichkeiten sind nicht durch den Clienten unterscheidbar, der sieht jeweils nur, dass der Timer abgelaufen ist. Die Reaktion des Clienten muss also in beiden Fällen die gleiche sein. In den obigen Implementationen können noch mehr Dinge schief gehen (z.b. könnte nur der Parameter x verloren gehen). Dies ist aber der naiven Implementation zuzuschreiben. Um die Timeouts in Code zu realisieren, kann man entweder auf Funktionalitäten der verweten Bibliothek für Kanalobjekte zurückgreifen, oder man lässt sich z.b. vom Betriebssystem per Interrupt nach einer gewissen Zeit Bescheid sagen. In beiden Fällen muss man wahrscheinlich eine Callback-Funktion (vielleicht verpackt in ein Objekt als Listener) an der passen Stelle registrieren. Diese Funktion ist dann für die Fehlerbehandlung zuständig. Diese Aufgabe wurde benutzt: Neu (angelehnt an HÜ 05 aus dem SoSe 2007, Aufgabe 4) KMS Sommersemester 2010 Präsenzübung 10 7