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

Remote Procedure Call

{{#lsth:TU Wien:Verteilte Systeme VO (Göschka)/Fragenkatalog Wiki|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

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

Location Service

{{#lsth:TU Wien:Verteilte Systeme VO (Göschka)/Fragenkatalog Wiki|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.

Bully- und Ring-Algorithmus

{{#lsth:TU Wien:Verteilte Systeme VO (Göschka)/Fragenkatalog Wiki|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.

Frage 4...

Nicht aus dem Fragenkatalog, bitte Ergänzen

Secure Channel

{{#lsth:TU Wien:Verteilte Systeme VO (Göschka)/Fragenkatalog Wiki|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.