TU Wien:Verteilte Systeme VO (Göschka)/Fragenkatalog Wiki

Achtung: Änderung der Prüfungsmodalitäten und Gültigkeit dieses Fragenkatalogs

Laut LVA-Homepage [1] gibt es nur mehr einen Prüfungstermin (14.10. 2013), für den auch wirklich Fragen aus diesem Katalog gestellt werden. Ab dann gilt folgendes für die Prüfungen:

---

• The only one exam of this course is the final written one. There is no midterm exam.
• An exam will consist of 20 questions. Unlike previous semesters, these questions are NOT in any public question catalog. The exam will take 80 minutes. It is a closed book exam.
• Exam questions will be based on the topics of the lectures given in the course. The exam preparation materials will be the lecture notes and corresponding chapters/sections of text books/papers/articles mentioned in the lectures.
• There will be no questions for topics in the text books which are not covered in the lectures or for topics which are not required as home exercises.
• Exam questions will cover both concepts/techniques in the course as well as how to apply these concepts/techniques.
• There will be 2 questions for each lecture (in total 20 questions for 10 lectures)
• An answer for a question will be given:
  • 0 point if the answer is incorrect,
  • 0.5 point if the answer is half-correct (40%-70% of the answer is correct and the answer shows a clear path that it leads to a complete correct answer)
  • 1 point if the answer is correct
• The maximum number of points of an exam is 20. The following mapping is applied
  • 18- 20 points = 1 (sehr gut) (100-90 % of the maximum number of points)
  • 16 - 17.5 points = 2 (gut) (89 - 80 % of the maximum number of points)
  • 13 - 15.5 points = 3 (befriedigend) (79-64 % of the maximum number of points)
  • 10.5 - 12.5 points = 4 (genügend) (63-51 % of the maximum number of points)
  • 0-10 points = 5 (nicht genügend) (50-0 % of the maximum number of points)

---

Da der Fragenkatalog große Teile des Stoffs abdeckt, ist es sicher nicht schlecht, wenn man ihn als Lernhilfe hernimmt, allerdings wird es nicht so wie bisher sein, dass garantiert Fragen daraus gestellt werden. Weiters sei angemerkt, dass der Fragenkatalog durchaus nicht vollständig ist und auch Fehler enthält. Wenn du einen entdeckst, bessere ihn bitte aus, am besten mit Quellenangabe (z.B. Buchseite).

Versionen

Stand 1.1.2011: Alle Fragen sind am letzten Stand und entsprechen nun dem aktuellen Fragekatalog auf der VO-Seite: [2]

---

Dies ist der ausgearbeitete Fragenkatalog aus dem Wintersemester 07/08 für Verteilte Systeme. Vieles der Informationen wurde aus einem Google-Docs-Dokument, das leider nicht mehr weiter verbessert werden kann (da die AutorInnen das Interesse an dem Dokument verloren haben...), heraus kopiert. Es gibt zu dem Google-Docs Dokument auch einen Thread im Informatik-Forum. Es wurden nun auch aktuelle Themen aus dem WS 08/09 eingearbeitet. Im WS09/10 wurden alte Fragen gekennzeichnet, teilweise erweitert und formatiert.

Grundlagen und Konzepte

• Buch: Kap. 1 und 2 bis inkl. 2.2

Definition Verteiltes System

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

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

Definition

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

Eigenschaften:

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

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

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

Designziele eines Verteilten Systems:

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

Was ist Transparenz?

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).

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.

Was versteht man unter "Openness"?

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

Scalability

Frage: Erläutern Sie Probleme und Lösungsansätze für "Scalability".

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

Scalability ist die Fähigkeit des Systems bei wachsenden Anforderungen noch einsatzfähig zu sein. Die Skalierbarkeit eines Systems kann dabei in mindestens drei unterschiedlichen Dimensionen gemessen werden:

• Größe/Ausmaß: noch mehr Benutzer oder Ressourcen können einfach hinzugefügt werden
• Geographisch: die Benutzer und Ressourcen dürfen weit auseinander liegen (topologisch)
• Administrativ: noch immer einfach verwaltbar, auch wenn es sich über viele unabhängige administrative Organisationen (domains) erstreckt.

Probleme bei der Skalierbarkeit (meist Performance-Probleme)

• Größe:
  Werden mehrere Benutzer oder Ressourcen unterstützt, werden wir häufig mit den Einschränkungen zentralisierter Dienste, Daten und Algorithmen konfrontiert:
  • Zentrale Services, z.B. ein einziger Server für alle Benutzer (ist aber oft für die Sicherheit erforderlich!)
  • Zentral verwaltete Daten, z.B. ein einziges Online-Telefonbuch
  • Zentral ablaufende Algorithmen, z.B. Routing durchzuführen, das auf vollständiger Information basiert

Nur dezentrale Algorithmen sollten verwendet werden! Charakteristika dezentraler Algorithmen:

• Keine Maschine hat vollständige Information über den Systemstatus.
• Computer entscheiden nur auf Grund von lokalen Informationen.
• Der Ausfall eines Computers schädigt nicht den Algorithmus.
• Die Existenz einer globalen Uhr wird nicht implizit vorausgesetzt.

• Geographisch:
  • Verteilte Systeme die für LANs entwickelt wurden, basieren auf synchroner Kommunikation: Client blockiert bis Antwort zurück gesendet wird – problematisch in WANs (zu langsam)
  • Kommunikation in WANs ist inhärent unzuverlässig und so gut wie immer Point-to-Point, LANs hingegen bieten hoch zuverlässige Kommunikation und unterstützen Broadcasting
  • Geographische Skalierbarkeit hängt stark mit den Problemen zentralisierter Lösungen zusammen, die auch die Größenskalierbarkeit behindern.
• Administrativ:
  Schwierige Frage wie ein verteiltes System über mehrere voneinander unabhängige administrative Domänen skaliert werden kann. Ein Problem sind die widersprüchliche Strategien zur
  • Benutzung (und Bezahlung) von Ressourcen
  • Verwaltung
  • Sicherheit

Skalierungstechniken:

• Verbergen der Latenzzeiten (wichtig für geographische Skalierbarkeit)
  • asynchrone Kommunikation -> Abarbeiten von anderen Aufgaben, während man auf eine Antwort wartet.
  • Gesamte Kommunikation reduzieren (z.B. Teile der Berechnung zum Client-Prozess verschieben, wie z.B. Überprüfen von Formulareinträgen schon beim Client)
• Verteilung -> Komponenten in kleinere Teile zerlegen und über gesamtes System verteilen. Bsp.: DNS (hierarchisch in Domains organisiert -> dieser wiederum in sich nicht überschneidende Zonen aufgeteilt -> Namen in jeder Zone werden von einem einzigen Name-Server behandelt)
• Replikation
  • Erhöht Verfügbarkeit
  • Balanciert die Last zwischen Komponenten aus -> bessere Performance
  • In WANs kann eine nahe gelegene Kopie Kommunikations-Latenz-Probleme verbergen
  • Caching = spezielle Form der Replikation (vom Client ausgelöst)
    • Nachteil: Caching und Replikation führt zu Konsistenzproblemen!

Probleme bei Scalable Size:

• Controlling the cost of physical resources: The quantity required should be O(n)
• Controlling the performance loss: In hierarchical system should be no worse than O(log n)
• Preventing software resources running out, but over-compensation may be even worse: Internet Addresses or Oracle7 2TB restriction
• Avoiding performance bottlenecks (centralized services, data, or algorithms)

Vertikale Verteilung

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}}

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)

Horizontale Verteilung

Frage: Was ist horizontale Verteilung? Mit welchen grundlegenden Design-Fragen müssen Sie sich beim Entwurf der horizontalen Verteilung eines Systems beschäftigen? Gibt es einen Zusammenhang zur vertikalen Verteilung?

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

Bei der horizontalen Verteilung können ein Client oder ein Server physisch in logisch äquivalente Teile unterteilt werden, aber jeder Teil arbeitet mit einem eigenen Anteil der vollständigen Datenmenge, sodass die Gesamtlast ausgeglichen ist.

=> "Anteil der vollständigen Datenmenge" => wirkt hier etwas verwirrend. Jeder Teil operiert auf der gleichen, vollständigen Datenmenge und nicht nur auf einem Teil davon. by thex

Wie sicher ist das? Zitat Buch Seite 44 "[..] but each part is operating on its own share of the complete dataset [..]" Ich hätte das wie im ursprünglichen Satz hier interpretiert --emptyvi

Ich denke hier darf nicht von einer Datenbank die repliziert wird ausgegangen werden, sondern z.B. eher von einer Gruppe (Cluster) von Webservern. Dabei arbeitet jeder von ihnen mit einem Anteil (die vom LoadBalancer ihm zugeteilten HTTP Requests) der vollständigen Datenmenge (alle HTTP Requests) --Mannaz 19:08, 9. Mär. 2011 (CET)

Die horizontale Verteilung von Anwendungskomponenten lässt also auch eine Zerlegung der Anwendungskomponenten auf physisch getrennte Rechner zu. Während bei der vertikalen Verteilung Anwendungskomponente genau einem Rechner zugeordnet werden. Wichtiger Bestandteil solcher Systeme ist eine geeignete Middleware,um verteilte Komponenten bzw. Objekte zu einem kohärenten Ganzen zusammen zu führen (z.B. CORBA, Enterprise JavaBeans, etc.) (???)

Beim Entwurf einer horizontalen Verteilung sollte man sich auch Gedanken machen welches Konsistenzmodell gewählt wird um sicherzustellen, dass die Server alle mit den gleichen Datenelementen arbeiten.

Datenzentrierte Konsistenzmodelle (strenge-, sequezielle-, kausale-, FIFO-Konsistenz) versus Clientzentrierte Konsistenzmodelle (Eventuelle Konsistenz, Monotones Lesen, etc)

(mein gedanke dazu)

Designfrage:

• Werden Replikate erst bei Bedarf erstellt oder schon am Anfang
• Weitergabe der Aufgaben vom Handler durch Round-Robin oder durch Aufgabenspezifische Unterteilung (aufgabenspez. Verteilung würde man doch bei vertikaler Verteilung nehmen oder? Wenn ich mich an die Laborübung erinnere war eine Round-Robin Alternative, dass mehrere Replikas nach Zufallsprinzip ausgewählt wurden,

Mit den Designfragen könnte auch das gemeint sein(deckt sich ungefähr mit den Folien S.62):

• Komponenten die oft kommunizieren sollten nahe beieinander liegen
• Physische Einschränkungen: einige Komponenten können nur auf spezifischen Rechnern oder an speziellen Orten laufen
• Granularität: Kleinere Komponenten erhoehen die Flexibilitaet, aber ebenso den Netzwerkverkehr. Umgekehrt reduzieren größere Komponenten die Netzwerkbelastung, aber ebenso wird die Flexibilitaet und Wiederverwendbarkeit reduziert.
• Wahl der Protokolle: entscheidend für Interoperabilität und Last
• End to End Eigenschaften: CAP - Consistency, Availability, Performance
• Full distribution -> distributed architecture

Was ich weis kann man das eben wählen ob Round Robin oder Aufgaben spezifisch, ist eben eine Design-Frage)

Horizontale Verteilung kann mit der vertikalen Verteilung kombiniert werden.

Beispiel zur horizontalen Verteilung (Webserver): Jeder Server verwaltet dieselbe Menge an Webseiten, und immer wenn eine Webseite aktualisiert wird, wird eine Kopie davon auf jeden Server platziert (je nach Konsistenzmodell verschieden schnell). Trifft eine Anforderung ein, wird sie unter Verwendung einer Round-Robin-Strategie an einen Server weitergegeben. Genügend Bandbreite vorausgesetzt, ist diese Form der horizontalen Verteilung sehr effektiv.

TODO: Zusammenhang mit der vertikalen Verteilung

Communication (1) - Middleware und RPC

• Buch: 2.1 (w.h.), 2.3, 2.4, 4.1, 4.2

ISO-OSI Modell

Frage: Beschreiben Sie das ISO-OSI Modell der geschichteten Protokolle (Grundprinzip). Stellen Sie den Bezug zu den Internet-Protokollen (TCP/IP) her. Warum sind Transport-Layer Protokolle für Verteilte Systeme oft nicht ausreichend?

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

Auf Grund des Fehlens von Shared Memory basiert die gesamte Kommunikation in verteilten Systemen auf dem Senden und Empfangen von Nachrichten (auf der untersten Ebene). Wenn ein Prozess mit einem entfernten Prozess kommunizieren möchte sind Vereinbarungen auf einer Vielzahl von Schichten erforderlich, von den Details der Bitübertragung auf unterster Ebene bis hin zu den Einzelheiten auf höherer Ebene, wie Informationen auszudrücken sind. Für einen einfacheren Umgang mit den mit der Kommunikation verbundenen Schichten hat die International Organization for Standardization (ISO) ein Referenzmodell entworfen, das die verschiedenen beteiligten Schichten klar herausstellt und benennt.

Das OSI-Modell (Open Systems Interconnection Reference Model) wurde entwickelt, um offenen Systemen die Kommunikation zu ermöglichen. Offenes System: ist dazu bereit, mit jedem anderen offenen System zu kommunizieren – durch die Verwendung von Standard-Regeln, die Format, Inhalt und Bedeutung der gesendeten und empfangenen Nachrichten regeln/bestimmen. Diese Regeln sind in Protokollen formalisiert. Zwei generelle Arten von Protokollen:

Verbindungsorientiert: bevor Daten ausgetauscht werden, richten Sender und Empfänger explizit eine Verbindung ein und verhandeln eventuell über das Protokoll, das sie verwenden werden. Wenn sie fertig sind müssen sie die Verbindung lösen/beenden (z.B. Telefonanruf). circuit switched (?) -> Verlässlichkeit vs. Setup-Aufwand

