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

Aus VoWi
Zur Navigation springen Zur Suche springen

« Prüfung 2009-01-23 | Prüfung 2009-04-30 »

Frage 1[Bearbeiten]

Frage: Was versteht man unter der vertikalen Verteilung bzw. N-Schichten-Systemen? Diskutieren Sie dabei alle Grundvarianten von Client/Server-Systemen. Ist folglich ein Java Applet eher ein Thick Client oder ein Thin Client?

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


Vertikale VerteilungÜbersicht über mögliche Verteilungen zwischen Client und Server

Das charakteristische Merkmal einer vertikalen Verteilung ist, dass sie erzielt wird, indem logisch unterschiedliche Komponenten auf (physisch) unterschiedlichen Maschinen angeordnet werden.

Das Client/Server Modell wird grundsätzlich in 3 verschiedene Anwendungsschichten unterteilt:

  • Die Ebene der Benutzeroberfläche enthält alles, was erforderlich ist um direkt mit dem Benutzer zu interagieren. Bsp.: Verwaltung der Bildschirmdarstellung
  • Die Verarbeitungsebene (Business Logic)
hier wird die Kernfunktionalität programmiert. (enthält Anwendungen)
  • Die Datenebene
hier werden die Daten unabhängig von der Applikation persistent gespeichert

Bei einer Unterscheidung von Client- und Serverseite spricht man von einer two-tier Architektur. Folgende Aufteilungen sind dabei denkbar:

  • (a) Nur ein Teil des UI liegt auf der Clientseite, z.B. ein Terminal.
  • (b) Der client-seitige Prozess stellt das gesamte User Interface dar, alles andere wird vom Server übertragen.
  • (c) Teile der Applikation werden zum Client verlagert, z.B. für einfache Operationen wie das Überprüfen der Korrektheit von Daten, bevor sie zum Server geschickt werden.
  • (d) Der Server wird nur als Persistenzschicht verwendet. Applikationen laufen am Client und führen nur Operationen auf Files oder Datenbanken am Server durch.
  • (e) Teile der Daten liegen auch beim Client, z.B. Caches.

Bei (a) und (b) spricht man von Thin Clients, bei (d) und (e) von Fat Clients.

Wenn die 3 Anwendungsschichten auf 3 verschiedenen Maschinen ansäßig sind, liegt eine three-tier Architektur vor, wie es z.B. bei vielen Websites der Fall ist: Der Web Server agiert nur als Entry Point einer Seite und leitet die Anfrage weiter an einen Application Server, welcher wiederum einen Datenbankserver aufruft.

Ein Java Applet ist irgendwo in der Nähe von (c/d) anzusiedeln, was es eher zu einem Fat Client macht. (User Interface und Application werden am Client ausgeführt)


Frage 2[Bearbeiten]

Frage: Wie kann man die Flexibilität der Middleware erhöhen sowie die Zusammenarbeit von Middleware und Anwendung effizienter gestalten? Erläutern Sie dabei die Grundprinzipien von Interceptoren, Adaptivität und Self-Management.

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

Flexibilität der MW erhöhen:

  • Interceptors
  • Separation of concern (Modularisierung)
  • Reflection (Anpassen der Parameter zur Laufzeit)
  • Component-based design
  • Middleware-Application interaction (Plug-ins, ...)
  • Autonomic computing, self-* (Selbstregulierung, Selbstwiederherstellung, ...)


