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

Aus VoWi
Zur Navigation springen Zur Suche springen

« Prüfung 2008-12-05 | Prüfung 2009-03-19 »

Frage 1[Bearbeiten]

Frage: Was versteht man unter "Openness"?

{{#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 versteht man unter "Openness"?\s*/si}}

Ein "Offenes VS" bietet Dienste nach Standardregeln an, die die Syntax und die Semantik dieser Dienste beschreiben.

In VS werden Dienste generell durch Schnittstellen (Interfaces) spezifiziert, die oft in einer Interface Definition Language (IDL) beschrieben sind.

Gute Spezifikationen sind vollständig (alles, was für eine Implementierung erforderlich ist, wurde spezifiziert) und neutral (Spezifikationen schreiben nicht vor, wie eine Implementierung aussehen soll).

Vollständigkeit ist wichtig für Interoperabilität (beschreibt den Grad bis zu dem zwei Implementierungen von Systemen/Komponenten verschiedener Hersteller zusammenarbeiten können, indem sie sich lediglich auf die Dienste der anderen verlassen, die nach einem gemeinsamen Standard spezifiziert sind).

Neutralität ist wichtig für Portabilität (beschreibt, in welchem Ausmaß eine Anwendung, die für VS A entwickelt wurde, ohne Veränderungen auf VS B ausgeführt werden kann, das dieselben Schnittstellen wie A implementiert).

Ein offenes VS sollte auch erweiterbar sein (Hinzufügen/Ersetzen von Komponenten, ohne dass die vorhandenen beeinträchtigt werden) -> Flexibilität

Um in einem offenen VS Flexibilität zu erzielen, sollte es aus kleinen, einfach austauschbaren/anpassbaren Komponenten angeordnet sein -> impliziert, dass nicht nur Definitionen der Schnittstellen der obersten Ebene (die von Benutzern/Anwendungen gesehen werden), sondern auch für Schnittstellen zu den internen Bestandteilen des Systems bereitgestellt werden sollten, und außerdem beschrieben wird, wie diese Bestandteile zusammenarbeiten.


Nötig ist Trennung von Policy (Richtlinie) und Mechanismus!

Eine Definition: Offenheit (Openness): Ein verteiltes System ist ein offenes verteiltes System, wenn neue Dienste zu den bereits existierenden Diensten hinzugefügt werden können, ohne letztere zu Unterbrechen bzw. Dienste zu duplizieren


Frage 2[Bearbeiten]

Frage: Erläutern Sie das Grundprinzip des Remote Procedure Call. Gehen Sie auf die Begriffe "client stub" und "server stub" näher 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*Remote Procedure Call\s*/si}}


Programme erhalten die Möglichkeit Prozeduren auf entfernten Rechnern auszuführen. Wenn ein Prozess auf Rechner A eine Prozedur auf dem Rechner B aufruft, wird der Prozess auf A angehalten und die Ausführung der aufgerufenen Prozedur findet auf Rechner B statt. Die Parameter können Informationen vom Aufrufer zum Aufgerufenen übertragen und werden im Ergebnis der Prozedur zurückkommen.

  • Der Client-Stub (auf dem Rechner des Clients) kapselt den entfernten Aufruf. Für den Aufrufer sieht der Aufruf also lokal aus. Erst durch den Client-Stub erfolgt die Weiterleitung des Aufrufs an den Server
  • Der Server-Stub auf dem Server kapselt die eigentliche Prozedur, die aufgerufen wird. Der Server-Stub nimmt den entfernten Aufruf an. Für die Server-Prozedur sieht der Aufruf so aus als käme er von einem lokalen Programm


A client stub is responsible for conversion of parameters used in a function call and deconversion of results passed from the server after execution of the function.
A server stub , is responsible for deconversion of parameters passed by the client and conversion of the results after the execution of the function.

Um einen RPC kurz zusammen zu fassen, sollen folgende Dinge erwähnt sein (Ablauf eines RPCs OHNE das Marshaling zu erwähnen):

  1. die Client Proc ruft den Client Stub auf
  2. der Client Stub baut sich an Hand der Parameter die Message und gibt diese dem OS
  3. das OS versendet diese Message an das OS des Remote Rechners
  4. das OS des Remote Rechners nimmt die Message entgegen und gibt sie dem Server Stub
  5. dieser packt die Parameter aus und ruft dann (lokal) den Server auf
  6. ... (Weg retour mit Return-Parametern) ...