Verbindungslos: Kein Setup im Vorhinein notwendig, der Sender verschickt einfach die erste Nachricht wenn sie fertig ist. (z.B. Brief in Briefkasten werfen. packet switched (?)

Im OSI-Modell wird die Kommunikation auf sieben Schichten bzw. Ebenen (Layer) aufgeteilt. Jede Schicht behandelt einen bestimmten Aspekt der Kommunikation. Auf diese Weise wird das Problem in Teile zerlegt und unabhängig voneinander auf verschiedenen Ebenen gelöst. Jede Schicht bietet eine Schnittstelle zur darüberliegenden Schicht.

Wenn Prozess A auf Maschine 1 mit Prozess B auf Maschine 2 kommunizieren will, erstellt er eine Nachricht und gibt sie an den Application Layer seiner Maschine weiter. Der Application Layer fügt der Nachricht vorne einen Header hinzu und gibt sie über das Layer 6/7-Interface an den Presentation Layer weiter etc… Der Data-Link Layer fügt zusätzlich hinten einen Trailer hinzu. Der Physical Layer übermittelt schließlich die Nachricht, indem er sie an das physische Übertragungsmedium übergibt.

Beim Empfänger geht die Nachricht den umgekehrten Weg (wird nach oben übermittelt), wobei jede Schicht seinen eigenen Header überprüft, und kommt schließlich beim Prozess B an. Die Information im Layer n -Header wird für das Layer n -Protokoll verwendet.

Jede Schicht hat bei diesem Modell ihr eigenes Protokoll, das unabhängig von anderen ausgetauscht werden kann. Die Ansammlung der in einem bestimmten System verwendeten Protokolle wird Protokollsuite bzw. Protokollstack genannt. Die OSI Protokolle waren niemals beliebt, dagegen werden die für das Internet entwickelten Protokolle wie TCP und IP am häufigsten verwendet.

1. Physical Layer (Bitübertragung)
   Die Bitübertragungsschicht ist für das Übertragen der Einsen und Nullen zuständig. Das Protokoll der Bitübertragungsschicht kümmert sich um die Standardisierung der Elektrischen-, Mechanischen- und Signalschnittstellen, sodass eine von einem Rechner ausgesendete 1 auch tatsächlich als 1 und nicht als 0 empfangen wird. Die Bitübertragungsschicht sendet lediglich Bits. Hierbei können allerdings Fehler auftreten, sodass ein Verfahren benötigt wird, um sie zu entdecken und zu korrigieren.
2. Data Link Layer (Sicherung)
   Dies ist Aufgabe der Sicherungsschicht. Sie gruppiert die Bits in Frames und berechnet eine Prüfsumme. Der Empfänger berechnet die Prüfsumme erneut. Stimmen beide überein wird der Frame als korrekt anerkannt und angenommen, wenn nicht bittet der Sender den Empfänger um die erneute Übertragung.
3. Network Layer (Vermittlung)
   Damit eine Nachricht vom Sender zum Empfänger gelangen kann können (in WANs) mehrere Teilstrecken (Hops) erforderlich sein. Die Auswahl des besten Weges (Routing) ist Aufgabe des Network Layer. Momentan ist das am weitesten verbreitete Netzwerkprotokoll das verbindungslose Internetet Protocol (IP)
4. Transport Layer (Transport)
   Die Transportschicht bildet den letzten Teil des grundlegenden Netzwerkprotokollstacks. Die Anwendungsschicht kann somit eine Nachricht an die Transportschicht in der Erwartung übermitteln, dass sie ohne Verluste ihr Ziel erreicht. Wenn die Transportschicht eine Nachricht von der Anwendungsschicht erhält, zerteilt sie sie in kleine Stücke (die klein genug für eine Übertragung sind) weist jedem eine fortlaufende Nummer zu und sendet dann alle. Transportverbindeungen können auf verbindungslosen oder verbindungsorienierten Netzwerkdiensten aufsetzten. Bei verbindungslosen Diensten kann nicht garantiert werden, dass alle Pakete in der selben Reihenfolge ankommen, in der sie gesendet wurden. Es ist Aufgabe der Software der Transportschicht, alles wieder in die richtige Reihenfolge zu bringen. Das Transportprotokoll des Internets wird TCP (Transmission Control Protocol) genannet. Die Kombination TCP/IP ist heute der Standard für Netzwerkkommunikation. Die Internetprotokollsuite unterstützt auch ein verbindungsloses Transportprotokoll namens UDP (Universal Datagram Protocol).
   Vorhandene Transportprotokolle sind oft nicht ausreichend, so werden regelmäßig neue vorgeschlagen, wie beispielsweise RTP (real-time transport protocol) zur Datenübertragung in Echtzeit.
5. Session Layer (Sitzung)
   Die Sitzungsschicht ist im Wesentlichen eine erweiterte Version der Transportschicht. Sie bietet eine Dialogkontrolle, um zu verfolgen welcher Teilnehmer gerade spricht, sowie Funktionen zur Synchronisierung. In der Praxis sind nur wenige Anwendungen an der Sitzungsschicht interessiert. In der Internetprotokollsuite ist sie nicht vorhanden.
6. Presentation Layer (Darstellung)
   Die Darstellungsschicht beschäftigt sich mit der Bedeutung der Bits. Hier können spezielle Konvertierungen stattfinden. Im Internet ist hier das SSL Protokoll angesiedelt.
7. Application Layer (Anwendung)
   Die Anwendungsschicht verschafft Anwnendungen Zugriff auf das Netzwerk. Der eigentliche Anwendungsprozess liegt darüber und ist nicht im OSI Modell abgebildet.
   * * Bsp.: File Transfer Protokoll (FTP): Übertragung von Dateien zwischen Client und Server (nicht mit dem Programm FTP zu verwechseln!)
   * Hyper Text Transfer Protokoll (HTTP): Übertragung von Webseiten
   Im OSI Modell fehlt eine klare Unterscheidung zwischen Anwendungen, anwendungsspezifischen Protokollen und Protokollen für allgemeine Zwecke.

Anmerkung: Von den drei Schichten oberhalb der Transportschicht wird in der Praxis nur die Anwendungsschicht genutzt. Die Internet-Protokollsuite fasst alles oberhalb der Transportschicht zusammen. (Wird es wirklich zusammengefasst? ich dachte es ist bei der IP Suite einfach nicht implementiert) (steht zumindest so im Buch: S.121 "In fact, in the Internet protocol suite, everything above the transport layer is grouped together." aber ich denke auch, dass zumindest die Funktionalität des session layers in der Internet-Protokollsuite nicht implementiert ist, deshalb wäre ich dafür den satz einfach wieder zu streichen - was meint ihr????)

Mein Senf dazu: Es wird auch der Presentation Layer (#6) für SSL Encryption genutzt, siehe Kapitel Security. Somit ist im Internet nur der Session Layer (#5) unbenutzt.

Gegenüberstellung TCP/IP und OSI siehe Grafik (link kaputt, weiß wer was da war?)

Warum sind Transport Layer Protokolle für verteilte Systeme oft nicht ausreichend?
Die Tranport-Layer Protokolle sind fuer verteilt Systeme oft nicht ausreichend, da sie die geforderten Transparenzen oft nicht erfüllen. Es sind weitere Protokolle notwendig um z.B. Location Transparency, Concurrency Transparency, ... zu erreichen.

Was ist Middleware

Frage: Was ist Middleware? Welche Anforderungen stellt man an Middleware? Welche Services soll Middleware bieten? Erläutern Sie den Zusammenhang zwischen Middleware und Architectural styles.

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

Middleware ist eine Softwarekomponente die viele oft von Verteilten Systemen benötigte Services zusammenfasst und in parametrisierbarer Form anbietet. Man muss daher gleiche Funktionalitäten nicht immer neu implementieren. Die Schicht ist logisch zwischen Application- und Transportlayer einzuordnen. Services von Middleware sind z.B. Verschlüsselung, Authentifizierung, Security, Replikation, Access-Transparenz, Naming etc. Man kann annehmen, dass sich die Entwicklung von Middleware für Verteilte Systeme weitgehend mit der Behandlung zusätzlicher Funktionalität unabhängig von Anwendungen beschäftigt. Die Middleware bildet eine Schicht zwischen Anwendungen und verteilten Plattformen. Ein wichtiger Zweck besteht darin einen Grad von Verteilungstransparenz zu bieten, der in einem gewissen Maß die Verteilung von Daten, die Verarbeitung und die Steuerung vor den Anwendungen verbirgt. Wenn Middleware nach einem bestimmten Architekturstil geformt ist, hat das den Vorteil, dass der Entwurf von Anwendungen einfacher werden kann, eventuell ist die Middleware dann jedoch nicht mehr optimal für das geeignet was der Anwendungsentwickler im Sinn hat.

Important styles of architecture for distributed systems (Folien)

• Layered architectures (OSI)
• Object-based architectures (and components)
• Data-centered architectures (file based, database, resourceful WS, ...)
• Event-based architectures
• .... and combinations thereof

Anforderungen: (ich glaube das ist eher gefragt als die Anforderungen unten)

• Unterstützt Transparenz
• Unterstützt Offenheit
• Unterstützt Wartbarkeit
• Unterstützt Interface Definition
• Gibt die Möglichkeit Skalierbarkeit hinein zu bringen
• Life-cycle Management für die Komponenten (aktivieren/deaktivieren)
• Liefert Kommunikationsgrundlagen
• Liefert Unterstützung für Concurrency (Thread library)

Services:

• Kommunikationsservice für Zugriffstransparenz
• Naming
• Persistence Service für die Persistence Transparenz
• Verteilte Transaktionen
• Replikationen um Failure Transparenz zu unterstützen
• Securitymechanismen: Authentication, Authorisation

Anforderungen an Middleware: Middleware ist nicht immer ideal für die Anwendungen, die Applikationsentwickler im Sinn hatten: CORBA hat z.B. nur Objekte bereitgestellt, die von remote clients aufgerufen werden konnten. Es hat sich herausgestellt, dass nur diese Form der Interaktion zu einschränkend ist. Also wurde Messaging hinzugefügt. Das hinzufügen von Features kann aber zu einer aufgeblasenen Middleware führen. Und obwohl Middleware Verteilungstransparenz bereitstellen sollte, sollten bestimmte Lösungen auch an die Applikationsanforderungen anpassbar sein. Eine Lösung wäre, unterschiedliche Middleware-Versionen zu entwerfen. Eine andere Möglichkeit ist Middlewaresysteme leicht konfigurierbar und adaptierbar zu gestalten.

Flexibilität

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

Remote Procedure Call

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) ...

Variablen-Handling bei (Remote) Procedure Calls

Frage: Wie können Variablen bei Prozedur-Aufrufen grundsätzlich übergeben werden? Wie werden Sie bei RPC gehandhabt und welche Probleme gibt es dabei? Was versteht man in diesem Zusammenhang unter "parameter marshalling"?

{{#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*Variablen-Handling bei \(Remote\) Procedure Calls\s*/si}}

Grundsätzlich können Variablen auf folgende Weisen übergeben werden:

• Call by value = der Wert der Variable wird übergeben
• Call by reference = der Pointer der auf die Variable am lokalen Rechner zeigt wird übergeben
• Call by copy/restore = der Wert der Variable wird kopiert und nachdem der aufgerufene Prozess fertig ist, wird die orginale Variable überschrieben.

Bei RPC kann man alle drei Varianten verwenden wobei man bei folgenden Punkten aufpassen muss:

• bei call-by-reference hat man das Problem dass eine lokale Adresse auf einen anderen Rechner sinnfrei ist. Also muss man diesen aufruf durch copy/restore ersetzen.
• bei den anderen beiden Arten hat man das Problem dass auf dem anderen Rechner sehr wahrscheinlich nicht genau die gleiche Darstellung von Zeichen, Zahlen usw wie auf dem lokalen Rechner vorherrscht. Man muss also vorher die Daten in ein Format bringen die der andere Rechner versteht. Dieser Prozess nennt sich marshalling.

Wenn die Parameter in ihrer marshalling Darstellung beim anderen Rechner ankommen, kann dieser sie interpretieren und den Aufruf der Prozedur mit den korrekten Daten aufrufen.

[eventuell Remove? glaub alle fragen wurden über dem Bild schon beantwortet]

Die Variablen, auch Parameter genannt, werden in Nachrichten verpackt und an den Server Stub gesendet. Das Verpacken von Parametern in Nachrichten wird auch als Marshaling bezeichnet.

(EDIT by Hochi ich glaub hier ist eher gemeint: call-by-value,call-by-reference,copy restore wenn nicht löschen)

In großen verteilten Systemen kommt es häufig vor, dass unterschiedliche Maschinen verwendet werden. Dabei kann es vorkommen das die unterschiedlichen Maschinen eigene Darstellungen für Zahlen, Zeichen und andere Datensätze verwenden (IBM Mainframe verwendet den EBCDIC-Zeichencode - IBM PC´s verwenden den ASCII Zeichensatz, Intel verwendet Little endian - SPARC verwendet Big endian, etc.)

- EDIT -

Meiner Meinung nach bezieht sich diese Frage auch auf den Abschnitt 4.2.2 Parameter Passing aus dem Buch, wo explizit auf Passing Value Parameters und Passing Reference Parameters eingegangen wird. Dazu gehört dann noch die ganze Sache mit dem Marshaling.

Passing Reference Parameters gestaltet sich dabei als durchaus schwierig, da eine Referenz am Client nicht gleich der Referenz am Server ist. (Beide arbeiten ja in einem eigenen Adressraum). Deshalb gibt es hierfür zB folgenden Ansatz: am Client-Stub wird die Referenz "aufgelöst", indem der gesamte Inhalt des zB Arrays mit in die Message kopiert wird. Am Server kann dann auf dieser Kopie gearbeitet werden. Wenn der Server nun fertig ist, wird die gesamte Message wieder retour übertragen und der Client stellt mittles copy/restore das Array bei sich wieder her. Dies ist nicht unbedingt performant, schafft aber Abhilfe gegen das Referenz Problem. Es gibt durchaus Optimierungen, wo zB durch vorheriges Wissen ob Parameter INPUT oder OUTPUT Parameter sind, eventuelle Kopien davon verworfen werden können bzw nicht mehr übertragen werden müssen.

Client/Server/IDL bei RPC

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}}

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:

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

Asynchrone RPC

Frage: Welche Arten von asynchronen RPCs gibt es? Geben Sie auch einen verallgemeinerten Überblick über verschiedene Typen der Kommunikation (persistent/transient bzw. synchron/asynchron).

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

Grundsätzlich kann zwischen 3 Arten von RPCs unterschieden werden:

• synchron - Der Client wartet auf ein Ergebnis des RPCs.
• asynchron - Der Client wartet auf eine Empfangsbestätigung des RPCs.
• one-way - Der Client wartet nicht (nicht einmal auf eine Empfangsbestätigung).

Der verzögerte synchrone RPC besteht aus der Aneinanderreihung von 2 asynchronen RPCs:

• 1. asynchroner RPC (Anfrage) wird vom Client an den Server gesendet.
• 2. asynchroner RPC (Ergebnisse) wird vom Server an den Client gesendet.

somit ergeben die beiden asynchrone RPCs einen verzögerten synchronen RPC (es wird verzögert ein Ergebnis gesendet)

Warum in der Grafik der RPC als one-way gekennzeichnet wurde ist fraglich. Meine Vermutung wäre, dass der Server trotzdem nicht untätig auf eine Empfangsbestätigung vom Client wartet sondern weitere Anfragen bearbeitet und die Bestätigung optional bekommt.

ein verzögerter RPC besteht aus einem RPC vom Client zum Server mit der Anfrage, und einem RPC vom Server zum Client mit der Antwort. Zweiterer ist ein Einweg-RPC. Das Zusammenführen der beiden Calls ist also quasi der "verzögerte-RPC" --thomas 18:13, 7. Mär. 2012 (CET)

Verzögerter synchroner RPC:

---

Allgemeiner Überblick über verschiedene Typen der Kommunikation (Kapitel Message-Oriented-Communication):

Achtung: Bedeutung von asynchron unterscheidet sich hier etwas von der Bedeutung bei RPCs.

(a) Persistente asynchrone Kommunikation; (b) Persistente synchrone Kommunikation; (c) Transiente asynchrone Kommunikation; (d) Empfangsbasierte transiente synchrone Kommunikation; (e) Auslieferungsbasierte transiente synchrone Kommunikation; (f) Antwortbasierte transiente synchrone Kommunikation

Bei einer persistenten Kommunikation wird eine zur Übertragung übergebene Nachricht so lange von der Kommunikations-Middleware gespeichert, wie es dauert, sie an den Empfänger auszuliefern. Im Gegensatz dazu wird bei transienter Kommunikation eine Nachricht nur so lange gespeichert, wie die sendende und empfangende Anwendung ausgeführt werden. Die charakteristische Eigenschaft asynchroner Kommunikation ist, dass der Sender sofort fortfährt, nachdem er seine Nachricht zur Übertragung abgegeben hat. Bei der synchronen Kommunikation ist der Sender gesperrt, bis er weiß, dass seine Anforderung akzeptiert wurde.

Communication (2) - RMI und Messaging

• Buch: 4.3, 4.4, 10.1.1, 10.3, 10.4

Remote Object/Method Invocation

Frage: Erläutern Sie die Grundprinzipien verteilter Objekte sowie der Remote Object (bzw. Method) Invocation. Gehen Sie auf die Begriffe "proxy" und "skeleton" ein. Erklären Sie den Unterschied zwischen "Compile-time" und "Run-time" Objekten. Erklären Sie den Unterschied zwischen persistenten und transienten Objekten.

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

Die Schlüsselfunktion von Objekten ist die Kapselung von Daten, also den Zustand, und den Operationen auf diesen Daten, also den Methoden. Methoden sind durch ein Interface verfügbar. Es ist wichtig zu verstehen, dass es keinen "legalen" Weg für einen Prozess gibt um auf den Zustand eines Objekts zuzugreifen oder diesen zu verändern ausser durch den Aufruf von Methoden, die durch das Interface des Objekts angeboten werden. Ein Objekt implementiert eventuell mehrere Interfaces und ein Interface kann von mehreren Objekten implementiert werden.

Diese Aufteilung zwischen Interfaces und den Objekten, die sie implementierten ist essenziell für verteilte Systeme. Eine strikte Aufteilung erlaubt uns ein Interface auf einen Computer (Client) zu platzieren während das Objekt auf einem anderen Computer (Server) liegt. Diese Organisation, wie in der folgenden Abbildung gezeigt, wird verteiltes Objekt genannt. Siehe auch #Object / Distributed Object

Wenn sich der Client an das verteilte Objekt bindet, wird die Proxy (Client-Stub) Implementierung geladen. Diese übernimmt das Marshalling der Parameter und das Unmarshalling der Antwort. Der Skeleton (Server-Stub) übernimmt das Parameterunmarshalling, das Ausführen des Methodenaufrufs des Objekts und Marshalling der Antwort am Server.

Compile Time Objekte basieren auf Klassendefinitionen (beschreibt einen abstrakten Datentyp). Diese Definition beinhaltet alle Methoden, die das Objekt aufweist und seine Struktur kann zur Laufzeit nicht geändert werden. Von einer kompilierten Klasse können dann zur Laufzeit die Objekte instanziert werden.

• Vorteil: Aus einer Klassendefinitionen können Client & Server Stubs abgeleitet werden (IDL)
• Nachteil: weniger flexibel als reine Laufzeitobjekte. Sprachabhängig. Genau eine Programmiersprache.

Laufzeitobjekte werden zur Laufzeit konstruiert. D.h. Die Implementierung ist weitgehend offen.

• Vorteil: verschiedene Programmiersprachen lassen sich leichter verbinden. Object wird mittels Object Adapter (wrapper) erstellt und somit sprachunabhängig gemacht.
• Nachteil: automatische Generierung von Stubs nicht möglich

Transiente Objekte existieren nur im (Arbeits-) Speicher des Servers, d.h. Wenn der Server beendet wird hört das Objekt auf zu existieren.

Persistente Objekte sind auf einen persistenten Speicher gesichert und können nach einem Neustart wieder von diesem gelesen werden.

Binding bei RMI

Frage: Wie funktioniert das Binding bei RMI? Welchen Zusammenhang gibt es zu den verschiedenen Arten, eine object reference zu implementieren. Vergleichen Sie (exemplarisch) CORBA und Java in Bezug auf Objektreferenzen.

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

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:

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

Ich bin der Meinung, dass alles obig gesagte zu dieser Frage nicht richtig ist. Es wird das Binding bei RPC beschrieben, und nicht bei RMI. Einer der wesentlichen Unterschiede zwischen RPC und RMI ist ja, dass RPC einzelne Prozedur remote aufrufbar macht, RMI hingegen Methoden von Objekten (objektorientiert). Kurz: Beschrieben wird hier Binding bei RPC, gefragt ist aber Binding bei RMI.

Ich würde die ersten beiden Fragen so beantworten:

Ad "Wie funktioniert das Binding bei RMI":

Binding bei RMI kann entweder implizit oder explizit erfolgen[1]. Wird implizit gebunden, so wird der Client genau dann transparent an das Objekt gebunden, wenn die Referenz zum eigentlichen Objekt aufgelöst wird. Beim expliziten Binden muss hingegen erst eine bestimmte Funktion aufgerufen werden, um sich an das Objekt zu binden, ehe dessen Methoden aufgerufen werden können. (Beim Expliziten Binden wird normalerweise ein Pointer auf einen Proxy zurückgegeben, welcher dann lokal verfügbar ist. Binden führt dazu, dass im Addressraum des Prozesses am Client ein Proxy angelegt wird, der eine Schnittstelle mit Methoden enthält, die der Prozess aufrufen kann.[2]

Ad "Welchen Zusammenhang gibt es zu den verschiedenen Arten, eine object reference zu implementieren?":

Bei allen Arten muss ausreichend Information vorhanden sein, damit sich ein Client an ein bestimmtes Objekt binden kann. Eine einfach Implementierung könnte beispielsweise aus Netzwerkadresse des Rechners (auf dem das Objekt liegt) + Endpoint der Kommunikation (der den Server auf dem Rechner bezeichnet) (+ Hinweis auf das zu referenzierende Objekt) [2].

[1] Folien WS10/11 Nummer 20.

[2] Buch "Verteilte Systeme - Prinzipien und Paradigmen, Andrew S. Tanenbaum und Maarten van Steen", Seite 494 f.

--emptyvi

Binden führt dazu, dass im Addressraum des Prozesses am Client ein Proxy angelegt wird, der eine Schnittstelle mit Methoden enthält, die der Prozess aufrufen kann.

Es gibt global und local object references.

• Global References werden bei implizitem Binding verwendet. Hierbei kann der Client direkt auf einer Referenz des Objektes die Methoden aufrufen.
• Explizites Binding verwendet sowohl lokale als auch globale Referenzen. Hier muss das Verteilte Objekt manuell an den lokalen Proxy gebunden werden. dh, es muss zuerst explizit ein Binding durchgeführt werden, bevor Methoden aufgerufen werden können.

Das Binding kann dabei immer nur an eine OR (object reference) geschehen. Diese muss genug Information darüber enthalten, dass ein Client ein Object binden kann. Eine simple OR wäre zB die IP-Adresse + Endpoint der Kommunikation (+ Object ID dort). Weiters müssen noch Infos wie zB das Protokoll, das Error Handling usw enthalten sein.

CORBA verwendet ausserdem die Interoperable Object Reference (IOR), welche alle Informationen beinhaltet um einen Kommunikationskanal zu einem Objekt aufzubauen. Diese beinhalten:

• Art des Kommunikationsprotokolls
• Angaben zum Ort des Objektes, wie im Fall von TCP/IP eine IP-Adresse und ein Port
• Vorgaben zur Darstellung von Text und Daten, wie Codepages, Endian, Verschlüsselung oder Kompression der Daten
• Angaben zur Identität des Objekts im Zielsystem

Um eine IOR zu erhalten, kann der Client den CORBA Naming Service verwenden.

Vergleichen Sie (exemplarisch) CORBA und Java in Bezug auf Objektreferenzen

Hier glaube ich, dass folgendes gemeint ist: während RMI Java spezifisch ist, muss es sich nicht um sprachenunabhängige Darstellungen von Objekten und somit auch von Objektreferenzen kümmern. CORBA hingegen (siehe 10.4.1 im Buch) hat eine andere Darstellung. Für CORBA hat eine Darstellung einer Referenz immer nur im Kontext des speziellen Prozesses eine Bedeutung. Man kann also nicht so einfach eine Referenz von C++ auf ein Java System übergeben. Deshalb hat CORBA die IORs eingeführt, um eine system- und sprachenunabhängige Darstellung von Objekten und Referenzen zu erreichen.

Kann das sein?

Static/Dynamic Invocation

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

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

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

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

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

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

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

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

Anwendungen von dynamic Invocation:

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

Parameterübergabe bei RMI?

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?

Message-orientierte Kommunikation

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.

• 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.

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.

Message-oriented Middleware

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:

• 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.).

Stream-orientierte Kommunikation

Frage: Erklären Sie "stream-oriented communication". Was ist "QoS" und inwiefern ist es für stream-oriented communication von Bedeutung?

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

Ein Datenstream ist nichts weiter als eine Folge von Dateneinheiten. Sie können sowohl auf kontinuierliche (Audio, Video), als auch auf diskrete Medien angewendet werden. Die zeitliche Abfolge ist für das Streaming von größter Bedeutung, damit die Daten rechtzeitig beim Client eintreffen.

• asynchron: keine zeitliche Beschränkung (Dateidownload)
• synchron: maximale End-to-End Verzögerung (Sensorenbeispiel: ein Sensor liefert in einer bestimmten Rate Signale. Diese müssen an den Empfänger übertragen werden. Wenn die Übertragung schneller ist als die Erfassungsrate, ist es ok, wenn sie langsamer ist als die Erfassungsrate, dann gibts Probleme)
• isochron: minimale und maximale End-to-End Verzögerung (Audio / Video Stream): hier muss die Übertragung zeitgerecht erfolgen. Siehe Audio + Video Stream - beide sollten die gleiche Verzögerung haben, sonst stimmt das Endergebnis nicht zusammen.

Ein einfacher Stream besteht aus einer Datenfolge (z.b. Mono Audio).

Ein komplexer Stream beinhaltet mehrere Substreams die in zeitlicher Abhängigkeit zueinander stehen (Stereo-Audio, Video mit Tonspuren).

QoS (Quality of Service)= Anforderung an zeitliche Steuerung. Solche Anforderungen beschreiben zB was von einem darunterliegenden VS und Netzwerk erwartet wird um sicherzustellen, dass bestimmte Dienste noch korrekt ausgeführt werden können.

• Erforderliche Bit-Rate
• max. Verzögerung bei Session beginn
• max. End-to-End Verzögerung
• max. Jitter (Verzögerungsvarianz)
• max. Umlaufverzögerung

Um Jitter zu vermeiden, wird ein Buffer verwendet. Somit können kleine Unregelmäßigkeiten im Datenstrom ausgeglichen werden.

Wenn ein Packet mehrere (Audio und/oder Video) Frames enthält und verloren geht, dann kann eine große Lücke beim Abspielen entstehen. Durch verschachtelte Rahmen (interleaved transmission) kann dieser Effekt reduziert werden. Dafür muss aber eine größere Start Verzögerung in Kauf genommen werden.

Operating System Support

• Buch: 10.2.1, Kap. 3

Interessierte finden zum Thema Client in dem Paper über die Entwicklung von User Interface Tools weitere Informationen. Interessierte finden in der CORBA Spezifikation im Kapitel 11 (POA - Portable Object Adapter) eine konkrete Umsetzung des allgemeinen Objekt-Adapter-Konzeptes.

Prozesse & Threads

Frage: Was ist der Unterschied zwischen Prozess und Thread? Was ist beim Einsatz von Multi-Threading zu beachten? Welche Bedeutung haben Threads in verteilten Systemen, insbesonders in Client/Server-Umgebungen?

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

Prozess-Eigenschaften:

• ist ein Programm in Ausführung auf einem virtuellen Prozessor
• ist eine Einheit des Ressourcenbesitzes und -schutzes: hat eigenen Addressraum und schützt diesen von anderen Prozessen
  • Nebenläufigkeitstransparenz durch den Hardware-Support des Beetriebssystems
• ist eine Einheit der Verteilung: wird vom Betriebssystem geplant und erstellt
• bedeutet hohe Kosten für Erstellung und Wechseln
  • Wenn die maximale Anzahl von Prozessen im Arbeitsspeicher erreicht ist, muss sogar Swapping verwendet werden (Austausch von Prozessen auf dem Arbeitsspeicher mit Prozessen auf der Festplatte)
• Granularität ist nicht ausreichend

Thread-Eigenschaften:

• führt wie Prozess eigenen Code aus, aber ohne Nebenläufigkeitstransparenz
• bedeutet einen Trade-Off: Robustness vs. Effizienz
• Schutz der Ressourcen bleibt dem Applikationsentwickler überlassen
• werden innerhalb eines Prozesses ausgeführt und erlauben nebenläufige Ausführung
  • haben nur minimale Informationen, die für das Sharing von Ressourcen benötigt werden wie z.B.: CPU, Scheduling Information, Synchronisation
• Prozess bleibt die Einheit des Ressourcen-Managements und Schutzes, Thread wird die Einheit der Verteilung

Worauf bei Multithreading geachtet werden muss:

• Safety - wie man Threads synchronisiert damit Sie sich nicht gegenseitig beeinflussen
• Liveness — Deadlocks vermeiden um dafür zu sorgen dass jeder Thread Fortschritt macht (Fairness!)
• Performance – Overhead (Performance Strafe) durch context switching und synchronisieren

Welche Bedeutung hat Threads in verteilten Systemen, inbesondere Client-Server Umgebungen?

• allgemein verbesseren Threads die Struktur eines Prozesses (großen Programmes)
  • Reaktiv (Server) - Applikation kann mehrere Incoming Events von Clients bearbeiten
  • Interaktiv (Client) - ein Thread antwortet auf Benutzerinteraktion, ein anderer erledigt Hintergrundarbeiten (vermeidet Blockierung und beschleunigt die gefühlte Geschwindigkeit)

Verteilte Systeme auf Client-Seite

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).