Ein wichtiger Zweck von Middleware (Schicht zwischen Applikationen und verteilten Plattformen) ist es, einen gewissen Grad an Verteilungstransparenz zu bieten. Auch Middleware-Systeme folgen bestimmtem Architekturstil (z.B. Object-based (CORBA, Event-based (TIB/Rendezvous)) Middleware-Systeme sollen einfach konfigurierbar, adaptierbar und individuell anpasspar sein, je nach Applikation daher wird Trennung zwischen Policy und Mechanismus vorgenommen!

TODO /* bzg. effizientere Gestaltung würde ich meinen, dass hier eine bessere Anpassbarkeit (eventuell automatisch) Bezug genommen werden kann (seite 58 / 59 Discussion bietet da glaub ich eine gute Richtlinie für die Beantwortung)


Interceptors

Software-Konstrukte, die den normalen Kontrollfluss unterbrechen und es erlauben, anderen (Applikations-spezifischen) Code auszuführen = Mittel um die Middleware anzupassen Objekt A ruft eine Methode auf, die zu Objekt B gehört, welches sich auf einer anderen Maschine als Obj. A befindet. Das ist ein Remote Object Call, dieser erfolgt in drei Schritten:

  1. A und B bieten beide das gleiche Interface an. A ruft die Methode auf, die in diesem Interface verfügbar ist auf.
  2. Der Aufruf von A wird in eine "generic object invocation" transformiert, möglich gemacht durch ein "object-invocation interface" der Middleware der Maschine, auf der sich A befindet.
  3. Am Schluss wird die "gen. obj. invoc." in eine message transformiert und wird über das transport-level network interface geschickt, das A's local operating system anbietet.
Generelle Ansätze zu Adaptiver Software

Middleware soll sich an Veränderungen in der Umgebung eines DS anpassen –> Konstruktion adaptiver Software. Drei Basistechniken, um zu Software-Adaptierung zu kommen:

  1. Separation of concerns: Traditionelle Art, Systeme zu modularisieren (d.h. Trennen der Teile eines Systems, die Funktionalität implementieren, von denen, die für Extrafunktionalitäten wie Reliability, Performance, Security etc. zuständig sind.) – ist in DS nicht einfach (Thema für aspect-oriented software development)
  2. Computational reflection: Fähigkeit eines Programms, sich selbst zu überprüfen und, wenn notwendig, sein Verhalten anzupassen
  3. Component-based design: unterstützt Anpassung durch Komposition (dynamisch zur Laufzeit)
Self-Management in Verteilten Systemen

Selbstmanagement ist in großen, verteilten Systemen von entscheidender Bedeutung. Für viele Systeme stellen eine zentrale Verwaltung und Organisation keine optimale Lösung dar. Die meisten selbstverwaltenden Systeme haben gemeinsam, dass Anpassungen mithilfe einer oder mehrerer Rückkopplungsschleifen (feedback-control-loops) erfolgen. Diese Schleife besteht neben den Komponenten, die das eigentliche VS ausmachen, aus 3 Teilen:

  • Die metric estimation component quantifiziert die Aspekte eines Systems, die Rückschlüsse auf seine Effizienz zulassen, z.B. Latenzzeiten.
  • Die feedback analysis component wertet diese Messungen aus und bestimmt, welche Veränderungen am System vorgenommen werden.
  • Schließlich beeinflussen verschiedene Anpassungsmechanismen das System direkt und verändern z.B. die Platzierung von Repliken, Scheduling Strategien oder Lastverteilung


Frage 3[Bearbeiten]

Frage: Wie funktioniert die Parameterübergabe bei RMI? Gehen Sie dabei auf jene Eigenschaften der Objektorientierung ein, welche den Vorteil von RMI gegenüber RPC bewirken.

{{#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*Parameterübergabe bei RMI\?\s*/si}}

In Java geht man davon aus, dass die Parameter einer Methode Eingabeparameter sind und dass es sich beim Ergebnis einer Methode um einen einzelnen Ausgabeparameter handelt. Für das Marshalling der von Argumenten und Ergebnissen wird die Serialisierung von Java verwendet. Somit kann jedes Objekt, das serialisierbar ist in Java RMI als Argument oder Ergebnis übergeben werden.


In Java war es wichtig, ein hohes Maß an Verteilungstransparenz zu erreichen und Remote Calls soweit wie möglich wie lokale aussehen zu lassen.

Das Prinzip der Stubs bleibt unverändert. Der Client-Stub wird hier als Proxy, der Server-Stub als Skeleton bezeichnet. Der Client übergibt bei RMI lokale Objekte als Methodenparameter dem Proxy mittels Copy/Restore, entfernte Objekte hingegen können als Referenz übergeben werden. ? Entspricht der OO.

