Verteilte Algorithmen Kap. 3: Ordnungen und Reihenfolgen

Transkript

1 Verteilte Algorithmen, WS 2015/16 wk Verteilte Algorithmen Kap. 3: Ordnungen und Reihenfolgen Winfried E. Kühnhauser Wintersemester 2015/16 Winfried E. Kühnhauser CSI Technische Universität Ilmenau

2 Roadmap START 1 Intro 2 Theoretische Grundlagen 3 Ordnungen und Reihenfolgen 4 Synchronisation 5 Konsens ZIEL Verteilte Algorithmen, WS 2015/16 wk Ordnungen und Reihenfolgen

3 Bob hup Christian Anna Sichten: Annas Sicht: hup Bob zeitgleich mit hup Christian Bobs Sicht: hup Bob früher als hup Christian Christians Sicht: hup Bob später als hup Christian Konsequenz der Kommunikationslatenz (Schallgeschwindigkeit): 3 Beobachter, 3 verschiedene Sichten auf dieselbe Ereignisfolge Verteilte Algorithmen, WS 2015/16 wk Ordnungen und Reihenfolgen 3 Ordnungen und Reihenfolgen

4 Verabredung: Treffen in der Berghütte um 5 Uhr Synchronisation der lokalen Uhren: Bob Lichtsignal Christian Anna Resultat alle drei treffen zu unterschiedlichen Zeiten ein alle drei glauben, sie selbst seien pünktlich Konsequenz lokaler Uhren: 3 Menschen, 3 unterschiedliche Auffassungen von zuvor synchronisierter... Zeit Verteilte Algorithmen, WS 2015/16 wk Ordnungen und Reihenfolgen

5 Ordnungen spielen eine zentrale Rolle für eine Vielzahl von Koordinations-, Sicherheitsund Fehlertoleranzalgorithmen Ordnung herstellen: Reihenfolge verteilt auftretender Ereignisse Fairness; Auswahlalgorithmen wie First Come, First Served Serialisierung verteilter atomarer Transaktionen Softwaremanagement; z.b. Programme wie make oder rsync IT-Sicherheit: Zeitstempel in kryptografischen Protokollen ( Frische, z.b. in Authentisierungsprotokollen, IPSec) in Authentisierungs- und Autorisierungstickets (Gültigkeitsdauer)... aber auch bei zunächst überraschenden Problemlösungen Effizienz Implementierung von RPC-Fehlersemantiken Verteilte Algorithmen, WS 2015/16 wk Ordnungen und Reihenfolgen

6 Roadmap Kap. 3 Ordnung und Reihenfolgen zeitliche Ordnungen Zeitbasis physische (Echtzeit-)Uhren Referenzzeitquellen Merkmale physischer Rechneruhren Algorithmen zur Synchronisation physischer Uhren kausale Ordnungen Grundlage logische Uhren Algorithmen zur Synchronisation logischer Uhren Verteilte Algorithmen, WS 2015/16 wk Ordnungen und Reihenfolgen

7 3.1 Zeitliche Ordnungen Beispiel: das Unix-Dienstprogramm make make organisiert Sparsamkeit Makefile: all: gcc -o foo foo.c make all Übersetzung von foo.c genau dann wenn foo nicht existiert oder foo älter ist als foo.c Verteilte Algorithmen, WS 2015/16 wk Zeitliche Ordnungen

8 Szenario foo.c auf Fileserver (montiert auf /src) foo und Übersetzung auf Workstation edit und make all auf Workstation Makefile: all: gcc -o foo /src/area51/foo.c File Server Workstation edit von foo.c lokale Uhren Erzeugung von foo make all die Wirklichkeit: foo.c jünger als foo muss übersetzt werden lokale Sichten: foo.c älter als foo muss nicht übersetzt werden Verteilte Algorithmen, WS 2015/16 wk Zeitliche Ordnungen

9 Monolithische Systeme: eine gemeinsame Zeitquelle Das Problem Verteilte Algorithmen, WS 2015/16 wk Zeitliche Ordnungen

10 Das Problem Verteilte Systeme: viele lokale Zeitquellen Task Task Task Task Wie schaffen wir eine gemeinsame Zeit? Verteilte Algorithmen, WS 2015/16 wk Zeitliche Ordnungen

11 3.1.1 Grundlagen Zeitbasis verteilter Systeme eine UTC-basierte Referenzzeit lokale Rechneruhren Synchronisationsalgorithmus 3 Problemfelder UTC weltweite, standardisierte Zeitreferenz (früher GMT) (Temps Universel Coordonné, Coordinated Universal Time); MEZ=UTC+1h abgeleitet aus der Temps Atomique International (TAI, 260 Uhren) Drift (Cäsium-Fontäne, 1 Sek. in 20 Mio. Jahren) veröffentlicht durch landgestützte Radiosender; Jitter (Latenzschwankung) 0,1-10 msek, je nach Entfernung vom Sender (bis 3000 KM), Wetterbedingungen GPS-Satelliten, Jitter 1 msek, abhängig von Ionendichte der Atmosphäre Verteilte Algorithmen, WS 2015/16 wk Grundlagen

12 3.1.1 Grundlagen Zeitbasis verteilter Systeme eine UTC-basierte Referenzzeit lokale Rechneruhren Synchronisationsalgorithmus Problemfelder UTC weltweite, standardisierte Zeitreferenz (früher GMT) (Temps Universel Coordonné, Coordinated Universal Time); MEZ=UTC+1:00 abgeleitet aus der Temps Atomique International (TAI) Drift (Cäsium-Fontäne, 1 Sek. in 20 Mio. Jahren) veröffentlicht durch landgestützte Radiosender; Jitter (Latenzschwankung) 0,1-10 msek, je nach Entfernung vom Sender (bis 3000 KM), Wetterbedingungen GPS-Satelliten, Jitter 1 msek, abhängig von Ionendichte der Atmosphäre Verteilte Algorithmen, WS 2015/16 wk Grundlagen

13 Rechneruhren elektronische Baugruppe zählt Schwingungen eines Quarzes macht Zähler über Speicherzellen/Register verfügbar wandelt Zähler in übliche Zeit- und Datumsformate um Betriebssysteme machen diese über funktionale Schnittstelle verfügbar; z.b. an der Unix-API durch gettimeofday(struct timeval *tv, struct timezone *tz); settimeofday(const struct timeval *tv, const struct timezone *tz); struct timeval { time_t tv_sec; /* seconds */ suseconds_t tv_usec; /* microseconds */ }; Verteilte Algorithmen, WS 2015/16 wk Grundlagen