Frage 3[Bearbeiten]

Frage: Was versteht man unter "Message-oriented Middleware MoM"? Erläutern Sie Modell und Architektur solcher "Message-Queueing"-Systeme. Erklären Sie die Primitivoperationen Put, Get, Poll und Notify eines Message-Queuing Systems. Diskutieren Sie Einsatzzwecke sowie Vor- und Nachteile - gehen Sie insbesonders auf den Begriff des Message Brokers und dessen Bedeutung für EAI 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*Message-oriented Middleware\s*/si}}


MoM bieten Unterstützung für persistente asynchrone Kommunikation. Anwendungen kommunizieren, indem sie ihre Nachricht in eine Message Queue einstellen. Jede Anwendung hat ihre eigene Queue von der sie liest.

Ein Sender einer Nachricht erhält nur eine Garantie, dass die Nachricht irgendwann in die Queue eingefügt wird.


Vorteil: Empfänger kann passiv sein während Sender sendet und umgekehrt (loosly-coupling).

Für das loosely-coupling gibt es 4 Kombinationen:

  • Sender running - Receiver running
  • Sender running - Receiver passive
  • Sender passive - Receiver running
  • Sender passive - Receiver passive


Nachteil: Übertragung kann sich im Minutenbereich abspielen.


Architektur:

MOM Architektur.png

  • Get: blockt solange die Queue leer ist; gibt ansonsten die erste Nachricht zurück
  • Put: hängt eine Nachricht an eine Queue an
  • Poll: Queue nach Nachrichten durchsuchen, gibt die erste Nachricht zurück. Blockt niemals.
  • Notify: installiert einen Handler, der aufgerufen wird, wenn eine Nachricht in die Queue gestellt wird.


MoM erlaubt es loosly-coupled Systems zusammenzuarbeiten. Unterschiedliche Systeme kommunizieren möglicherweise über unterschiedliche Nachrichtenformate, die von anderen Systemen nicht verstanden werden.

Message-Broker und Einsatz in EAI: Der Hauptzweck eines Message-Brokers (MB) ist es, eingehende Nachrichten so umzuwandeln, dass sie von der Zielanwendung verstanden werden können. Zusätzlich zu seiner Hauptaufgabe kann ein Message-Broker jedoch noch andere Aufgaben erfüllen - so wird ein Message-Broker etwa für EAI (Enterprise Application Integration) verwendet. Hierbei handelt es sich um ein sogenanntes Publish/Suscribe-Modell. Hierbei senden Anwendungen Veröffentlichungen zum Thema X an den Broker, der diese Veröffentlichungen dann an andere Anwendungen, die Thema X abonniert haben, weiterleitet. (lt. Verteilte Systeme - Principles and Paradigms (Tanenbaum) Seite 175 f.).


Frage 4[Bearbeiten]

Frage: Welche Aspekte Verteilter Systeme sind auf Client-Seite zu berücksichtigen? Wie werden User Interfaces in die Architektur Verteilter Systeme eingebunden? Wie können dabei verschiedene Arten der Transparenz unterstützt 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*Verteilte Systeme auf Client-Seite\s*/si}}

TODO: Verschiedene Aspekte? Wie werden sie eingebunden?


Paper über die Entwicklung von User Interface Tools: UI Tools

Clients müssen in Verteilten Systemen mit dem User und dem Remote Server parallel kommunizieren. Dies kann durch Multithreading am besten und einfachsten geschehen. Weiters können dadurch zB Latenzzeiten bei der Kommunikation überbrückt werden. Wenn es die Server unterstützen, so kann auch über Load-Balancing nachgedacht werden, so dass sich ein Client von mehreren Server-Replikas die Daten parallel besorgt. Auch die lokale Abarbeitung von Daten steigert die Performance, da zB der Netzwerktransfer minimiert werden kann (zB durch Formularkontrolle am Client anstatt am Server).

User Interfaces

  • Model
  • Control
  • View

UIs werden (wie auch Verteilte Systeme) oft schon in einem Schicht-Model realisiert (Vertikale Verteilung). Einzelne Schichten können auf verschiedenen Maschinen laufen (Horizontale Verteilung) (Distributed User Interface). z.B.: kann das Rendering und die Interpretation der Usereingaben komplett am Server erfolgen und der Client dient nur noch als "dumme" Konsole (Remote Application ==> Rechner-Last auf Server). Damit wird die Application unabhängig von der Client-Plattform (Location, Migration, Relocation Transparency).