Eine Referenz auf ein Verteiltes Objekt beinhaltet folgende Informationen:

  • Netzwerkadresse
  • Endpunkt des Servers
  • lokaler Bezeichner des echten Objekts (nur von Server verwendet)

In einem RPC werden alle Methodenparameter immer mittels Copy/Restore Variante übergeben.


In beiden Fällen werden die Parameter schlussendlich vom Proxy gemarshalled und an den Server-Stub/Skeleton gesendet.


mehr infos => siehe p.460 Kapitel 10.3.3 (lokale Objekte können kopiert werden, remote Objects per Reference übergeben)


Unterschied zu RPC ist, wenn Referenzen zu einem wiederum entfernten Objekt übergeben werden, werden diese nicht durch copy/Restore übergeben sondern wieder als Referenz, um die sich dann der Server weiter kümmert.


EDIT: ich glaube folgendes trifft es besser: Vergleich: Verteile Systeme 2003 (s.114 Kapitel 2.3.4 Parameterübergabe)

Weil die meisten RMI Systeme systemübergreifende Objektreferenen unterstützen, ist die Parameterübergabe in Methodenaufrufen im Allgemeinen weniger eingeschränkt als bei RPCs.

Bei RMIs können Objektreferenzen konistent als Parameter in Metohdenaufrufen verwendet werden. Die Referenz wird als Wert übergeben und somit von einer Maschine auf die andere kopiert. Eine ausschließliche Verwendung von Objektreferenten kann aber sehr inefektiv sein. Z.B. Dann wenn es sich lediglich um kleine Objekte wie Integers oder Boolsche Werte handelt. Hierbei muss für jeden Aufruf eine Aufforderung in verschiedenen Adressräumen und noch schlimmer zwischen verschiedenen Maschienen gemacht werden.

Deshalb werden Referenzen auf entfernte Objekte und solche auf lokale Objekte häufig unterschiedlich behandelt: Wird eine Methode mit einer Objektreferenz als Parameter aufgerufen wird diese Referenz nur dann kopiert und als Wertparameter übergeben, wenn es sich auf ein entfernetes Objekt bezieht. In diesem Fall wird das Objekt tatsächlich als Referenz übergeben. Bezieht sich die Referenz jedoch auf ein lokales Objekt (selber Adressraum wie Client), so wird das refenzierte Objekt als ganzes kopiert und zusammen mit dem Aufruf übergeben. Also wird das ganze Objekt als Wert-Parameter übergeben.

TODO: Wie spielt dies mit der OO zusammen?


Frage 4[Bearbeiten]

Frage: Erläutern Sie das Konzept der Virtualisierung und in weiterer Folge deren Bedeutung für die Code Migration in heterogenen Umgebungen. Beschreiben Sie die zwei verschiedenen Arten von Architekturen von "virtual machines".

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

Prozesse und Threads können als Möglichkeit gesehen werden, mehrere Aufgaben (scheinbar) zeitgleich zu absolvieren. Auf einem Computer mit einem einzigen Prozessor ist diese Gleichzeitigkeit natürlich eine Illusion, die durch schnelles Umschalten zwischen beiden Prozessen erreicht wird. Virtualisierung erweitert diesen Gedanken auf Ressourcen, und wird auch als resource virtualization bezeichnet.

Es gibt viele unterschiedliche Arten von Interfaces, die von den einfachen Befehlssätzen einer CPU bis über eine enorme Sammlung von Application Programming Interfaces die mit vielen Middlewaresystemen geliefert werden. Hier dient Virtualisierung dazu, dass ein Interface erweitert oder ersetzt wird, damit es die Eigenschaften eines anderen Systems imitieren kann. (Bild auf Seite 80, englische Ausgabe, Second Edition)

