pruefungen:hauptstudium:ls4:vs-2018-09-20

Inhaltsverzeichnis

Allgemeines
RPC
Semantiken
Replikation
Mutlicast
Konsistenzen

VS - 7.5ECTS

Prüfer: Tobias Distler Beisitzer: Michael Eischer

Die Prüfungsatmosphäre war sehr entspannt. Tobias hat die Fragen gestellt und Michael hat das Protokoll geführt. Note sehr gut.

Prinzipiell wurden nur Fragen gestellt, die bereits in anderen Prüfungsprotokollen (vs-2018-07-19, vs-2018-07-26) gelistet sind, hier aber trotzdem nochmal ein ausführlicheres Protkoll.

Allgemeines

Was ist ein VS, wofür ist es gut und welche Problemstellungen gibt es?
- Definition von VS
  - mehrere Rechner über Netzwerk verbunden
  - arbeiten zusammen an Aufgaben
  - bieten Dienste an
- Netzwerk nicht zuverlässig, langsam, Latenzen, Knoten können ausfallen, etc.

RPC

Was sind die Komponenten eines Fernaufrufs?
- Stub + Skeleton (+Kommunikationssystem)
Wie läuft so ein Fernaufruf ab?
- Skizze mit dem Standardfernaufruf
Woher weiß der Stub, an wen er Requests schicken muss?
- Stub ist ein Proxy → Enthält ClientID + Serveraddresse
Woher kommt der Stub?
- Wird vom Server erstellt und mithilfe einer Registry zur Verfügung gestellt (Client kann diese dann verwenden)
Wie geht man mit Parametern um?
- gibt verschiedene Varianten (Eingabeparameter, Ausgabeparameter, Ein-Ausgabeparameter)
- Besonderheit bei Referenzen
  - Objekte kopieren
  - Stub generieren und mitschicken → Fernaufrufe
Wann könnte Objekte kopieren denn schneller sein als Fernaufrufe tätigen?
- Hier hab ich ein bisschen für gebraucht: Objekt übertragen muss man nur einmal, während (sehr) viele Fernaufrufe getätigt werden könnten

Semantiken

Wie geht man mit einem unzuverlässigen System um? Wir haben da mehrere kennengelernt
- Habe mit MAYBE angefangen, da wurde nur gemeint ich darf die überspringen
- AT-LEAST-ONCE
- AT-MOST-ONCE (
- Maybe (sollte ich gleich überspringen), At-Least-Once, At-Most-Once (wollte noch Last-Of-Many sagen wurde aber hier unterbrochen)
Wie funktioniert At-Most-Once genauer? Also wie geht man mit auf serverseite gespeicherten Antworten um?
- Garbage Collection
  - Bei neuer Anfrage vom Client altes Ergebnis verwerfen
  - Timeout (#ClientVersuche * Client-Resend-Timeout + Buffer)
Was macht man hier, wenn eine verzögerte Nachricht kommt, NACHDEM alles gelöscht wurde?
- nicht nochmal berechnen (Verletzung der Semantik!!)
- Timestamps mitsenden + vergleichen (hier ist allerdings nicht immer eindeutig, ob eine Anfrage mit altem Timestamp schon berechnet wurde → ignorieren und auf neue Anfrage warten)

Replikation

Welche Arten der Replikation kennen wir?
- aktive und passive Replikation
  - aktiv: Alle Replikate rechnen und (einer oder alle) antworten (Fehlererkennung, schnellste Antwort nehmen, etc)
  - passiv: einer rechnet und schickt anderen Zustandsupdates + antwortet
Wir hatten in der Übung den VSAuctionService implementiert. Was bräuchte man um diesen Dienst aktiv zu replizieren?
- total geordneten, uniform zuverlässigen Multicast
- Deterministischer Zustandsautomat
Gibts hier weitere Probleme?
- Hier kam ich erstmal nicht darauf, aber er wollte im Endeffekt auf mögliche Quellen von Nichtdeterminismus, in diesem Fall: Timestamps beim Bieten + Auktionsdauer → Ein Replikat zum setzen/updaten der Timestamps

Mutlicast

Was ist der Unterschied zwischen zuverlässiger Multicast und uniform zuverlässiger Multicast?
- Hab hier den kleinen Unterschied in der Definition genannt: uniforme Einigung berücksichtig fehlerhafte Knoten
Was genau bedeutet dies denn für den zuverlässigen Multicast?
- fehlerhafte Knoten können in einen inkonsistenten Zustand geraten
Gibts da noch weitere Probleme?
- Hier hab ich minimal für gebraucht, war aber kein Problem: Clients können von fehlerhaften Knoten inkonsistente Antworten erhalten

Konsistenzen

Wir haben in den Übungen einen replizierten Key-Value-Storage gebaut. Welche Konsistenzen bietet und dieses System?
- Strong Consistency
Warum?
- Alle Anfragen (Schreib + Leseanfragen) sind durch JGroups + JChannel total geordnet und Leseanfragen können nicht vor „jüngeren“ Schreibanfragen beantwortet werden
Wie wäre das denn, wenn wir Leseanfragen direkt bei Replikaten ausführen könnten? Welche Konsistenzgarantien haben wir dann?
- keine Synchronisation durch JGroups/JChannel
- hab hier alle Konsistenzen aufgezählt und gesagt ob gültig oder nicht
  - Strong Consistency → Offensichtlich nicht
  - Eventuel Consistency → Hab man quasi immer
  - Consistent Prefix → Ja, da es immer einen Schreibzugriff gibt der bei allen Replikaten ausgeführt wurde
  - Bounded Staleness → Nein, Netsplit könnte dauerhaft sein
  - Read-My-Write → Nein, Schreibanfrage könnte noch in JGroups/JChannel stecken
  - Monotonic Read → Nein, wenn man jedes mal anderes Replikat fragt und dieses ältere Datensätze hat
Könnte man hier Read-My-Writes bzw Monotonic Read erreichen?
- Ja mithilfe von Timestamps
  - Client schickt Timestamp des „jüngsten“ geforderten Datensatzes mit
  - Server antwortet mit Timestamp des „jüngsten vorhandenen Datensatzes“
  - Falls Client neuere Daten anfordert als auf dem Server vorhanden → warten