Arten der Transparenz: Neben Benutzeroberfläche und anderer für die Applikation benötigter Software besteht die Client-Software aus Komponenten, mit denen Verteilungstransparenz erzielt werden soll. Im Idealfall sollte ein Client nicht erkennen, dass er mit einem entfernten Prozess kommuniziert.

Die Zugriffstranzparenz wird häufig realisiert, indem aus der vom Server gebotenen Schnittstellendefinition ein Client-Stub erzeugt wird. Der Stub bietet dieselbe Schnittstelle, die auch auf dem Server zur Verfügung steht, verbirgt jedoch die möglichen Unterschiede in Hinblick auf die Maschinenarchitektur, sowie die eigentliche Kommunikation. Es gibt unterschiedliche Möglichkeiten, Orts-, Migrations- und Relokationstransparenz zu realisieren. Die Verwendung eines praktischen Namenssystem ist wesentlich. In vielen Fällen ist auch die Zusammenarbeit mit Client-seitiger Software wichtig. Ist beispielsweise ein Client bereits zu einem Server gebunden, kann der Client direkt informiert werden wenn sich die Position des Servers ändert. In diesem Fall kann die Middleware des Clients die aktuelle Position des Servers vor dem Benutzer verbergen und die erneute Bindung zu dem Server ggf. transparent vornehmen.

Auf ähnliche Weise implementieren viele Verteilte Systeme die Replikationstransparenz mithilfe Client-seitiger Lösungen.

Die Maskierung von Kommunikationsfehlern mit einem Server erfolgt normalerweise über Client-Middleware. Beispielsweise kann eine Client-Middleware so konfiguriert werden, dass sie wiederholt versucht, eine Verbindung mit einem Server aufzunehmen, oder nach mehreren Versuchen einen anderen Server auszuprobieren (Fehlertransparenz).


Frage 5[Bearbeiten]

Frage: Wie funktioniert in flachen Namensräumen das Location Service? Geben Sie das Grundprinzip möglicher Lösungen an und gehen Sie dabei auch auf die Begriffe Mobility und Discovery ein. Erläutern Sie Vor- und Nachteile bei der Verwendung von "Forwarding Pointers". Wie funktionieren "Home-based approaches" für mobile Geräte?

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

Ein Location Service bezeichnet ein Two-Level mapping zum Übersetzen von Namen in Adressen über sog. Identities.

In einem Ad hoc Netzwerk, wie z.B. P2P, müssen Rechner Services und Resourcen ankündigen bzw. auffinden können (discovery). Ein Location Service kann dazu benutzt werden, Services zu registrieren und aufzufinden. Dadurch wird ein hoher Grad an Mobility erreicht, da ein Host nicht mehr über eine fixe Adresse (IP) angesprochen wird. Location Services unterscheiden sich von NS und Directory Services durch die Anforderung, dass sie sich oft/schnell ändern.

Location and Naming Service.jpg

Lösungen:

  • Broadcast und Multicast:

Wird nach einer Entität gesucht, sendet man per Broadcast Anfragen an alle Geräte im Netzwerk ob sie diese Entität haben. Wenn ja wird die Adresse des Eintrittspunkts zurückgeliefert, ansonsten die Anfrage einfach ignoriert. Bsp.: ARP Dies sorgt jedoch für jede Menge unnötigen Traffic und die Hosts werden ständig mit Anfragen nach Entitäten belästigt. Eine Lösung wäre der Wechsel auf Multicast, durch die nur eine begrenzte Anzahl an Hosts die Anfrage erhält.

  • Forwarding Pointers:

Ein Ansatz um Mobility zu erreichen ist die Verwendung von Forwarding Pointers. Wenn eine Entität seinen Ort ändert, lässt sie eine Referenz zurück, welche auf ihren neuen Ort zeigt.

Vorteil: sehr einfach. Sobald eine Entität lokalisiert wurde, kann ein Client die aktuelle Adresse nachschlagen, indem er der Kette der Referenzen folgt.

Nachteil: Lange Ketten, möglicherweise viele Zwischenschritte notwendig, eine falsche Referenz unterbricht die gesamte Kommunikation (broken link). Zwischenstandorte müssen ihren Teil der Kette so lange wie möglich halten.