Virtualisierung hilft:

  • Altlasten-Interfaces auf neue Plattformen zu transportieren.
  • Verschiedene Applikationen laufen auf unterschiedlichen Rechnern auf die unterschiedliche Clients zugreifen können. Gleichzeitig sollen unterschiedliche Ressourcen leicht verfügbar sein für die Applikationen. Durch Virtualisierung kann man die Unterschiedlichkeit von Plattformen und Maschinen reduzieren, indem man jede Applikation auf einer eigenen Virtual Machine laufen lässt und sowohl die Libraries als auch das Betriebssystem übernimmt.
  • In Content Delivery Netzwerken die replication unterstützen, ist das Management einfacher, wenn die Server Virtualisierung unterstützen. Damit wird erlaubt eine gesamte Seite, samt der Umgebung zu Kopieren.

Vorteile:

  • Erreichen von Flexibilität
  • Erreichen von Portabilität
  • Austauschbarkeit (in Bezug auf das hostende OS. Sollte dies nicht übereinstimmen, so kann durchaus eine neue VM installiert werden, um die Applikation wieder zum Laufen zu kriegen)

Architekturen:

Process Virtual Machine: We can build a runtime system that essentially provides an abstract instruction set that is to be used for executing applications. Instructions can be interpreted (as in the case for the Java runtime environment), but could also be emulated as is done for running Windows applications on UNIX platforms. Note that in the latter case, the emulator will also have to mimic the behavior of system calls, which has proven to be generally far from trivial. Stressing that Virtualisation is done essentially only for a single process.

VMM: An alternative approach toward virtualization is to provide a system that is essentially implemented as a layer completely shielding the original hardware, but offering the complete instruction set of that same (or other hardware) as an interface. Crucial is the fact that this interface can be offered simulatneously to different programs. As a result, it is now possible to have multiple, and different operating systems run independently and concurrently on the same platform. The layer is generally referred to as a virtual machine monitor (VMM). Typical examples of this approaches are VMware and Xen.

VMMs werden immer wichtiger im Kontext von Verlässlichkeit und Sicherheit für Verteilte Systeme. Da sie eine komplette Isolation der Anwendung und der Umgebung davon durchführen kann ein Fehler oder eine Sicherheitsattacke nicht mehr die ganze Maschine lahm legen, sondern nur den Teil der VMM. Die restlichen laufen also normal weiter. Weiters wird bei VMMs das Decoupling noch weiter getrieben, was eine noch bessere Portabilität bewirkt - nichts von den Schichten über dem VMM ist mehr abhängig von einer speziellen Hardware darunter.

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


Code Migration in heterogeneous systems

Anfangs war es recht schwer, Code Migration zwischen unterschiedlichen Plattformen durchzuführen, zB Pascal Code zu migrieren. Durch die Einführung von Virtualisierung wurde dies enorm erleichtert. Entweder man setzt überhaupt auf ein virtuelles Betriebssystem um die Migration so einfach als möglich zu gestalten, oder man geht den Weg wie Java ihn gegangen ist.

Code wird in Java nicht mehr direkt auf Maschinenbefehle runterkompiliert sondern auf eine Art "intermediate language", der dann plattform unabhängig ist und von einer plattform abhängigen JVM (java virtual machine) interpretiert wird. Dadurch erreicht man ein hohes Maß an Portabilität und Flexibilität was das Betriebssystem und dergleichen betrifft.


Frage 5[Bearbeiten]

Frage: Was ist ein "Name Space"? Erläutern Sie das Grundprinzip des "Closure Mechanismus" anhand eines Beispieles (zB Unix File System).

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

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

Name Space: Namen werden in einem Verteilten System mithilfe eines Namespace organisiert. Ein Name identifiziert ein Objekt. Namen sind dabei immer relativ zu einem Verzeichnisknoten. Zur eindeutigen Zuordnung ist jedoch der entsprechende Kontext – eben der Namensraum zu beachten. Hierarchische Namen können als beschriftete gerichtete Graphen dargestellt werden:

  • Blattknoten = benannte Entität
  • Verzeichnisknoten (hat ausgehende Kanten): speichert eine Verzeichnistabelle: jede ausgehende Kante wird als Paar der Form (Kantenbeschriftung, Knotenbezeichner) gespeichert, (siehe obige Skizze)


