TU Wien:Verteilte Systeme VO (Göschka)/Prüfung 2011 10-10

Aus VoWi
Zur Navigation springen Zur Suche springen

1.Definition Verteiltes System[Bearbeiten]

Frage: Geben Sie eine charakterisierende Definition für ein "Verteiltes System" an. Nennen Sie die wichtigsten Design-Ziele bzw. charakteristischen Eigenschaften von Verteilten Systemen. Stellen Sie weiters den Zusammenhang zu den typischen Fallstricken beim Entwurf verteilter Systeme her.

{{#dpl:resultsheader=Diese Frage wurde bereits in folgenden Prüfungen gestellt: |oneresultheader=Diese Frage wurde bereits in der folgenden Prüfung gestellt: |noresultsheader=* Diese Frage wurde noch nie gestellt! |skipthispage=no |shownamespace=false |uses=Vorlage:Kapitel |replaceintitle=/Verteilte Systeme VO \(Göschka\)\/Prüfung/, |include={Kapitel}.dpl |includematch=/\|\s*TU Wien:Verteilte Systeme VO \(Göschka\)\/Fragenkatalog Wiki\s*\|\s*Definition Verteiltes System\s*/si}}

Definition 
Ein Verteiltes System ist eine Menge voneinander unabhängiger Computer, die dem Benutzer wie ein einzelnes, kohärentes System erscheinen.

Eigenschaften:

  • Ein Verteiltes System besteht aus autonomen Komponenten.
  • Den Benutzern (Menschen oder Programmen) präsentiert es sich als ein einziges System.
  • Unterschiede zwischen den einzelnen Computern und der Art wie sie miteinander kommunizieren bleiben weitgehend vor den Benutzern verborgen. Ebenso der innere Aufbau.
  • Benutzer können konsistent und einheitlich mit dem System arbeiten.
  • Grundsätzlich sollten Verteilte Systeme einfach zu erweitern oder zu skalieren sein.
  • Es steht normalerweise ununterbrochen zur Verfügung, auch wenn einige Komponenten vorübergehend ausfallen.

Um heterogene Computer und Netzwerke zu unterstützen und gleichzeitig das Erscheinungsbild eines einzigen Systems anzubieten, werden Verteilte Systeme häufig mit Hilfe einer Softwareschicht angeordnet, welche sich logisch zwischen einer Höheren Ebene von Benutzern und Anwendungen und einer darunter liegenden Ebene von Betriebssystemen und grundlegenden Kommunikationseinrichtungen befindet. Entsprechend wird ein solches Verteiltes System als 'Middleware' bezeichnet. Selbstverständlich unterscheiden sich verteilte Systeme von herkömmlicher Software, weil die Komponenten über ein Netz verteilt sind. Diese Verteilung während des Entwurfs nicht zu berücksichtigen macht viele Systeme unnötig komplex und führt zu Fehlern die später oft behoben werden müssen. Folgende typischen Fehlannahmen werden beim Entwurf verteilter Systeme oft getroffen:

  • Das Netzwerk ist zuverlässig.
  • Das Netzwerk ist sicher.
  • Das Netzwerk ist homogen.
  • Die Topologie ändert sich nicht.
  • Die Latenzzeit beträgt Null.
  • Die Bandbreite ist unbegrenzt.
  • Die Übertragungskosten betragen Null.
  • Es gibt genau einen Administrator.

Designziele eines Verteilten Systems:

  • Ressourcen sollen leicht zugänglich sein
  • Soll verstecken, dass Ressourcen im Netzwerk verteilt werden (=Transparenz)
  • Openness
  • Soll skalierbar sein
  • Fehlertoleranz
  • Concurrency


2.SSL[Bearbeiten]

Frage: Was ist der Secure Socket Layer (SSL, auch TLS genannt)? Positionieren Sie SSL/TLS im Internet Protokoll Stack.

{{#dpl:resultsheader=Diese Frage wurde bereits in folgenden Prüfungen gestellt: |oneresultheader=Diese Frage wurde bereits in der folgenden Prüfung gestellt: |noresultsheader=* Diese Frage wurde noch nie gestellt! |skipthispage=no |shownamespace=false |uses=Vorlage:Kapitel |replaceintitle=/Verteilte Systeme VO \(Göschka\)\/Prüfung/, |include={Kapitel}.dpl |includematch=/\|\s*TU Wien:Verteilte Systeme VO \(Göschka\)\/Fragenkatalog Wiki\s*\|\s*SSL\s*/si}}

SSL (auch TLS) ist ein Verschlüsselungsprotokol zur sicheren Datenübertragung im Internet. SSL steht für Secure Socket Layer und verschlüsselt eine TCP-Verbindung. SSL befindet sich direkt über dem Transportlayer.

TLS layer.png

Der Ablauf ist wie folgt:

  • Der Client teilt dem Server seine Verschlüsselungs- und Kompressionsmöglichkeiten mit (1)
  • Der Server wählt welche davon aus und teilt dies dem Client mit (2)
  • Der Server authentifiziert sich mittels Zertifikat am Client, welches den Public Key beinhaltet und von einer Certification Authority (CA) signiert wurde. (3) (Eventuell authentifiziert sich auch der Client mittels Zertifikat (Schritt 4))
  • Der Client erzeugt eine Zufallszahl, verschlüsselt sie mit dem Public Key des Servers und sendet sie diesem (5). Wenn Client Authentification verlangt wird, dann signiert der Client zuvor die Zahl noch mit seinem Private Key. (das [R]c im Schritt 5)
  • Beide leiten aus dieser Zufallszahl einen Session Key ab, der ab nun verwendet wird. Der Session Key ist ein einmalig benutzerbarer symmetrischer Schlüssel, der während der Verbindung zum Ver- und Entschlüsseln der Daten genutzt wird. Alle Nachrichten zwischen den Kommunikationspartnern werden ab nun nur noch verschlüsselt übertragen.

TLS mutual authentication.png


3.Vector Timestamps[Bearbeiten]

Frage: Welchen Nachteil haben die Lamport-Timestamps und wie kann dieser durch Vector-Timestamps überwunden werden?

{{#dpl:resultsheader=Diese Frage wurde bereits in folgenden Prüfungen gestellt: |oneresultheader=Diese Frage wurde bereits in der folgenden Prüfung gestellt: |noresultsheader=* Diese Frage wurde noch nie gestellt! |skipthispage=no |shownamespace=false |uses=Vorlage:Kapitel |replaceintitle=/Verteilte Systeme VO \(Göschka\)\/Prüfung/, |include={Kapitel}.dpl |includematch=/\|\s*TU Wien:Verteilte Systeme VO \(Göschka\)\/Fragenkatalog Wiki\s*\|\s*Vector Timestamps\s*/si}}

Nachteil: keine kausalen Abhängigkeiten. Nur weil T(a) < T(b) gilt sagt das noch nicht aus, dass a auch vor b stattgefunden hat. Es kann sich ja um Zeiten von 2 oder mehreren verschiedenen unabhängigen Prozessen handeln.

Vector-Timestamp:

Ein Vector Timestamp (VT oder Vector Clock VC) hat die Eigenschaft, dass wenn VC(a) dem Event a zugeordnet ist, dann hat dieser Vektor die Eigenschaft dass wenn VC(a) < VC(b) für ein Event b ist, a kausal vor b ausgeführt worden ist.

Jeder von n Prozessen hat einen Vektor von der Länge n (initialisiert mit dem Null-Vektor). Bei jedem Ereignis in Prozess i zählt dieser Element i um 1 hoch. Der Vektor wird an die gesendete Nachricht angehängt. Beim Empfang durch Prozess j wird das Weitergeben der Nachricht an die Applikation solange verzögert bis gilt (m ist die Message; m[i] beschreibt den Counter des Prozesses i im Vector der Message):

  • m[i] = Vj[i] + 1
  • m[k] <= Vj[k] für alle k außer i

Beim Empfang der Nachricht wird aus dem empfangenen und dem eigenen Vektor ein neuer gebildet, dessen Einträge die Maxima der beiden Vektoren darstellen (elementweises Maximum)

Bitte Abbildung aus dem Buch einfügen, für besseres Verständnis


Edit (Bild aus den Folien):

TU Wien-Verteilte Systeme VO (Göschka) - Bild Vector Clock.png


Potentiell kausal abhängige Nachrichten können durch elementweisen Vergleich der Vektoren gefunden werden. Es handelt sich dabei um eine partielle Ordnung der Ereignisse.


4.Code Migration[Bearbeiten]

Frage: Erläutern Sie die wichtigsten Aspekte der Code Migration. Erklären Sie "strong mobility" und "weak mobility" und geben Sie für "weak mobility" ein Beispiel an.

{{#dpl:resultsheader=Diese Frage wurde bereits in folgenden Prüfungen gestellt: |oneresultheader=Diese Frage wurde bereits in der folgenden Prüfung gestellt: |noresultsheader=* Diese Frage wurde noch nie gestellt! |skipthispage=no |shownamespace=false |uses=Vorlage:Kapitel |replaceintitle=/Verteilte Systeme VO \(Göschka\)\/Prüfung/, |include={Kapitel}.dpl |includematch=/\|\s*TU Wien:Verteilte Systeme VO \(Göschka\)\/Fragenkatalog Wiki\s*\|\s*Code Migration\s*/si}}

Bei der Code Migration werden nicht nur Daten, sondern ganze Programme verschickt, dies ist sogar im laufenden Zustand möglich. - Wird gemacht aus performance-gründen, z.B.: Auf dem Server läuft eine Datenbank, die Client-application stellt viele Anfragen. Hier könnte es gut sein, einen Teil des Client-Codes auf den Server zu bringen, damit nur noch die Antworten gesendet werden müssen und das Netzwerk entlastet wird. - Möglich ist auch ein Mobile Agent, der das Netz durchsucht, indem Kopien davon gemacht werden und er von Seite zu Seite geschickt wird. - Oder auch um Software dem Client zur Verfügung zu stellen

Ein Prozess besteht aus 3 Segmenten: Code (tatsächlicher Programmcode), Resourcen (Referenzen zu externen Resourcen , die für den Prozess benötigt werden, wie Files, Drucker, Geräte, andere Prozesse, ...), Execution (Speichert den Exekutionsstatus des Prozesses: private Daten, Stack, Programm Counter,..)

Weak Mobility: Hier wird nur das Code Segment transportiert, möglicherweise mit Initialisierungsdaten. Es ist hier nur möglich das Programm an einer, von möglicherweise mehreren, vordefinierten Positionen zu starten, wie z.B. bei Java Applets, die immer beim Begin gestartet werden. Der Vorteil dieser Methode ist die Einfachheit, die einzige Anforderung ist, dass der Empfänger den Code ausführen kann.

Strong Mobility: Hier wird auch das Execution Segment übertragen. Charakteristisch ist, dass der laufende Prozess angehalten, auf eine andere Maschine übertragen, und dort weiterlaufen kann. Es ist schwieriger zu implementieren als Weak Mobility.

Zur Übertragung des Resource Segment muss das Prozess-Resourcen Binding sowie das Resource-Maschinen Binding berücksichtigt werden.

  • Prozess-Resource: Wenn eine Resource by identifier gebunden ist, muss sich der migrierte Code wieder genau zu dieser Resource verbinden. by value gebundene Resourcen sind nur durch deren Daten von Bedeutung. Resourcen die by type gebunden sind, können einfach durch Geräte mit derselben Schnittstelle ersetzt werden.
  • Resource-Maschine: Unattached resources können einfach zwischen zwei Maschinen ausgetauscht werden, fastened resources können nur unter hohen Kosten ausgetauscht werden während fixed resources an eine bestimmte Maschinen gebunden sind.

Lösungsansätze zum Bewegen von Resourcen sind z.B. das Kopieren einer Resource, das Einrichten einer Referenz auf eine entfernte Resource oder das Binden einer lokal verfügbaren Resource


Bild aus den Folien:

TU Wien-Verteilte Systeme VO (Göschka) - Bild Code Migration.png


5.Static/Dynamic Invocation[Bearbeiten]

Frage: Was versteht man unter "static" und "dynamic" Invocation von verteilten Methoden? Geben Sie Beispiele an.

{{#dpl:resultsheader=Diese Frage wurde bereits in folgenden Prüfungen gestellt: |oneresultheader=Diese Frage wurde bereits in der folgenden Prüfung gestellt: |noresultsheader=* Diese Frage wurde noch nie gestellt! |skipthispage=no |shownamespace=false |uses=Vorlage:Kapitel |replaceintitle=/Verteilte Systeme VO \(Göschka\)\/Prüfung/, |include={Kapitel}.dpl |includematch=/\|\s*TU Wien:Verteilte Systeme VO \(Göschka\)\/Fragenkatalog Wiki\s*\|\s*Static\/Dynamic Invocation\s*/si}}


Static Invocation setzt voraus, dass die Schnittestellen eines Objektes bereits bekannt sind. Eine Änderung erfordert eine Neukompilierung am Client.

Bsp. MyObject.doSomething(in1, in2, out1, out2)


Dynamic Invocation erlaubt es den Namen der Methode des verteilten Objekts, die es aufrufen will, zur Laufzeit zu bestimmen.

Bsp. invoke(MyObject, id(doSomething), in1, in2, out1, out2).

Id() bezeichnet hier den Look-up nach dem Methodennamen (z.B. aus einem Directory Service).

Anm. koDiacc: in PHP könnte dynamic Invocation zB so aussehen. $function_name = "getItDone"; $function_name(); es wird somit die function getItDone() aufgerufen. Sichere Variante wäre is_callable(). Ist nun vielleicht nicht die richtige Antwort im Bezug auf VS, aber mir hats geholfen, das besser zu verstehen :) Quelle: https://web.archive.org/web/20180817172248/http://www.recessframework.org/page/php-callables-is-callable-call-user-func-array-reflection


Anwendungen von dynamic Invocation:

object browser, run-time inspection, batch processing, frameworks