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

Aus VoWi
Zur Navigation springen Zur Suche springen

« Prüfung 2008-07-04 | Prüfung 2008-12-05 »

Frage 1[Bearbeiten]

Frage: Was ist Transparenz? Beschreiben Sie die standardisierten Arten von Transparenz und erklären Sie den Zusammenhang zwischen den einzelnen Transparenz-Definitionen. Was ist der Nachteil von Transparenz?

{{#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*Was ist Transpar.*\s*/si}}

Transparenz: Die Verteilung des Systems soll vom Benutzer verborgen werden (ein VS, das für den User wie ein einziger Computer aussieht, nennt man transparent).

  • Access:Hide differences in data representation and how a resource is accessed
  • Location: Hide where a resource is located
  • Migration: Hide that a resource may be moved to another location
  • Relocation: Hide that a resource may move to another location while in use
  • Replication: Hide that a resource may exist in several copies
  • Concurrency: Hide that a resource may be shared by several competitive users
  • Failure: Hide the failure and recovery of a resource
  • Persistence:Hide whether a (software) resource is in memory or on disk

Frage:

  • Wo genau ist der Unterschied zu Skalierungs- u. Leistungstransparenz?


Zusammenhang 
Siehe Grafik in Folie 1 - Seite 39 (fälschlicherweise bezeichnet als Seite 41).

TU Wien-Verteilte Systeme VO (Göschka) - Zusammenhang transparenz.PNG

Nachteile 
Es gibt Situationen (wenn sich verteilte Systeme auf Geräte erstrecken, die von Menschen herumgetragen werden), in denen Orts- und Kontextkenntnis von Bedeutung sind. z.B.: ist es besser ein Dokument auf dem beschäftigten Drucker im Nachbarzimmer auszudrucken, als auf einem freien Drucker, der sich aber in einem anderen Land befindet.
Vollständige Verteilungstransparenz ist nicht möglich -> Benutzer verstehen das Verhalten eines VTs besser, wenn sie wissen, dass es so etwas wie Transparenz nicht gibt.
Es gibt Situationen in denen es keine gute Idee ist, alle Aspekte der Verteiltheit vor dem Benutzer komplett zu verbergen.
Trade-Off zwischen einem hohen Grad an Transparenz und der Performance des Systems! (z.B. wenn Replikas auf verschiedenen Kontinenten immer konsistent sein müssen, kann eine einzelne Update-Operation Sekunden dauern, was vor dem Benutzer nicht mehr verborgen werden kann; Maskierung des Ausfalls eines Servers kann System auch verlangsamen).
Was Embedded und Ubiquitous VS betrifft, kann es besser sein, die Verteiltheit offen darzustellen, anstatt sie verbergen zu wollen.
Angesichts der Tatsache, dass vollständige Verteilungstransparenz nicht möglich ist, ist fraglich, ob es überhaupt vernünftig ist, dies vorzugeben – wird die Verteilung explizit gemacht, so wird das (manchmal unerwartete) Verhalten eines VS verständlicher.


Frage 2[Bearbeiten]

Frage: Wie schreibt man für RPCs Client und Server und welche Rolle spielt dabei die IDL? Welche Ziele werden mit dem Einsatz einer IDL in einem verteilten System verfolgt? Was versteht man in diesem Zusammenhang unter "binding"?

{{#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*Client\/Server\/IDL bei RPC\s*/si}}


Verteilte Systeme - Client, Server, IDL.jpg

Der gesamte Prozess einen RPC-Client und Server zu schreiben und einzusetzen ist in nebenstehender Abblidung zusammengefasst.

In einem Client-Server-System ist die Schnittstellendefinition (angegeben in der IDL - Interface Definition Langugae) der Kleber, der alles zusammenhält. In den IDL-Datein sind Prozedurdeklarationen (in ähnlicher Form wie Funktionsprototypen in C), Typedefinitionen, Konstantendeklarationen und andere Infomationen für die korrekte Verpackung der Parameter und das Auspacken der Ereignisse enthalten.

Ein extrem wichtiges Element jeder IDL-Datei ist ein global eindeutiger Bezeichner für die spezifizierte Schnittstelle. Versucht ein Client versehentlich sich zu einem falschen Server zu binden, oder auch zu einer älteren Version des richtigen Servers, wird der Fehler erkannt und das Binden findet nicht statt.

Nachdem die IDL-Datei bearbeitet wurde (Namen der Prozeduren und ihre Parameter eingetragen) , wird der IDL Compiler aufgerufen.

Die Ausgabe des IDL-Compilers besteht aus drei Teilen:

  • Header-Datei (wird jeweils in den Sever- und Client-Code inkludiert)
  • Client-Stub
  • Server-Stub

Anschießend werden der Client sowie der Server Code kompiliert, ebenso wie die beiden Stub-Prozeduren. Die resultirenden Client-Code- und Client-Stub-Objektdateien werden anschließend zu der Laufzeitbibliothek gebunden, um die ausführbare Programmdatei für den Client zu erzeugen. Analog dazu werden der Server-Code und der Server-Stub kompiliert und gebunden (EDIT: gelinkt ist vielleicht besser), um die Programmdatei des Servers zu erzeugen. Mit dem Einsatz der IDL als Schnittstellendefinitionssprache wird die Applikationsentwicklung wesentlich vereinfacht. Daher bieten alle RPC basierenden Middleware-Systeme eine IDL, bei manchen ist sie sogar zwingend vorgeschrieben.

Binding bei RPC


Um eine fremde Prozedur aufzurufen, muss eine Nachricht vom Client-Prozess zum Server-Prozess versendet werden. In dieser müssen der Name der Prozedur (oder eine ID) und die zugehörigen Parameterwerte enthalten sein. Die Nachricht sollte letztlich bei einem Server-Prozess ankommen, der genau diese Prozedur implementiert.

Binding:

RMI Binding.png

  1. Server registriert einen Endpoint
  2. Server registriert einen Service
  3. Client looks up the Service at a Directory Service
  4. Client asks Server for Endpoint
  5. Client sends RPC


Frage 3[Bearbeiten]

Frage: Erläutern Sie die Grundprinzipien (Kategorien) von Message-orientierter Kommunikation und gehen Sie auf CORBA Messaging exemplarisch ein. Beschreiben Sie zwei unterschiedliche Methoden, wie asynchrone Methodenaufrufe in CORBA Messaging erfolgen können.

{{#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*Message-orientierte Kommunikation\s*/si}}


Message Orientierte Kommunikation basiert auf Nachrichten, die zwischen den einzelnen Systemen hin und hergeschickt werden und bieten Unterstützung für persistente/transiente, synchrone/asynchrone Kommunikation (MoM: persistent asynchron durch Queues; Message Passing Interface: transient synchron/asynchron).

Wichtig zu wissen bei den Queues ist folgendes: es gibt im Prinzip trotzdem keine Garantie, dass eine Message jemals gelesen wird, auch wenn sie in die Queue aufgenommen ist. Es kann also sein, dass es nie zu dem kommt. Dies ermöglicht aber genauso eine sehr lose Kopplung von Software!


CORBA Messaging verbindet Methodenaufrufe und objektbasierte Nachrichtenübermittlung mitteinander.


CORBA stellt dafür prinzipiell einen Nachrichtendienst zur Verfügung, über den persistente asynchrone Kommunikation trotz konsequenter objektbasierter Handhabung möglich wird.


Es gibt 2 Formen eines asynchronen Aufrufs:

  • Callback-Model: Zu jeder ursprünglichen Schnittstelle werden 2 neue Schnittstellen erzeugt, wobei eine dem Aufruf dient (Parameter enthalten keine Return Werte), und eine als Callback fungiert (Parameter sind Rückgabewerte der urspr. Schnittstelle). Sobald eine Antwort eintrifft, wird der Callback mit den Return Werten des Aufrufs ausgelöst. (Resultat der Invocation wird automatisch an Anwendungsebene weitergegeben, sobald sie verfügbar ist). Der Client muss eine Implementierung des Callbacks zur Verfügung stellen.

asynchroner Aufruf mit Callback

  • Polling-Model: Zu jeder ursprünglichen Schnittstelle werden 2 neue Schnittstellen erzeugt, wobei eine dem Aufruf dient (Parameter enthalten keine Return Werte) und eine Schnittstelle (Parameter sind Rückgabewerte der urspr. Schnittstelle), welche es der Anwendungsebene erlaubt, eingegangene Nachrichten (Resultate der Invocation) abzufragen. Dies muss von der Anwendungsebene explizit angestossen werden.

asynchroner Aufruf mit Polling

Beide Methoden können aus der ursprünglichen Schnittstelle automatisch generiert werden.


In beiden Fällen bleibt es dem Client überlassen, sich für synchrone oder asynchrone Kommunikation zu entscheiden und berühren den Server nicht.


Frage 4[Bearbeiten]

Frage: Was sind die Besonderheiten von Objekt-Servern? Welche Arten gibt es dabei für die "Invocation", also den Aufruf (evtl. auch die Aktivierung/Activation) eines Objektes auf Server-Seite (Policies hinsichtlich thread, code sharing, und object creation)? Was ist in diesem Zusammenhang ein Objekt-Adapter?

{{#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*Objektserver\s*/si}}

Ein Objektserver dient zum Bereitstellen von Objekten in einem Verteilten System. Im Gegensatz zu herkömmlichen Servern, stellt der Objektserver keine spezifischen Dienste zur Verfügung, dafür sind die Objekte des Servers zuständig. Der Objektserver stellt lediglich die Mittel, um lokale Objekte remote zugreifbar zu machen. Bevor ein Objekt aufgerufen kann, muss es in den Adressraum des Servers gebracht werden. Es gibt verschiedene Arten der Aktivierung von Objekten: Sie können beim Start des Servers (alle zugleich) erstellt werden, oder beim ersten Aufruf (können nach dem ersten Aufruf bestehen bleiben bis zur Beendigung des Servers, oder gleich nach Beendigung der Anfrage zerstört werden)

Des weiteren kann die activation policy eines Objektes festlegen, ob es in einem gemeinsamen Speicherbereich mit anderen Objekten, oder in einem eigenen Speicherbereich untergebracht wird (aus Sicherheitsgründen).

Durch Codesharing können sich Objekte den Code teilen, sodass dieser nur einmal am Server geladen werden muss (z.B.: Ein Objekt zum Zugriff auf eine Datenbank, welches von allen Anfragen benutzt werden kann). Es kann vom Objektserver für jedes Objekt ein Thread erzeugt werden, oder ein Thread für alle Objekte (Warteschlange falls Anfragen während der Bearbeitung eintreffen). Alle diese Entscheidungen werden in der activation policy festgelegt.

Der Object Adapter dient als Hülle um ein Objekt und stellt den Mechanismus bereit, um ein Objekt nach einer gewissen Strategie (activation policy) zu aktivieren.

Ein Objekt Server kann mehrere Object Adapter beinhalten, ein Object Adapter mehrere Objekte.

Wichtig ist noch, dass ein Object Adapter generisch ist, er weiß nicht von den Schnittstellen eines Objektes, nur so kann er für beliebige Objekte verwendet werden.


Die Skizze ist im englischen Buch (Second Edition) auf der Seite 77 zu finden. (--> glaub ich nicht) Hier wird wohl eher die Grafik von Seite 453 gemeint sein.

  • Seite 491 in der Deutschen ausgabe (2.auflage)

Bild: TU Wien-Verteilte Systeme VO (Göschka) - TU Wien-Verteilte Systeme Object Adapter.png


Frage 5[Bearbeiten]

Frage: Erklären Sie die Schichten der Verteilung von Name Spaces. Erläutern Sie die Einsatzmöglichkeiten von Replication und Caching in den verschiedenen Schichten. Erklären Sie verschiedene (hierarchische) Möglichkeiten der iterativen/rekursiven "name resolution".

{{#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*Schichten in Name Spaces\s*/si}}

Layer name spaces.png

Schichten:

  • Globale Schicht
    • wenige Knoten der höchsten Ebene (Root-Knoten und seine Kind-Knoten)
    • sehr stabil, da Änderungen sehr selten sind
    • können Organisation oder Gruppen von Organisationen abbilden (z.B. com, org, Länder: at, de)
    • geographische Ausdehnung: weltweit
    • Reaktionszeit im Sekundenbereich
    • Viele Replikate (da wenig Änderungen leicht zu replizieren)
    • Effektives Caching durch Clients (da wenig Änderungen zu erwarten sind)
  • Administrations Schicht
    • Knoten die innerhalb einer Organisation verwaltet werden
    • Besteht aus vielen Knoten (im Vergleich zur globalen Schicht)
    • Reaktionszeit im Millisekundenbereich
    • keine bis wenige Replikate
    • Caching durch Clients möglich
  • Management Schicht
    • Knoten die innerhalb einer Abteilung verwaltet werden
    • besteht aus zahllosen Knoten
    • Reaktionszeit: sofort
    • keine Replikate
    • Caching durch Clients manchmal möglich


iterative Namensauflösung:

  1. der Resolver übergibt den vollständigen Namen an Root-Server.
  2. Root-Server löst Name soweit wie möglich auf und gibt als Zwischenergebnis die Adresse des nächsten NS und dem verbleibenden Pfadnamen an den Client/Resolver zurück.
  3. Client fragt den retournierten NS nach dem verbl. Pfadnamen.
  4. Schritt 3 wiederholt sich solange bis der gesamte Namen aufgelöst wurde.

Iterative name res.png


Rekursive Namensauflösung:

  1. der Resolver übergibt den vollständigen Namen an den Root-Server.
  2. Wenn der NS den Namen nicht vollständig auflösen kann (oder aus dem Cache lesen kann) fragt er automatisch den nächsten NS ohne ein Zwischenergebnis an den Client zu senden.
  3. Sobald ein NS den Namen vollständig aufgelöst hat, wird des Endergebnis an den übergeordneten NS weitergegeben.
  4. Der Root-Server übergibt das vollständige Resultat an den Client.
  • Vorteil: effektiveres Caching, geringere Kommunikationskosten
  • Nachteil: benötigt mehr Leistung am Server

Recursive name res.png


Daher: Globale Schicht ? iterative, Administrationsschicht ? rekursiv


Caching steigert die Geschwindigkeit der Namensauflösung bei einem Cachehit und reduziert die Netzwerklast.


Replikation verbessert die Availability, steigert die Geschwindigkeit durch „nähere“ Replikate und reduziert Hot-Spots.


Frage 6[Bearbeiten]

Die Frage bestand aus 2 Fragen aus dem Fragenkatalog.


Frage: Was sind die Gründe für die Verwendung von Logical Clocks? Erklären Sie die Unterschiede zu den Physical Clocks. Was ist die "happened-before" Beziehung und wie funktionieren die "Lamport-Timestamps"?

{{#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*Logical Clocks\s*/si}}

Verwendung von Logical Clocks: Es ist meist ausreichend, wenn alle die selbe Zeit haben, auch wenn diese nicht mit der realen Zeit zusammenpasst. Es ist oft nur die Reihenfolge der Operationen wichtig.

Unterschiede: Die physikale Uhr ist die "reale" Uhr (Kristall-Oszillator, mittlere Sonnensekunde, Atomuhr (TAI, International Atomic Time), UTC (Universal Coordinated Time), wobei eine Logische Uhr eine Reihung der Ereignisse darstellt.

"happend-before"-Beziehung: a -> b wird gelesen als "a passiert vor b". Dies bedeutet, dass alle Prozesse wissen, dass a vor b eingetreten ist. Zwei Situationen:

  • wenn a und b im selben Prozess sind, und a tritt vor b ein dann ist "a->b" = true
  • wenn a das Ereignis darstellt, dass eine Nachricht von einem Prozess gesendet wird, und b ist das Ereignis, dass die Nachrricht von einem anderen Prozess empfangen wird. Eine Nachricht kann nicht empfangen werden, bevor sie gesendet wird (und auch nicht gleichzeitig).

Dies ist eine transitive Relation: a -> b und b -> c, dann a -> c

Lamport-Timestamps: Ereignisse werden nur durchnummeriert. Potentiell kausal abhängige Ereignisse (im Sinne der "happend-before"-Beziehung) bekommen dabei Nummern so zugewiesen, dass das abhängige Ereignis eine größere Nummer hat als die Ursache, und dass diese Nummern bei allen Prozessen gleich sind. Jeder Prozess hat seinen eigenen Counter (logische Uhr). Bei jedem Ereignis (Berechnung, Senden, Empfangen) wird er um 1 erhöht und hängt diese Zahl der Nachricht an. Empfänger setzt seinen Counter auf das Maximum aus seinem aktuellen Counter und der mitgeschickten Zahl, anschließend erhöht er seinen Counter um 1. Es muss immer gelten:

  • T(b) > T(a), falls a und b in dieser Reihenfolge im gleichen Prozess stattfinden

Eigenschaften:

  • 2 aufeinanderfolgende Ereignisse a und b im gleichen Prozess: T(a) < T(b)
  • Der Empfang einer Nachricht hat immer höhere Zahl als das Senden
  • Die Relation ist transitiv abgeschlossen

Es kann jedoch nicht auf kausale Abhängigkeiten geschlossen werden, d.h. T(a) < T(b) bedeutet nicht unbedingt dass a->b gilt (nur in die andere Richtung).


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.


Frage 7[Bearbeiten]

Frage: Was sind die Hauptgründe für den Einsatz von Replikation in verteilten Systemen? In welcher Beziehung stehen Replikation und Skalierbarkeit zueinander? Erläutern Sie in diesem Zusammenhang verschiedene Varianten der Content Replication und des Content Placement.

{{#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*Gründe für Replikation\s*/si}}

Die 2 Hauptgründe für die Replikation sind Zuverlässigkeit und Leistung.

Wurde ein Dateisystem repliziert, ist es unter Umständen möglich die Arbeit fortzusetzen, auch wenn ein Replikat abgestürzt ist (Es wird einfach auf ein anderes Replikat umgeschaltet). Daher wird die Zuverlässigkeit erhöht.

Die Skalierung nach der Größe tritt beispielsweise auf, wenn immer mehr Prozesse auf Daten zugreifen müssen, die von einem einzigen Server verwaltet werden. In diesem Fall kann die Leistung verbessert werden, indem man diesen Server repliziert und damit die Arbeit aufteilt.

Die Skalierung in Hinblick auf die Größe eines geografischen Bereichs kann ebenfalls eine Replikation erforderlich machen. Dabei wird eine Kopie der Daten in die Nähe des Prozesses platziert, der sie nutzt, und somit die Datenzugriffszeit reduziert.

Kehrseite der Replikation ist jedoch, dass Replikate Mehraufwand bedeuten, da die Daten konsistent gehalten werden müssen. Man muss also abschätzen ob das Einsetzen von Replikaten den zusätzlichen Aufwand (Traffic, Ressourcen) rechtfertigt. (Medizin schlimmer als Krankheit?=trade off)


Content Replication and Placement

TU Wien-Verteilte Systeme VO (Göschka) - distsys tanenbaum S298.gif


Replica-Server Placement (ist eigentlich nicht gefragt!) wo plaziere ich meine Replication-Server am besten?

  • Kriterium Latenz/Bandbreite
  • Autonome Systeme (AS)
    • Plazierung der Replika beim Router mit den meisten Inferfaces in einem AS
    • komplexe Berechnung
  • Regions (mehrere Nodes die den selben Content abfragen)
    • Region kann zu groß (zuviele Cluster für eine Replika) oder
    • zu klein gewählt sein (ein Cluster wird über mehrere Regions verteilt
    • einfache Berechnung um flash crowds (plötzlicher Anstieg) abzufangen



Content Replication and Placement

Permanente Repliken

  • Cluster Based: Server befinden sich am selben Ort, es kann zb. Round Robin durchgeführt werden
  • Mirroing: gespiegelte Server die sich an einem anderen Ort befinden

Server-initiierte Repliken:

  • Replika wird dynamisch installiert wo viele Request herkommen, dazu ist es notwendig
  • die Anzahl der Zugriffeauf ein File zu zählen und wissen woher der Zugriff kommt
  • Schwellenwert für
    • Replika erstellen
    • Replika löschen (wobei es immer eine Replika geben muss)
    • Wenn Wert zwischen beiden kann Content verschoben werden
  • Ideal um flash crowds abzufangen

Client-initiierte Repliken: Auch bekannt als Cache, werden auf dem lokalen Speicher oder im lokalen Netzwerk platziert. Dienen zum Verbessern der Zugriffszeiten auf Daten, werden jedoch nur eine begrenzte Zeit gespeichert um zu verhindern, dass extrem veraltete Daten verwendet werden, Effizienz kann gesteigert werden wenn ein gemeinsamer Cache verwendet wird.


Frage 8[Bearbeiten]

Frage: Erläutern Sie die Aussage der "Byzantinischen Generäle".

{{#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*"Byzantinische Generäle"\s*/si}}

Die Darstellung es Buches ist fehlerhaft und beschreibt nur eine abgewandelte Form des Three Byzantine Problems. Dies wurde von Prof. Göschka in der Vorlesung gesagt, und im Fragenkatalog nochmals extra darauf hingewiesen, dass die "originale" Version aus den Folien verwendet werden sollte, und NICHT die aus dem Buch. Deshalb habe ich die Beschreibung aus dem Buch, die vorher hier stand, ersetzt - hier steht also die korrekte Version.


Vorweg - wer das ganze im Original lesen will, sei hier an diesen Auszug von Lamport et al. verwiesen (Seite 384, 3. Absatz): http://research.microsoft.com/en-us/um/people/lamport/pubs/byz.pdf


Problembeschreibung:

Ein kommandierender General will einen Befehl an seine n-1 untergeordneten Generäle weitergeben. (Jeder der n Generäle könnte ein Verräter sein). Hierbei müssen jedoch die folgenden beiden Bedingungen erfüllt werden:

  1. Alle loyalen Generäle, befolgen den selben Befehl
  2. Wenn der kommandierende General loyal ist, befolgen alle loyalen Generäle seinen Befehl


Problemlösung und Aussage:

Es müssen zumindest 3m+1 Generäle vorhanden sein damit beide Bedingungen erfüllt werden können, wobei m die Anzahl der Verräter darstellt. Anders gesagt: Die Anzahl der Verräter muss < 1/3 der Gesamtanzahl der Generäle darstellen.

Hierzu noch zwei Abbildungen aus den Folien (Exemplarische Erklärung der Notation: 1:2:v ist hier als Prozess1 sagt, dass Prozess2 Befehl "v" sagt):

TU Wien-Verteilte Systeme VO (Göschka) - byz3.png

Hier ist zu erkennen, dass bei einem Verräter insgesamt 3 Generäle (Prozessen) nicht ausreichen. Es kann von den zwei loyalen Generälen keine Mehrheit gebildet werden.

TU Wien-Verteilte Systeme VO (Göschka) - byz4.png

Erst ab 4 Generälen (Prozessen) ist ein gemeinsamer Konsens unter Erfüllung der beiden obigen Kriterien möglich.


Frage 9[Bearbeiten]

Frage: Beschreiben Sie die Funktionsweise des RSA Algorithmus im Detail. Was sind die Vor- und Nachteile von RSA?

{{#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*RSA\s*/si}}

Bei RSA wird die Sicherheit dadurch erreicht, dass es keinen effektiven Algorithmus gibt um Primzahlen zu finden. Sowohl private als auch public key sind aus 2 sehr großen Primzahlen (hunderte Stellen) konstruiert. RSA zu knacken ist äquivalent darin diese zwei Primzahlen zu finden.

Private und public key werden in 4 Schritten erstellt:

  • Es werden 2 sehr große Zufallszahlen p und q erzeugt,
  • und deren Produkt n=p*q sowie z=(p-1)*(q-1) berechnet.
  • Anschließend wird ein Schlüssel (z.B. der öffentliche) d so gewählt dass, dass d relativ prim zu z ist, also ggT(d, z) = 1.
  • Der andere Schlüssel e wird so gewählt dass e*d mod z = 1 ist.

Eine der Nummern (z.B. d) wird dann zur Verschlüsselung, und die andere (z.B. e) zur Entschlüsselung verwendet.

Der gesamte öffentliche Schlüssel ist dann (d, n) und der private (e, n). Die beiden Schlüssel sind aber gleichwertig, d.h. man kann privaten und öffentlichen Schlüssel auch vertauschen (natürlich nur solange man keinen davon veröffentlicht hat).

Die Verschlüsselung passiert durch E(m) = m^e mod n, die Entschlüsslung durch m = D(E(m)) = E(m)^d mod n. m ist dabei ein Teil der Nachricht, der als Integer interpretiert im Bereich 0 – (n-1) liegen muss (dadurch kann der Rest bei Division durch n maximal n-1 sein).

  • Nachteil: größerer Rechenaufwand, und langsamer, Sicherheitspunkt: ist auch wirklich der richtige am anderen ende...
  • Vorteil:keine direkte Schlüsselübergabe wie bei gemeinsamem Schlüssel


Frage 10[Bearbeiten]

Frage: Was ist ein Web-Server? Wozu dient das Hypertext Transfer Protokoll HTTP? Nennen Sie zwei HTTP Operationen. Diskutieren Sie die Funktionsweise eines CGI-Programms.

{{#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*Webserver\/HTTP\/CGI\s*/si}}

Ein Webserver ist ein Programm das eingehende HTTP Anforderungen erfüllt, indem er das angeforderte Dokument lädt und es an den Client schickt.

HTTP ist ein allgemeines Client-Server-Protokoll, das für viele dokumentenbasierte Übertragungen im Internet verwendet wird. Es ist nicht für eine bestimmte Anwendung spezialisiert und kann Dokumente in beide Richtungen übertragen. Am bekanntesten ist die Übertragung gewöhnlicher Webseiten, es können aber auch ganze Anwendungen auf http aufgebaut werden. Obwohl http selbst zustandslos ist kann man mit Hilfe von Cookies ein zustandsbehaftetes Protokoll simulieren, was für moderne Webabwendungen notwendig ist. Insgesamt wird http verwendet um von Clients aus bestimmte Services in Anspruch nehmen zu können.

HTTP-Operationen:

Operation Beschreibung
Get Dokument an den Client schicken
Put Dokument speichern
Post Bereitstellung von Daten die einem Dokument hinzugefügt werden soll
Delete Dokument löschen
Head Anforderungen, Head eines Dokument zurückzugeben

"Head" wird verwendet am Server, wenn der Client nicht das eigentliche Dokument will, aber die dazugehörigen Metadaten.

Mit "Get" bekommt ein Client ein Dokument vom Server.

Mit "Put" fragt der Client den Server, ob er ein Dokument unter einem bestimmten Namen speichern kann. (Der Server weist zwar nicht einfach Anfragen zurück, akzeptiert aber nur jene von Authorisierten Clients).

"Post" ist ähnlich dem Speichern eines Dokumentes, nur dass der Client eine Anfrage schickt, um Daten zu einem Dokument oder einer Sammlung von Dokumenten hinzuzufügen. (Bsp.: Artikel zu einer Newsgroup hinzufügen).

"Delete" ist eine Anfrage um ein Dokument mit einem bestimmten Namen zu löschen.


CGI (Common Gateway Interface) ist eine der ersten Erweiterungen der HTML Basis-Architektur und dient der Unterstützung einfacher Benutzer-Interaktion. Es definiert eine Standardmethode, wie der Webserver ein Programm ausführen kann mit Benutzerdaten als Input. CGI Programme arbeiten meist mit der lokal auf dem WEB server gespeicheten Datenbank. Nach Verarbeitung der Daten erzeugt das Programm ein html-Dokument und gibt dies dem Server zurück, der es dem Client weiter gibt. (Generierte Dokumente)