Durch 'Aliases können mehrere Namen auf die gleiche Entität zeigen.

  • Hardlinks: absolute Pfade verweisen auf den selben Knoten im Graphen (siehe Fig. 5-9.)


  • Symbolic Links: speichern Pfad zu einer Entität

Symboliclink.png


Durch Mounting können Namensräume miteinander kombiniert werden. (benötigt: access protocol, server, mounting point).


Closure Mechanismus: zu wissen, wie und wo die Namensauflösung beginnen soll ? Auswahl des ersten Knotens.

Bsp. Unix: um absoluten Verzeichnispfad (/users/home) aufzulösen, muss dem Dateisystem der Root-Knoten „/“ bekannt sein. Der tatsächliche Offset des Root-Knotens ist im Superblock des logischen Laufwerks kodiert.

Bsp. DNS: Der Closure Mechanismus bei DNS sind die IP-Adressen der 13 DNS-Root-Server


Frage 6[Bearbeiten]

Frage: Welche Probleme gibt es bei der Ermittlung des "Global State" und wie können diese überwunden werden? Geben Sie zumindest einen Algorithmus an. Hinweis: Dies wird nur in den Folien und im PDF (weiter unten und im Fragenkatalog und auf der Homepage im Fragenkatalog) erwähnt.

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

Global State
Der Globale State eines verteilten Systems besteht aus

  • dem localen Zustand eines jeden Prozesses
  • zusammen mit den Nachrichten die gerade unterwegs sind (gesendet aber noch nicht empfangen)


Probleme:

  • Es könnte ein inkonsistener "Schnitt" durch das System gemacht werden. (Ergebnisse ohne Ursache. z.B.: Empfangen einer Nachricht ohne Senden dieser Nachricht)
  • Keiner hat eine globale Sicht auf das System.
  • Es gibt keine gemeinsame Zeit für die Aufzeichnung ("Stichtag")

Lösung der Probleme durch Ermittlung des Globale State durch Chandy und Lamport-Algorithmus.

Bitte die Probleme überarbeiten, mir ist nicht mehr eingefallen


Algorithmus von Chandy und Lamport (Snapshot vom Global State):

Chandy Lamport.png

Ein Initiator beginnt seinen eigenen Status aufzuzeichnen und schickt einen Marker aus. Beim Empfang des 1. Markers zeichnet jeder Rechner seinen lokalen Status auf und schickt den Marker weiter. Bis zum Empfang des Markers zum zweiten Mal zeichnet queued jeder Prozess alle eingehenden Nachrichten. Beim Empfang des Markers zum zweiten Mal ist die Aufzeichnung abgeschlossen: der lokale Status und die aufgezeichneten Nachrichten können an den ursprünglichen Initiator gesendet werden, wo dann die Auswertung passiert.

Der aufgezeichnete Status ist garantiert konsistent, kann aber Kombinationen von lokalen Zuständen enthalten, die so nie aufgetreten sind.

EDIT: Ich verstehe den Algorithmus (lt. wikipedia) anders: Der Initiator schickt einen Aufzeichnungs-Marker an alle anderen Rechner. Wenn ein Rechner den Marker zum ersten Mal erhält, schickt er seinen momentanen Status an den Initiator und hängt den Marker an alle anderen seiner ausgehenden Pakete (um den Marker weiter zu verbreiten). Erhält er jetzt eine Message an der kein Marker hängt, so war dieses Message offensichtlich gerade "im Äther" als die Aufzeichnung begann. Da sie natürlich auch zum Global State gehört, wird die Message ebenfalls an den Initiator geschickt. Dieser hat dadurch den Überblick über den Status aller Rechner und aller Nachrichten die zu diesem Zeitpunkt im Netz unterwegs waren.