14 Merkmale von Rechneruhren Auflösung Zeitintervall zwischen zwei Zählerinkrementierungen typische Frequenz heutiger Rechneruhren 1GHz Auflösung 1 Nanosekunde Drift langsames Entfernen von Referenzzeit typische Drift heutiger Rechneruhren etwa 10-6, d.h. 1 Sek in 11 Tagen synchronisierte Uhren divergieren (schon nach 500 Mikrosekunden) Synchronisation; wann, wie oft, wie? Verteilte Algorithmen, WS 2015/16 wk Grundlagen

15 Beispiel: Computer-Aided Engineering Analyse der Verbrennungsvorgänge in Otto-Motoren Optimierung von Verbrauch Leistung Schadstoffemission Verteilte Algorithmen, WS 2015/16 wk Grundlagen

16 Echtzeit-Messwerterfassung Messwerterfassung Steuerung Auswertung (Zeit, Licht, Druck) Worst-case Abstand zweier Uhren mit Driftrate 10-6 nach 10 Sek.: 10 sek = nsek (~ 2mm Kolbenbewegung, faches Auflösungsvermögen einer typischen Rechneruhr) Folgen der Drift nach wenigen Minuten entspricht Abstand einem kompletten Hub Synchronisation notwendig, je nach erforderlicher Präzision durch spezielle Hardware (in obigem Beispiel) Synchronisationsalgorithmus (make-szenario) Verteilte Algorithmen, WS 2015/16 wk Grundlagen

17 Synchronisation von Echtzeit-Uhren Übereinstimmung einer Rechneruhr mit perfekter UTC hängt ab von Präzision des Referenzzeitgebers Jitter der Signallaufzeit: Abstand vom Zeitgeber, atmosphärische Bedingungen Drift der lokalen Uhren Synchronisation wie oft Qualität des Algorithmus Kalkulierbarkeit der Kommunikationsdauer (Jitter) Punkt 1: die Physiker arbeiten (optische Strontium-Uhren; 2013: ) Punkt 2 und 3: die Ingenieure arbeiten (Referenzpunkte, Korrektursignale, Uhren) Punkt 4: wir können etwas tun Verteilte Algorithmen, WS 2015/16 wk Grundlagen

18 Quantifizierung der Drift: Wann Synchronisation? Abstand der Uhrensynchronisation, so dass die maximale Uhrenabweichung nicht mehr als ein bestimmtes δ beträgt? t: perfekte Zeit c(t): driftbehaftete Rechneruhr, nähert t mittels Funktion c an Idealfall : c( t) = t, c( t ) c( t d. h. t t c(t) c(t 2 ) c(t 1 ) 2 1 ) dc dt 2 1 = = Bereich zu schneller Uhren: dc dt > 1 1 Bereich zu langsamer Uhren: dc dt dc perfekte Uhr : = 1 dt < 1 (1. Ableitung von c) t 1 t 2 t Verteilte Algorithmen, WS 2015/16 wk Grundlagen

19 Rechneruhr mit maximaler Driftrate ρ Maximale Driftrate ρ ist Teil jeder Uhren-Spezifikation dc eine Uhr arbeitet innerhalb ihrer Spezifikation 1 ρ 1+ ρ dt heute typische Größe für Rechneruhren: 10-6 ρ 10-5 Wirkung der Drift Maximaler Abstand δ zweier synchronisierter Uhren mit Driftraten ρ 1 und ρ 2 nach Δt: δ (ρ 1 +ρ 2 )Δt Resynchronisation zweier Uhren, die nicht weiter als δ abweichen dürfen, nach Δt = δ ρ 1 + ρ 2 Sekunden Verteilte Algorithmen, WS 2015/16 wk Grundlagen

20 Δt = δ ρ 1 + ρ 2 Sekunden Beispiel: ρ 1 =ρ 2 =10-5 Abweichung nach 1 Tag (Δt =86400 sek): δ 1,728 sek bei max. Abweichung von δ =1 µsek Synchronisation nach Δt = = 50 msek Verteilte Algorithmen, WS 2015/16 wk Grundlagen

21 3.1.2 Zeitsynchronisation nach Cristian Szenario verteiltes System Zeitserver mit Referenzzeit Klienten mit lokalen Uhren maximal zulässige Uhrenabweichung δ Synchronisationsalgorithmus Parameter δ die Driftraten ρ i der lokalen Echtzeituhren Verfahren jeder Klient synchronisiert seine Echtzeit-Uhr mit dem Zeitserver klientenspezifisches Synchronisationsintervall: Δt Klient = δ/ρ Klient Verteilte Algorithmen, WS 2015/16 wk Zeitsynchronisation nach Cristian

22 Schritte je Klient und Algorithmusablauf 1. Klient: Anfordern der Zeit beim Zeitserver 2. Zeitserver: Antwortet mit aktueller Uhrzeit 3. Klient: Korrektur der lokalen Uhr Klient Hm how much watch? so much watch! Zeitserver Verteilte Algorithmen, WS 2015/16 wk Zeitsynchronisation nach Cristian

23 Korrekturfaktoren Probleme des Cristian schen Verfahrens: 1. Botschaftenlaufzeit veraltete Uhrzeit T 1 T 2 Klient Zeitserver Korrekturfaktor K = halbe round-trip-zeit der Zeitanfrage K T 2 T = Jitter der Botschaftenlaufzeiten Ungenauigkeit des Korrekturfaktors Verfeinerung: Verwendung statistischer Mittelwerte für T 2 - T 1 Verteilte Algorithmen, WS 2015/16 wk Zeitsynchronisation nach Cristian

24 3. Unbekannte Serverlast Ungenauigkeit des Korrekturfaktors? T trans T 1 T S T 2 Klient T trans Zeitserver Verfeinerung: Berücksichtigung der Bearbeitungszeit T S des Servers Annahmen Laufzeiten der beiden Botschaften sind annähernd gleich (wenig Jitter) Server sieht unmittelbar vor Absenden der Antwort auf die Uhr, d.h. K T trans Server schickt zusätzlich T S T T = 2T trans + T 2 1 S, d.h. K = T trans T = T1 T 2 2 S Verteilte Algorithmen, WS 2015/16 wk Zeitsynchronisation nach Cristian