Serverdesign

Frage: Geben Sie grundlegende Design-Entscheidungen für Server an und bewerten Sie diese. Gehen Sie auf den Unterschied zwischen stateful und stateless Servern genauer ein und geben Sie Beispiele an. Erläutern Sie anhand einer Skizze Architektur und Funktionsweise eines multi-threaded Servers (zB File- oder Web-Server). Was ist beim Einsatz von Multi-Threading vom Entwickler besonders zu beachten?

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

Grundlegende Design-Entscheidungen sind zB:

• benötigt man einen iterativen Server (Server handled alles selbst)
• oder einen concurrent server (nebenläufig, gibt alle Aufgaben an eigene Worker-Threads oder andere Prozesse weiter)
• wie werden Interrupts behandelt(zB. wenn man ein File via FTP auf den Server lädt und währenddessen bemerkt, dass es das falsche ist )
  • Server Interrupt: Eine Möglichkeit für den User ist es den Client zu beenden und neu zu starten -> Server wird Verbindung aufgeben und das File verwerfen, da er denkt der Client ist abgestürzt.
  • out of band control: Client und Server so entwickeln dass sie in der Lage sind out of band daten zu senden. Der Server behandelt diese Daten mit höchster Priorität vor allen Anderen. Eine Möglichkeit: Server hört auf einem getrennten Control End Point, ob out of band Daten vom Client kommen.