weitere Infos GlobalState.pdf,Chandy-Lamport-Algorithmus auf Wikipedia (de),Chandy-Lamport auf Wikipedia (en)

ausführliche Erklärung des Algorithmus: https://web.archive.org/web/*/https://users.informatik.haw-hamburg.de/~schmidt/vs/05_ZeituGlobalerZustand.pdf

EDIT2: Ich verstehs eigentlich nach dem Artikel in der deutschen Wikipedia und dem PDF auch so wie in der ersten Erklärung (nicht dem EDIT).

EDIT3: Ich verstehe es nach den Folien und dem PDF ebenfalls so wie ganz oben (und nicht im EDIT) beschrieben. -- emptyvi

EDIT4: Tatsächlich stimmt die erste Version mit der deutschen Wikipedia, und die zweite mit der englischen überein. Es handelt sich wohl um zwei verschiedene Varianten des Algorithmus. Bei der einen wird der Status nur aufgezeichnet, bei der anderen auch an den Initiator gesendet. Und dann muss die empfangene Nachricht auch weitergeleitet werden.


Frage 7[Bearbeiten]

Frage: Was sind Epidemic Protocols. Welche Vor- und Nachteile haben diese? Erklären Sie "gossiping" ("rumor spreading") im Zusammenhang mit Replica update propagation. Erläutern Sie Vor- und Nachteile. Erklären Sie das Anti-Entropy Modell im Zusammenhang mit Replica update propagation. Erläutern Sie Vor- und Nachteile.

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


Epidemic Protocols sind für Datenspeicher gedacht, welche nur eine schlußendliche (en eventual = de schlußendlich!) Konsistenz aufweisen müssen. Das heißt: Wenn es keine Aktualisierung gibt, muss nur sichergestellt sein, dass alle Repliken irgendwann identisch sind.

Das Hauptziel dieser Protokolle ist es, schnell Information an viele Knoten zu verbreiten während man nur lokale Informationen verwendet.

  • Vorteile: Gute Skalierbarkeit, Aktualisierung an alle Repliken erfolgt in so wenigen Nachrichten wie möglich -> geringe Netzwerkbelastung.
  • Nachteile: Weitergabe des Löschens eines Datenelements ist schwierig, löst keine Aktualisierungskonflikte, nur -e-v-e-n-t-u-e-l-l-e- schlußendliche Konsistenz (sehr schwache Konsistenz? -- nicht schwach, aber erst später).


Das Anti-Entropy Modell ist ein Weitergabemodell für Epidemische Protokolle welches per Zufall einen anderen Server auswählt, und mit diesem dann Aktualisierungen austauscht. Es kann pull- oder pushed basiert arbeiten (Ein Server schickt seine Updates zu einem anderen oder holt sie von einem anderen). Wenn viele Knoten infiziert sind, ist die Chance relativ gering über den push-Ansatz weitere Knoten für ein Update zu finden. Der pull-Ansatz funktioniert viel besser wenn viele Knoten infiziert sind.

EDIT1: Es ann gezeigt werden , dass Akutalisierungen irgenwann über alle Server verteilt werden wenn nur ein einziger Server infektiös ist (bei pull-Ansatz)

Gossiping ist eine spezielle Form des Anti-Entropy Modells und ein effizientes Weitergabemodell für Epidemische Protokolle. Die Funktionsweise ist einfach: Wenn ein Datenelement aktualisiert wurde, wendet sich der Server an einen beliebigen anderen Server um ihm die "Neuigkeit" mitzuteilen. Dieser wiederum macht dasselbe und kontaktiert den nächsten Server um die Aktualisierung vorzunehmen usw. Wenn ein Server erreicht wird, der schon "infiziert" wurde, ist die "Neuigkeit" nicht mehr so interessant und macht nur mehr mit einer gewissen Wahrscheinlichkeit weiter mit "gossiping".

  • Vorteil: Aktualisierung wird schnell weitergereicht
  • Nachteil: Es kann nicht garantiert werden das alle Server "infiziert" werden, sprich mit Aktualisierungen versorgt werden.