25 Der Algorithmus im asynchronen Modell Tasks Zeitserver timesv n Klienten timecl i (für alle Klienten identisch) Parameter maximale Uhrenabweichung δ klientenspezifische lokale Driftrate ρ i (Vereinfachende) Annahmen einfacher Korrekturfaktor K = T T Driftrate sämtlicher Klientenuhren 10-5 Verteilte Algorithmen, WS 2015/16 wk Zeitsynchronisation nach Cristian

26 Der Algorithmus im asynchronen Modell Kommunikationstopologie und Komponenten G=(N,E) mit N = { timesv} { timecl i 1 i n} E = {(timecl i,timesv) 1 i n} (timesv,timecl i ) 1 i n { } In timecli = {(timesv,timecl i )},1 i n Out timecli = {(timecl i,timesv)},1 i n In timesv = (timecl i,timesv) 1 i n N 0 = { timesv} { } { } Out timesv = (timesv,timecl i ) 1 i n Botschaften: timerequest timereply(time_t time) Verteilte Algorithmen, WS 2015/16 wk z.b. für n=4 timecl 3 timecl 4 timecl 2 timesv timecl Zeitsynchronisation nach Cristian

27 Ein Klient i, 1/2 Async Cristian timecl i : Ø Variables: ρ i 10-5 ; // drift of clock local to timecl i δ 20msek; // max. clock synch deviation t1, t2, time time_t; wakeup {true,false} true. Verteilte Algorithmen, WS 2015/16 wk Zeitsynchronisation nach Cristian

28 Ein Klient i, 2/2 Ø Input: // initiate time sync cycles when wakeup. Action: t1 getlocaltime(); send timerequest to (timecl i, timesv); // trigger next clock sync: wakeup false; setlocaltimer(δ/ρ i, wakeup). // wakeup true after δ/ρ i Ø Input: msg=timereply(time). Action: t2 getlocaltime(); setlocaltime(time + (t2-t1)/2). // simple correction Verteilte Algorithmen, WS 2015/16 wk Zeitsynchronisation nach Cristian

29 Der Server Async Cristian timesv: Ø Variables: timecl N \ {timesv}. Ø Input: // init, at tic 0 msg=nil. Action if timesv N 0 : startlocalutctimer(). Ø Input: msg=timerequest, origin(msg)=(timecl,timesv) In TimeSv. Action: send timereply(getutctime()) to (timesv,timecl) Out TimeSv. Verteilte Algorithmen, WS 2015/16 wk Zeitsynchronisation nach Cristian

30 Anmerkungen zur Algorithmusbeschreibung präzise Beschreibung sämtlicher Algorithmuskomponenten: N präzise Beschreibung sämtlicher Kommunikationsbeziehungen: E, In, Out präzise Beschreibung des Algorithmusanlaufs: N 0 ={timesv} präzise Aussagen ( Async ) über Algorithmus- und Botschaftenlaufzeiten, Reihenfolgen, Zeitkomplexität präzise Beschreibungen der Algorithmuskomponenten Async Cristian timecl i Async Cristian timesv mit lokalen Variablen, deren Wertebereichen und Initialisierung Initialisierung gesendete und empfangene Botschaften Reaktionen auf Botschaften und Bedingungen Verteilte Algorithmen, WS 2015/16 wk Zeitsynchronisation nach Cristian

31 Einschränkungen des Cristian schen Algorithmus grundsätzliche Voraussetzung Referenz- (UTC) Zeitserver Monotonie der Zeit schnelle Klientenuhren führen zu ihrem Rücksetzen Skalierbarkeit Zeitserver ist Last-Engpass Präzision Jitter der Botschaften-Laufzeiten, z.b. in Weitverkehrsnetzen Ausfalltoleranz Zeitserver ist single-point-of-failure nicht für beliebige Einsatzszenarien geeignet Verteilte Algorithmen, WS 2015/16 wk Zeitsynchronisation nach Cristian

32 Möglichkeiten der Professionalisierung Monotonie der Zeit sanftes Abbremsen der Uhr statt hartes Setzen (vgl. Unix-adjtimex()) Korrektur der Frequenz der lokalen Uhr Skalierbarkeit und Ausfalltoleranz Lastverteilung und Redundanz: Zeitserver-Gruppe ein anderer Synchronisationsalgorithmus Verteilte Algorithmen, WS 2015/16 wk Zeitsynchronisation nach Cristian

33 3.1.3 Der Berkeley-Algorithmus wie spät? Klient 1. Server: sendet Zeitanfrage an Klienten Zeitserver Klient Klient 3:10 Klient 2. n Klienten returnieren ihre lokale Uhrzeit t i 3. Server: Mittelwertbildung: t = n i=1 t i n Zeitserver 3:09 3:14 Klient Klient +1 Klient 4. Server: sendet t-t i an alle Klienten i; z.b. bei t = 3:11 Zeitserver +2-3 Klient Klient Verteilte Algorithmen, WS 2015/16 wk Der Berkeley-Algorithmus

34 Wertung Pros keine UTC-Uhr notwendig, Zeitbestimmung durch Mittelwertbildung Präzisionsverbesserung durch klientenspezifische Laufzeitstatistiken Server ist kein spof, jeder kann diese Aufgabe übernehmen (falls Klienten sich untereinander kennen...) Kontras nicht UTC-synchronisiert Präzisionsproblem durch Jitter skaliert nicht besonders gut Lastengpass beim Server Abgleichintervalle nicht ρ i -spezifisch, orientieren sich an schlechtester Uhr das Network Time Protocol (NTP) Verteilte Algorithmen, WS 2015/16 wk Der Berkeley-Algorithmus

35 3.1.4 Das Network Time Protocol Ziel verlässliche, skalierbare UTC-Zeitsynchronisation in Netzen mit schwankenden Botschaftenlaufzeiten Anwendungsszenarien z.b. Internet-Zeit Infrastrukturen: Kommunikationssysteme, Energienetze, Verkehrsmanagement Nicht zu verwechseln mit PTP (Precision Time Protocol, IEEE 1588): Standard für Mess- und Steuerungssysteme Industrieautomatisierung räumlich begrenzt Verteilte Algorithmen, WS 2015/16 wk Das Network Time Protocol

36 Leistungen Präzision; typische Werte (Abweichung von UTC) 10 Millisekunden über WANs <1 Millisekunde in LANs <1 Mikrosekunde in LANs mit lokaler UTC-Uhr Verlässlichkeit; Umgang mit fail-stop Ausfällen byzantinischen Ausfällen Angriffen Implementierungsfehlern Lastskalierbarkeit; Organisation von Servernetzen automatische Optimierung Gegenstand Anzahl und Beziehungen der Zeitserver Synchronisationsalgorithmen Verteilte Algorithmen, WS 2015/16 wk Das Network Time Protocol