Daher müssen die Ketten so kurz wie möglich gehalten werden.


Homebased Aproach:

Ein Ansatz um Mobility in großen Netzwerken zu erreichen ist die Verwendung von Homebased Approaches. Die Homelocation speichert dabei immer den aktuellen Standort einer Entität. Ändert die mobile Entität ihren Standort registriert sie eine Care-Of-Address beim Home-Agent.

Ein Client, der den aktuellen Standort nicht kennt, kann ihn also immer bei der HL erfragen und anschließend direkt kommunizieren.


Frage 6[Bearbeiten]

Frage: Vergleichen Sie den "Bully" und den "Ring"-Algorithmus für Election hinsichtlich Fehlertoleranz. Warum sind diese Algorithmen für ad-hoc oder large-scale Systeme weniger geeignet und welche grundsätzlichen Lösungsansätze verfolgt man daher dort?

{{#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*Bully- und Ring-Algorithmus\s*/si}}

Sowohl bully, als auch der ring election Algorithmus basieren auf der Idee, dass jeder Prozess eine eindeutige ID besitzt (z.B.: ProzessID), und der Prozess mit der höchsten ID als Koordinator fungiert.

  • bully algorithmus: Sobald ein Prozess bemerkt, dass der Koordinator ausgefallen ist, sendet er eine ELECTION Nachricht an alle Prozesse mit einer ID höher als seiner eigenen ID. Wenn er keine Antwort erhält, so ist er der neue Koordinator (schickt COORDINATOR Nachricht an die anderen Prozesse), wenn jedoch einer der Prozesse antwortet, so übernimmt dieser die Kontrolle, wer neuer Koordinator wird (in diesem Fall schickt der Prozess wieder eine ELECTION Nachricht, die geschieht so lange, bis der Prozess mit der höchsten ID Koordinator geworden ist und eine COORDINATOR Nachricht an die anderen Prozesse sendet).
  • ring algorithmus: Die Prozesse sind logisch in Form eines Ringes angeordnet. Der Prozess, der den Ausfall des Koordinators bemerkt, sendet eine ELECTION Nachricht an seinen Nachfolger (wenn dieser nicht antwortet an dessen Nachfolger, so lange bis einer antwortet). Jeder Prozess hängt seine ID an die Nachricht an. Wenn die Nachricht den Ring einmal durchlaufen hat, und beim Initiator angelangt ist, sendet dieser eine COORDINATOR Nachricht aus, da ihm nun der Prozess mit der höchsten ID bekannt ist. Der neue Koordinator kann seine Arbeit aufnehmen, nachdem die COORDINATOR Nachricht wieder beim Initiator angelangt ist, wird sie entfernt. Falls mehrere Prozesse gleichzeitig den Ausfall des Koordinators bemerken und eine ELECTION Nachricht aussenden, ändert es nichts am Ergebnis, es wird lediglich ein wenig zusätzlicher Traffic erzeugt.

Beide Algorithmen sind sehr Fehlertolerant, da immer wieder ein neuer Koordinator gewählt werden kann. Es besteht KEIN Single-Point-Failure Problem.

Bei ad-hoc-Netzwerken kann sich die Topologie schnell ändern und man kann nicht davon ausgehen dass die Kommunikation zuverlässig (reliable) ist. Der Bully- und Ring-Algorithmus sind daher für derartige Netzwerke nicht geeignet. Außerdem ist es durch die heterogene Struktur wichtig dass nicht irgendein Koordinator gewählt wird, sondern der beste (anhand eines Kriteriums, z.B.:Bandbreite). Bei der Auswahl sendet ein Knoten die ELECTION Nachricht an all seine Nachbarn. Empfängt ein Nachbar diese Nachricht setzt er den Sender als Parent und leitet die ELECTION Nachricht an alle Nachbarn außer den Parent weiter. Dadurch entsteht eine Baumstruktur. Jeder Parent wartet nun nach dem Weiterleiten auf die Response aller seiner Kinder. Die Response enthält die ID und das Score (Bewertung) des besten Prozesses im Subtree. Hat ein Parent von allen Kindern eine Response erhalten, kann er wiederum eine Response an seinen (mit dem besten Prozess) Parent senden. Der Root-Prozess weiß daher welcher Prozess der geeignetste Leader ist.

Bei large-scale-Netzwerken werden Superpeers ausgewählt, da ein Koordinator zu wenig sein wird. Auswahl mehrerer ausgezeichneter Knoten, die sich jeweils um eine Anzahl anderer Knoten kümmern. Dabei müssen Superpeers folgende Kriterien erfüllen:

  1. Superpeers sollten geringe Latenzzeiten gegenüber normalen Peers haben
  2. Superpeers sollten im Netzwerk gleichmäßig sein.
  3. Die Anzahl der Superpeers sollte eine definierte Anzahl relativ zur Anzahl normaler Knoten nicht unterschreiten
  4. Jeder Superpeer sollte nur eine gewisse Anzahl an Knoten bedienen

Lösungsansatz zur Election eines Superpeers: Es werden für n Superpeers n Token zufällig im Netz verteilt. Kein Knoten kann mehr als einen Token gleichzeitig haben. Außerdem wirken auf die Token so genannte Kräfte die sicherstellen sollen, dass sich Token voneinander abstoßen (vgl. Teilchen mit gleicher Ladung). Erfährt ein Knoten von ein oder mehreren Token in der Umgebung kann aufgrund der Richtung, in der die anderen Token liegen jene Richtung bestimmt werden in die sein Token weitergegeben wird. Hält ein Knoten einen Token für eine gewisse Zeit (Token haben sich stabilisiert) wird dieser zu einem Superpeer. Im englischen Buch S. 270 wird darauf hingewiesen, dass diese mysteriöse Kraft mit einem Gossip-Protokoll realisiert werden kann.


Frage 7[Bearbeiten]

Frage: Erläutern Sie die Funktionsweise der "primary-based" Protokolle. Bewerten und vergleichen Sie die verschiedenen Arten.

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

In Primary Based Protokollen ist jedem Datenelement x im Speicher ein primärer Server zugeteilt, der für die Koordination von Schreiboperationen für x verantwortlich ist. Unterscheidungen können getroffen werden ob die primäre Kopie auf einem entfernten Server festgelegt ist oder ob Schreiboperationen lokal ausgeführt werden können, nach denen die primäre Kopie zu dem Prozess verschoben wird, wo die Schreiboperation initiiert wird.

Bei dem einfachsten Primary-based Protokoll (Remote-Write Protocol) werden alle Operationen zu einem bestimmten (fixierten) single-server weitergeleitet. Wenn z.B. eine Schreiboperation stattfinden soll, wird die Operation zuerst weitergeleitet an den Primary Server für das item. Der Primary Server führt daraufhin ein Update auf der lokalen Kopie des Items durch und leitet das Update an alle Backup-Server weiter. Jeder Backup-Server führt das Update genauso durch und sendet ein Acknowledge zurück an den Primary Server. Wenn alle aktualisiert wurden, schickt der Primary Server ein Acknowledge zurück zu dem initialisierenden Prozess. Das Performance Problem bei diesem Schema ist, dass es relativ lange braucht, bevor ein Prozess der ein Update initiiert hat fortfahren darf. Eine Alternative wäre einen nonblocking Ansatz zu wählen. Das Problem bei einem nonblocking System ist die Fehlertoleranz. Der Vorteil ist die Geschwindigkeit.

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

Alternativ: (Local-Write Protocol) Wenn ein Item geupdated werden soll, wird zuerst die primäre Kopie lokalisiert (wie zuvor). Und dann wird diese Kopie auf die eigene location kopiert. dazu gibt es noch die Möglichkeit, das Datenitem zuerst auf den Server zu migrieren, auf dem der Schreibzugriff abgesetzt wird (Änderung des Primarys) und die Operation dann dort auszuführen (local-write). Der Hauptvorteil dieser Vorgehensweise besteht darin, dass mehrere Schreiboperationen nacheinander lokal erfolgen können, während lesende Prozesse weiterhin auf ihre lokalen Kopien zugreifen können. eine Verbesserung dieser Art kann jedoch nur dann erfolgen, wenn ein nicht sperrendes Protokoll beachtet wird, das Aktualisierungen an die Replikate weiterleiten, nachdem der primäre Server sie lokal erfolgreich ausgeführt hat.


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


Frage 8[Bearbeiten]

Frage: Welche Eigenschaften erwartet man sich von einem "Secure Channel"? Geben Sie jeweils auch Beispiele für unerwünschte Effekte an. Erklären Sie wie sich zwei Kommunikationsteilnehmer basierend auf Public Key Cryptography gegenseitig authentifizieren 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*Secure Channel\s*/si}}