Daten löschen ist leider in den vorgestellten Ansätzen nicht so leicht. Epidemische Protokolle sind gut, um Daten zu verbreiten, aber ein Nachteil ist, dass das Löschen schwierig ist. Wenn man einen Datensatz von einem Knoten komplett löscht, ist der Knoten ja wieder susceptible (ansteckbar) und wird die "Krankheit" bald wieder bekommen. Daher muss man data removal per "death certificates" verbreiten, die eigentlich selbst nur Updates sind, die Datensätze ungültig machen. Leider wird es mit der Zeit sehr viele "death certificates" auf jedem Knoten geben, was Performanzmäßig nicht gerade ideal ist.


Frage 8[Bearbeiten]

Frage: Erläutern Sie die Fehlerklassen in RPC-Client/server-Umgebungen. Gehen Sie besonders auf das "lost reply" Problem ein.

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

In den Folien 75-80 steht noch ein wenig mehr zu den Fehlerklassen!

Fehlerklassen von RPC Systemen:

  • Der Client kann den Server nicht finden.
  • Die Frage geht zwischen Client und Server verloren
  • Der Server stürzt nach Erhalt der Nachricht ab
  • Die Antwort des Servers geht auf dem Weg zum Client verloren
  • Der Client stürzt nach versenden der Anfrage ab

Falls die Antwort vom Server verloren geht (lost reply) ist es für den Client schwer zu sagen, ob die Antwort oder die Anfrage verloren gegangen ist, oder der Server in der Zwischenzeit abgestürzt ist. Eine Möglichkeit wäre es, die Anfrage erneut zu stellen, dies ist aber nur sinnvoll bei idempotenten Operationen (Operationen welche wiederholt ausgeführt werden können, z.B.: Daten lesen, während eine Überweisung von einem Konto zu einem anderen nicht idempotent ist). Man könnte nun versuchen alle Request idempotent aufzubauen, was aber nicht immer möglich ist. Eine weitere Möglichkeit wäre es, jeder Anfrage eine ID zu vergeben, sodass der Server erkennen kann, ob die Anfrage schon bearbeitet wurde, oder eine neue ist. In diesem Fall stellt sich die Frage, wie lange der Server sich die Anfragen merken soll. Zusätzlich könnte der Client bei jeder Nachfrage ein Bit anhängen, ob es sich um eine neue, oder eine wiederholte Anfrage handelt.


Frage 9[Bearbeiten]

Diese Frage war nicht im Fragenkatalog. Gefragt war: Was ist Authentication, Authorization und Access Control. Was ist ein Referenzmonitor? Nennen Sie Mechanismen für Zugriffssteuerung oder Zugriffskontrolle. (Letzteres bin ich mir nicht zu 100% sicher).

Authentifizierung – wird verwendet um die behauptete Identität eines Benutzers, Clients, Servers, Hosts oder einer anderen Entität zu überprüfen. Bei Clients gilt als grundlegende Voraussetzung, das ein Dienst die Identität eines Clients in Erfahrung bringen muss bevor er im seinen Auftrag in irgendeiner Wiese tätig wird (außer der Dienst steht jedem zur Verfügung). Benutzer werden im Normalfall durch Passwörter authentifiziert, aber es gibt viele andere Möglichkeiten.

Autorisierung - Nach Authentifizierung eines Clients ist es erforderlich zu prüfen, ob dieser Client autorisiert ist, die angegebene Aktion durchzuführen. Der Zugriff auf Datensätze in einer medizinischen Datenbank ist ein typisches Beispiel. Je nachdem, wer auf die Datenbank zugreift, kann das Erlaubnis für das Lesen der Datensätze, das Ändern bestimmter Fehler in einem Datensatz oder das Hinzufügen oder Löschen eines Datensatzes gewährt werden.