37 NTP ist der Standardzeitdienst im Internet (derzeit > Server) weit mehr als ein Protokoll: eine weltweit verteilte Klient/Server- Infrastruktur Klienten mit spezifischen Synchronisationsalgorithmen zu Servern Servern in unterschiedlichen Rollen mit unterschiedlichen Kommunikationsbeziehungen Atom/GPS/Funkuhren Stratum-1-Server Stratum-2-Server Stratum-3 Server Stratum-4 (Klienten) Verteilte Algorithmen, WS 2015/16 wk Das Network Time Protocol

38 NTP-Architektur Hierarchische, baumartig strukturierte verteilte Synchronisationstopologie Knoten: Zeitserver und -klienten Kanten: Kommunikationswege zur Synchronisation stratum-1: Primär-Server mit UTC-Uhr stratum-2: direkter Sekundärserver, synchronisiert mit stratum-1 stratum-3: indirekter Sekundärserver, synchronisiert mit stratum-2 Blätter: Arbeitsplatzrechner Auswahl eines Servers basierend auf Abstand zu UTC Server Stratum Verteilte Algorithmen, WS 2015/16 wk Das Network Time Protocol

39 3 Formen der Zeitsynchronisation 1. Zeitansage per Multicast in LANs mit Multicast (schwach synchronisiert) Zeitserver senden periodisch Zeitbotschaften an Empfänger (Dämonen), die auf Arbeitsplatzrechnern ablaufen eine Zeitbotschaft (typisch per UDP) stratum i LAN es ist 7 Uhr, 5 Min und 10 Sek es ist 7 Uhr, 5 Min und 20 Sek... stratum i+1 Verteilte Algorithmen, WS 2015/16 wk Das Network Time Protocol

40 2. Zeitabfrage für höhere Genauigkeit, für Netze ohne Multicast Cristian-Algorithmus benutzt durch Fileserver, Authentisierungsserver, Autorisierungsserver, Namensdienste, oft auch schon Workstations request/reply Botschaftenpaare per UDP stratum i wie spät ist es? LAN es ist 7 Uhr, 5 Min und 10 Sek stratum i+1 Verteilte Algorithmen, WS 2015/16 wk Das Network Time Protocol

41 3. Symmetrischer Zeitabgleich auf kleinen strata, zwischen Zeitservern in LANs bidirektionaler Fluss von Zeitinformationen; benutzt zwischen den Zeitservern der oberen strata zwei Zeitbotschaftenpaare, ausgetauscht per UDP stratum-1 sync WAN stratum-2 LAN stratum-3 Verteilte Algorithmen, WS 2015/16 wk Das Network Time Protocol

42 Synchronisationsschema Ziel Synchronisation des Zeitservers A mit Zeitserver B Methode A bestimmt Offset o der lokalen Uhr von der Uhr des Zeitservers B 1. Abschätzen von o durch Austausch eines Botschaftenpaars 2. Berechnung des dabei gemachten Fehlers 3. Falls dieser zu groß ist, Neuversuch B sync WAN A LAN Verteilte Algorithmen, WS 2015/16 wk Das Network Time Protocol

43 Abschätzung des Offsets b,b : Synchronisationsbotschaftenpaar T i-3... T i : lokale Uhrzeiten Server A Server B T i-3 b: (T i-3 ) T i-2 T i b : (T i-3,t i-2,t i-1 ) T i-1 Mit t und t als (unbekannten) Laufzeiten von b und b und o als (unbekanntem) Uhrenoffset gilt Ti 2 = Ti 3 + t + o T = T + t' o i i 1 (falls o sich im Zeitintervall [T i-2,t i-1 ] nicht ändert) Verteilte Algorithmen, WS 2015/16 wk Das Network Time Protocol

44 Umformung Auflösen von Ti 2 = Ti 3 + t + o T = T + t' o i i 1 nach o ergibt o o = Ti 2 Ti 3 t = Ti 1 Ti + t' Addition der Gleichungen ergibt oder nach Umsortieren 2o = Ti 2 Ti 3 t + Ti 1 Ti + t o T T + T 2 T t' 2 i 2 i 3 i 1 i t = + ' Dieser nun isolierte Term... Verteilte Algorithmen, WS 2015/16 wk Das Network Time Protocol

45 o T T + T 2 T t' 2 i 2 i 3 i 1 i t = +... ist in A zum Zeitpunkt T i die einzige Unbekannte in dieser Gleichung. Wenn wir die bekannten Größen als Abschätzung o i für den momentanen Uhrenabstand o wählen, dh. Ti 2 Ti 3 + Ti 1 Ti o = o i + t ' t mit oi = 2 2 dann lässt sich zeigen (siehe Übungen), dass o i d i 2 o o i + d i 2 Mit anderen Worten, o wird durch o i mit maximalem Fehler d i / 2 angenähert, wobei d i = t + t' = Ti 2 Ti 3 + Ti Ti 1 die Gesamtübertragungszeit der beiden Botschaften b und b ist. Dass d i =t+t wirklich so aussieht, lässt sich analog zur Bestimmung von o zeigen Verteilte Algorithmen, WS 2015/16 wk Das Network Time Protocol

46 Wir hatten das Gleichungssystem Ti 2 = Ti 3 + t + o T = T + t' o i i 1 Umsortieren ergibt t = Ti 2 Ti t' T T 3 = i i 1 + o o d.h. die Summe der Botschaftenlaufzeiten d i ist tatsächlich d i = t + t' = Ti 2 Ti 3 + Ti Ti 1 und der durch d i charakterisierte Fehler ist errechenbar unabhängig vom realen Offset der beiden Uhren. Verteilte Algorithmen, WS 2015/16 wk Das Network Time Protocol

47 Erreichtes Term, der auf der Basis nur eines Botschaftenpaars eine Annäherung des augenblicklichen Uhrenabstands gibt: o i = T i 2 T i 3 +T i 1 T i 2 Term, der den bei dieser Annäherung maximal gemachten Fehler gegenüber dem tatsächlichen Offset o angibt: mit o i d i 2 o o i + d i 2 d i = T i 2 T i 3 +T i T i 1 Verteilte Algorithmen, WS 2015/16 wk Das Network Time Protocol