Secure Channel: Wie der Name schon sagt, ist ein Secure Channel ein sicherer Kanal zwischen zwei oder mehreren Teilnehmer, der vor Angriffen (z.B.: Eavesdropping, Spoofing, Message Tampering, etc.) schützen soll. Die meisten Angriffe kann man durch eine Verschlüsselung des Kanals abwehren (Public- und Private-Key Encryption). Er schützt aber nicht gegen Interruption.


Unerwünschte Effekte eines nicht verschlüsselten Kanals

  • Sender der Nachricht kann nicht bestimmt werden (Spoofing):
'A' -> B : "I want to buy 10 widgets."
B -> A : "Here are your 10 widgets."
A -> B : "I did not order widgets."
  • Nachrichtenänderung (Message Tampering):
A -> B : "I want to buy 10 widgets."
B -> A : "Here are your 100 widgets."
A -> B : "I ordered 10!"
B -> A : "I received an order for 100!"


Authentifizierung basierend auf Public Key Cryptography

1. Alice -------- Kb+(A, Ra) -------> Bob
     |                                 |
2.   |   <---- Ka+(Ra, Rb, Kab) -----  |
     |                                 |
3.   |   -------- Kab(Rb) ---------->  |

Die Kommunikationspartner besitzen den öffentlichen Schlüssel (K+) des jeweils anderen.

