Präsentation herunterladen
Die Präsentation wird geladen. Bitte warten
Veröffentlicht von:Elfi Heidorn Geändert vor über 10 Jahren
1
Verteilte Algorithmen und Datenstrukturen
Christian Scheideler Institut für Informatik Universität Paderborn
2
Verteilte Algorithmen und Datenstrukturen
Vorlesung: Mi Uhr, F0.530 Übung: Mi Uhr, F0.530 Webseite: Prüfung: 50%: Softwareprojekt 50%: mündliche Prüfung Notenverbesserung um 0,3: Präsentation in Übung Voraussetzungen: Grundkenntnisse in Algorith-men und Datenstrukturen
3
Verteilte Algorithmen und Datenstrukturen
Übungsaufgaben: wöchentliche Ausgabe und Abgabe am Mittwoch teils theoretisch, teils praktisch Skript und Übungsaufgaben: Webseite Bücherempfehlungen: kein Buch (Vorlesung basiert auf neuesten Ergebnissen)
4
Verteilte Algorithmen und Datenstrukturen
Inhalt: Einführung Netzwerktheorie Routing und Scheduling Hashing und Caching Verteilter Konsens und Transaktionen Dynamische Netzwerke für Zusammenhang (Cliquen, Cliquegraphen und Expander) Dynamische Netzwerke für Routing (Verankerte und dezentrale Netzwerke) Verteilte Datenstrukturen Drahtlose Netzwerke
5
Einführung Übersicht: Motivation Was ist Robustheit?
Das Subjects Paradigma (Grundlage für verteilte Programme) Die Simulationsumgebung Beispiele
6
Einführung Sequentielle Algorithmen und Datenstrukturen
Verteilte Algorithmen und Datenstrukturen
7
Was sind Kernprobleme für verteilte Systeme?
Einführung Was sind Kernprobleme für verteilte Systeme?
8
Verteilte Systeme Jedes verteilte System benötigt einen zusammenhängenden Wissensgraph über die Teilnehmer. Solch ein Graph: Overlaynetzwerk
9
Verteilte Algorithmen und Datenstrukturen
Inhalt: Einführung Netzwerktheorie Routing und Scheduling Hashing und Caching Verteilter Konsens und Transaktionen Dynamische Netzwerke für Zusammenhang (Cliquen, Cliquegraphen und Expander) Dynamische Netzwerke für Routing (Verankerte und dezentrale Netzwerke) Verteilte Datenstrukturen Drahtlose Netzwerke
10
Verteilte Systeme Skalierbares Overlaynetzwerk:
Hoher Durchsatz an Nachrichten Jede Nachricht benötigt nur geringe Zeit
11
Verteilte Algorithmen und Datenstrukturen
Inhalt: Einführung Netzwerktheorie Routing und Scheduling Hashing und Caching Verteilter Konsens und Transaktionen Dynamische Netzwerke für Zusammenhang (Cliquen, Cliquegraphen und Expander) Dynamische Netzwerke für Routing (Verankerte und dezentrale Netzwerke) Verteilte Datenstrukturen Drahtlose Netzwerke
12
Verteilte Systeme Skalierbares Speichersystem:
Hoher Durchsatz an read/write Operationen Jede Operation benötigt nur geringe Zeit
13
Verteilte Algorithmen und Datenstrukturen
Inhalt: Einführung Netzwerktheorie Routing und Scheduling Hashing und Caching Verteilter Konsens und Transaktionen Dynamische Netzwerke für Zusammenhang (Cliquen, Cliquegraphen und Expander) Dynamische Netzwerke für Routing (Verankerte und dezentrale Netzwerke) Verteilte Datenstrukturen Drahtlose Netzwerke
14
Verteilte Systeme In offenen verteilten System kann sich die Menge der Teilnehmer stark mit der Zeit verändern. Problem: wie erhalten wir die Funktionalität eines verteilten Systems??
15
Verteilte Systeme Drei grundlegende Ansätze: server-basiert verankert
peer-to-peer strukturierte Overlaynetzwerke
16
Verteilte Algorithmen und Datenstrukturen
Inhalt: Einführung Netzwerktheorie Routing und Scheduling Hashing und Caching Verteilter Konsens und Transaktionen Dynamische Netzwerke für Zusammenhang (Cliquen, Cliquegraphen und Expander) Dynamische Netzwerke für Routing (Verankerte und dezentrale Netzwerke) Verteilte Datenstrukturen Drahtlose Netzwerke
17
Verteilte Datenstrukturen
Transparente Datenstrukturen: Verteilte Hashtabelle Verteilte Suchstrukturen Verteilter Heap Transparenz: keine extra Links notwendig
18
Verteilte Systeme Korrektheit, Skalierbarkeit, Robustheit,...
19
Verteilte Algorithmen und Datenstrukturen
Inhalt: Einführung Netzwerktheorie Routing und Scheduling Hashing und Caching Verteilter Konsens und Transaktionen Dynamische Netzwerke für Zusammenhang (Cliquen, Cliquegraphen und Expander) Dynamische Netzwerke für Routing (Verankerte und dezentrale Netzwerke) Verteilte Datenstrukturen Drahtlose Netzwerke
20
Verteilte Systeme Robustheit:
Operationen arbeiten korrekt selbst unter massiven Angriffen System kann sich selbständig erholen
21
Fundamentales Dilemma
Skalierbarkeit: Minimiere Ressourcen für Operationen Robustheit: Maximiere Ressourcen für Angriffe Trotzdem erstaunlich gute Lösungen möglich Skalierbare Systeme leicht zu attackieren!!
22
Konsensus 5 3 8 2 3 3 3 3
23
Konsensus Modell: n Spieler Jeder Spieler kennt alle anderen
Zeit verläuft in synchronen Fragerunden Pro Fragerunde kann jeder Spieler nur O(1) viele Fragen stellen / beantworten 5 8 Was ist Deine Nummer? 8.
24
Konsensus Alle Spieler ehrlich: Minimum-Regel:
Nach O(log n) Runden haben alle Spieler dieselbe Nummer m.h.W. x y Was ist Deine Nummer? y. x:=min{x,y} Zufälliger Spieler
25
Konsensus Ein Spieler unehrlich:
Minimum-Regel: unbeschränkte Laufzeit. 5 1 Was ist Deine Nummer? 5. irgendwann später… 5 1 Was ist Deine Nummer? 1.
26
Konsensus Besser: Median-Regel:
O(log n) Runden m.h.W.: ehrliche Spieler O(log n loglog n): max n gegn. Spieler z y x Nummer? Nummer? z. y. Zufälliger Spieler x:=median{x,y,z} Zufälliger Spieler
27
DoS-resistentes Informationssystem
Past-Insider-Attacke: Gegner kennt alles über System bis (unbekannte) Zeit t0 Ziel: skalierbares Informationssystem, so dass alles, was nach t0 eingefügt oder aktualisiert worden ist, sicher (m.h.W.) gegen past-insider DoS Attacken ist Sie sind gefeuert!
28
Entkopplung bzgl. Ort, Zeit und Fluss.
Robustheit Entkopplung bzgl. Ort, Zeit und Fluss. Ortentkopplung: interagierende Prozesse müssen nicht ihre physikalischen Orte kennen Zeitentkopplung: interagierende Prozesse müssen nicht zur selben Zeit miteinander interagieren Flussentkopplung: die Ausführung einer Aktion innerhalb eines Prozesses sollte nicht von anderen Prozessen abhängen
29
Gesetze der Robustheit
Entkopplung und Selbsterholung von jedem Zustand Nur dann können verteilte Systeme hochgradig skalierbar und verfügbar sein
30
Gesetze der Robustheit
Vollständige Kontrolle über Ressourcen und Informationen Nur dann können verteilte Prozesse sicher ausgetauscht werden und miteinander interagieren
31
Gesetze der Robustheit
Eignerzustimmung und Kontrolle Geringste Ausgesetztheit Selbsterholung Entkopplung [POLA, K. Cameron: The laws of identity, D. Epp: The eight rules of security,…]
32
Gesetze der Robustheit
Eignerzustimmung und Kontrolle: Eindeutig definierte Zuständigkeiten Vollständige Kontrolle über Info & Ressourcen Geringste Ausgesetztheit: Nicht mehr Wissen als notwendig Vollst. Kontrolle über Informationsfluss Selbsterholung: Erholung muss von jedem Zustand aus möglich sein (solange die Plattform noch im legalen Zustand ist) Entkopplung: keine Synchronisation notwendig für die Primitive
33
Subjects Paradigma Subjekte Objekte Relaypunkte Aktionen
34
Wichtig für Verifikation und Kontrolle!
Subjects Paradigma Subjekte: atomar gebunden an Ort statische Menge an Aktionen sequentielle Abarbeitung von Aufgaben Objekte und erzeugte Relays und Subjekte lokal zum Subjekt keine Identität, d.h. Informationsaustausch ist nur über Relays möglich Wichtig für Verifikation und Kontrolle!
35
Subjects Paradigma atomar, anonym, aktiv, unbeweglich,
enthält Objekte, Relays und Aktionen atomar, anonym, passiv, beweglich atomar, Identitäten erzeugbar, passiv, unbeweglich atomar, anonym, unbeweglich, garantierte Terminierung
36
Subjekt kann Subjekte erzeugen
kann Objekte besitzen und Aktionen ausführen kann Verbindungen aufbauen, die nicht umlegbar sind
37
Relaypunkte Keine Anwender-zugreifbare Identität, aber (dunkle) Identitätsobjekte erzeugbar Ausgehende Kante bei Erzeugung festgelegt. a) ohne Identität b) mit Identität R R A R
38
Erstes Kennenlernen A B Öffentliche Identität (TAN)
Subjekte besitzen keine Identität Identitäten nicht kopierbar, nur einmal verwendbar Relayverbindungen können nicht umgelegt werden
39
Vorstellung A B C Zustimmung und Kontrolle, geringste Ausgesetztheit?
R>B C B>A A>B Zustimmung und Kontrolle, geringste Ausgesetztheit?
40
Delegation von Rechten
Zustimmung und Kontrolle, geringste Ausgesetztheit?
41
Quelle des Objekts R R R’ R‘‘ Startpunkt des Objekts wird dem Objekt mitgegeben. Damit kann bei R’’ überprüft werden, wer die Quelle des Objekts war.
42
Nachkommen Mutter Kind Kind in derselben Maschine wie Mutter.
Ressourcenkontrolle Mutter Kind Kind in derselben Maschine wie Mutter.
43
Nachkommen Einfrieren Löschen
44
Clones Erinnerung: Subjekte unbeweglich, atomar
Zustimmung und Kontrolle, geringste Ausgesetztheit?
45
Clones Objekte prinzipiell völlig offen gegenüber Eigner.
Objekte mit Zugriffsrechten: Clones O A B S O Zustimmung und Kontrolle, geringste Ausgesetztheit?
46
Erholbarkeit Existierende Objekte immer erreichbar, da immer Subjekt zugeordnet Nachkommenbaum der Subjekte immer zusammenhängend und damit Ressour-cenkontrolle lückenlos Kommunikation von Kind zu Mutter immer vorhanden, und damit immer schwacher Kommunikationszusammenhang der Subjekte
47
Subjects Paradigma Simulationsumgebung existiert basierend auf C++
Vorlesungsseite: Einführung in C++ Link auf frei verfügbaren Compiler Subjects Library und Beispielprogramme
48
Objekte Object: Basisklasse für Objekte Container für dynamische Daten
keine Identität (nur über Referenz erreichbar) keine Aktionen transferierbar, aber hat zu jedem Zeitpunkt eindeutigen Besitzer (Subjekt) Besitzer kann auf alle Anwendungsdaten innerhalb vom Objekt zugreifen
49
Objekte Von Object abgeleitete Klassen:
Identity: enthält Identität eines Relaypunkts Clone: enthält “schlafendes” Subjekt Objekte dieser Klassen sind nur einmal verwendbar, und auf deren Inhalte können Subjekte nicht zugreifen. Benutzerdefinierte Objekte: ObjectType(<UserObject>) { public: <benutzerdefinierte Variablen> <evtl. Konstruktor> };
50
Relays Relay: Klasse für Relaypunkte nicht transferierbar
nur eine ausgehende Kante, die bei Generierung erzeugt wird und dann nicht mehr umgelegt werden kann anonym, aber Identitäten können für eingehende Kanten generiert und transferiert werden
51
Relays Benutzerdefinierte Relays: RelayType(<UserRelay>) { public: <benutzerdefinierte Variablen> <evtl. Konstruktor> };
52
Identitäten Anweisungen:
new Identity(Relay *r): erzeugt neue öffentliche Identität von Relay r new Identity(Relay *r, Relay *r’): erzeugt private Identität von r für r’ delete i: löscht Identität
53
Clones Anweisungen: publicClone(<UserSubject>,NONE) oder publicClone(<UserSubject>,<UserObject> *o): erzeugt öffentliches Clone vom Typ UserSubject privateClone(<UserSubject>,NONE, Relay *r) oder privateClone(<UserSubject>,<UserObject> *o, Relay *r): erzeugt privaten Clone vom Typ UserSubject für Relay r delete c: löscht Clone
54
Subjekte Subject: Basisklasse für Subjekte atomar, anonym
können Objekte und Relays besitzen nicht transferierbar Kindsubjekt immer am selben Ort wie Mutter frei definierbare, aber von Anfang an fest vorgegebene Aktionen, die auf alle Anwen-dungsdaten innerhalb eines Subjekts und deren Objekte zugreifen können
55
Subjekte Benutzerdefiniertes Subjekt: SubjectType(<UserSubject>) { protected: <benutzerdefinierte Variablen> <interne benutzerdefinierte Methoden> public: FirstAction(<UserSubject>,<Action>) <benutzerdefinierte Aktionen> };
56
Subjekte Alle extern aufrufbaren Aktionen müssen
folgende Form haben: Action <UserAction>() {…} Action <UserAction>(<UserObject> *o) {…} Start der Subjects-Umgebung: runSubjects(<UserSubject> *s, <UserObject> *o, t); // t=0: laufe, bis keine Aufgaben mehr
57
Subjekte Reservierte Variablen:
ulong _debugID: eindeutige Identität für Debugging Relay *parent: Relay zu Muttersubjekt ulong source: ID des Relays, von dem Aufruf kam (lokal eindeutig) ulong sink: ID des Relaypunkts, der Aufruf empfangen hat
58
Subjekte Anweisungen:
new(<UserSubject>,NONE) oder new(<UserSubject>,<UserObject> *o): erzeugt neues Subjekt wakeupClone(Clone *c): aktiviert Subjekt im Clone c delete(s): löscht Subject (muss Kind sein, damit möglich) Wichtig: bei new/delete “()” benutzen!
59
Subjekte Anweisungen:
new Relay: erzeugt neuen Relaypunkt, dessen ausgehende Kante zum Subjekt selbst zeigt new Relay(Identity *i): erzeugt Relaypunkt mit Verbindung zum Relaypunkt mit Identität i (damit wird i invalidiert) delete r: löscht Relaypunkt r call(verb, object | NONE): generiert Anfrage verb(object) für eigenes Subjekt rcall(verb, object | NONE): generiert Anfrage verb(object) für Ziel von Relay r
60
Subjekte Anweisungen:
wakeup(s): weckt Subjekt s auf (und alle seine Nachfolger im Stammbaum) freeze(s): friert Subjekt s ein (und alle seine Nachfolger im Stammbaum) int idle(): gibt an, ob noch Anfragen für Subjekt int idle(Relay *r): gibt an, ob noch ausgehende Anfragen für Relay r
61
Subjects Paradigma Ursprung: Hewitts Actor Modell (1973) für neuronale Netzwerke Seitdem hauptsächlich Arbeiten im Bereich der Betriebssysteme und Programmiersprachen (EROS, E Language, Singularity,…)
62
Beispiele Hello-Beispiele und anderes auf der Webseite
SPAM-resistentes -System Robustes DNS Digital Rights Management Online Banking
63
SPAM-resistente Emails
Einsichten: Grundlegendes Problem: ungenehmigte s Genehmigung muss an Absender und nicht an s geknüpft sein Genehmigungen müssen zurücknehmbar sein Die Identität des Absenders (und des Adressaten) darf nicht transferierbar sein.
64
SPAM-resistente Emails
Subjects: anfangs kann niemand mit Alice kommunizieren (nicht einmal die Mutter). Alice
65
SPAM-resistente Emails
Alice und Bob sind nicht verbunden: Bob kann keine Nachricht direkt an Alice schicken. Alice Bob
66
SPAM-resistente Emails
Erste Kontaktaufnahme: SPAM von Bob: Alice löscht R R Alice Bob R Öffentliche Identität (TAN)
67
SPAM-resistente Emails
Vorstellung: Alice Bob R R>B Carol B>A A>B
68
SPAM-resistente Emails
Problem: Alice will mit David kommunizie-ren, kennt aber David nicht. Lösung: System, das Beziehungen zeigt? (wie Xing, Facebook,…) Alice Bob Carol David
69
Robustes DNS Internet DNS: Hierarchische Menge von Servern Root Server
Benutzer
70
Robustes DNS Aufgabe des DNS: Namen IP-Adressen
Aufgabe hier: übersetze Namen in Identitäten Besserer Schutz? Google A A A Amazon Benutzer
71
Robustes DNS Aufgabe des DNS: Namen IP-Adressen
Aufgabe hier: übersetze Namen in Identitäten Besserer Schutz? Angreifer Angreifer Google A A A Angreifer Amazon Benutzer
72
Robustes DNS Google hat festen Link zu Amazon: kein Angreifer kann Amazon übernehmen Angreifer Google A A A Amazon Benutzer
73
Robustes DNS Benutzer hat festen Link zu Google: kein Angreifer kann Google übernehmen, es sei denn, Benut-zer fällt auf Phishing-Atacke rein… Google A A A Angreifer Amazon Benutzer
74
Robustes DNS Benutzer versucht, alle Identitäten von Amazon (z.B. für DoS-Attacke) an sich zu ziehen: Google kann das erkennen und schließt Benutzer aus. Angreifer Google A A A Amazon Benutzer
75
Robustes DNS Problem: Angreifer startet Sybil-Atacken (d.h. generiert beliebig viele Benutzer) Angreifer Google A A A Amazon Benutzer
76
Digital Rights Management
Problem: Digitaler Content ist kopierbar. Hardware: Kassettenrekorder CD-Brenner DVD-Brenner Blueray-Brenner Software: Digitaler Schutz knackbar / umgehbar Hauptproblem
77
Digital Rights Management
Software-Attacken: Benutzer installiert Ripping-Software, um Raubkopien seines Contents zu erstellen Benutzer holt sich Content von einer Tauschbörse Legaler Content vom Benutzer wird über Virus / Trojaner von außen gestohlen
78
Digital Rights Management
Nutzungsproblem: DRM-Modelle der Provi-der oft sehr eingeschränkt, was legale Nutzer verärgert. Mögliche Modelle für Provider und Nutzer: Content kopierbar, aber nur von einem Benutzer verwendbar. Content nicht kopierbar, aber beliebig weitergebbar.
79
Digital Rights Management
2. Modell: Content nicht kopierbar, aber beliebig weitergebbar. Durch Clones umsetzbar: X X X X Song X Song X Sony Alice Bob
80
Digital Rights Management
2. Modell: Content nicht kopierbar, aber beliebig weitergebbar. Vorteil: Nutzer kann X nicht inspizieren, da Zugriff über Sony-Subjekt kontrolliert. X Sony Alice Bob
81
Digital Rights Management
2. Modell: Content nicht kopierbar, aber beliebig weitergebbar. Vorteil: X kann nicht von außen (ohne Hand-lung von Alice) gestohlen werden. X Sony Alice Bob
82
Online Banking Problem: Sichere Transaktionen zwischen Kunde und Bank
83
Online Banking Umsetzung in Subjects-Umgebung: Probleme:
R kommt nicht von Bank R wird durch Gegner abgefangen R Bank Kunde R Öffentliche Identität (TAN)
84
Online Banking Probleme: R kommt nicht von Bank
R wird durch Gegner abgefangen Lösung: Verwende sicheren Offline-Transfer (persönliche Abholung, Brief) Weitere Probleme: Phishing Attacken auf Kunde Kunde möchte von beliebigem Rechner Zugriff
85
Online Banking Phishing Attacke auf Kunde: Bank Kunde Angreifer
Angreifer kann keinen Kontakt zu R herstellen! R’
86
Online Banking Phishing Attacke auf Kunde: Bank Kunde Angreifer
Bank akzeptiert nur Anfragen, die bei R starten!
87
Online Banking Zugriff über beliebigen Rechner:
Verwende z.B. USB-Stick mit Minirechner, um Emulationsproblem zu umgehen? Details noch zu klären…
88
Fragen?
Ähnliche Präsentationen
© 2024 SlidePlayer.org Inc.
All rights reserved.