• ist der Server / besitzt der Server
  • stateless Server hat keine Information über den Status des Clients und kann eigenen Status ändern ohne den Client darüber zu informieren. (z.b. Webserver). Zustandslose Server enthalten in Wirklichkeit zwar dennoch Informationen über die Clients, aber entscheidend ist dass der Verlust dieser Informationen zu keinen Unterbrechungen führt.
  • stateful Server enthält beständige Information über Clients. Diese werden so lange behalten bis sie ausdrücklich gelöscht werden. (z.B. Fileserver: Tabelle mit Clients und Berechtigungen). Sind aus Clientsicht schneller als stateless Server. Nachteil: Stürzt der Server ab, muss der Status vor dem Absturz wieder hergestellt werden. Gelingt das nicht kommt es zu Problemen.
  • soft state (der Server kennt den Client nur für eine bestimmte Zeit und verwirft danach alles wieder)
  • session state (hier werden Aktionen immer in einer Session ausgeführt, in der sich ein Client authentifiziert hat - zB WebServer mit Session à la Cookies)
• wie/wo kann man den Server finden?
  • Name oder Directory Server
  • Well known Port addresses(0-1023)

Arten von Servern:

• multithreaded server: bestehend aus einem dispatcher und mehreren worker threads. Der dispatcher thread wartet auf eingehende anfragen, und startet pro anfrage einen worker thread, an welchen die anfrage weitergereicht wird. Somit ist es möglich, dass während eine Anfrage bearbeitet wird, der dispachter thread wieder auf neue Anfragen warten kann.
• single-threaded server: Bestehend aus nur einem einzigen Thread, welcher die Anfragen entgegennimmt, bearbeitet und das Ergebnis an den Client sendet. Die Implementierung ist recht einfach, jedoch kann immer nur ein Client zur selben Zeit bearbeitet werden.
• finite-state machine: Ebenfalls nur ein Thread. Die finite state machine hält eine Tabelle mit Ergebnissen bereit, sodass eine Anfrage, wo das Ergebnis bekannt ist, sofort beantwortet werden kann. Falls das Ergebnis nicht in der Tabelle enthalten ist, wird eine Anfrage an die Festplatte geschickt, jedoch sofort weitergearbeitet. Wenn das Ergebnis dieser Anfrage eintrifft, wird es in die Tabelle eingetragen und an den Client geschickt.

Beim Einsatz von Multi-Threaded Servern ist zu beachten:

• Wer erzeugt den Thread?
• Wann wird der Thread erzeugt?
• Fixe Anzahl an Threads?
• Verschiedene Architekturen sind möglich(Thread-per-request, Thread-per-connection, Thread-per-object)
• Synchronisation

Die Thread-Erzeugung ist sehr teuer. Die Kosten der Thread-Erzeugung können verringert werden, wenn man einen Thread für mehrere Anfragen verwendet. Eine fixe Anzahl an Threads können schon beim Starten erzeugt and und den einkommenden Anfragen zugewiesen werden.

Objektserver

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:

Code Migration

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

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

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

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

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

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

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

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

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

Bild aus den Folien:

Virtualisierung

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.

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.

Naming and Discovery

• Buch: Kap. 5

Name/Identifier/Address

Frage: Erläutern Sie die Begriffe "Name", "Identifier", "Address" sowie den Bezug zwischen diesen Begriffen in der Praxis.

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

Name: benennt eine Entität (meistens benutzerfreundlich). Eine Entiät kann hierbei ein Host, Drucker,... sein.

Vorteile:

• unabhängig von Adresse (ortsunabhängig) durch Namensauflösung
• für Benutzer sind (hierarchische) Namen leichter zu merken als z.B. reine (IP) Adressen

Eigenschaften:

• Location independent
• Unique

Address: Um mit einer Entiät interagieren zu können, muss man auf diese zugreifen können. Den Namen eines Zugriffspunktes einer Entität nennt man Adresse. Eine Entität kann mehrere Adressen haben: Bsp: Eine Person ist die Entität, ihr Zugriffspunkt die Telefonnummer (eine Person kann mehrer Telefonnummern haben). Entitäten können ihre Adresse von Zeit zu Zeit wechseln. Direkte Verwendung einer Adresse ist problematisch, da dadurch die Location-, Replication- und Migration-Transparenz nicht unterstützt wird und Adressen auch oft für Menschen schwer lesbar sind. Gute Namen sollten daher die Adresse weder direkt, noch versteckt codieren.

Identifier: für Eindeutige Kennzeichnung einer Entität, die folgenden Kriterien entspricht:

• Jeder Identifier verweist höchstens auf eine Entität
• Auf jede Entität verweist höchstens ein Identifier
• Ein Identifier verweist immer auf die gleiche Entität

Identifier können durch Counter oder Zufallszahlgeneratoren erzeugt werden. Wobei bei zweiterem sichergestellt werden muss dass sich Zahlen mit hoher Wahrscheinlichkeit NICHT wiederholen.

Name Spaces

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}}

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

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

Schichten in Name Spaces

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}}

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.

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

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.

Domain Name System

Frage: Erläutern Sie das Domain Name System DNS, sowie den Ablauf bei der Namens-Auflösung anhand der DNS Database (Resource Records). Was ist reverse lookup? Was ist ein zone-transfer?

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

DNS ist das NS für das Internet. Es wird verwendet um Domainnamen auf IP-Adressen zu mappen. Eine Domain kann man sich als „Unterbaum“ eines hierarchischen Graphen vorstellen. Pfadnamen nennt man „Domainname“.

Knoten speichern ihre Daten in Resource Records. Resource Record ist die kleinste Informationseinheit im DNS.

ausgewaehlte Resource Record Typen:

• SOA ? Start of Authority: Informationen zur dargestellten Zone
• A ? IP eines Hosts
• MX ? Mailserver
• NS ? Name eines NS der die dargestellte Domain implementiert
• CNAME ? Alias-Implementierung von DNS: speichert den cannonical name (= primary name) des hosts (--> soft link)
• PTR ? wird für reverse DNS verwendet: hat host mit cannonical name soling.cs.vu.nl die IP 130.37.20.20, dann wird ein PTR eintrag für soling.cs.vu.nl mit wert 20.20.37.130.in-addr.arpa angelegt
• (etc.)

Caching und Replikation werden zur Steigerung der Effektivität verwendet.

Zone-Transfer = Zonenübertragung (Übertragung von Resource Records) auf einen anderen NS also z.b. von Primary NS auf Secondary NS. Dies dient der Ausfallsicherheit und Performance.

(Ein Secondary NS kann ein Primary NS einer anderen Zone sein. Beide sind authorative).

Reverse-lookup: wird benötigt um von einer IP auf einen Domainname zu schließen. Dazu wurde eine eigene Domain (mit 3 (Ebenen von) Subdomains) begründet: in-addr.arpa-Domäne.

Somit lassen sich z.B. alle IP Adressen die mit 193 beginnen in der 193.in-addr.arpa Domäne finden.

Ablauf bei der Namens-Auflösung anhand der DNS Database (Resource Records):

Wenn man eine Verbindung zu einer Domain aufbauen will, braucht man zunächst einmal dessen IP-Adresse. Angenommen, ein Rechner X will eine Verbindung zu „de.wikipedia.org.“ (Rechner Y) aufbauen. Dazu braucht er dessen IP-Adresse. In den folgenden Schritten wird beschrieben, wie dies ablaufen könnte.

1. Der Rechner X sucht in seiner Hosts-Datei, ob die IP-Adresse für „de.wikipedia.org“ dort hinterlegt ist. Falls dem nicht so ist, fragt er beim DNS-Server nach.
2. Hat der DNS-Server von Rechner X eine IP-Adresse für den angefragten Namen zwischengespeichert, antwortet er damit und die Anfrage kommt zum Ende (siehe letzter Punkt). Andernfalls fragt er einen der 13 Root-Nameserver nach „de.wikipedia.org.“.
3. Der Root-Nameserver findet heraus, dass die Auflösung dieses Namens in der „org.“-Zone weitergeht und sendet die Namen und die IP-Adressen der „org.“-Nameserver zum DNS-Server von Rechner X.
4. Nun fragt der DNS-Server von Rechner X einen der Nameserver für „org.“-Domains nach „de.wikipedia.org.“.
5. Der „org.“-Nameserver sendet ihm die Namen der Nameserver für die Zone „wikipedia.org.“.
6. Anschließend fragt der DNS-Server von Rechner X einen „wikipedia.org.“-Nameserver wie die IP-Adresse des Namens "de.wikipedia.org." ist.
7. Mit dieser Adresse wird an den DNS-Server von Rechner X geantwortet und der …
8. … sendet sie an den Rechner X, welcher nun zum Beispiel seine HTTP-Anfragen an die IP-Adresse von „de.wikipedia.org.“ senden kann.

Directory Services

Frage: Was ist Directory Service bzw. "Attribute-based naming"? Beschreiben Sie den prinzipiellen Aufbau des X.500 Name Space sowie dessen LDAP Implementierung.

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

Attribute-based naming

• jede Entity hat eine Menge von Attribut-Wert Paaren
• diese Menge sagt etwas über die Entity aus
• Entitäten können aufgrund ihrer Eigenschaften gefunden werden (bei vielen Entitäten fällt das Merken des Namens schwer)

Attributbasierte Services werden oft auch als Directory Services bezeichnet. Diese Attribute können innerhalb des Directories zum Suchen von Entities verwendet werden.

X.500 (basierend auf OSI) ist ein hierarchisch organisiertes Directory Service. Die Benennung einer Entität basiert auf deren Attribut-Wert Paaren (=attributbasierte Bennenung).

Es gibt einen einzigen Directory Information Tree (DIT) welcher Einträge hierarchisch speichert (Verteilung über mehrere Server möglich). Jeder Eintrag kann mehrere Attribute-Wert-Paare speichern.

Jeder Eintrag hat einen eindeutigen Distinguished Name, der eine Kombination aus seiner eigenen RDN (Relative Distinguished Name) und der RDN all seiner übergeordneten Einträgen ist.

Vorteil: effektives Suchen wird möglich (Besucher gibt Beschreibung dessen ein, was er sucht).

LDAP (lightweight directory access protocol) ist eine effizientere, einfachere Implementierung auf TCP Basis, die hierarchisch ist.

Verwendung: z.B. zum Beschreiben von Zugriffsberechtigungen für Benutzerauthentifizierung (MS Active Directory), oder als Verzeichnis für Personen und E-Mailadressen.

Attribute Namenskonvention:

• C ? Country
• L ? Location
• O ? Organisation
• OU ? Organisational Unit
• CN ? Common Name
• Zusätzliche Attribute können spezifiziert werden

Pfade werden aus Attribut-Wert Paaren gebildet. Z.b.

/C=At/L=Vienna/O=TU-Wien/OU=Infosys/CN=Main_Server/

Beispiel-Baum eines Directories dargestellt mit LDAP Attributen

Suchen können mit Wildcards verwendet werden. Gibt alle Main Server der TU-Wien zurück:

search(„&(C=At)(O=TU-Wien)(OU=*)(CN=Main_Server))

Location Service

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.

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.

Clocks and Agreement

• Buch: Kap. 6

Buchauszug (c) Pearson/Prentice Hall - mit freundlicher Genehmigung des Verlages (für die Frage zum "Global state")

Uhrensynchronisation

Frage: Wozu braucht man Uhrensynchronisation? Erläutern Sie das NTP und den Berkeley Algorithmus. Was ist die Problematik bei der Synchronisation von Physical Clocks?

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

Uhrensynchronisation braucht man für die Festlegung der Reihenfolge von Operationen in Verteilten Systemen (Korrektheit verteilter und zeitabhängiger Informationsverarbeitung). Es muss nicht immer eine "wirkliche" Uhr verwendet werden. Es kann auch nur eine logische Uhr verwendet werden.

NTP (Network Timing Protocol): Es handelt sich dabei um eine Synchronisation mit einem externen Zeitgeber. Die Genauigkeit von Zeitgebern wird durch das sogenannte Stratum definiert. Je niedriger es ist, desto genauer ist eine Zeitquelle. Beim NTP wird ein höheres Stratum mit einem niedrigeren synchronisiert. Ein Rechner sendet eine Nachricht an den Zeitserver und merkt sich den Sendezeitpunkt t1. Der Server zeichnet sich den Empfangszeitpunkt t2 sowie den Sendezeitpunkt der Antwort (kurz davor) t3 und schickt die Antwort. Der Rechner zeichnet den Empfangszeitpunkt t4 auf. (t1 und t4: lokale Zeit; t2 und t3: Serverzeit)

Berechnung der Abweichung und des Delays:

Abweichung = ((t2 - t1) + (t3 - t4)) / 2

Delay = ((t2 - t1) + (t4 - t3)) / 2

Die Abweichung mit zugehörigem Delay wird acht mal ermittelt und die Abweichung mit dem kleinsten delay effektiv verwendet. Korrektur: beschleunigen oder bremsen der lokalen Uhr.

Delay über einem Grenzwert --> Zeitquelle nicht vertrauenswürdig (citation needed!).

Berkley Algorithmus: Es handelt sich dabei um eine interne Synchronisation. Es gibt einen Koordinator, welcher seine lokale Zeit an alle sendet (auch an sich selbst). Jeder antwortet mit seiner Abweichung von dieser Referenzzeit. Danach berechnet der Koordinator die durchschnittliche Abweichung und schickt jedem zurück, um wie viel er seine Zeit vor- oder zurückstellen muss. Korrektur: beschleunigen oder bremsen der lokalen Uhr.

• Problematik: Uhren dürfen nie zurück gestellt werden, nur über längere Zeit verlangsamt. Antwortzeiten über Netzwerk unterschiedlich.

weiß nicht, ob man sich dabei nur physische Uhren konzentrieren soll oder nicht (bitte diesen Punkt überarbeiten). Bei physischen Uhren kann es durch den Kristall-Oszillator zu einer Uhr-Asymmetrie kommen.

Edit: Ich glaub das Problem von "Physical Clocks" ist auf den Folien (WS2012/13) Seite 6 beschrieben. TAI seconds are of constant length, unlike solar seconds. Leap seconds are introduced when necessary to keep UTC in phase with the sun. Weiterer Punkt: ZeitZonenProblematik

Logical Clocks

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).

Vector Timestamps

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):

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

Distributed Mutual Exclusion

Frage: Wie funktioniert Distributed Mutual Exclusion. Wie verhalten sich verschiedene Algorithmen (centralized, distributed, token-ring) hinsichtlich Skalierbarkeit und Fehlertoleranz?

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

Das Ziel von Distributed Mutual Exclusion ist, in einem Verteilten System den exklusiven Zugriff auf Ressourcen zu vergeben, es soll verhindert werden, dass 2 Prozesse gleichzeitig auf dieselbe Ressource zugreifen. Dazu werden mehrere Ansätze verfolgt:

