Also dann herzlich willkommen zum letzten Teil von den verteidigten Systemen.

Und ein ganz wichtiges Thema haben wir bisher nicht betrachtet, das ist die Frage, wie es mit der Uhrzeit in so einem verteidenden System ist.

Das heißt, nicht unbedingt mit der Uhrzeit, aber überhaupt mit dem, was es mit dem Thema Zeit auf sich hat.

Und darum geht es im Wesentlichen jetzt heute in der Vorlesung.

Die Frage ist zuerst natürlich, warum brauchen wir gemeinsame Zeiten im verteidenden System?

Welche Probleme haben wir sonst, wenn wir eben keine gemeinsamen Zeiten haben?

Dann die Frage, wo liegen die Probleme bei der Synchronisation von Uhren und wie bekommt man sie in den Griff?

Eine Lösung ist letztendlich, dass man nicht mit physikalischen Uhren arbeitet, sondern mit logischen Uhren.

Da werde ich mal zwei Modelle vorstellen, Lampert-Uren und Vektor-Uren.

Das ist eigentlich in all den Fällen, wo wir aufgrund von Algorithmen genauer Aussagen über kausale Abhängigkeiten brauchen.

Oder über potenzielle kausale Abhängigkeiten.

Wo uns letztendlich also physikalisch synchronisierte Zeiten einfach nicht reichen, weil Ereignisse so schnell aufeinander folgen,

dass die maximal mögliche physikalische Synchronisation nicht ausreicht.

Man muss halt einfach sehen, wir reden über Gigahertz getaktete Prozessoren.

Also letztendlich einzelne Ereignisse liegen im Bereich von Bruchteilen von nanosekunden.

Und wenn wir gut physikalisch synchronisieren können, dann liegen wir im Bereich von Mikrosekunden.

So und damit reden wir also nach wie vor eben über einen Faktor weit über 1000. Und 1000 Ereignisse hin oder her ist halt keine Kleinigkeit.

Wenn ich also über die Abhängigkeiten von Ereignissen nachdenke oder ob ein Ereignis vor einem anderen stattgefunden hat oder nicht.

Und an den Stellen, wo wir damit halt einfach ein Problem haben bei dieser Genauigkeit,

kommt man letztendlich nicht drum herum dann eben mit logischen Uhren zu arbeiten.

Und gerade verteilte Algorithmen brauchen sowas an einigen Stellen.

Und an den Stellen, wo es halt eigentlich nur darum geht, dass mehr oder weniger doch die Rechner mehr oder weniger gleiche Zeit haben

und wir vielleicht über eine Granularität von, wenn wir an Unix denken, Prozessgranularität, ich erzeug eine Datei, ein Compiler erzeugt eine Datei.

Dann erzeugt er vielleicht noch eine Datei oder so.

Also da reden wir dann ja schon über Zeiten, die deutlich im Mikrosekunden, wenn nicht im Millisekunden- oder Sekundenbereich liegen.

Und da tut es uns dann natürlich sowas wie physikalisch ordentlich synchronisierte Uhren ganz gut.

Gut und da will ich dann zwei Protokolle oder zwei Algorithmen vorstellen, den Konvergenzalgorithmus, CNV von Lampard auch wieder.

Und das Network Time-Protokoll, das letztendlich der Algorithmus, der in der Praxis heutzutage im Internet im Masseneinsatz ist

und der die Basis dafür ist, dass eigentlich die meisten Rechner doch relativ gut synchronisierte Uhren haben.

Was ist unser Problem jetzt nun eigentlich?

Also wenn ich jetzt so ein Kommando wie Make betrachte, beispielsweise, kennt ja jeder aus der Systemprogrammierung,

da eine Funktionalität davon ist ja, dass nur die Dateien neu generiert werden, die auch neu generiert werden müssen,

bei denen sich also die Quelle seit der letzten Generierung von der Zieldatei verändert hat.

Solange das auf einem Rechner ist, ist das alles kein Problem.

Der Rechner erzeugt Zeitstempel an den Dateien und indem man die vergleicht, kann man so eine Entscheidung treffen.

Wenn jetzt natürlich die Dateien auf verschiedenen Rechnern liegen und auf dem einen Rechner kombiniere ich zum Beispiel die Datei XYZ.C,

weil ich die über ein Network File System gemountet habe, dann kann es sein, dass ich zum Zeitpunkt 21.44, was immer auch das sein mag,

die Datei XYZ.O erzeuge.

Und wenn jetzt die Uhr auf dem anderen Rechner nachgeht, dann kann es sein, dass zu einem späteren Zeitpunkt die Datei XYZ.C verändert wird,

wieder abgespeichert wird und dann ist der Zeitstempel hier 21.43, weil das ja auf dem Knoten 2 passiert.

Und damit die Datei hat dann auch den Zeitstempel 21.43 und die Datei XYZ.O auf dem Knoten 1, die dort erzeugt wurde,

hat den Zeitstempel 21.44 und damit ist die natürlich nach wie vor neuer.

Und die Datei würde eben nicht neu kompiliert werden.

So, damit haben wir jetzt natürlich ein Problem.

Wenn wir wieder Make aufrufen, würden die Korrekturen nicht übernommen werden und das verwirrt natürlich den Softwareentwickler massiv,

weil er natürlich damit nicht rechnet irgendwie und dann hat er was geändert und das taucht hinterher im Kompilat nicht auf.

Aber daran sieht man letztendlich auch schon, alleine wenn man mal die Zeitstempel von Unix-Dateien betrachtet,

dann sind diese sowieso bloß mit Sekundengenauigkeit.

Das heißt also da, wenn wir jetzt physikalisch synchronisierte Uhren hätten, tut es uns das.

Dann ist das gut und ich meine, das ist ja auch die Praxis, die wir heutzutage haben.