48 Messergebnisse des Synchronisationserfolgs Abweichung von UTC 1-50 Millisekunden in WANs 99% weniger als 30 Millisekunden typische Werte (NTPv4) 10 Millisekunden über WANs <1 Millisekunde in LANs Ergänzende Techniken zur Präzision Netz-Jitter Filterung Gewichtung der Zeitinformationen nach ihrer Quelle (strata) Verteilte Algorithmen, WS 2015/16 wk Das Network Time Protocol

49 Verlässlichkeit fail-stop Ausfall einer Primärserver-Uhr Server wird zum Sekundärserver fail-stop Ausfall eines stratum-i Servers abhängige stratum-i+1 Server suchen neuen stratum-i Server byzantinische Ausfälle, Angriffe: digital signierte Zeitinformationen authentisch integritätsgesichert Verteilte Algorithmen, WS 2015/16 wk Das Network Time Protocol

50 Skalierbarkeit Aufteilung der Last auf Servernetzwerk Verteilte Algorithmen, WS 2015/16 wk Das Network Time Protocol

51 Idee Anwendungsbeispiele Nutzung synchronisierter Zeit für effiziente Lösungen ganz anderer Probleme Beispiel Implementierung von RPC-Fehlersemantiken Recap: Fehlersemantiken beim RPC Spezifikation der Garantien, die ein Kommunikationsmodell auch bei partiellen Ausfällen gibt; etablierte Fehlersemantiken: exactly-once at-most-once at-least-once Verteilte Algorithmen, WS 2015/16 wk Anwendungsbeispiele

52 At-most-once-Garantien bei Erfolgsmeldung: Ausführung genau 1 bei Fehlermeldung: höchstens 1x, d.h. Ausführung gar nicht, partiell, oder genau 1 Implementierung Höchstens 1x Duplikatfilterung im RPC-Server keine mehrfache Operationsausführung bei Wiederholung des Aufrufs Neusenden der (gespeicherten) Ergebnisse Ein Server muss dazu Duplikate erkennen können Ergebnisse speichern Verteilte Algorithmen, WS 2015/16 wk Anwendungsbeispiele

53 Straight-forward Implementierung der Aufrufer versieht jeden RPC mit einer eindeutigen Identifikation der RPC-Server speichert Identifikationen aller ausgeführten RPCs speichert Ergebnisse aller ausgeführten RPCs erkennt Wiederholungen (und sendet dann lediglich Ergebnisse erneut) Schutz vor Serverausfall persistente Speicherung der RPC-Identifikation persistente Speicherung der RPC-Ergebnisse! bei jedem RPC (sehr teuer)! und wie lange? (sehr unscharf) so naiv geht das nicht Verteilte Algorithmen, WS 2015/16 wk Anwendungsbeispiele

54 Implementierung bei synchronisierter Zeit Ziele Weg Vermeidung der Kosten der persistenten Speicherung von Identifikationen Präzisierung des Zeitraums, für den Ergebnisse verwahrt werden müssen der Aufrufer versieht jeden RPC mit einer eindeutigen Identifikation, bestehend aus einer Klienten-Id einem Zeitstempel der RPC-Server speichert je Klient den letzten Zeitstempel (flüchtig, preiswert) speichert Ergebnisse aller ausgeführten RPCs erkennt Wiederholungen und sendet dann lediglich Ergebnisse erneut ausreichend für Erkennen von Duplikaten im Normalfall Verteilte Algorithmen, WS 2015/16 wk Anwendungsbeispiele

55 Folge bei Serverausfall Flüchtigkeit der RPC-Identifikationen Server erkennt nach Wiederanlauf keine Duplikate Idee: der Server merkt sich lediglich ungefähren Ausfallzeitpunkt persistent erkennt alle RPCs, die das Potenzial zu einem Duplikat haben die vor dem Ausfallzeitpunkt eingetroffen sind also möglicherweise vorher noch ausgeführt wurden dazu reichen 2 Zeiten: Zeitstempel eines RPCs Ausfallzeitpunkt eintreffende RPCs eventuell ausgeführt keinesfalls ausgeführt Ausfallzeitpunkt Zeit Verteilte Algorithmen, WS 2015/16 wk Anwendungsbeispiele

56 Dann wird evtl. ein gar nicht ausgeführter RPC als Duplikat eingestuft schadet aber nicht, da at-most-once-konform; Klient wird Aufruf schon wiederholen führt im (seltenen) Fehlerfall evtl. zu höherem Wiederanlaufaufwand reduziert im Normalfall kostenträchtige Operationen auf persistentem Speicher so geht s eventuell ausgeführt keinesfalls ausgeführt eintreffende RPCs Ausfallzeitpunkt Zeit Verteilte Algorithmen, WS 2015/16 wk Anwendungsbeispiele

57 Die Voraussetzungen eine globale Zeit mit maximaler Abweichung δ alle Knoten (Klienten, Server) haben eine synchronisierte Zeit jeder Klient versieht einen RPC mit dessen Geburtsdatum eine globale Konstante, die maximale Lebensdauer MLD eines RPCs der RPC-Server berechnet einen Stichzeitpunkt l (von lates ) durch l = t Server - MLD - δ und bestimmt damit die Länge eines Zeitschweifs innerhalb des Schweifs geborene RPCs gelten als lebendig früher geborene gelten als verstorben (die lates ) RPCs im Server zum Zeitpunkt t Server l δ MLD t Server Zeit Zeitschweif eines lebendigen RPCs Zeitschweif noch aus Kulanz wg. Uhrentoleranz δ lebendigen RPCs Zeitschweif eines verstorbenen RPCs Verteilte Algorithmen, WS 2015/16 wk Anwendungsbeispiele

58 Der Algorithmus alle ΔT Zeiteinheiten* ) schreibt Server t Server auf persistenten Speicher Wiederanlauf des Servers: l persistenterspeicher.t Server + ΔT; dieser Zeitpunkt ist später als der Ausfallzeitpunkt; Folgen: sämtliche eintreffenden RPCs mit jüngerem Zeitstempel sind mit Sicherheit noch nicht bearbeitet eintreffende RPCs mit älterem Zeitstempel werden vom Server als verstorben betrachtet: sind entweder schon bearbeitet oder aber sind es noch nicht Pech, jedoch at-most-once-konform, so dass der Aufrufer korrekt reagieren wird Anmerkung l löst gleichfalls das Problem der Dauer des Speicherns von Ergebnissen: werden weggeworfen in dem Augenblick, da der zugehörige RPC verstirbt * ) Größe von ΔT: Adaption an individuelle Anwendungsmerkmale Verteilte Algorithmen, WS 2015/16 wk Anwendungsbeispiele