Access Control – Kontrollwerkzeuge zur Nachvervollgung verwendet, welche Clients worauf zugreifen haben und in welcher weise. Auch wenn Kontrollen keinen wirklichen Schutz vor Sicherheitsbedrohungen bieten, können Kontrollprotokolle äußerst nützlich für die Analyse eines Sicherheitsbruches und die Nachfolgende Einleitung von Maßnahmen gegen Eindringlinge sein. Aus diesem Grund sind Angreifer normal weise begierig, keine Spuren zu hinterlassen, die letztendlich zur Aufdeckung ihrer Identität führen könnten. Das Protokollieren von Zugriffen führt so manchmal dazu, dass Angriffe ein Riskanteres Unternehmen werden.

Buch Seite 414 - 2.Auflage Deutsch

Frage 10[Bearbeiten]

Frage: Erläutern Sie das Grundprinzip von publish/subscribe als Kommunikations-/Koordinationsmechanismus. Worin bestehen die Möglichkeiten aber auch die Probleme dieses Mechanismus (v.a. dessen Implementierung). Erläutern Sie weiters JINI und JavaSpaces als konkrete Technologien.

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

Publish/Subscribe-Systeme, bei denen Nachrichten mit einem gewissen Typ versehen werden. Diese werden an alle Prozesse zugestellt, die sich dafür interessieren (indem sie sich vorher dafür registriert haben). Funktioniert nur wenn beide Prozesse aktive sind. Dieser Ansatz wird als Meeting-based bezeichnet. Publish/Subscribe systeme sind referentiell ungekoppelt, und können temporal ungekoppelt (Message wird gespeichert und zugestellt, sobald Subscriber online) oder gekoppelt (Subscriber muss online sein um Message zu empfangen)

Vorteile: Der Publisher muss sich keine Gedanken um die Systemtopologie machen und um die Zustellung, sondern kann einfach eine Nachricht in das System schicken. Besser Skalierbar als ein traditionelles Client-Server Modell.

Nachteile: Der Publisher weiß nicht, wer die Nachrichten empfangen soll und kann nicht feststellen, ob alle, die die Nachricht erhalten sollen sie auch erhalten haben. Wenn es viele Publisher, aber nur einen Subscriber gibt, und der Subscriber crasht, gehen die Nachrichten verloren.

(Anm. koDiacc: Hab jetzt kein Buch zur Hand, aber müsste es nicht heißen: Wenn es viele Subscriber (=Abbonnementen) gibt, aber nur einen Publisher (Veröffentlicher), und der Publisher "baden" geht, stehen die Subscriber mit leeren händen da?)


Anm.: ich glaube, dass hier außerdem ("v.a. dessen Implementierung") das Broker-Konzept erklärt werden soll. Hier ein Versuch (hauptsächlich aus dem deutschen Buch (2008, S.176) kopiert):

Ein Broker verwaltet einen Vorrat aus Regeln und Programmen, die eine Nachricht des Typs T1 in eine Nachricht des Typs T2 umwandeln können. Das Problem besteht in der Regeldefinition und Programmentwicklung. Als kommerzielles Produkt werden Broker oftmals irreführend als "intelligent" bezeichnet. Broker werden jedoch mit umfangreichen Entwicklungswerkzeugen mitgeliefert, und der Vorrat an Regeln und Programmen muss weiterhin von Experten gefüllt werden. Die "Intelligenz" des Systems liegt also in Wirklichkeit in den Köpfen von Experten/Entwicklern.


Jini setzt Generative Communication um. Es speichert Tupel von Java-Objekten in einem Shared Dataspace (JavaSpace), aus dem sie von interessierten Prozessen durch Matching mit einem Template (ebenfalls ein Tupel aus Objekten, das aber nicht vollständig ausgefüllt sein muss) wieder abgefragt werden können. Das Abfragen kann dabei auch das gelesene Tupel auch gleich aus dem Datastore entfernen (take-Operation). Neben dem Zugriff auf JavaSpaces unterstützt Jini auch noch Naming und Security (Authentification, so dass nur berechtigte Prozesse auf den Datastore zugreifen können).. [ausreichend??]