• centralized: ein Prozess agiert als Koordinator, er erhält die Anfragen der anderen Prozesse und gewährt oder verwehrt den Zugriff auf die Ressource, sodass immer nur ein Prozess zur selben Zeit mit der Ressource arbeitet. Ist dieser Prozess mit seiner Arbeit fertig, teilt er dies dem Koordinator mit. Falls ein Prozess eine Anfrage stellt und die Ressource in Verwendung ist, kann der Koordinator die Anfrage in einer Warteschlange zwischenspeichern. (Vorteile):hohe Effizienz; Einfache Implementierung; keine Starvation (jeder Prozess kommt an die Reihe); keine Deadlocks (Nachteile): Der Koordinator ist ein Single-point of failure und ein bottleneck :(

Skalierbarkeit: eher schlecht, sobald viele Rechner von einem Coordinator abhängen wird der Coordinator eine sehr große Queue haben. Außerdem ist so der Koordinator ein bottleneck Fehlertoleranz: sobald der Koordinator ausfällt ist die Ressource nicht mehr erreichbar, also ein single point of failurs

• distributed: Wenn ein Prozess exklusiven Zugriff auf eine Ressource haben will, so schickt er eine Nachricht an alle anderen Prozesse (einschließlich sich selbst). Dieser Nachricht hängt er seine logische Zeit (Lamport clock) an. Der Empfänger dieser Nachricht hat 3 Antwortmöglichkeiten:
  • Greift er selbst auf die Ressource zu, so antwortet er mit denied
  • Greift er nicht darauf zu, und hat es auch nicht vor, so ist die Antwort OK
  • Greift er noch nicht darauf zu, will es aber, so werden die logischen Zeiten der Nachrichten (seine eigene + die Anfrage des anderen Prozesses) verglichen, die niedrigere gewinnt, je nachdem antwortet der Prozess mit denied oder OK

Wird von jedem der n Prozesse auf ein OK gewartet, so gibt es nicht mehr einen single-point of failure, sondern n (sobald einer der n Prozesse gecrasht ist funktioniert dieses Prinzip nicht mehr); Bei dieser Variante kommt es zu einem sehr hohen Kommunikationsaufwand; Dieser Algorithmus beseitigt keine Bottlenecks, da jeder Prozess befragt wird und jeder die selbe Arbeit erledigen muss -> keine Aufteilung der Arbeit.

Skalierbarkeit: Je mehr Rechner im Netzwerk hängen umso stärker steigt die Anzahl der Kommunikationsnachrichten. Fehlertoleranz: sobald ein Rechner ausfällt kann niemand mehr auf die Ressource zugreifen da immer ein OK fehlt. Also n points of failure!

• token ring: Ein Token wird zwischen den Prozessen weitergereicht, nur der Prozess, der das Token hält, ist zum Zugriff auf die Ressource berechtigt. Benötigt ein Prozess keinen Zugriff, so reicht er einfach das Token zum nächsten Prozess weiter. (Vorteile): Einfache Implementierung; keine Starvation (jeder Prozess kommt an die Reihe); keine Deadlocks (Nachteile): stürzt der Prozess ab, der das Token hält, geht es verloren, es ist schwer zu erkennen wann ein Token verloren gegangen ist; auch wenn kein Prozess auf die Ressource zugreifen will, muss trotzdem ständig das Token weitergereicht werden.

Skalierbarkeit: Je mehr Rechner im Ring sind umso kürzer hat jeder Rechner die Ressource und müssen länger auf den Token warten. Fehlertoleranz: Es muss immer geprüft werden ob der Token noch existiert oder ob er verloren gegangen ist. Das bedeutet deutlich zusätzlichen Overhead und der steigt mit der Anzahl der Rechner.

• decentralized
  • Replizierte Ressourcen & Coordinators
  • Vorausscheidung: Abstimmung ob m > n/2
  • Wenn eine Ressource besetzt, DENIED zurück an Requester

Dateiserver implementieren

Frage: Sie sollen einen Dateiserver implementieren der mehrere Clients gleichzeitig bedienen kann. Nennen und beschreiben Sie einen (konkreten) Mechanismus der garantiert dass immer nur einer der Clients gleichzeitig eine Datei schreiben darf. Die anderen Clients sollen solange blockiert werden (egal ob schreibend oder lesend) bis der schreibende Client seine Arbeit beendet hat. Warum ist das sinnvoll?

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

Bitte nochmal durchsehen und vl verbessern -> starvation kann bei read befehlen passieren, dafür bekommt der client immer die aktuellste version

Ich würde einen abgewandelten centralized algorithmus verwenden:

Die Threads innerhalb des Server Prozesses treffen die Entscheideungen. Die Grundlage dafür liefert ein zentraler Datenbestand innerhalb des Prozesses.

Vorteile: Exklusiver Schreibzugriff (gewährt durch zentrale Authorität); Hohe Effizienz; Einfache Implementierung; Keine Deadlocks; Keine Starvation (jeder Prozess kommt an die Reihe

Nachteile:single-point of failure

Damit mehrere Anfragen gleichzeitig verarbeitet werden können, würde ich einen multi threaded server entwickeln. Bestehend aus:

• dispatcher thread (nimmt Anfragen entgegen, startet pro Anfrage einen worker thread)
• worker thread (bedient die Anfrage eines Clients)
• Liste aller Datein (pro Datei wird vermerkt, welcher Thread wie (read/write) gerade darauf zugreift, in Form einer Queue).

Eine Client Anfrage besteht aus einem Befehl (read/write) und dem Dateiname (Pfad). Somit gibt es 2 Möglichkeiten, wie der worker thread reagieren kann:

• bei read: worker thread trägt sich bei der Datei in die Warteliste als read ein; prüft ob in der Liste ein Thread die Datei gerade schreibt, wenn ja->wait; danach: senden der Datei an Client; austragen aus der Liste.
• bei write:worker thread trägt sich bei der Datei in die Warteliste als write ein;prüft ob in der Liste ein Thread die Datei gerade schreibt, wenn ja->wait; danach: alle thread in der Liste dieser Datei auf wait setzen; Datei von Client empfangen & schreiben; gibt es einen weiteren write thread in der Liste, dann diesen "aufwecken" (notify), sonst alle read threads aufwecken mit notify.

Bully- und Ring-Algorithmus

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.

Global State

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):

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.

Consistency and Replication

• Buch: 7.1, 7.4, 7.5, 10.6, 4.5.2

Gründe für Replikation

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

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.

Update Propagation

Frage: Geben Sie verschiedene Möglichkeiten der Update Propagation (Content Distribution) an und bewerten Sie diese hinsichtlich Vor- und Nachteilen sowie Einsatzmöglichkeiten.

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

Status versus Operation:
Ein wichtiger Entwurfsaspekt kümmert sich darum, was überhaupt weitergegeben werden soll. Dafür gibt es grundsätzlich 3 Möglichkeiten:

• Weitergabe der Aktualisierung nur durch eine Benachrichtigung:

In einem Invalidierungsprotokoll werden andere Kopien darüber informiert, dass eine Aktualisierung stattgefunden hat und dass ihre Daten nicht mehr gültig sind.

Vorteil: es wird wenig Netzwerkbandbreite verbraucht, da nur eine Benachrichtigung versendet wird.

Nachteil: kann höhere Delays bei Anfragen bedeuten, da erst das Update erfragt werden muss, wenn tatsächlich Daten gelesen werden sollen.

Einsatzbereich: wenn es viele Aktualisierungsoperationen im Vergleich zu Leseoperationen gibt.

• Übertragung der Aktualisierungs-Daten:

Vorteil: Alle Replicas haben die aktualisierten Daten sobald sie die Nachricht bekommen

Nachteil: Viel Bandbreitenverbrauch, sind die Nachrichten zu häufig, kann es sein das Updates verloren gehen, da die Replikas nicht schnell genug die Updates holen können bevor schon die nächste Updatenachricht da ist und die Daten am Server wieder anders sind

Einsatzbereich:dort wo das Lese/Schreib Verhältnis hoch ist.

• Weitergabe der Aktualisierungs-Operation:

Hier werden keine Änderungen an den Daten übertragen, sondern jeder Replik wird mitgeteilt, welche Aktualisierungsoperation sie ausführen soll.

Dieser Ansatz wird auch aktive Replikation genannt.

Vorteil: Aktualisierungen können mit minimalen Kosten für die Bandbreite weitergegeben werden.

Nachteil: Jede Replik benötigt möglicherweise mehr Rechenleistung, insbesondere wenn die Operationen relativ komplex sind. Anmerkung von Prof. Göschka: Liefert die gleiche Operation angewendet auf die Gleiche Datenmenge immer dasselbe Ergebnis? --> Nein: extremes Beispiel: Random Funktion!!

Pull- oder Push-Protokolle:
Dieser Entwurfsaspekt unterscheidet sich darin , ob Aktualisierungen abgeholt (pull) oder automatisch verschickt werden (push).

In einem push-basierten Ansatz, auch als Server-basierte Protokolle bezeichnet, werden Aktualisierungen an andere Repliken weitergegeben, ohne dass diese welche angefordert haben.

Server-basierte Protokolle werden hauptsächlich dort eingesetzt, wo die Repliken im Allgemeinen einen relativ hohen Konsistenzgrad aufweisen müssen.

Dieser Bedarf eines hohen Konsistenzgrades hat mit der Tatsache zu tun, dass permanente und Server-initiierte Repliken sowie große Caches häufig von vielen Clients gemeinsam genutzt werden, die wiederum hauptsächlich Leseoperationen durchführen. Daher ist das Lese/Aktualisierung Verhältnis relativ hoch (eine Aktualisierung wird oft gelesen).

Ein wichtiger Aspekt bei push-basierten Ansätzen ist, dass der Server alle Clients verwalten muss, welche Aktualisierungen von ihm erhalten. Neben der Tatsache, dass statusbehaftete Server weniger fehlertolerant sind, kann die Verwaltung aller Client-Repliken und -Caches eine wesentlichen Overhead auf dem Server verursachen

In einem pull-basierten Ansatz, auch als Client-basierte Protokolle bezeichnet, fordert ein Server oder Client einen anderen Server auf, ihm Aktualisierungen zu senden, die ihm zu diesem Zeitpunkt vorliegen.

Dieser Ansatz wird häufig von Web-Caches verwendet, wo der Browser zuerst prüft ob die im Cache befindlichen Datenelemente noch aktuell sind, und dann bei Bedarf die Aktualisierung vom Webserver holt.

Client-basierte Protokolle sind effizient, wenn das Lese/Aktualisierung Verhältnis relativ niedrig ist.

Der größte Nachteil ist, dass die Antwortzeit im Falle eines veralteten Cache-Eintrag steigt.

Aspekt	Push-basiert	Pull-basiert
Status am Server	Liste mit Client-Repliken und -Caches	Keine
Gesendete Nachrichten	Aktualisierung(und möglicherweise später die Aktualisierung laden)	Pull und Aktualisieren
Antwortzeit auf dem Client	Unmittelbar (oder Laden/Aktualisierungszeit)	Laden/Aktualisierungszeit

Häufig wird eine Mischform aus beiden Ansätzen verwendet, die auf Leases basiert. Ein Lease ist eine Zusage des Servers, dass er an den Client eine bestimmte Zeit lang Aktualisierungen per Push überträgt. Wenn ein Lease abläuft, ist der Client gezwungen, den Server für mögliche Aktualisierungen zu kontaktieren, um diese bei Bedarf per Pull zu erhalten. Alternativ kann der Client auch ein neues Lease anfordern. Wie die Expiration time bei Leases gewählt wird:

• Age-based:

Annahme das länger unveränderte Daten auch weiterhin wenig Änderungen haben werden.

Daten mit länger zurückliegender Änderungszeit bekommen höhere Expiration time

• Renewal-frequency-based:

Clients die eine hohe Update Rate haben bekommen einen höhere Expiration time

• State-space overhead:

Schutzmechanismus um eine Überlastung des Servers zu vermeiden

Wenn der Server eine Überlastung feststellt verringert er die Expiration time der Leases und reguliert somit seine Last.

Unicasting versus Multicasting:
Bei einer Unicast-Kommunikation sendet ein Server, der Teil des Datenspeichers ist, seine Aktualisierung an N andere Server, indem er N separate Nachrichten sendet, je eine an jeden Server. Beim Multicasting übernimmt das zugrunde liegende Netzwerk die Aufgabe, eine Nachricht effizient an mehrere Empfänger zu senden.

Das Multicasting kann häufig effizient mit einem push-basierten Ansatz kombiniert werden, um Aktualisierungen weiterzugeben. In diesem Fall verwendet ein Server eine Multicast-Gruppe, um mehreren anderen Server (welche in der Multicast-Gruppe sind) Aktualisierungen bereitzustellen.

Bei einem pull-basiertem Ansatz ist es häufig nur ein einziger Client der eine Aktualisierung anfordert. In diesem Fall wird Unicasting die effizientere Lösung sein.

kommentar: die antwort gehört mEn gekürzt, das kann ich nie in 10 minuten so detailiert ausführen. ich hab nur keine ahnung was da von der lva-leitung als relevant angesehen wird. ich würd aber denk ich das leasing weg lassen und push/pull auch gröber anschneiden. ideen? --thomas 15:24, 5. Mär. 2012 (CET)

@thomas: Die genaue Antwort wird man auf die konkrete Fragestellung anpassen müssen. Ich finde so wie das da steht ist das eine gute Zusammenfassung von dem Thema. (Bin aber kein VS-gosu!! ^^) --Gast 21:55, 5. Mär. 2012 (CET)

Primary-based Protokolle

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.

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.

Replicated-write Protokolle

Frage: Erläutern Sie die Funktionsweise der "replicated-write" Protokolle. Bewerten und vergleichen Sie die verschiedenen Arten. Welche Probleme können bei "Active Replication" auftreten? Erklären Sie "quorum-based" Replikationsprotokolle und geben Sie die Bedingungen an, um Read-Write und Write-Write Konflikte zu verhindern.

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

Im Gegensatz zu Primary-Based Protokollen erlauben Replicated-Write-Protokolle den Zugriff auf beliebigen Replikate. Die Änderungen werden dann an alle anderen Replikate propagiert, entweder über Active Replication (die Operationen werden ausgeschickt und überall nachvollzogen – nur bei deterministischen Operationen möglich; gleiche Reihenfolge wird durch totally-ordered Multicast und deterministisches Thread Scheduling erreicht) oder über quorumbasierte Ansätze (es wird immer eine bestimmte Anzahl von Replikaten gelesen bzw. geschrieben, so dass es keine Schreib/Schreib- oder Lese/Lese-Konflikte geben kann ).

• lese/schreib Zugriff verhinden Qr+Qw>n
• schreib/schreib Zugriff verhindern Qw>n/2

Eine Spezialform von Replicated-Write-Protokollen ist Coordinator-Cohort-Replication. Dabei wird die Anfrage an ein (beliebiges) Replikat gesendet, das die Updates synchron an alle anderen propagiert. Dazu ist ein distributed-Locking-Mechanismus erforderlich.

Alternative Antwort (die ich persönlich verständlicher finde):

Schreib-operationen werden im Gegensatz zu primary-based Protokollen an vielen replicas ausgeführt.

active replication: Die Operation wird an jedes Replica gesendet. Das Problem ist, dass Operationen überall in der selben Reihenfolge geliefert werden müssen. Was es daher braucht ist einen "totaly-ordered multicast- Mechanismus". Hier gibt es aber in groß skalierten Systemen Probleme. Als Alternative kann ein zentraler Koordinator (Sequencer) verwendet werden. Meistens ist eine Mischung aus beiden nötig.

quorum-based protocolls: Hier wird ein Voting verwendet. Bsp.: Um ein File zu aktualisieren, muss der Client zuerst mindestens die Hälfte der Server plus 1 dazu bringen dem Update zuzustimmen. Um das File zu lesen muss der Client wiederum mindestens die Hälfte der Server plus eins dazu bringen ihre Versionsnummern des Files zu schicken. Wenn alle Versionsnummer gleich sind, muss es sich um die aktuelle Version handeln.

Eine Verallgemeinerung hierfür ist das Gifford's scheme, das folgenden Regeln folgt: Der Client muss eine Mehrheit der Server mit den Update versorgen. Beim Lesezugriff muss auch wieder von zumindest der Anzahl der nicht upgedaten Server +1 gelesen werden. Dabei gewinnt die Dateneinheit mit der höchsten Versionsnummer.

1. Nr + Nw > N (verhindert read-write Konflikte) 2. Nw > N/2 (verhindert write-write Konflikte)

Replikation von Objekten

Frage: Welche Besonderheiten sind bei der Replikation von Objekten zu beachten? Erläutern Sie (inkl. genauer Skizze) wie man "Replication transparency" in Objektsystemen umsetzen könnte ("replicated invocation").

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

folgender Absatz ist meiner Meinung nach zu wenig

Eine Menge von Replikaten wird zu einer Gruppe zusammengefasst, wobei ein Replikat der Koordinator dieser Gruppe ist. Aufgerufen wird eine Methode immer bei allen Replikaten um sicherzustellen, dass alle den aktuellen Status haben (etwa über Reliable Multicast). Falls dieses replizierte Objekt jedoch selbst wieder eine Methode eines anderen distributes Objects aufruft, dann wird das nur vom Koordinator der Gruppe gemacht. Andernfalls würde die Methode zu oft aufgerufen werden. Auch die Antwort eines Aufrufs wird nur vom Koordinator zurückgeschickt.

Schon eher trifft es das hier:

Problem: Wenn Objekte in verteilten Systeme verwendet werden und ebenfalls verteilt sind, dann müssen auch die Zugriffe auf Objekte konsistent gehalten werden, da es sonst zu inkonsitenten Zuständen innerhalb des Systems führen kann (entry consistency). Wir müssen also eine gleichzeitige Ausführung von Methoden am Objekt verhindern (durch Locking relativ einfach zu lösen) und wir müssen Änderungen (Methodenaufrufe) auf ALLE Replikate des Objektes verteilen um sicherzustellen, dass nicht 2 unterschiedliche Aufrufe auf ein verteiltes System zur gleichen Zeit geschehen.

Dies kann folgendermaßen geschehen:

• primary-based approach: ein "Koordinator" übernimmt die Kontrolle und delegiert die Aufrufe. Problem: Overhead, Skalierbarkeit geht verloren, "Koordinator" muss andere verteilte Objekte kennen.
• totally-ordered-multicasts: Methodenaufrufe werden zB durch Lamport clocks durchnummeriert und dann in der Reihenfolge auf jedes Objekt ausgeführt. Problem dabei: sehr aufwändig, viel Overhead

Folgendes Bild beschreibt ein weiteres Problem:

Methodenaufrufe auf ein vielleicht nicht verteiltes Objekt werden mehrmals ausgeführt. Um dies zu verhindern, gibt es zB folgenden Ansatz:

Falls von A aus ein Aufruf in B erfolgt, so ruft A alle Replikate in B (B1, B2, B3) auf. Wenn B nun seinerseits wieder eine Methode von C aufruft, so wird das nur vom Koordinator von B (z.B. B1) gemacht (und zwar bei C1 und C2). Andernfalls (wenn alle 3 Replikate von B den Aufruf durchführen würden) wäre die Methode von C zu oft aufgerufen worden. Die Antworten werden nur vom Koordinator zurückgegeben, also von z.B. C2 zu allen 3 Replikaten von B, und von B1 zu A.

Wird hier ausreichend auf das "Replication transparency" eingegangen? Wie wird die Replikationstranpsarenz hier konkret umgesetzt?

Epidemic Protocols

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.

Dependability and Fault Tolerance

• Buch: 8.1 - 8.4

Buchauszug (c) Pearson/Prentice Hall - mit freundlicher Genehmigung des Verlages (für die Frage zum "Two army problem")

Fehlertoleranz

Frage: Erläutern Sie die grundlegenden Begriffe der Dependability. Nennen Sie die fünf wesentlichen Attribute (bzw. Requirements) eines "dependable system". Was ist der Unterschied zwischen Availability und Reliability? Erläutern Sie die "dependability threats" Failure, Error und Fault sowie den Zusammenhang zwischen den drei. Erläutern Sie "permanent", "transient" und "intermittent" faults anhand von Beispielen.

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

Eine Eigenschaft von Verteilten System ist, dass es keinen single-point of failure gibt, fällt eine Komponente aus, so werden möglicherweise einige andere Operationen beeinträchtigt, jedoch nicht das komplette System. Fehlertoleranz bedeutet, dass ein System auch im Falle eines Fehlers seine Dienste zur Verfügung stellt. Attribute eines dependable system:

• Availability/Verfügbarkeit wird als Wahrscheinlichkeit angegeben, mit welcher ein Service/System zu einem beliebigen Zeitpunkt korrekt arbeitet, sagt jedoch nichts darüber aus, wie lange ein System am Stück verfügbar ist. Ein hoch verfügbares System hat also eine hohe Wahrscheinlichkeit zu jedem beliebigen Zeitpunkt zu funktionieren.
• Reliability/Ausfallsicherheit: Definiert die Eigenschaft, das ein System fortlaufend fehlerfrei läuft. Ein höchst zuverlässiges System steht also durchgehend über einen relativ langen Zeitraum fehlerfrei zur Verfügung.

Im Gegensatz zur Verfügbarkeit ist hier von einem Zeitraum und nicht von einem Zeitpunkt die Rede. Wenn ein System pro Stunde eine Millisekunde lang nicht funktioniert ist, hat es zwar eine hohe Verfügbarkeit, aber keine hohe Ausfallsicherheit. Andererseits hat ein System welches ganze 11 Monate am Stück fehlerfrei läuft aber dann den ganzen Dezember über abgeschalten wird, hat eine hohe Ausfallsicherheit aber ist nicht hoch verfügbar.

• Safety/Sicherheit: Definiert, wie sicher ein System im Falle eines Fehlers agiert, sodass keine größeren Schäden passieren.

Bsp: Bei einem Software Fehler in einem Atomkraftwerk sollte das System keinen Katastrophen ähnlichen Zustand annehmen.

• Integrity/Integrität: Das System soll nicht in einen ungewünschten/nicht definierten Zustand gelangen.
• Maintainability/Wartbarkeit: Gibt an, wie leicht ein System im Falle eines Fehlers repariert werden kann. Eine hohe Maintainability kann zu einer hohen Verfügbarkeit führen, da im Falle eines Fehlers dieser möglicherweise automatisch erkannt und repariert werden kann.

dependability threats:

• Fault: ist die Ursache eines Errors/Fehlers
• Error: Ein Teil des Systemzustands, welcher wegen eines Faults angenomen wurde und schlussendlich zu einem failure führen könnte
• Failure: Ein Failure tritt ein, wenn ein System durch einen Error seine Dienste nicht mehr vollständig oder überhaupt nicht mehr anbieten kann.

Faults können wie folgt klassifiziert werden:

• transient fault: Treten zufällig, jedoch nicht wiederholt auf. Bsp: Ein Vogelschwarm stört die Funkverbindung.
• intermittent fault: treten zufällig auf, verschwinden wieder, und kommen dann wieder; diese Klasse der Faults ist besonders schwer zu identifizieren. Bsp: ein loser Netzwerkstecker, welcher zu einem Wackelkontakt führt.
• permanent: Treten solange dauerhaft auf, bis die fehlererzeugende Komponente ersetzt wurde. Bsp: Hardwaredefekte, Software Bugs

Fehlermodelle und k-fault-tolerance

Frage: Wozu benötigt man Fehlermodelle ganz allgemein? Geben Sie verschiedene Fehlermodelle für "fail-controlled systems" an und diskutieren Sie diese v.a. hinsichtlich des benötigten Aufwandes für die Maskierung. Inwiefern ist es u.U. heikel zu spezifizieren, daß ein System "k-fault-tolerant" sein soll?

{{#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*Fehlermodelle und k-fault-tolerance\s*/si}}

{{FreeWarning|text= Achtung: Diese Fehlermodelle sind falsch, wie wir in der Prüfung vom 17.01.2011 leider feststellen mussten. Siehe https://web.archive.org/web/*/www.informatik-forum.at/showthread.php?85245-After-test-17.01.2011&p=690539&viewfull=1#post690539

Fehler werden in Klassen unterteilt, um die Auswirkungen besser einschätzen zu können.

• crash failure: ein server stürtzt ab und gibt keine Rückmeldungen mehr, bis er neugestartet wird. Bis der crash eingetroffen ist, arbeitet der Server korrekt
• omission failure: Ein Server antwortet nicht auf Anfragen. Das kann verschiedene Gründe haben, beispielsweise, dass er nie die Anfrage erhalten hat (receive omission). Oder der Server hat die Anfrage erhalten, beantwortet, ist aber nicht in der Lage die Antwort zu versenden (send omission)
• timing failure: Wenn eine Antwort länger als eine definierte Response-Time benötigt, spricht man von einem Timing failure
• response failure: wenn die Antwort eines Servers inkorrekt ist. Es gibt 2 Arten von response Fehlern: value failure der Server liefert eine falsche Antwort (Suchmaschine liefert webseiten, nach welchen nicht gesucht wurde); state transition failure: passieren, wenn der Server unerwartet auf eine Anfrage reagiert (z.B: ein Server erhält eine Anfrage, welche er nicht erkennen kann und daraus Aktionen startet, welche niemals passieren dürften)
• arbitrary failure/bizantine failure: ist eine sehr schwerwiegende klasse von fehlern, wenn z.b. ein Server eine Antwort liefert, welche niemals erstellt werden dürfte (die aber nicht als fehlerhaft erkannt werden kann)

Richtige Antworten für Fehlermodelle:

• fail-halt (fail-stop) system: Halting failures only. Often: halting can be detected; d.h. der Server stürzt ab und teilt das entweder vorher mit oder es ist für andere, von ihm abhängige Prozesse ersichtlich, dass er abgestürzt ist.
• fail-passive (fail-silent) system: Stuck output instead of erratic output (Silence as opposed to babbling). Often crash failures. Other processes may incorrectly conclude that a server has halted whereby the server is only unexpectedly slow!; Server crashed, aber teilt dies nicht mit (häufig!), hier ist es schwierig festzustellen, ob der Server tatsächlich down oder nur langsam ist (oder das Problem ganz woanders liegt, etwa in der Netzwerkverbindung).
• fail-consistent system: No byzantine failures.
• fail-inconsistent system: Any type of failure.
• fail-safe system: All minor failures, no catastrophic consequences expected.; Output des Systems ist falsch, kann aber von anderen Prozessen als solcher erkannt werden.

Ein System ist k-Fehler-tolerant, wenn es k Fehler verkraften, aushalten kann. Zum Beispiel ist ein Server mit 3 Netzteilen in Bezug auf diese 2-fault tolerant: 2 Netzeile können ausfallen, aber die Stromversorgung ist immer noch gewährleistet!

Hauptproblem in der Spezifikation von k-fault-tolerant liegt v.a. darin, dass man nicht ohne weiteres sagen kann, was k tatsächlich für eine Zahl ist. Kann man zB über Erfahrungswerte festlegen, aber auch das ist natürlich keine Garantie.

Aufwand für die Maskierung:

• fail-stop or fail-silent: k+1: Wenn man 3 Systeme hat und 1 fällt aus, braucht man genau 1 weiteres um es zu ersetzen, wenn man weiß, dass es down ist.
• fail-passive (fail-consistent) with or w/o distributed agreement: 2k+1: Wenn man 3 Systeme hat, eines abstürzt dies aber nicht mitteilt, braucht man 2 Systeme, die eine Mehrheit liefern.
• arbitrary (malicious, two-faced, byzantine) without distributed agreement: 2k+1: Wie fail-passive - wenn man 3 Systeme hat, eines davon lügt, und man schaut sich die Ergebnisse der drei nachher an, braucht man mindestens 2 um zu sagen, was das korrekte Ergebnis ist
• byzantine (arbitrary failures, malicious, two-faced) with distributed agreement: 3k+1: Hat man 3 Systeme, bei denen das Ergebnis von einem oder mehreren Systemen davon abhängt, wie die anderen entscheiden, kann man mit 3 kein garantiert korrektes Ergebnis finden -> man braucht min. 4 (siehe hierzu #"Byzantinische Generäle" )
• It is therefore wise to provide enough errordetection logic inside a component to guarantee failsilent behaviour at the system level!

Redundanz

Frage: Wieso benötigt man Redundanz zur Maskierung von Fehlern? Welche Arten von Redundanz gibt es?

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

Um auch in der Zwischenzeit, während ein Fault vorhanden ist, fehlerfreies Verhalten garantieren zu können, sind Redundanzen notwendig. Diese können entweder zeitlich (z.B. mehrmalige Übertragung wie bei TCP), datentechnisch (Prüfsummen, Hamming-Distanzen, etc.) oder physikalisch (doppelte Ausführung eines Servers wie z.B. im DNS) realisiert sein. Im Falle von physikalischen Redundanzen kann man unterscheiden ob die redundanten Systeme ständig im Gesamtsystem mitlaufen (aktiv) oder nur im Falle eines Faults angekoppelt werden (passiv). Bei passiven Systemen kann weiter unterschieden werden ob die (nicht angeschlossenen) redundanten Teile nebenbei mitlaufen (hot standby) oder komplett abgeschaltet sind (cold standby). Ein Beispiel für eine redundante Systemarchitektur ist Triple Modular Redundancy (TMR).Ein Schaltkreis, bei dem jedes Element einer sequentiellen Aneinanderreihung von Komponenten 3 Mal ausgeführt wird. Als Input bekommt jedes Element das (von einem Voter ermittelte) Mehrheitsergebnis der vorherigen Komponente. Die Voter müssen, da diese selbst fehlerhaft sein können, ebenfalls repliziert sein. So kann bei einem fehlerhaften Komponent, ausgeglichen werden, ohne das das System den Fehler mitbekommt.

TMR am Beispiel:

---

alternative Antwort (absätze aus dem deutschen buch)

Wenn ein System fehlertolerant sein soll, kann es versuchen, das Auftreten von Ausfällen vor anderen Prozessen zu verbergen. Die Schlüsseltechnik hierfür ist die Verwendung drei verschiedener Arten von Redundanz:

Für Informationsredundanz werden zusätzliche Bits zur ursprünglichen Nachricht um eine Wiederherstellung durcheinandergeratener Bits zu ermöglichen. Beispielsweise kann ein Hamming-Code zu den übertragenen Daten hinzugefügt werden, um Störungen durch Rauschen auf der Übertragungsleitung wiederherstellen zu können.

Bei zeitlicher Redundanz wird eine Aktion ausgeführt und dann, falls erforderlich, wiederholt. Dieser Ansatz eignet sich für Störungen die vorübergehend oder wiederkehrend auftreten. Transaktionen verwenden diesen Ansatz. Wenn eine Transaktion abgebrochen wird, kann sie wiederholt werden.

Bei technischer Redundanz, werden dem System zusätzliche Prozesse oder Komponenten hinzugefügt, damit das System als Ganzes den Verlust oder Fehlerfunktion bestimmter Komponenten kompensieren kann. Zum Beispiel hat eine Boeing 747 4 Triebwerke, kann aber mit 3 fliegen.

"Two-army" Problem

Frage: Erläutern Sie die Aussage des "two-army" Problems.

{{#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*"Two-army" Problem\s*/si}}

Im two-army Problem geht es darum, dass mit unzuverlässiger Kommunikation 2 Prozesse nicht zu einem gemeinsamen Konsens kommen können.

Die Annahme dieses Problems ist, dass es eine rote und eine blaue Armee gibt. Die blaue Armee, bestehend aus 2 Generälen, an verschiedenen Orten, möchte sich einen Angriffzeitpunkt ausmachen. So wird eine Nachricht mittels eines Boten von General A zu General B geschickt, wann dieser Angriff erfolgen soll. General B bekommt die Nachricht und schickt sie an A zurück. A bemerkt, dass B nicht weiß, ob die Nachricht bei A angekommen ist und so möglicherweise nicht angreift. Deswegen schreibt A zurück an B, welcher sich bei Erhalt der Nachricht denkt, dass A nicht sicher weiß, ob die Nachricht angekommen ist. So werden lauter Nachrichten verschickt, es gibt bei unsicheren Verbindungen (der Bote in diesem Fall) keine Sicherheit über den Erhalt der Nachricht und somit keine letzte Nachricht, und damit auch keine Übereinkunft.

//Anm. koDiacc. Etwas ausführlicher & anschaulicher erklärt ist das Problem hier: https://web.archive.org/web/20180817172257/http://www.damon4.com/ Ich habs aus der Beschreibung die hier im Wiki stand nicht sofort kapiert :)

"Byzantinische Generäle"

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):

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.

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

Fehler in RPC

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.

Reliable/Orderd Multicast

Frage: Was versteht man unter reliable bzw. ordered multicast (group communication) in statischen Gruppen von Prozessen? Was muss man bedenken, wenn sich die Gruppen dynamisch verändern können? Erläutern Sie das Prinzip des "atomic multicast" ("virtual synchrony").

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

Diese Services garantieren, dass Nachrichten an alle Mitglieder einer Prozessgruppe gesendet werden.

Meistens wird eine gesicherte point-to-point Verbindung von der Transportschicht bereit gestellt. Schwieriger ist es allerdings ein gesichertes Multicasting anzubieten. Eine Nachricht die zu einer Prozessgruppe gesendet wird, soll jedes Mitglied dieser Gruppe erreichen. Es müssen aber auch Situationen abgedeckt sein, wie das crashen eines Mitglieds, das hinzukommen eines neuen und dass alle Mitglieder die Nachrichten in der gleichen Reihenfolge erhalten. Um die Ordnung einzuhalten kann eine Sequenznummer an die Nachrichten angehängt werden.

Ein Hauptproblem bei Multicasting ist die Unterstützung von vielen Empfängern. Gibt es N Empfänger, kommen in der Regel auch N Acknowledgements zurück, dadurch kann der Sender "überschwemmt" werden. Eine Möglichkeit ist, dass Empfänger den Sender nur informieren, wenn sie eine Nachricht nicht erhalten haben. Aber in diesem Fall wird der Sender die Nachrichten nicht ewig speichern, sondern sie nach einer gewissen Zeit löschen.

Es muss einstimmig klar sein, wie eine Gruppe aussehen muss, damit eine Multicastnachricht gesendet werden darf.

Ordered Multicast

Ein multicast ist ordered, wenn sichergestellt ist, dass alle abgesendeten Nachrichten, jeden einzelenen Knoten in exakt derseleben Reihenfolge erreichen.

Es gibt 4 verschiedene Arten Multicasts zu ordnen:

• Unordered Multicasts

• FIFO ordered Multicasts

• Causally ordered Multicasts

• Totally ordered Multicasts

Atomic Multicast

Meistens ist es nötig zu garantieren, dass Nachrichten entweder alle Empfänger erhalten oder keiner von ihnen und dass die Nachrichten bei allen in der gleichen Reihenfolge ankommen. Das wird "Atomic Multicast Problem" genannt.

Bsp.: An eine Gruppe von Prozessen werden Mutlicast Update-Nachrichten verschickt. Ein Replica crasht. Das Update wurde aber auf den anderen Replicas trotzdem durchgeführt. Wenn das Replica wieder aktiv wird, wird es einige Updates vermissen. Bei Atomic Multicast wird das Update erst durchgeführt, wenn alle anderen Mitglieder sich einig sind, dass das abgestürzte Replica nicht mehr Teil der Gruppe ist. Wenn es wieder aktiv wird, bekommt es keine Updates, bis es sich wieder als Mitglied registriert hat und somit alle Daten von einem anderen System geholt hat.

Virtual Synchrony

Ist eine strengere Form/Art von Atomic Multicast:

Es wird garantiert, dass jede Nachricht zu jedem nicht-fehlerhaften Prozess gesendet wird. Wenn der Sender der Nachricht beim Multicasting crasht, wird die Nachricht entweder zu allen Prozessen übertragen oder von allen ignoriert. Das Prinzip von Virtual Synchrony kommt daher, dass alle Multicasts zwischen view-changes passieren. Unter einem View-Change versteht man eine Nachricht die alle Mitglieder der Gruppe, über das kommen oder gehen eines Mitgliedes informiert. Ein View-Change verhält sich wie eine Barriere, durch die kein Multicast durch kann.

Beispiel zu Virtual Synchrony:

• Es existieren 3 Prozesse die folgende Gruppensicht darstellen G(P1,P2,P3)
• Es wird eine Multicast Nachricht m von P1 mit der Gruppenansicht G versendet (sprich m wird an P2 und P3 versendet)
• Zusätzlich wird angenommen, dass ein Prozess die Gruppe betritt/verlässt. Daraus folgt eine Änderung der Gruppensicht (View Change), welche durch das senden einer Multicast Nachricht vc verteilt wird.
• D.h. wir haben jetzt zwei Multicast Nachrichten die gleichzeitig übertragen werden.
• Was ist zu tun: Es muss sichergestellt werden, dass entweder m an alle Gruppenmitglieder ausgeliefert wird bevor diese vc erhalten ODER m an keinen ausgeliefert wird.
• Grundsätzlich: Es gibt nur einen Fall wo das Übertragen von m fehlschlagen darf: Wenn der Sender des Multicast m (in unserem Fall also P1) abstürzt!

Security

• Buch: Kap. 9, 12.8

Habe jetzt die Reihenfolge der Fragen auf die des neuen Fragenkatalogs (Stand. 13.04.2009) geändert.

Security Threats

Frage: Erläutern Sie die Definition von Security mit den Attributen Availability, Confidentiality und Integrity anhand von Beispielen. Beschreiben Sie jeweils vier Security Threats und Security Mechanisms.

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

Security Attribute:

• Availability: Die Wahrscheinlichkeit, dass ein Service zu einem beliebigen Zeitpunkt verfügbar ist

• Confidentiality: Es dürfen nur berechtigte Benutzer oder Prozesse Zugriff auf ein System und die darin gespeicherten Daten haben

• Integrity: It is the charactaristic that alterations to a system's asserts can be made only in an authorized way. In other words, improper alterations in a secure computer system should be detectable and recoverable. Major assets of a computer system are its hardware, software and data.

Es gibt folgende security threats:

• Lauschangriff "Interception" (Unauthorisierter Zugriff)
• Unterbrechung "Interruption" (File ist beschädigt oder verloren - Services oder Daten sind nicht mehr zugänglich bzw unbrauchbar)
• Modifizierung "Modification" (Unauthorisierte Änderung von Daten)
• Erzeugung "Fabrication" (Zusätzliche Daten werden generiert, die normalerweise nicht existieren würden. Ein Eindringling legt laufend fehlerhafte Daten an um das System zu blockieren.) ==> dagegen Authentifizierung/Autorisierung

Security Mechanismen (dienen zur "Umsetzung" von Security Policies):

• Encryption: Verschlüsselt Daten, damit sie ein Attackierender nicht verstehen kann.

• Authentication: Wird verwendet um die Identität eines Users, Clients, Servers oder Hosts zu verifizieren.

• Authorization: Wird verwendet um festzustellen, ob der Client eine bestimmte Aktion durchführen darf.

• Auditing: Wird verwendet um festzuhalten, welcher Client worauf zugegriffen hat und wie.

(Security Policies hingegen beschreiben nur, welche Aktionen eine Entität in einem System durchführen darf)

SSL

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

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

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

Der Ablauf ist wie folgt:

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

Cryptography / Symmetrische & Asymmetrische Verschlüsselung

Frage: Geben Sie eine Definition für "Cryptography" an und erläutern Sie die Funktionsweise von symmetrischen und asymmetrischen Verschlüsselungsverfahren. Gehen Sie dabei auch auf die spezifischen Vor- und Nachteile ein und geben Sie konkrete Beispiele für Algorithmen an.

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

Definition (Übersetzt aus der Definition in den Folien):

Kryptographie bezeichnet mathematische Techniken, die in Beziehung mit Aspekten der Informationssicherheit stehen, wie etwa:

• Confidentiality
• Integrity
• Authetication
• Non-repudiation

Fest verbunden mit dem Begriff Sicherheit in verteilten Systeme ist der Begriff der Kryptographie. Sie befasst sich im Prinzip mit dem Ver- und Entschlüsseln von Daten. Sie wird auch als Technik des "Versteckens" von Information bezeichnet. Es geht also darum, dass ein Sender seine Nachricht verschlüsselt (encrypt) und den verschlüsselten Text (ciphertext) an den Empfänger schickt, welcher diesen dann wieder entschlüsseln (decrypt) kann um auf den Plain-Text zu kommen.

Bei symmetrischer Verschlüsselung verwenden beide Kommunikationspartner den gleichen Schlüssel zur Ver- und Entschlüsselung. Es müssen Information und Schlüssel gleichzeitig verschickt werden. Es ist also notwendig den Schlüssel über einen sicheren Kanal zu senden.

• Vorteil: schneller als Asymmetrische Verschlüsselung
• Nachteile:
  • der Schlüssel muss geheim gehalten werden
  • es werden N(N-1)/2 Schlüssel benötigt und jeder Host muss N-1 Schlüssel verwalten ==> KDC (wächst exponentiell) (EDIT: N(N-1)/2 wächst doch eher quadratisch...)
• Bsp: Blowfish, DES (Data Encryption Standard, Wegen der geringen Schlüssellänge von 56 Bit wird aus Sicherheitsgründen eher das Triple DES gewählt) Anm.: Ich denke weder DES noch Triple DES kann auch nur irgendwie als sicher beschrieben werden. Anm. 2: "DES is now considered to be insecure for many applications." (Quelle: Wikipedia)

Bei asymmetrischer Verschlüsselung hat jeder Partner einen Schlüssel zum Ver- und einen zum Entschlüsseln. Der zum Verschlüsseln ist öffentlich, der zum Entschlüsseln privat. Die beiden Schlüssel sind unterschiedlich bilden aber zusammen ein eindeutiges Paar - dh, wenn eine Nachricht mit dem public Key von A verschlüsselt wurde, so kann diese NUR A mit seinem private Key entschlüsseln.

• Vorteil:
  • nur eine Person kann die Nachricht wieder entschlüsseln (Sicherheit)
  • Schlüsselverteilung einfach, da Public Key eigentlich nutzlos für Angreifer
  • Schlüsselanzahl wächst linear
• Nachteil:
  • viel langsamer
  • jeder hält trotzdem noch immer seine eigenen 2 (public + private) + die public keys der N-1 anderen Teilnehmer ==> KDC (kann jetzt nicht als Nachteil gesehen werden)
• Bsp: RSA (verwendet für Verschlüsselung und digitale Signatur)

Um die Vorteile beider Verfahren zu nutzen gibt es hybride Verfahren, bei denen mittels asymmetrischer Verschlüsselung ein symetrischer Schlüssel, ein sogenannter Session Key, ausgetauscht wird.

Secure Channel

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.

Symmetrische Authentifizierung

Frage: Erklären Sie, wie sich zwei Kommunikationsteilnehmer basierend auf symmetrischen Schlüsseln gegenseitig authentifizieren können. Zeigen Sie auch auf, welche Probleme entstehen können, wenn ein Protokoll falsch "optimiert" wird.

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

Zur Auflockerung: https://web.archive.org/web/20180817172259/https://xkcd.com/177/

• 1 : Alice sendet ihre Identität an Bob um einen Kommunikationskanal zu eröffnen.

• 2 : Bob Sendet eine Aufforderung Rb an Alice (Kann z.B. eine Zufallszahl sein)

• 3 : Alice verschlüsselt es mit dem secret Key Kab (den sie mit Bob teilt) und schickt die Nachricht an Bob. Bob kann die Nachricht entschlüsseln und festzustellen, ob sie Rb enthält, wenn das der Fall ist, weiß er, dass Alice an der anderen Seite sitzt. Alice weiß aber noch nicht, dass es sich sicher um Bob handelt auf der anderen Seite.

• 4 : Alice sendet eine Aufforderung Ra an Bob.

• 5 : Bob sendet Kab(Ra) zurück.

Diese Reduzierung ist sehr unsicher und kann leicht zu einer Reflection Attack führen.

Reflaction Attack: Chuck gibt sich als Alice aus. Er lässt Bob die Nachricht selbst in einem zweiten Kanal verschlüsseln.

Digitale Signatur

Frage: Was ist eine digitale Signatur, welche Garantien bietet sie und wie funktioniert sie? Was ist eine Hash Funktion und welche Eigenschaften muss sie erfüllen, damit sie im Rahmen einer digitalen Signatur eingesetzt werden kann.

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

Digitale Signatur Eine digitale Signatur ist ein Anhang an eine Nachricht, die die Authentizität des Absenders A (Garantie, dass die Nachricht tatsächlich von A gesendet wurde) dem Empfänger B der Nachricht bestätigt und aber auch gleichzeitig eine Veränderung der Nachricht verhindert, da die Signatur eindeutig an den Inhalt der Nachricht gebunden ist.

Funktionsweise der digitalen Signatur: Von einer zu signierenden Nachricht wird der Hashwert gebildet. Dieser Hashwert wird mit dem privaten Schlüssel des Absenders A verschlüsselt (das ist die Signatur) und an die Nachricht angehängt. Der Empfänger der Nachricht bildet wiederum den Hashwert und entschlüsselt die Signatur mit dem öffentlichen Schlüssel des Absenders. Wenn die beiden Hashwerte überein stimmen, so kann man davon ausgehen, dass die Nachricht tatsächlich vom Absender A stammt und unverändert ist.

Hashfunktion Eine Hashfunktion H() bestimmt von einer Eingabe m einen Wert h konstanter Länge. Dieser Wert wird Hashwert genannt. Folgende Eigenschaften muss/sollte eine gute Hashfunktion erfüllen:

• keine Umkehrungfunktion H'(), die es erlaubt den Eingabewert m anhand des Hashwertes h zu bestimmen. (Hashfunktion sind Einwegfunktionen)
• Strong collision resistance. It is hard to find any x and y such that H(x) = H(y).
• Die Länge des Hashwertes soll immer gleich sein, und unabhängig von der Länge des Plain Textes.

Key Distribution Centre (KDC)

Frage: Was ist ein Key Distribution Centre (KDC), wozu wird es eingesetzt und welchen Vorteil bietet es? Geben Sie ein konkretes Verfahren zur gegenseitigen Authentifizierung von Kommunikationsteilnehmern mit Hilfe eines KDC an und beschreiben Sie für jeden Schritt, wer sich wem gegenüber bereits authentifiziert hat.

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

Eines der größten Probleme bei Shared Secret Key Authentications ist die Skalierbarkeit der Systeme. Es müssen einfach zu viele Schlüssel gewartet werden. Bei N Hosts im System muss jeder der Hosts mit N-1 anderen einen Secret Key teilen. Im System gibt es dann N(N-1)/2 Schlüssel und jeder Host muss N-1 warten.

Eine Alternative dazu (zur "Schlüsselwartung") stellt das KDC dar (Key Distribution Center). Es teilt einen Secret Key mit jedem Host aber die Hosts untereinander müssen keine Secret Keys mehr teilen. Es müssen also nur noch N Keys gewartet werden.

Authentifizierung mit KDC:

Die Grundidee ist folgende: das KDC händigt jedem der Teilnehmer einen Key aus, mit dem diese dann untereinander kommunizieren können.

Ablauf:

1. Alice sendet eine Message an das KDC wo sie bekannt gibt, mit wem sie sprechen will
2. das KDC retouniert einen Shared Secret Key Ka,b an Alice und Bob, welcher mit dem Secret Key des jeweiligen Empfängers verschlüsselt wurde

Hierbei gibt es nur ein Problem: Alice könnte den Schlüssel schon bekommen haben und eine Kanal zu Bob aufmachen, obwohl dieser den Schlüssel noch nicht hat (oder noch nicht dazu bereit ist). Abhilfe schafft folgendes angepasste Protokoll.

Hierbei erhält Bob nicht vom KDC sondern von Alice seinen Schlüssel übermittelt. Dieser Ansatz wird als Ticketing bezeichnet (die Message Kb,kdc(Ka,b) ist das Ticket). Auch hier kann nur Bob etwas mit dem Ticket anfangen, da nur er den Private Key zum Entschlüsseln hat.

Ein konkretes Protokoll für die Authentifizierung, welches nun diesen Ansatz verwendet, ist das Needham-Schroeder-authentication protocol.

Ablauf:

1. Alice sendet eine Challenge Ra1 und die Teilnehmerdaten an das KDC. Ra1 ist hierbei eine sog. nonce - eine zufällige Nummer die nur einmal verwendet wird, um 2 Nachrichten miteinander in Relation zu setzen. Wenn Ra1 nicht in Message 1 gewesen wäre, so könnte Alice die Antwort 2 nicht deuten bzw nicht korrekt deuten, da diese Nachricht von einer alten Anfrage stammen könnte.
2. das KDC liefert das Ticket retour und den Secret Key Kab für die Kommunikation mit Bob. In der Message ist auch B enthalten was gemacht wird, um einen eventuellen Eindringling nicht die Möglichkeit zu geben, die Kommunikation zu verhindern. Annahme: Eindringling C modifiziert Message 1 und gibt statt B seine Identität C mit. Ohne B in der Return-Message wüsste A dann nicht, ob nun wirklich mit B kommuniziert wird.
3. nun kann der Channel aufgebaut werden, indem das Ticket an Bob geschickt wird. Hierfür wird wieder eine neue nonce verwendet: Ra2
4. Bob liefert nun Ra2-1 retour. Damit weiß Alice, dass Bob einerseits die Nachricht genau entschlüsseln konnte und andererseits auch, dass die Return Message zur Message 3 gehört. Mit dem -1 weiß Alice aber auch, dass Bob die Challenge lesen konnte, die ja mit dem Shared Key Kab verschlüsselt wurde (wäre aber nicht notwendig)
5. als letztes muss nun nur noch Alice Bob zeigen, dass sie auch in der Lage ist seine Challenge zu entschlüsseln indem sie ihm die Challenge - 1 verschlüsselt retour sendet

Alte Fragen

Diffie-Hellman Schlüsselaustausch

Frage: Erklären Sie wie der Diffie-Hellman Schlüsselaustausch funktioniert und geben Sie ein Beispiel an. Ist Diffie-Hellman ein Public-Key oder ein Shared Key Cryptosystem? Erklären Sie Ihre Antwort.

{{#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*Diffie-Hellman Schlüsselaustausch\s*/si}}

Diffie-Hellmann wird für unsichere (abhörbare) Kommunikationswege benützt, da der eigentliche Schlüssel nie übertragen wird.

1. A erzeugt große zahlen n und g (welche dann public gemacht werden)
2. A erzeugt große Zufallszahl X
3. A sendet an B n,g, g^x mod n (B berechnet sich daraus g^xy mod n)
4. B erzeugt große Zufallszahl Y
5. B schickt an A g^y mod n (A berechnet sich daraus g^xy mod x)

A sowie B können durch g^(xy) mod n entschlüsseln.

Ist ein Public-Key prinzip da man g^x mod n als public und x als private -Key sehen kann.

Public oder Shared Key?

Frage: Sie arbeiten in einer Bank. Ihr Chef sagt, dass Sie die Netzwerkkommunikation verschlüsseln müssen weil man nicht will, dass man wichtige Kundeninformationen abhört. Würden Sie ein Public-Key oder ein Shared Key Verfahren für die Verschlüsselung einsetzen? Erklären Sie Ihre Antwort.

{{#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*Public oder Shared Key\?\s*/si}}

Wenn es nur um "Abhörsicherheit" geht und ein sicherer Kanal besteht um die Keys auszutauschen (innerhalb _einer_ Bank könnte man das wohl noch von Hand machen) sind wohl shared keys besser.

• leichter zu implementieren (zb.: kein PKI)
• Sym. zu Asym ist Faktor 10^3 schneller
• Features von Public Key Verfahren wie Signaturen etc. werden nicht benötigt

Kaputter Mailserver

Frage: Sie sind Netzwerkadministrator und bemerken, dass der Mail Server nicht mehr funktioniert, weil ein Angreiffer eine sehr hohe Anzahl an Requests schickt. Klassifizieren Sie diese Attacke anhand des Security Threat Models im Buch.

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

Es gibt:

• Lauschangriff "Interception" (Unauthorisierter Zugriff)
• Modifizierung "Modification" (Unauthorisierte Änderung von Daten)
• Unterbrechung "Interruption" (File ist beschädigt oder verloren)
• Erzeugung "Fabrication" (Zusätzliche Daten werden generiert, die normalerweise nicht existieren würden)==> dagegen Authentifizierung/Autorisierung

Kevin, 15.1.2010: imho ist das eine DoS, also eine Interruption (Availability eines Dienstes wird eingeschränkt)

Schwachstellen in DES

Frage: Geben Sie zwei mögliche Schwachstellen des DES (Data Encryption Standard an).

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

• Heutzutage sind wegen der kurzen Schlüssel (56 Bit) Brute Force Attacken (Alle Möglichkeiten werden durchprobiert) möglich
• Verwendet man andere als die ursprünglich designten S-Boxen, so verliert DES sehr schnell seine Sicherheit (Weil das System aus Sicheitsgründen nie vollständig beschrieben wurde)

Sicherheitspolitik vs. Sicherheitsmechanismen

Frage: Wodurch unterscheidet sich Sicherheitspolitik (security policy) von Sicherheitsmechanismen (security mechanisms)? Zählen Sie auch die wichtigsten Mechanismen auf.

{{#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*Sicherheitspolitik vs. Sicherheitsmechanismen\s*/si}}

Security policies sind eine Beschreibung der geforderten Schutzmaßnahmen. Darin steht etwa, wer auf welche Services zugreifen darf.

Security mechanisms sind eine Menge von technischen Maßnahmen zur Realisierung der Security policies, z.B. Encryption, Authentification, Authorization und Auditing.

Zertifikate

Frage: Wozu benötigt man bei einem asymmetrischen Verschlüsselungsverfahren (public key crypto system) Zertifikate (certificates)? Wozu wird eine Zertifizierungsstelle (certification authority) benötigt?

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

Ein Zertifikat bestätigt die Zuordnung eines Public Keys zu einer Person. Sie werden von sogenannten Certification Authorities ausgestellt. Dazu wird Identität einer Person, Public Key und ein Timestamp in ein Zertifikat zusammengefasst, das von der Certification Authority signiert wird.

MD5

Frage: Im Buch ist MD5 definiert als "A hash function for computing 128-bit, fixed length message digest from an arbitrary length binary input string". Wie gross ist die Wahrscheinlichkeit, dass zwei Input Strings die selbe MD5 Wert liefern?

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

moegliche Quelle - nicht sicher ?!?

Einige grundlegende Überlegungen zu deinem Problem:

• MD5 ist eine bis dato nicht geknackte Hashfunktion mit einer Hashgröße von 128 bit. Update
• Nehmen wir an, MD5 wäre eine ideale Hashfunktion, d.h. für beliebigen Input kommt jeder Output mit gleicher Häufigkeit vor (dies ist inkorrekt, aber hier kein prinzipieller Fehler).
• 128 bits entsprechen 2^128 = 3*10^38 (!!) Möglichkeiten. Wenn du also versuchst, für einen Hash x einen Input y zu erraten, ist der mit einer Wahrscheinlichkeit von 1/(3*10^38) korrekt.
• Ein moderner Prozessor schafft in einem nicht überdurchschnittlich gut optimierten Programm auf einem Prozessorkern eine Million MD5-Hashes pro Sekunde.

Wkt: 1/2^128

RSA

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

Zusammenhang Dependability Security

Frage: Wie hängen Dependability und Security zusammen? Warum kann man sie nicht einzeln betrachten, sonden muss Sie integriert betrachten. Man sollte auch irgendwelche Attribute (waren nicht gegeben) zu den 2 zuordnen.

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

Technology Overview

• Buch: 10.1.2, Überblick Kap. 12 und 13

Koordinationsmodelle

Frage: Ordnen Sie in der folgenden Taxonomie den vier Typen von Koordinationsmodellen jeweils zwei konkrete Techniken, Beispiele oder Systeme zu.

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

Grafik zur Fragestellung:

		Temporal
		Coupled	Uncoupled
Referential	Coupled	(a) Direct	(b) Mailbox
	Uncoupled	(c) Meeting oriented	(d) Generative Communication

Erklärung:

Bei der koordination geht es um die Koordination zwischen Prozessen.

Referential bedeutet: explizite Referenz in Kommunikation (z.B.: die kommunikation kann nur entstehen, wenn der Prozess die Identität des anderen Prozesses kennt).

Temporal bedeutet: Beide Prozesse müssen laufen.

(c): Nachrichten werden an Subscriber geschickt, die online sind. Mir fällt dazu gerade kein Beispiel ein

Antwort: (Ergänzt nach den Folien)

		Temporal
		Coupled	Uncoupled
Referential	Coupled	(a) TCP/Telefon; RPC/RMI/Transient Message Passing	(b) Mail/Brief/SMS; Peristant message passing
	Uncoupled	(c) CSS ???; TIB/Rendevous, Publish/Subscribe, event & subject-based, "ad hoc"-communication	(d) Jini/Linda; tuple spaces; peristant DSM; associative; JavaSpaces

Publish/Subscribe

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??]

Webserver/HTTP/CGI

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)

Alte Fragen

EAI

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?

Begriffe / Erklärungen

Hier sollen kurze Begriffe, die immer wieder auftauchen erklärt werden, um das Verständnis des Gesamtstoffes zu verbessern.

Socket

Ein Socket ist im Wesentlichen ein Kommunikationsendpunkt von welchem eine Anwendung lesen (Daten die vom Netzwerk hereinkommen) und darauf schreiben (Daten, die an das Netzwerk gesendet werden sollen) kann. Ein Socket ist also eine Abstraktion über dem eigentlichen Kommunikationsendpunkt, der vom OS für ein spezielles Transport Protokoll verwendet wird.

Um auf Socket lesen und schreiben zu können, gibt es folgende Operationen:

• Socket : erstellt einen neuen Kommunikationsendpunkt
• Bind : bindet eine lokale Adresse an den Socket
• Listen : hört auf eingehende Verbindungen
• Accept : blockiert den Aufrufer bis eine Connection aufgebaut wird (siehe zB Java ServerSocket.accept())
• Connect : aktiver Versuch eine Verbindung herzustellen
• Send : sendet Daten über die Verbindung
• Receive : empfängt Daten
• Close : schließt die Verbindung

Serverprogramme führen üblicherweise die ersten 4 dieser Befehle aus, um Verbindungen annehmen zu können. Clients müssen zwar ebenfalls einen Socket erstellen, müssen diesen aber nicht explizit binden.

Object / Distributed Object

Ein Objekt besteht im Wesentlichen aus den Daten, die es hält - sein Zustand und den Operationen, die auf diese Daten durchgeführt werden können - den Methoden. Diese Methoden sind über das Interface, welches das Objekt definiert verfügbar. Es gibt laut dem objektorientierten Ansatz keinen anderen Weg als die Daten (den Zustand) eines Objektes über die dafür vorgesehenen Methoden zu ändern. Wie ein Objekt mehrere Interfaces implementieren kann, so kann es auch mehrere unterschiedliche Objekte geben, die ein und das selbe Interface implementieren.

Eine charakteristische aber nicht sofort intuitive Eigenschaft von den meisten verteilten Objekten ist, dass ihr Zustand nicht verteilt ist, sondern auf einem einzelnen Computer liegt. Nur die Interfaces, die vom Objekt implementiert werden sind auf anderen Rechnern verfügbar. Solche Objekte werden auch Remote Objekte genannt. In einem allgemeinen verteilten Objekt könnte der Zustand selbst auch physisch über mehrere Rechner verteilt sein aber diese Verteilung ist vor den Clients hinter den Interfaces des Objektes versteckt.

Veränderungen können nur über Remote Interfaces (Proxy des Objektes) durchgeführt werden. Dieser Proxy reicht alle Änderungen an das Skeleton des Servers weiter, welches dann die eigentlichen Änderungen durchführt.

Object server

siehe Objektserver