VS 7.5 ECTS

Prüfer: Jürgen Kleinöder

Beisitzer: Tobias Distler

sehr gut

Wirklich locker, Gesprächstil

Allgemein sehr lockere Atmosphäre, „rede einfach mal“. Wenn die Richtung nicht interessiert, dann rührt sicher der Prüfer von selbst.

V.a. auf Verständnis. Anders als den Prüfungsprotokollen von früher™ mit Rüdiger Kapitza als Prüfer zu entnehmen, wurden auch keine expliziten Aufzählungen (im Sinne von: Die neun Probleme verteilter Systeme) gefragt.

Vielmehr wurde Verständnis abgeprüft, und dabei gerne auch mal über den Inhalt der Vorlesung hinaus diskutiert, nicht nur mit mir, sondern auch zweimal kurz zwischen Prüfer und Beisitzer, was mir aber nicht negativ angerechnet wurde.

Besprechung der Note dauert auch mal länger, was aber nicht unbedingt der Schaden des Prüflings ist :D

1-1.5 Wochen, Folien lesen, auch Übungsfolien, und vor der Prüfung nochmal kurz über unsere Implementierung aus der Übung geschaut.

Ja. Allerdings würde ich rückblickend ggf. weniger Zeit auf die konkreten Algorithmen am Ende der VL verwenden, aber ymmv. Ist vll für Leute relevant, die unter Zeitdruck lernen… Allerdings kann das auch nur mit meiner konkreten Prüfung zusammenhängen (wurden garnichts zu diesen Themengebieten gefragt).

Klassischer Einstieg: Was ist ein Verteiltes System und warum will man das

Gruppe von Rechnern, verbunden durch ein Netzwerk, die kooperieren einen gemeinsamen Dienst nach außen anzubieten und dem Benutzer als ein einzelnes System erscheint…

Warum:

• Fehlertoleranz
• Lastverteilung
• Kooperation verteilter Nutzer

(Mehr viel mir auf die schnelle nicht ein)

Übergang über Probleme der VS/Fehlertoleranz/Replikation

Wie identifiziert man Objekte in einem Verteilten System mit Replikation?

Paar aus Objektid und Ort

Repliziertes System mit Aktiver Replikation. Wie sieht ein Aufruf in dem System aus?

(siehe Übung/folien), wichtig: Aufrufunterdrückung, Antwortunterdrückung…

Was muss man beachten/Welche Probleme können auftreten?

Nichtdeterminismus, z.B. durch Seiteneffekte in den Berechnungen, wie dem anfordern einer Zufallszahl

Wie handhabt man das

Nur einmal die Anfrage durchführen, den restlichen Berechnungen den gleichen Wert zur Verfügung stellen

Nur einmal? Wir wollen doch durch Redundanz Fehlertolerant sein. Kann man das irgendwie Fehlertolerant machen?

Erster Vorschlag: Einigungsprotokoll. Jeder berechnet Zufallszahl, einigen sich

→ Geht, aber ist halt nochmal eigenes Protokoll

Geht das auch irgendwie mit „Bordmitteln“ (konkrete Formulierung war etwas anders)

Ja, naja. Zufallsobjekt replizieren, mit ganz normalem Fernaufruf. Wie bei aktiver Replikation dann aufrufunterdrückung → Ergebnis per Multicast verteilen

→ Geht

Weitere Dinge, die man bei der aktiven Replikation beachten müsste?

Nichtdeterminismus durch Nebenläufigkeit (dann noch kurz genauer erklären)

Wie kann man das lösen?

Konkretisiert: also nicht einfach Nebenläufigkeit unterlassen. Wichtig ist auch: Locks helfen hier nicht, da ja die Nebenläufigkeit innerhalb der durch den Fernaufruf ausgelösten Methode stattfindet und in der Ausführung über die Replikate hinweg nicht deterministisch ist.

Hilfestellung: Denken sie mal an andere Replikationsmechanismen

Mit Cold-Passive Replikation kann man das abmildern: Nach dem Zustandstransfer ist die Nebenläufigkeit in der Teilmenge irrelevant. Probleme ergeben sich nur, falls zwischen zwei Zustandstransfers Daten an den Client geschickt wurden: Nach Ausfall wiedereinspielen aus dem Log: Unterschiedliche Reihenfolgen bei Threads am Locks o.Ä. möglich.

Was schreibt man denn in den Log?

Anfragen, Antworten, Anfragen/Antworten von transitiv ausgelösten Anfragen an andere Objekte

Auf Nachfrage: Reicht nicht, um das Problem zu lösen: Kann nur erkennen, wenn etwas nicht stimmt, es aber nicht korrigieren (beim Replay des Logs kann erkannt werden, dass eine falsche Antwort (bspw. aufgrund von Wettlaufsituationen an einem Schloss) gegeben werden würde, Zustand kann aber nicht rekonstruiert werden)

Wie geht man damit um?

Naja. Vor Clientantwort immer Zustandstransfer. Aber langsam

<Kurze Diskussion zwischen Tobias Distler und Jürgen Kleinöder wie man das tatsächlich macht („Das ist eine gute Frage“)>

Tatsächlich schreibt man dann wohl Teile des gemeinsamen Zustands ins Log…

Replikation ist aber ja nur der letzte Ausweg bei Fehlertoleranz. Was kann man denn sonst noch so machen?

RPC-Semantiken. Kurze Auflistung welche es gibt, Vor/Nachteile, welche Eigenschaften muss man haben?

Spezifische Punkte:

Idempotenz bei at-least-once: Was wenn man das nicht gewährleisten kann? → Versuch idempotent zu machen (Bspw.: Get + Set statt inc. Was kann dabei schief gehen? (Synchro), Lösung: CAS (Compare&Swap) exporten oder Locks). Kurze Diskussion über Definition von Idempotenz: Weil CAS hat ja unterschiedliche Rückgabewerte bei gleichen Paramtern…

Garbage Collection bei at-most-once: Kurz: Warum braucht man das überhaupt. Dann halt, wie kann man das umsetzen (Also pro client: merken bis zu welchem Zeitpunkt man anfragen gesehn/abgearbeitet hat, und zu alte, wiederholte Anfragen ignorieren, falls sie schon vom GC weggeräumt wurden). Geht es auch einfacher (mit etwas HIlfe): Ja ein einzelner Epochenzähler global. Dann im Epochenwechsel die alten Ergebnisse wegräumen. Nachteil: Hohe Anfälligkeit der Anwendung am Epochenübergang, noch kurz: Was könnte man dagegen tun?

TIME UP