TU Wien:Verteilte Systeme VO (Göschka)/Prüfung 2010-03-11

Aus VoWi
Wechseln zu: Navigation, Suche

« Prüfung 2010-01-08 | Prüfung 2010-04-29 »

Modus[Bearbeiten]

5 Fragen, nur 4 davon sind zu beantworten. zeit: 45 Minuten. Alle Fragen aus dem Fragenkatalog.

Prüfungsfragen[Bearbeiten]

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: 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 3[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 4[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 5[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)