59 Beispiel ΔT=2 tics, δ=1 tic, max. RPC-Lebenszeit MLD=3 tics Ausfallzeitpunkt Wiederanlauf lokale Serverzeit t pers.sp. t pers.sp. t pers.sp. t pers.sp. t= 99: l = 95; l t-mld-δ (Schweiflänge 4) t= 100: l = 96; persistenter Speicher 100 t= W.: l = 102; l persistenterspeicher + ΔT t= 104: l = 102; persistenter Speicher 104 (Schweiflänge 2) t= 105: l = 102; (Schweiflänge 3) t= 106: l = 102; persistenter Speicher 106 (Schweiflänge 4) t= 107: l = 103; usw. mit Schweiflänge 4 Komplexitätsanalyse s. Übungen Verteilte Algorithmen, WS 2015/16 wk Anwendungsbeispiele

60 Weitere Anwendungsbeispiele synchronisierter Uhren verteilte Dateisysteme Konsistenz lokaler Caches, für die die Server zeitliche Konsistenzgarantien abgeben Softwaregenerierung ( make ) verteiltes Ressourcenmanagement Ausfalltoleranz: leases (locks mit Haltbarkeitsdatum) statt locks Kommunikationsinfrastrukturen Synchronisation medialer Datenströme Echtzeitsysteme Rechtzeitigkeitsgarantien / Quality of Service Garantien IT-Sicherheit Gültigkeitsdauer von Autorisierungstickets (e.g. Kerberos) Frischegarantie in kryptografischen Authentisierungsprotokollen Verteilte Algorithmen, WS 2015/16 wk Anwendungsbeispiele

61 3.1.6 Zusammenfassung Synchronisation physischer Uhren: 3 Grundprinzipien passiver Zeitserver aktiver Zeitserver Zeitsynchronisationsinfrastruktur Verteilte Algorithmen, WS 2015/16 wk Zusammenfassung

62 Cristian Voraussetzungen präzise Zeitbasis im Zeitserver Klienten müssen Server kennen Präzision Korrekturfaktoren, statistische Mittelwerte, Filter Verlässlichkeit Zeitserver ist spof Skalierbarkeit Zeitserver ist Flaschenhals Komplexität: 2 Schritte, 2 Botschaften je Synchronisation linear einfache Implementierbarkeit passiver Server, aktive Klienten klientenspezifische Synchronisationsintervalle zustandsfreier Server, einfacher Wiederanlauf nach Ausfall Verteilte Algorithmen, WS 2015/16 wk Zusammenfassung

63 Berkeley Voraussetzung Server muss Klienten kennen (resp. Broadcast) Präzision statistische Mittelwerte und Filter Verlässlichkeit Zeitserver ist spof, aber (c.g.s.) ersetzbar Skalierbarkeit Zeitserver ist Flaschenhals Komplexität: 3 Schritte, 3 Botschaften je Synchronisation linear einfache Implementierbarkeit aktiver Server, passive Klienten globales Synchronisationsintervall, schlechteste Uhr bestimmt δ zustandsbehafteter Server, aufwändiger Wiederanlauf Verteilte Algorithmen, WS 2015/16 wk Zusammenfassung

64 NTP Voraussetzungen Klienten müssen (mehrere) Server kennen Präzision skalierbar (Server-strata, Synchronisationsalgorithmen) Verlässlichkeit kein spof Algorithmen zur automatischen Rekonfiguration nach Uhren/Serverausfällen authentische und integritätsgesicherte Zeitinformationen Skalierbarkeit Verteilung der Anfragelast auf viele Server Implementierung aufwändig durch Servernetzwerk und dessen Synchronisation Verteilte Algorithmen, WS 2015/16 wk Zusammenfassung

65 3.2 Kausale Ordnungen Noch einmal: verteilte Softwaregenerierung make: Übersetzen t(letzte Übersetzung) < t(letzte Änderung) Problem dabei Kosten synchronisierter Uhren Unschärfe synchronisierter Uhren Besser: Übersetzen letzte Übersetzung letzte Änderung Relative Ordnung: früher als, happens before Verteilte Algorithmen, WS 2015/16 wk Kausale Ordnungen

66 Motivation Konsens über Reihenfolge verteilter Ereignisse ist für viele Algorithmen grundlegend Echtzeit-Rechneruhren je enger die Synchronisation, desto höher die Synchronisationskosten keine perfekte und nachhaltige Synchronisation ohne spezielle Hardware für viele Anwendungsfälle reicht es aus, eine relative Ordnung zwischen beobachtbaren Ereignissen ohne Bezug zu realer Zeit herzustellen Relative Ordnungen statt Zeitstempel Relative Ordnungen partielle (potenziell) kausale Ordnungen totale (potenziell) kausale Ordnungen Verteilte Algorithmen, WS 2015/16 wk Kausale Ordnungen

67 Ziel also Konsens über Reihenfolge verteilt aufgetretener Ereignisse zu jeweils 2 Ereignissen a, b soll systemweit eindeutig entscheidbar sein, ob a vor b oder b vor a stattgefunden hat Verteilte Algorithmen, WS 2015/16 wk Kausale Ordnungen

68 Informelle Definition Definition (happens-before-relation): (a) Lokale Ordnung: Wenn a und b zwei Ereignisse in derselben Task sind und a vor b stattfindet, dann gilt a b. (b) Verteilte Ordnung: Wenn a das Ereignis des Absendens einer Botschaft in einer Task und b das Ereignis des Empfangs dieser Botschaft in einer anderen Task ist, dann gilt a b. (c) Transitive Abgeschlossenheit a b b c a c Verteilte Algorithmen, WS 2015/16 wk Kausale Ordnungen

69 Beispiel t 1 a c t 2 b d a c c d a d b d a?b b?c? Eigenschaften ist nicht-totale, strenge, potenziell kausale Ordnung: es gibt Ereignisse a und b mit weder a b noch b a ( parallel ) a a echte kausale Abhängigkeit muss nicht existieren, birgt (lediglich) die Möglichkeit einer Kausalität Verteilte Algorithmen, WS 2015/16 wk Kausale Ordnungen

70 Etwas genauer Schreibweise Mit e i x, bezeichnend ein Ereignis x in Task i lautet die happens-before- Relation (i=j x<y) (lokale Ordnung) e i x e j y (i j b: e ix =send(b) e jy =receive(b)) (verteilte Ordnung) ( e kz : e ix e k z e kz e jy ) (transitive Abgeschlossenheit) Anmerkungen e f e hat das Potenzial, Ursache für f sein (potenziell kausal) (e f) e kann keinesfalls Ursache für f sein mit H: Menge aller Ereignisse in einem va ist (H, ) ein ereignisbasiertes Modell eines va Verteilte Algorithmen, WS 2015/16 wk Kausale Ordnungen