1. Alice schickt Bob eine Nachricht mit dem Inhalt 'A' ("Ich bin Alice") und einer Challenge Ra (z.B.: Zufallszahl). Diese Nachricht wird mit Bobs öffentlichem Schlüssel Kb+ verschlüsselt.

2. Da nur Bob die Nachricht entschlüsseln kann, bekommt er die Challenge Ra. Er generiert einen Session Key Kab, der für die weitere Sitzung des Secure Channels verwendet wird. Bob antwortet mit Ra, einer neuen Challenge Rb und dem Session Key verschlüsselt mit dem öffentlichen Schlüssel von Alice Ka+.

3. Alice ist nun in Besitz des Session Keys und bestätigt Bobs Challenge Rb mit dem Session Key verschlüsselt.


Frage 9[Bearbeiten]

Frage: Was ist EAI? Geben sie 3 Beispiele von Architekturen, die die Anwendung erleichtern. Was ist ein "Legacy 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*EAI\s*/si}}


Unter Enterprise Application Integration versteht man die Schaffung von betrieblichen Anwendungssystemen durch die Kombination einzelner Anwendungen unter Verwendung einer gemeinsamen Middleware.

Präsentations - Integrationsmodell z.B: Gemeinsames Java Interface für mehrere Mainframe Anwendungen

Daten - Integrationsmodell z.B: Integration von Kundendaten aus verschiedenen DB-Systemen in eine Call-Center-Anwendung

Funktionales Integrationsmodell z.B: Schaffung einer einheitlichen Kundensicht über alle betrieblichen Anwendungen und Datenbanken durch Schnittstellen der Middleware zu allen Anwendungen

Im Buch auf Seite 41 (deutsche Ausgabe, 2008) steht, dass EAI eine Middleware ist, die die Kommunikation zwischen mehreren Anwendungen ermöglicht (siehe Abbildung 1.11). Beispielsweise wird dies durch RPC, RMI und Message Oriented Middleware ermöglicht. RPC und RMI verlangen im Gegensatz zu MoM, dass Aufrufer und Aufgerufener beide aktiv sein müssen. Außerdem muss bekannt sein, wie man sich gegenseitig ansprechen kann. Diese enge Kopplung ist ein schwerwiegender Nachteil und zu MoM geführt.


Ein Legacy System bezeichnet eine etablierte, historisch gewachsene Anwendung.

Ein grundsätzliches Problem mit der Ablösung von Legacysystemen ist der gewachsene Funktionsumfang.


ANMERKUNG koDiacc: Diese Frage kam heute am 6.6.2012 bei der Prüfung dran. Sollten wir sie deswegen nicht von den "Alten Fragen" entfernen? Oder hier lassen, weil sie nicht im Offiziellen Fragenkatalog der LVA-HP steht?