71 Verteilte Algorithmen, WS 2015/16 wk Anwendungsbeispiele verteiltes Ressourcenmanagement: first-come-first-served-strategien Softwaremanagement: make, s.o. transaktionale Systeme: Sicherungsreihenfolgen Analyse verteilter Systeme: Ursache und Wirkung Welche Ereignisse können Ursache für ein gegebenes Ereignis sein? Welche Ereignisse können Folgen eines gegebenen Ereignisses sein? 1. Kausale Vergangenheit Menge aller Ereignisse, die Ursache für ein Ereignis e sein können: {f f e} 2. Kausale Zukunft Menge aller Ereignisse, die durch e verursacht werden können: {f e f} 3. Kausale Unabhängigkeit (e f) (f e) e und f sind kausal unabhängig

72 Implementierung kausaler Ordnungen Ziel Implementierung von durch Zuordnung diskreter Werte zu Ereignissen Gesucht mindestens: eine in allen Tasks identisch berechnete Ordnungsfunktion o, so dass für Ereignisse e, f gilt o potenziell kausal idealerweise (weil universeller): e f o(e) < o(f) eine in allen Tasks identisch berechnete Ordnungsfunktion o, so dass für Ereignisse e, f gilt o kausal e f o(e) < o(f) Verteilte Algorithmen, WS 2015/16 wk Kausale Ordnungen

73 Grundlage: Logische Uhren Partielle potenziell kausale Ordnungen e f o(e) < o(f) Definition Eine logische Uhr ist eine streng monoton wachsende Zählfunktion lc: N, wobei für jede Folge, lc i,..., lc j,... von Aufrufen von lc gilt: i, j, i < j: lc i < lc j Also: jeder Aufruf von lc liefert einen größeren Wert als der vorangehende es besteht insbesondere kein Bezug zu einer realen Uhrzeit Verteilte Algorithmen, WS 2015/16 wk Partielle potenziell kausale Ordnungen

74 Logische Uhren sind tasklokal einfach implementierbar (schlichter Zähler) reichen allein nicht zur Implementierung von aus: Beispiel: t i e i 1 e i 2 e i 3 b b e i 4 t j e j 1 e j 2 e j 3 e j 4 e j 5 e j 6 send(b) receive(b), und o(e i1 )=1 < o(e j3 )=3 OK send(b ) receive(b ), aber o(e j6 )=6 > o(e i4 )=4 Verteilte Algorithmen, WS 2015/16 wk Partielle potenziell kausale Ordnungen

75 Lamport s Algorithmus Ziel Implementierung von mittels lokaler logischer Uhren, d.h. Ordnungsfunktion o so dass e f o(e) < o(f) Weg Idee o = lokale logische Uhr plus Synchronisation aller lokalen logischer Uhren 2 nicht interagierende Tasks haben keine Möglichkeit, Abweichungen ihrer logischen Uhren zu beobachten falls Tasks interagieren, so können sie nebenbei eine relative Ordnung zwischen nun beobachtbaren Ereignissen herstellen: Synchronisation preiswert: Nutzung regulärer Botschaften zur Synchronisation ( piggy-backing ) Verteilte Algorithmen, WS 2015/16 wk Partielle potenziell kausale Ordnungen

76 Implementierung einer partiellen potentiell kausalen Ordnung ppco mit e f ppco(e) < ppco(f) jede Task t i besitzt eine lokale logische Uhr lc i ppco(e i )=lc i, und jedes Ereignis in t i wird mit lc i gestempelt: e lc i i beim Senden einer Botschaft durch t i wird diese um lc i ergänzt beim Empfang dieser Botschaft in t j synchronisiert t j seine lokale logische Uhr durch lc j max(lc i, lc j ) stempelt t j das Ereignis des Botschaftenempfangs anschließend mit lc j Obiges Beispiel damit: t i e i 1 e i 2 e 1 j e 2 j e 3 j e 4 j e 5 j e 3 i e 7 i t j (b,1) (b,6) e j 6 Verteilte Algorithmen, WS 2015/16 wk Partielle potenziell kausale Ordnungen

77 Korrektheit des Lamport schen Algorithmus Beweis, dass der Lamport sche Algorithmus die Eigenschaft e,f verteilte Ereignisse und e f ppco(e) < ppco(f) besitzt, durch Induktion über die Länge von e f (Übungen) Cave: Lamport s Algorithmus liefert lediglich eine partielle Ordnung (mehr muss er auch nicht, da partiell ist) : aus ppco(e)<ppco(f) folgt nicht unbedingt e f; vgl. z.b. e i 1 und e j 2 (d.h. falls e f oder f e gilt, gibt ppco(e) und ppco(f) die Richtung des Pfeils an) t i e i 1 e i 2 e 1 j e 2 j e 3 j e 4 j e 5 j e 3 i e 7 i t j (b,1) (b,6) e j 6 Verteilte Algorithmen, WS 2015/16 wk Partielle potenziell kausale Ordnungen

78 Idee Partielle kausale Ordnungen e f o(e) < o(f) Lokale Buchführung über alle logischen Uhren (statt nur der eigenen) jede t i hat statt lc i nun einen Vektor vc i ( vector clock von t i )! # # vc i = # # # " lc 1 lc 2! lc n $ & & & & & % wobei vc i (j)=lc j j=1..n mit den lokalen logischen Uhren lc j der n t j (letzter in t i bekannter Stand) Verteilte Algorithmen, WS 2015/16 wk Partielle kausale Ordnungen

79 Verteilte Algorithmen, WS 2015/16 wk Vektoruhrsynchronisation (analog Lamport) e 1 [1,0] e 1 [2,0] e 2 [1,6] e 2 [0,1] e 2 [0,2] e 2 [1,3] e 1 [3,0] e 2 [1,4] e 2 [1,5] e 1 [4,6] t 1 t 2 b, 1 0! " # $ % & ' ( ) ) * +,, b', 1 6! " # $ % & ' ( ) ) * +,, 1 0! " # $ % & 2 0! " # $ % & 3 0! " # $ % & 4 6! " # $ % & 0 1! " # $ % & 0 2! " # $ % & 1 3! " # $ % & 1 4! " # $ % & 1 5! " # $ % & 1 6! " # $ % & Partielle kausale Ordnungen

80 Implementierung einer partiellen kausalen Ordnung pco mit e f pco(e) < pco(f) jede Task t i besitzt eine lokale Vektoruhr vc i pco(e i )=vc i, und jedes Ereignis in t i wird mit vc i gestempelt: e vc i i beim Senden einer Botschaft in t i wird diese um vc i ergänzt beim Empfang dieser Botschaft in t j synchronisiert t j seine lokale Vektoruhr: k j: vc j [k] max(vc i [k], vc j [k]) stempelt t j das Ereignis des Botschaftenempfangs anschließend mit vc j Dann gilt e i e j : e i e j pco(e i )<pco(e j ) mit pco(e i )<pco(e j ) vc i <vc j k=1..n: vc i [k] vc j [k] k: vc i [k]<vc j [k] (Beweis Fidge, Logical Time in Distributed Computing Systems, 1991) Anmerkung: pco ist wie ppco partiell Verteilte Algorithmen, WS 2015/16 wk Partielle kausale Ordnungen

81 Verteilte Algorithmen, WS 2015/16 wk Vektoruhren (pco) vs. Lamport-Uhren (ppco) e 1 [1,0] e 1 [2,0] e 2 [1,6] e 2 [0,1] e 2 [0,2] e 2 [1,3] e 1 [3,0] e 2 [1,4] e 2 [1,5] e 1 [4,6] t 1 t b, 6 1 b', Partielle kausale Ordnungen e 1 1 e 1 2 e 2 6 e 2 1 e 2 2 e 2 3 e 1 3 e 2 4 e 2 5 e 1 7 t 1 t 2 (b,1) (b,6)

82 3.2.3 Totale Ordnungen Ein Problem: partielle Ordnungen nicht immer ausreichend t i e i 1 (b,1) e i 2 e i 3 (b,6) e i 7 t j e j 1 e j 2 e j 3 e j 4 e j 5 e j 6 z.b. ppco(e i1 )=ppco(e j1 ), ppco(e i3 )=ppco(e j3 ), analog pco Beispiele FCFS-Strategien (z.b. bei verteiltem wechselseitigen Ausschluss, s.u.) Serialisierungsreihenfolge verteilter (Multiserver-) Transaktionen ( TIS) Verteilte Algorithmen, WS 2015/16 wk Totale Ordnungen

83 Definition Totale potenziell kausale Ordnungen mit Lamport-Uhren Sei I eine endliche Indexmenge mit totaler strenger Ordnung < ; seien ferner alle Tasks t i eines verteilten Algorithmus eindeutig identifiziert durch Indizes i I (globale, eindeutige Ids) sei c i die lokale logische synchronisierte (Vektor-)Uhr von t i Dann wird für Ereignisse e i in den t i eine totale potenziell kausale Ordnung tpco definiert durch tpco(e i )=(i, c i (e i )), wobei tpco(e i ) < tpco(e j ) definiert ist durch tpco(e i ) < tpco(e j ) c (e ) < c (e ) i i j j i < j falls c i (e i ) c j (e j ) sonst Verteilte Algorithmen, WS 2015/16 wk Totale Ordnungen

84 Anmerkungen eine solche totale Ordnung hat keine physische Signifikanz (da Task-Ids zufällig sind): t 1 e 1 1 e 1 2 (b,1) e 1 3 (b,6) e 1 7 t 2 e 2 1 e 2 2 e 2 3 e 2 4 e 2 5 e 2 6 z.b. tpco(e 13 ) < tpco(e 23 ), tpco(e 13 ) < tpco(e 24 ) sie erfüllt jedoch ihren Zweck: in allen t i ist tpco identisch berechenbar Verteilte Algorithmen, WS 2015/16 wk Totale Ordnungen

85 Analog für tco(e i ). Totale kausale Ordnungen mit Lamport-Uhren Verteilte Algorithmen, WS 2015/16 wk Totale Ordnungen

86 3.2.4 Zusammenfassung 4 kausale Ordnungen basierend auf synchronisierten logischen (Vektor)Uhren (Lamport) partiell, potentiell kausal: ppco, e f o(e) < o(f) partiell, kausal: pco, e f o(e) < o(f) totale Ordnungen tpco: ppco mit Task-Ids tco: pco mit Task-Ids Verteilte Algorithmen, WS 2015/16 wk Zusammenfassung

87 3.3 Zusammenfassung Zeitliche Ordnungen Eigenschaften total teuer, abhängig von Synchronisationsqualität angenähert echtzeitsynchron unscharf, Zeitfenster δ: z.b. a,b zeitgleich t(a)-δ t(b) t(a)+δ nutzbar als Zeittakt für synchrone Algorithmen (mit Vorsicht, wg. Unschärfe) Synchronisationsalgorithmen passiver Zeitserver: Cristian scher Algorithmus aktiver Zeitserver: Berkeley-Algorithmus Infrastruktur: NTP Verteilte Algorithmen, WS 2015/16 wk Zusammenfassung

88 Anwendungsbeispiele zeitliche Garantien Dateisysteme: Cachekonsistenz Ressourcenmanagement: leases (locks mit Haltbarkeitsdatum) statt locks Kommunikationsinfrastrukturen Synchronisation medialer Datenströme Rechtzeitigkeitsgarantien / Quality of Service - Garantien IT-Sicherheit Frische-Stempel in Authentisierungsprotokollen Haltbarkeitsdatum von Autorisierungen trittbrettfahrende Algorithmen (Bsp. at-most-once) Verteilte Algorithmen, WS 2015/16 wk Zusammenfassung

89 Kausale Ordnungen Eigenschaften relative Ordnung von Ereignissen ohne Bezug zur realen Zeit scharf anwendungsspezifische Varianten: partiell vs. total potentiell kausal vs. kausal mit unterschiedlichen Kosten von preiswert (eingeschränktes Anwendungsspektrum) partiell, potentiell kausal bis teuer (universell) total, kausal Implementierungen basierend auf synchronisierten lokalen logischen Uhren (Lamport s piggy-backing) Task-Ids (o.ä.) für totale Ordnungen Verteilte Algorithmen, WS 2015/16 wk Zusammenfassung

90 Anwendungsbeispiele Ressourcenmanagement: z.b. first-come-first-served-strategien Softwaremanagement: make transaktionale Systeme: Sicherungsreihenfolgen Analyse verteilter Systeme Verteilte Algorithmen, WS 2015/16 wk Zusammenfassung