diff options
Diffstat (limited to 'LaTeX/chapters')
| -rw-r--r-- | LaTeX/chapters/conclusion.tex | 8 | ||||
| -rw-r--r-- | LaTeX/chapters/implementierung.tex | 214 | ||||
| -rw-r--r-- | LaTeX/chapters/introduction.tex | 28 | ||||
| -rw-r--r-- | LaTeX/chapters/protokolle.tex | 749 | ||||
| -rw-r--r-- | LaTeX/chapters/simulator.tex | 837 | ||||
| -rw-r--r-- | LaTeX/chapters/titlepage.tex | 11 |
6 files changed, 922 insertions, 925 deletions
diff --git a/LaTeX/chapters/conclusion.tex b/LaTeX/chapters/conclusion.tex index 677300b..5806e03 100644 --- a/LaTeX/chapters/conclusion.tex +++ b/LaTeX/chapters/conclusion.tex @@ -1,10 +1,10 @@ \chapter{Ausblick}
-Es wurde erfolgreich ein Simulator für die Simulation verteilter Systeme entwickelt. Der Simulator hat bereits 10 implementierte Protokolle zur Auswahl eingebaut. Zudem steht dem Gebraucher ein sehr komfortables Protokoll-API zur Verfügung, womit der Entwicklung neuer Protokolle quasi keine Grenzen gesetzt sind.
+Es wurde erfolgreich ein Simulator für die Simulation verteilter Systeme entwickelt. Der Simulator hat bereits 10 implementierte Protokolle zur Auswahl eingebaut. Zudem steht dem Anwender ein sehr komfortables Protokoll-API zur Verfügung, womit der Entwicklung neuer Protokolle quasi keine Grenzen gesetzt sind.
Darüber hinaus verfügt der Simulator über eine Vielzahl von sehr flexiblen Einstellungsmöglichkeiten. Für jede Simulation lassen sich somit komplett andere Konfigurationen verwenden. Jeder beteiligte Prozess hat wiederum eigene lokale Einstellungen, wo sich auch jedes Protokoll für jeden Prozess separat einstellen läßt. Die Anzahl und Flexibilität der Möglichen Szenarien wird dadurch um einen sehr großen Faktor erweitert.
-Mit dem Ereigniseditor gibt es eine komfortable Möglichkeit eigene Szenarien zu programmieren um sie anschließend zu Simulieren. Hierbei kann entweder auf die bereits enthaltenen Protokolle- oder auf selbst implementierte Protokolle zugegriffen werden. Alle Dazugehörigen Einstellungen und programmierten Ereignisse lassen sich vom Gebraucher für eine spätere Wiederverwendung plattformunabhängig abspeichern. Somit können auch abgespeicherte Szenarien beispielsweise an Kommilitonen weitergegeben werden oder für eine spätere Präsentierung zwischengespeichert werden. Mit dem Loggfilter lassen sich mithilfe von regulären Ausdrücken nur die relevanten Loggnachrichten anzeigen, was die Analyse einer Simulation erheblich vereinfacht. Weitere Funktionalitäten wie Lamport- und Vektor-Zeitstempel sowie Anti-Aliasing runden den Simulator ab.
+Mit dem Ereigniseditor gibt es eine komfortable Möglichkeit eigene Szenarien zu programmieren um sie anschließend zu Simulieren. Hierbei kann entweder auf die bereits enthaltenen Protokolle- oder auf selbst implementierte Protokolle zugegriffen werden. Alle Dazugehörigen Einstellungen und programmierten Ereignisse lassen sich vom Anwender für eine spätere Wiederverwendung plattformunabhängig abspeichern. Somit können auch abgespeicherte Szenarien beispielsweise an Kommilitonen weitergegeben werden oder für eine spätere Präsentierung zwischengespeichert werden. Mit dem Logfilter lassen sich mit Hilfe von regulären Ausdrücken nur die relevanten Lognachrichten anzeigen, was die Analyse einer Simulation erheblich vereinfacht. Weitere Funktionalitäten wie Lamport- und Vektor-Zeitstempel sowie Anti-Aliasing runden den Simulator ab.
Durch den objektorientierten Aufbau ist der Simulator relativ einfach erweiterbar, was nicht nur das Protokoll-API betrifft. Insgesamt wurde an den meisten Stellen darauf geachtet, dass zu einem sp\"{a}teren Zeitpunkt Erweiterungen einfließen k\"{o}nnten. Insbesondere soll die Serialisierung von Objekten r\"{u}ckw\"{a}rtskompatibel bleiben, da sonst bei jeder neuen Simulatorversion alle Simulationen erneut angelegt und abgespeichert werden m\"{u}ssten.
@@ -12,7 +12,7 @@ Hätte für diese Diplomarbeit noch mehr Zeit zur Verfügung gestanden, dann könnte \begin{itemize}
\item Die M\"{o}glichkeit Protokolle zu entwickeln ohne den kompletten Quelltext des Simulators vorliegen zu haben. Protokollklassen also als separate Bibliothek einbinden, die dynamisch geladen werden k\"{o}nnen.
- \item Die Simulationsdauer beliebig lang machen können. Dazu müsste \textit{VSSimulatorVisualisation} entlang der Zeitachse scrollbar gemacht werden, sodass der Benutzer für eine nachträgliche Betrachtung des Simulationsverlaufes zu jeder beliebigen Position zurückspringen kann.
+ \item Die Simulationsdauer beliebig lang machen können. Dazu müsste \textit{VSSimulatorVisualisation} entlang der Zeitachse scrollbar gemacht werden, so dass der Benutzer für eine nachträgliche Betrachtung des Simulationsverlaufes zu jeder beliebigen Position zurückspringen kann.
\item Eine Zoomfunktion für die Simulationsvisualisierung einbauen.
\item Im Ereigniseditor selbst auch periodische Ereignisse programmierbar machen. Bisher kann nur jedes Ereignis separat programmiert werden oder auf Protokoll-Interne Wecker zurückgegriffen werden.
\item Lamport- und Vektor-Zeitstempel als Ereigniseintrittskriterien verwenden können.
@@ -20,4 +20,4 @@ Hätte für diese Diplomarbeit noch mehr Zeit zur Verfügung gestanden, dann könnte \item Weitere Funktionalitäten einbauen wie zum Beispiel das Anklicken einer Nachrichtenlinie, was zu einer Nachricht alle verfügbaren Informationen anzeigt und diese gegebenenfalls vom Benutzer editiert werden können.
\end{itemize}
-Da der Simulator höchstwahrscheinlich unter einer Open Source Lizenz freigegeben wird, und ich mich selbst sehr für die Entwicklung und Anwendung von Open Source Software interessiere, werden die einen oder anderen Funktionen nachträglich eingebaut werden. Kommilitonen werden auch herzlich dazu eingeladen sein sich an diesem Software-Projekt zu beteiligen. Als Vorbild sei hier der CPU-Simulator M32, der von Prof. Oßmann an der Fachhochschule Aachen entwickelt wurde, genannt. Hier existieren bereits einige Erweiterungen und Verbesserungen der Ursprungsversion, die von den Studenten angefertigt wurden. Für die Entwicklung/Erweiterung wurde keine proprietäre Software verwendet, sodass jeder kostenlosen Zugriff auf die dazugehörigen Tools hätte.
+Da der Simulator höchstwahrscheinlich unter einer Open Source Lizenz freigegeben wird, und ich mich selbst sehr für die Entwicklung und Anwendung von Open Source Software interessiere, werden die einen oder anderen Funktionen nachträglich eingebaut werden. Kommilitonen werden auch herzlich dazu eingeladen sein sich an diesem Software-Projekt zu beteiligen. Als Vorbild sei hier der CPU-Simulator M32, der von Prof. Oßmann an der Fachhochschule Aachen entwickelt wurde, genannt. Hier existieren bereits einige Erweiterungen und Verbesserungen der Ursprungsversion, die von den Studenten angefertigt wurden. Für die Entwicklung/Erweiterung wurde keine proprietäre Software verwendet, so dass jeder kostenlosen Zugriff auf die dazugehörigen Tools hätte.
diff --git a/LaTeX/chapters/implementierung.tex b/LaTeX/chapters/implementierung.tex index c264a18..2183e07 100644 --- a/LaTeX/chapters/implementierung.tex +++ b/LaTeX/chapters/implementierung.tex @@ -1,6 +1,6 @@ -\chapter{Die Implementierung}
+\chapter{Implementierung}
-In diesem Kapitel wird auf die Implementierung des Simulators eingegangen. Der Simulator wurde in der Programmiersprache Java entwickelt. Bei der Betrachtung der Zielgruppe wird klar, dass Java für die gestellte Aufgabe die geeignetste Programmiersprache ist. Der Simulator ist somit auf jeder Plattform verfügbar, für die es die JRE (Java Runtime Environment) gibt und erstreckt sich somit über alle gängigen Betriebssysteme. Da an der Fachhochschule Aachen auch Java gelehrt wird, sollten hier die meisten Studenten auch eigene Erweiterungen, wie eigene Protokolle, entwerfen können. Der Simulator wurde mit dem derzeit aktuellsten Java SDK (Software Development Kit) in der Version 6 (1.6) entwickelt.
+In diesem Kapitel wird auf die Implementierung des Simulators eingegangen. Der Simulator wurde in der Programmiersprache Java entwickelt. Bei der Betrachtung der Zielgruppe wird klar, dass Java für die gestellte Aufgabe die geeignetste Programmiersprache ist. Der Simulator ist somit auf jeder Plattform verfügbar, für die es die JRE (Java Runtime Environment) gibt, und erstreckt sich somit über alle gängigen Betriebssysteme. Da an der Fachhochschule Aachen auch Java gelehrt wird, sollten hier die Studenten auch eigene Erweiterungen, wie eigene Protokolle, entwerfen können. Der Simulator wurde mit dem derzeit aktuellsten Java SDK (Software Development Kit) in der Version 6 (1.6) entwickelt.
\begin{table}
\fbox{
@@ -26,15 +26,15 @@ In diesem Kapitel wird auf die Implementierung des Simulators eingegangen. Der S \label{tb:Pakete}
\end{table}
-Da es sonst den Rahmen sprengen würde, soll im Folgenden der komplette Quelltext nicht bis in das letzte Detail behandelt werden. Der Quelltext erstreckt sich nämlich, einschließlich Kommentare, auf über 15.000 Zeilen und über 61 Dateien. Zudem ist die generierte Quelltext-Dokumentation (Javadoc) über 2MB groß. Alle folgenden UML-Diagramme stellen aufgrund der Übersichtlichkeit lediglich die wesentlichen Dinge dar. Alle Details lassen sich im Quelltext und der dazugehörigen Dokumentation einsehen. Die Paketstruktur des Quelltextes ist in Tabelle \ref{tb:Pakete} in alphanumerischer Reihenfolge aufgeführt.
+Da es sonst den Rahmen sprengen würde, soll im Folgenden der komplette Quelltext nicht bis in das letzte Detail behandelt werden. Der Quelltext erstreckt sich nämlich, einschließlich Kommentare, auf über 15.000 Zeilen und über 61 Dateien. Zudem ist die generierte Quelltext-Dokumentation (Javadoc) über 2MB groß. Alle folgenden UML-Diagramme stellen aufgrund der Übersichtlichkeit lediglich die wesentlichen Dinge dar. Alle Details lassen sich im Quelltext und der dazugehörigen Dokumentation einsehen. Die Paketstruktur des Quelltextes ist in Tabelle \ref{tb:Pakete}. in alphanumerischer Reihenfolge aufgeführt.
\section{Einstellungen und Editoren}
-Eine Simulation ist von einer Vielzahl von Einstellungen abhängig. Da auf diese Einstellungen in den weiteren Teilkapitel stets zurückgegriffen wird, macht es Sinn die dazugehörigen Klassen zuerst zu betrachten.
+Eine Simulation ist von einer Vielzahl von Einstellungen abhängig. Da auf diese Einstellungen in den weiteren Teilkapitel stets zurückgegriffen wird, macht es Sinn, die dazugehörigen Klassen zuerst zu betrachten.
-\subsection{Einstellungsobjekte}
+\subsubsection{Einstellungsobjekte}
-Auf Abbildung \ref{fig:PackagePrefs} ist der Aufbau des Pakets \textit{prefs} zu sehen. In einer Instanz der Klasse \textit{VSPrefs} lassen sich viele verschiedene Daten als Variablen für eine spätere Verwendung dynamisch ablegen und stellt somit einen Container für diese Daten dar. In einem \textit{VSPrefs}-Objekt speichert der Simulator alle seine Einstellungen ab. Zudem besitzt jedes Prozessobjekt und jedes Ereignisobjekt für lokale Einstellungen seine eigene Instanz von \textit{VSPrefs}. Später wird noch erklärt, dass Protokollobjekte auch als Ereignisse eingesetzt werden. Somit können Protokolleinstellungen auch in ein \textit{VSPrefs}-Objekt abgespeichert werden. Selbst Nachrichtenobjekte besitzt hiervon eine eigene Instanz, wobei hier die zu verschickenden Daten abgelegt werden können.
+Auf Abbildung \ref{fig:PackagePrefs}. ist der Aufbau des Pakets \textit{prefs} zu sehen. In einer Instanz der Klasse \textit{VSPrefs} lassen sich viele verschiedene Daten als Variablen für eine spätere Verwendung dynamisch ablegen und stellt somit einen Container für diese Daten dar. In einem \textit{VSPrefs}-Objekt speichert der Simulator alle seine Einstellungen ab. Zudem besitzt jedes Prozessobjekt und jedes Ereignisobjekt für lokale Einstellungen seine eigene Instanz von \textit{VSPrefs}. Später wird noch erklärt, dass Protokollobjekte auch als Ereignisse eingesetzt werden, womit Protokolleinstellungen auch in einem \textit{VSPrefs}-Objekt abgespeichert werden k\"{o}nnen. Selbst Nachrichtenobjekte besitzt hiervon eine eigene Instanz, wobei hier die zu verschickenden Daten abgelegt werden.
\begin{figure}[h]
\centering
@@ -43,11 +43,11 @@ Auf Abbildung \ref{fig:PackagePrefs} ist der Aufbau des Pakets \textit{prefs} zu \label{fig:PackagePrefs}
\end{figure}
-Jede Variable besteht aus einen Datentypen, einen Variablennamen und einer optionalen Beschreibung sowie einen Wert. Einige Datentypen unterstützen auch die Angabe von Minimal- und Maximalwerten (zum Beispiel besteht eine Prozentangabe aus einen Integerwert zwischen \textit{0} und \textit{100}), was mithilfe der \textit{VSPrefsRestriction}-Klasse implementiert wird. Da man beispielsweise bei Prozent ein \textit{\%} und bei Millisekunden ein \textit{ms} hinter der Variable sehen möchte, kann für jede Variable auch ein optionaler Einheiten-String abgespeichert werden.
+Jede Variable besteht aus einen Datentypen, einen Variablennamen und einer optionalen Beschreibung sowie einen Wert. Einige Datentypen unterstützen auch die Angabe von Minimal- und Maximalwerten (zum Beispiel besteht eine Prozentangabe aus einen Integerwert zwischen \textit{0} und \textit{100}), was mit Hilfe der \textit{VSPrefsRestriction}-Klasse implementiert wird. Da der Anwender beispielsweise bei Prozent ein \textit{\%} und bei Millisekunden ein \textit{ms} hinter der Variable sehen möchte, kann für jede Variable auch ein optionaler Einheiten-String abgespeichert werden.
-Eine Variablenbeschreibung wird für die Darstellung im GUI verwendet, während der Variablenname eher für die interne Verwendung vom Simulator verwendet wird. Zum Beispiel hat die Variable \textit{message.prob.outage} (Verlustwahrscheinlichkeit einer Nachricht) als Variablenbeschreibung ``Nachrichtenverlustw'keit''. Wenn für eine Variable keine Beschreibung existiert so wird, wie auf Abbildung \ref{fig:SimulationseinstellungenExperten} anhand der Farbvariablen schon gesehen wurde, für die Anzeige einer Variable der Datentyp und der Variablenname verwendet. Variablennamen verwenden die auf Tabelle \ref{tb:VariablenPrefixe} angegebenen Prefixkonventionen. Alle verfügbaren Typen wurden bereits in Tabelle \ref{tb:VariablenDatentypen} aufgelistet. \textit{VSPrefs} stellt für alle Variablentypen entsprechende Zugriffsmethoden zur Verfügung.
+Eine Variablenbeschreibung wird für die Darstellung im GUI verwendet, während der Variablenname eher für die interne Verwendung vom Simulator verwendet wird. Zum Beispiel hat die Variable \textit{message.prob.outage} (Verlustwahrscheinlichkeit einer Nachricht) als Variablenbeschreibung ``Nachrichtenverlustw'keit''. Wenn für eine Variable keine Beschreibung existiert so wird, wie auf Abbildung \ref{fig:SimulationseinstellungenExperten}. anhand der Farbvariablen schon gesehen wurde, für die Anzeige einer Variable der Datentyp und der Variablenname verwendet. Variablennamen verwenden die auf Tabelle \ref{tb:VariablenPraefixe}. angegebenen Präfixkonventionen. Alle verfügbaren Typen wurden bereits in Tabelle \ref{tb:VariablenDatentypen}. aufgelistet. \textit{VSPrefs} stellt für alle Variablentypen entsprechende Zugriffsmethoden zur Verfügung.
-Im Folgenden werden nicht alle existierenden Methoden aufgelistet, da diese auch in der Quelltext-Dokumentation eingesehen werden können. Die Methoden werden nun nur anhand des Integer-Datentyps verdeutlicht. Für alle anderen Typen gilt fast alles analog. Für Integer stehen in \textit{VSPrefs} folgende Methoden zur Verfügung:
+Im Folgenden werden nicht alle existierenden Methoden aufgelistet, da diese auch in der Quelltext-Dokumentation eingesehen werden können. Stattdessen werden die Methoden nur anhand des Integer-Datentyps verdeutlicht. Für alle anderen Typen gilt fast alles analog. Für Integer stehen in \textit{VSPrefs} folgende Methoden zur Verfügung:
\begin{itemize}
\setlength{\itemsep}{-2mm}
@@ -69,10 +69,10 @@ Im Folgenden werden nicht alle existierenden Methoden aufgelistet, da diese auch \begin{table}
\fbox{
\begin{tabular}{c|l|l}
- \textbf{Variablen-Prefix} & \textbf{Beschreibung} & \textbf{Beispiel}\\
+ \textbf{Variablen-Präfix} & \textbf{Beschreibung} & \textbf{Beispiel}\\
\hline
\textit{col} & Farbvariablen & \textit{Color: col.background = Color-Objekt}\\
- \textit{div} & Diverse versteckte Variablen & \textit{Integer: div.window.loggsize = 300} \\
+ \textit{div} & Diverse versteckte Variablen & \textit{Integer: div.window.logsize = 300} \\
\textit{keyevent} & Variablen, die Tastaturkürzel definieren & \textit{Integer: keyevent.close = KeyEvent.VK\_C} \\
\textit{lang} & Variablen, die Text beinhalten & \textit{String: lang.activate = aktivieren}\\
\textit{message} & Variablen, die Nachrichten betreffen & \textit{Integer: message.prob.outage = 0}\\
@@ -81,26 +81,26 @@ Im Folgenden werden nicht alle existierenden Methoden aufgelistet, da diese auch \end{tabular}
}
\caption{Konventionen für Variablennamen-Präfixe in \textit{VSDefautPrefs}}
- \label{tb:VariablenPrefixe}
+ \label{tb:VariablenPraefixe}
\end{table}
Hierbei stellt \textit{key} den Variablennamen- und \textit{val} den Variablenwert dar. \textit{descr} ist eine optionale Variablenbeschreibung. Es können sowohl Java's Integer-Objekte, als auch Java's primitiver Integer-Typ \textit{int} verwendet werden. Ein \textit{int}-Wert wird intern allerdings als Integer-Objekt abgespeichert (für eine spätere Serialisierung, mehr dazu aber später) und macht somit keinen großen Unterschied. Die Methode \textit{getIntegerKeySet} gibt alle vorhandenen Integer-Variablennamen (\textit{key}s) als \textit{Set} zurück.
-\textit{VSPrefs} bietet auch eine Reihe von \textit{initInteger}-Methoden an, welche sich von den \textit{setInteger}-Methoden dadurch unterscheiden, dass sie eine Variable nur einen Wert zuweisen, wenn sie vorher noch nicht initialisiert wurde, was durch \textit{setInteger} oder \textit{initInteger} selbst geschehen sein kann. Eine komplette Übersicht aller Methoden (auch für andere Datentypen) gibt es in der Quelltext-Dokumentation.
+\textit{VSPrefs} bietet auch eine Reihe von \textit{initInteger}-Methoden an, welche sich von den \textit{setInteger}-Methoden dadurch unterscheiden, dass sie einer Variable nur einen Wert zuweisen, wenn sie vorher noch nicht initialisiert wurde, was durch \textit{setInteger} oder \textit{initInteger} selbst geschehen sein kann. Eine komplette Übersicht aller Methoden (auch für andere Datentypen) gibt es in der Quelltext-Dokumentation.
-\textit{VSPrefs} speichert alle Integervariablen in einem \textit{HashMap<String,Integer>}-Objekt ab, wobei der String-Wert den Variablennamen \textit{key} angibt. Für die Beschreibung \textit{descr}, den Einheiten-String \textit{unit} sowie möglichen Minimal- und Maximalwerte werden separate Instanzen von \textit{HashMap} verwendet. Da alle \textit{HashMap}-Objekte synchronisiert sind, können alle Methoden von verschiednenen Threads gleichzeitig verwendet werden.
+\textit{VSPrefs} speichert alle Integervariablen in einem \textit{HashMap<String,Integer>}-Objekt ab, wobei der String-Wert den Variablennamen \textit{key} angibt. Für die Beschreibung \textit{descr}, den Einheiten-String \textit{unit} sowie möglichen Minimal- und Maximalwerte werden separate Instanzen von \textit{HashMap} verwendet. Da alle \textit{HashMap}-Objekte synchronisiert sind, können alle Methoden von \textit{VSPrefs} aus verschiednenen Threads gleichzeitig verwendet werden.
\textit{VSSerializablePrefs} implementiert das Interface \textit{VSSerializable} und kann somit alle enthaltenen Daten in eine Datei abspeichern beziehungsweise laden. Auf die Serialisierung und Deserialisierung von Simulationen wird später genauer eingegangen.
-Die Klasse \textit{VSDefaultPrefs} erweitert \textit{VSSerializablePrefs} und initialisiert bei Instantiierung automatisch alle verfügbaren Simulationsvariablen (bereits schon \"{u}ber 160) mit ihren Standardwerten. Dort sind auch alle Spracheinstellungen abgelegt. Sollte jemand den Simulator in eine andere Sprache, zum Beispiel ins Englische, übersetzen wollen, so muss er lediglich diese Datei und die Protokoll-Klassen (mehr dazu später) editieren. Die Spracheinstellungen sind nämlich in einem \textit{VSPrefs}--Objekt als versteckte String-Variablen abgespeichert. Spracheinstellungen für Protokolle wurden in den Protokollklassen direkt angegeben, da dies mehr Komfort für den Protokollentwickler bietet und für jede neue Textausgabe nicht ständig \textit{VSDefaultPrefs.java} editiert werden muss.
+Die Klasse \textit{VSDefaultPrefs} erweitert \textit{VSSerializablePrefs} und initialisiert bei Instantiierung automatisch alle verfügbaren Simulationsvariablen (bereits schon \"{u}ber 160) mit ihren Standardwerten. Dort sind auch alle Spracheinstellungen abgelegt. Sollte jemand den Simulator in eine andere Sprache, zum Beispiel ins Englische, übersetzen wollen, so muss er lediglich diese Datei und die Protokoll-Klassen (mehr dazu später) editieren. Die Spracheinstellungen sind einem \textit{VSPrefs}-Objekt als versteckte String-Variablen abgespeichert. Spracheinstellungen für Protokolle wurden in den Protokollklassen direkt angegeben, da dies mehr Komfort für den Protokollentwickler bedeutet und für jede neu programmierte Textausgabe nicht ständig \textit{VSDefaultPrefs.java} editiert werden muss.
-Alle Variablen die als Prefix \textit{lang}, \textit{keyevent}, \textit{div} oder \textit{col} im Namen tragen, sind versteckte Variablen und werden in einem Editor nicht angezeigt. Im Expertenmodus sind hingegen nur Variablen die mit \textit{lang} und \textit{keyevent} beginnen versteckt. Somit lassen sich im Expertenmodus weitere Variablen vom Anwender editieren.
+Alle Variablen die als Präfix \textit{lang}, \textit{keyevent}, \textit{div} oder \textit{col} im Namen tragen, sind versteckte Variablen und werden in einem Editor nicht angezeigt. Im Expertenmodus sind hingegen nur Variablen, die mit \textit{lang} und \textit{keyevent} beginnen, versteckt. Somit lassen sich im Expertenmodus weitere Variablen vom Anwender editieren.
-\subsection{Editorobjekte}
+\subsubsection{Editorobjekte}
-Wie Variablen intern abgespeichert werden ist bereits bekannt. Für das Editieren der Variablen werden Editor-Objekte verwendet. Auf Abbildung \ref{fig:PackagePrefsEditors} ist die Klassenstruktur des dazugehörigen Paketes \textit{prefs.editors} angegeben.
+Wie Variablen intern abgespeichert werden, ist bereits bekannt. Für das Editieren der Variablen werden Editor-Objekte verwendet. Auf Abbildung \ref{fig:PackagePrefsEditors}. ist die Klassenstruktur des dazugehörigen Paketes \textit{prefs.editors} angegeben.
-Die Basis eines Editors stellt die abstrakte Klasse \textit{VSAbstractEditor} dar, dem ein \textit{VSPrefs} Objekt zum Editieren übergeben wird. Ein Editor stellt alle verfügbaren nicht-versteckten Variablen des \textit{VSPrefs}-Objektes im GUI dar und bietet gleichzeitig die Möglichkeit alle Variablen darüber zu editieren an. Für das Editieren von Farbwerten wird auf \textit{VSColorChooser} zurückgegriffen. Die Klasse \textit{VSEditorTable} ist für das \textit{JTable}-Objekt aus Java's Swing-Bibliothek zuständig, welches bei der graphischen Darstellung aller Variablen eingesetzt wird. Die abstrakte Klasse \textit{VSAbstractBetterEditor} wurde, wegen der Übersicht, als Zwischenschritt eingefügt.
+Die Basis eines Editors stellt die abstrakte Klasse \textit{VSAbstractEditor} dar, dem ein \textit{VSPrefs} Objekt zum Editieren übergeben wird. Ein Editor stellt alle verfügbaren nicht-versteckten Variablen des \textit{VSPrefs}-Objektes im GUI dar und bietet gleichzeitig die Möglichkeit, alle Variablen darüber zu editieren. Für das Editieren von Farbwerten wird auf \textit{VSColorChooser} zurückgegriffen. Die Klasse \textit{VSEditorTable} ist für das \textit{JTable}-Objekt aus Java's Swing-Bibliothek zuständig, welches bei der graphischen Darstellung aller Variablen eingesetzt wird. Die abstrakte Klasse \textit{VSAbstractBetterEditor} wurde, wegen der Übersicht, als Zwischenschritt eingefügt.
\begin{figure}[h]
\centering
@@ -109,13 +109,13 @@ Die Basis eines Editors stellt die abstrakte Klasse \textit{VSAbstractEditor} da \label{fig:PackagePrefsEditors}
\end{figure}
-Die Klasse \textit{VSSimulatorEditor} dient für das Editieren der globalen Simulationseinstellungen und \textit{VSProcessEditor} für das Editieren der Prozesseinstellungen sowie der dazugehörigen Protokollvariablen. Da diese beiden Klassen von \textit{VSAbstractBetterEditor} erben, können sie mithilfe von \textit{VSEditorFrame} in einem separaten Fenster angezeigt werden. Alternativ können die Editoren auch in der Sidebar im Tab ``Variablen'' angezeigt werden. Auf Abbildung \ref{fig:Simulationseinstellungen} wurde bereits ein \textit{VSEditorFrame} in Aktion gesehen. Auf Abbildung \ref{fig:NeueSimulationVariablen} wurde hingegen ein Prozesseditor in der Sidebar geöffnet. Für Protokolle gibt es keine separate Editor-Klasse, da sie bereits vom Prozesseditor aus editiert werden können. Dabei iteriert der Prozesseditor über alle für den jeweiligen Prozess verfügbaren Protokollobjekte und fügt deren Variablen zusätzlich in den Prozesseditor ein. Somit erscheinen die Prozess- und die dazugehörigen Protokollvariablen im selben Editor und bieten dem Benutzer so eine bessere Übersicht.
+Die Klasse \textit{VSSimulatorEditor} dient für das Editieren der globalen Simulationseinstellungen und \textit{VSProcessEditor} für das Editieren der Prozesseinstellungen sowie der dazugehörigen Protokollvariablen. Da diese beiden Klassen von \textit{VSAbstractBetterEditor} erben, können sie mit Hilfe von \textit{VSEditorFrame} in einem separaten Fenster angezeigt werden. Alternativ können die Editoren auch in der Sidebar im Tab ``Variablen'' angezeigt werden. Auf Abbildung \ref{fig:Simulationseinstellungen}. wurde bereits ein \textit{VSEditorFrame} in Aktion gesehen. Auf Abbildung \ref{fig:NeueSimulationVariablen}. wurde hingegen ein Prozesseditor in der Sidebar geöffnet. Für Protokolle gibt es keine separate Editor-Klasse, da sie bereits vom Prozesseditor aus editiert werden können. Dabei iteriert der Prozesseditor über alle für den jeweiligen Prozess verfügbaren Protokollobjekte und fügt deren Variablen in den Prozesseditor zusätzlich ein. Somit erscheinen die Prozess- und die dazugehörigen Protokollvariablen im selben Editor und bieten dem Benutzer so eine bessere Übersicht.
\section{Ereignisse}
-\subsection{Funktionsweise von Ereignissen}
-
Für jedes Ereignis existiert eine dazugehörige Klasse, welche die auszuführenden Aktionen implementiert. Eine Instanz davon wird für eine spätere Ausführung dem Task-Manager übergeben. Auf den Task-Manager wird später noch genauer eingegangen.
+Jedes programmierbare Ereignis muss, bevor es vom Simulator verwendet werden kann, in der statischen Klasse \textit{VSRegisteredEvents} registriert werden. Der Simulator bezieht alle verf\"{u}gbaren Ereignisse aus \textit{VSRegisterEvents}, womit der Entwickler bei jeder Entwicklung eines neuen Ereignisses keine andere Stelle mehr im Quelltext des gesamten Simulators \"{a}ndern muss. Da sich die Anzahl der verfügbaren Ereignisklassen des Simulators bei Laufzeit nicht ändert, gibt es keine Instanzen von \textit{VSRegisteredEvents}. Alle Methoden und Klassenattribute sind hier statisch. Wenn beispielsweise eigene Ereignisse implementiert werden, dann müssen alle neuen Ereignisse per Hand in die Datei \textit{VSRegisteredEvents.java} übernommen- und der Simulator neu kompiliert werden.
+
\begin{figure}[h]
\centering
\includegraphics[width=13.5cm]{images/events}
@@ -123,9 +123,7 @@ Für jedes Ereignis existiert eine dazugehörige Klasse, welche die auszuführenden \label{fig:PackageEvents}
\end{figure}
-Jedes programmierbare Ereignis muss, bevor es vom Simulator verwendet werden kann, in der statischen Klasse \textit{VSRegisteredEvents} registriert werden. Da sich die Anzahl der verfügbaren Ereignisklassen des Simulators bei Laufzeit nicht ändert, gibt es keine Instanzen von \textit{VSRegisteredEvents}. Alle Methoden und Klassenattribute sind hier statisch. Wenn beispielsweise eigene Ereignisse implementiert werden, dann müssen alle neuen Ereignisse per Hand in die Datei \textit{VSRegisteredEvents.java} übernommen- und der Simulator neu kompiliert werden.
-
-In der Implementierung wird zwischen drei Haupttypen von Ereignissen unterschieden, die jeweils in verschiedenen Paketen liegen (Abbildung \ref{fig:PackageEvents}):
+In der Implementierung wird zwischen drei Haupttypen von Ereignissen unterschieden, die jeweils in verschiedenen Paketen liegen (Abbildung \ref{fig:PackageEvents}.):
\begin{enumerate}
\item \textit{events.implementations}: In diesem Paket befinden sich alle Ereignisse, die ohne weitere Spezialbehandlung vom Simulator eingesetzt werden können und vom Benutzer direkt im Ereigniseditor programmierbar sind.
@@ -134,14 +132,14 @@ In der Implementierung wird zwischen drei Haupttypen von Ereignissen unterschied \item \textit{VSProcessRecoverEvent}: Dieses Ereignis lässt den dazugehörigen Prozess wiederbeleben.
\end{itemize}
- \item \textit{events.internal}: In diesem Paket befinden sich alle Ereignisse, die vom Simulator intern verwendet werden. Bevor der Simulator von diesen Ereignissen Gebrauch machen kann, muss er vorher einige Spezialbehandlungen durchführen.
+ \item \textit{events.internal}: In diesem Paket befinden sich alle Ereignisse, die vom Simulator intern verwendet werden.
\begin{itemize}
- \item \textit{VSAbstractInternalEvent}: Diese Klasse stellt weitere Methoden zur Verfügung, die von allen internen Ereignissen benötigt werden. Derzeit betrifft dies nur Methoden zur Serialisierung der gegebenen Objekte. Auf die Serialisierung (Abspeichern/Laden) von Simulationen wird später noch genauer eingegangen.
- \item \textit{VSMessageReceiveEvent}: Diese Klasse wird für die Ankunft einer Nachricht bei einem Empfängerprozess benötigt. Sie kapselt die eigentliche Nachricht und überprüft, ob der Empfängerprozess das zur Nachricht dazugehörige Protokoll versteht. Diese Klasse überprüft auch die Simulationseinstellung ``Nur relevante Nachrichten anzeigen'' und entscheidet, ob die Nachricht nach Eintreffen in der Visualisierung und im Loggfenster berücksichtigt werden soll oder nicht.
+ \item \textit{VSAbstractInternalEvent}: Diese Klasse stellt weitere Methoden zur Verfügung, die von allen internen Ereignissen benötigt werden. Derzeit betrifft dies nur Methoden zur Serialisierung der gegebenen Objekte.
+ \item \textit{VSMessageReceiveEvent}: Diese Klasse wird für die Ankunft einer Nachricht bei einem Empfängerprozess benötigt. Sie kapselt die eigentliche Nachricht und überprüft, ob der Empfängerprozess das zur Nachricht dazugehörige Protokoll versteht. Diese Klasse überprüft auch die Simulationseinstellung ``Nur relevante Nachrichten anzeigen'' und entscheidet, ob die Nachricht nach Eintreffen in der Visualisierung und im Logfenster berücksichtigt werden soll oder nicht.
\item \textit{VSProtocolEvent}: Diese Klasse implementiert gleichzeitig vier verschiedene Ereignisse: Das Aktivieren/Deaktivieren eines Servers/Clients eines gegebenen Protokolls. Der Ereigniseditor berechnet anhand der verfügbaren Protokolle automatisch alle möglichen Kombinationen und bietet sie dem Anwender in seiner Auswahl an. Für alle dieser vier Ereignisse wird jeweils ein Objekt von \textit{VSProtocolEvent} verwendet, jedoch mit jeweils anderen Attributwerten.
\item \textit{VSProtocolScheduleEvent}: Diese Klasse wird für die Wecker-Ereignisse benötigt. Wecker-Ereignisse können nur von Protokollen (mehr dazu später) erstellt werden. \textit{VSProtocolScheduleEvent} besitzt eine Referenz auf das gegebene Protokoll und ruft bei Ereigniseintrittszeit entweder die Methode \textit{onServerScheduleStart} bei einem Server- oder \textit{onClientScheduleStart} bei einem Clientprotokoll auf.
\end{itemize}
- \item \textit{protocols.implementations}: In diesem Paket befinden sich alle Protokollimplementierung. Jedes Protokoll besitzt hier seine eigene Klasse. Alle Protokolle erben hierbei von der auf Abbildung \ref{fig:PackageEvents} zu sehenden Klasse \textit{protocols.VSAbstractProtocol}. Da \textit{protocols.VSAbstractProtocol} von \textit{events.VSAbstractEvent} erbt, kann ein Protokollobjekt auch als Ereignis eingesetzt werden. Ein solches Ereignis ruft bei Eintritt entweder die Methode \textit{onServerStart} oder die Methode \textit{onClientStart} des Protokolls auf, was einer Server- beziehungsweise einer Clientanfrage entspricht. Die Implementierung von Protokollen wird später genauer behandelt.
+ \item \textit{protocols.implementations}: In diesem Paket befinden sich alle Protokollimplementierung. Jedes Protokoll besitzt hier seine eigene Klasse. Alle Protokolle erben hierbei von der auf Abbildung \ref{fig:PackageEvents}. zu sehenden Klasse \textit{protocols.VSAbstractProtocol}. Da \textit{protocols.VSAbstractProtocol} von \textit{events.VSAbstractEvent} erbt, kann ein Protokollobjekt auch als Ereignis eingesetzt werden. Ein solches Ereignis ruft bei Eintritt entweder die Methode \textit{onServerStart} oder die Methode \textit{onClientStart} des Protokolls auf, was einer Server- beziehungsweise einer Clientanfrage entspricht. Die Implementierung von Protokollen wird später genauer behandelt.
\end{enumerate}
Alle Ereignisse, die das Interface \textit{VSCopyableEvent} implementieren, können vom Anwender im Ereigniseditor mit einem Rechtsklick kopiert werden und müssen die Methode \textit{initCopy(VSAbstractEvent copy)} implementieren. Dort werden dann alle relevanten Attribute in das neue Ereignis \textit{copy} kopiert.
@@ -156,9 +154,9 @@ Alle Ereignisklassen erweitern die abstrakte Klasse \textit{VSAbstractEvent} und Des Weiteren werden folgende nicht-abstrakte Methoden von \textit{VSAbstractEvent} vererbt:
\begin{itemize}
- \item \textit{public void logg(String message)}: Diese Methode schreibt eine Loggnachricht in das Simulationsloggfenster.
- \item \textit{public VSAbstractEvent getCopy()}: Diese Methode erstellt vom aktuellen Ereignis eine Kopie, worauf eine Referenz zurückgegeben wird. Alle Ereignisse die kopiert werden können müssen ebenso das Interface \textit{VSCopyableEvent} implementieren. Wenn ein Ereignis dies nicht tut und \textit{getCopy()} aufgerufen wird, dann wird von Java die Ausnahme \textit{exceptions.VSEventNotCopyable} geworfen.
- \item \textit{public VSAbstractEvent getCopy(VSInternalProcess process)}: Diese Methode erstellt vom aktuellen Ereignis ebenfalls eine Kopie, jedoch mit dem Unterschied, dass das Ereignis einem anderen Prozess zugewiesen wird.
+ \item \textit{public void log(String message)}: Diese Methode schreibt eine Lognachricht in das Simulationslogfenster.
+ \item \textit{public VSAbstractEvent getCopy()}: Diese Methode erstellt vom aktuellen Ereignis eine Kopie, worauf eine Referenz zurückgegeben wird. Alle Ereignisse, die kopiert werden können, müssen auch das Interface \textit{VSCopyableEvent} implementieren. Wenn ein Ereignis dies nicht tut und \textit{getCopy()} aufgerufen wird, dann wird die Ausnahme \textit{exceptions.VSEventNotCopyable} geworfen.
+ \item \textit{public VSAbstractEvent getCopy(VSInternalProcess process)}: Diese Methode erstellt vom aktuellen Ereignis ebenso eine Kopie, jedoch mit dem Unterschied, dass das Ereignis einem anderen Prozess zugewiesen wird.
\end{itemize}
Jede Ereignisklasse hat außerdem Zugriff auf folgende Attribute, die von \textit{VSAbstractEvent} vererbt werden:
@@ -168,11 +166,11 @@ Jede Ereignisklasse hat außerdem Zugriff auf folgende Attribute, die von \textit \item \textit{protected VSAbstractProcess process}: Eine Referenz auf das Prozessobjekt des jeweiligen Prozesses, auf welches das Ereignis angewendet wird.
\end{itemize}
-Da \textit{VSAbstractEvent} die Klasse \textit{VSSerializablePrefs} erweitert, können alle Ereignisse mit allen ihren Variablen serialisiert werden. Hierauf wird später nochmal eingegangen.
+Da \textit{VSAbstractEvent} die Klasse \textit{VSSerializablePrefs} erweitert, können alle Ereignisse mit allen ihren Variablen serialisiert werden.
-\subsection{Beispielimplementierung eines Ereignisses}
+\subsubsection{Beispielimplementierung eines Ereignisses}
-Im Folgenden wird als Beispiel die Implementierung des Prozessabsturzereignisses \textit{VSProcessCrashEvent} behandelt. Da die dazugehörige Klasse keine Attribute besitzt, verbleibt hier auch die \textit{initCopy}-Methode mit leerem Rumpf. Wegen der Serializierung und Deserialisierung von Ereignisobjektten muss jede Ereignisklasse in \textit{onInit()} mit \textit{setClassname} den eigenen Klassennamen mitteilen. Bei der Deserialisierung von Ereignissen werden n\"{a}mlich Objekte anhand der Klassennamen dynamisch neu erstellt, wo der Klassenname stets bekannt sein muss. In \textit{onStart()} wird das eigentliche Ereignis ausgeführt. Hier wird obligatorisch überprüft, ob der Prozess bereits abgestürzt (hier eigentlich nicht notwendig, verbessert hier aber die Lesbarkeit) ist und gegebenenfalls wird der Prozess dann zum Absturz bewegt.
+Im Folgenden wird als Beispiel die Implementierung des Prozessabsturzereignisses \textit{VSProcessCrashEvent} behandelt. Da die dazugehörige Klasse keine Attribute besitzt, verbleibt hier auch die \textit{initCopy}-Methode mit leerem Rumpf. Wegen der Serializierung und Deserialisierung von Ereignisobjektten muss jede Ereignisklasse in \textit{onInit()} mit \textit{setClassname} den eigenen Klassennamen mitteilen. Bei der Deserialisierung von Ereignissen werden n\"{a}mlich Objekte anhand der Klassennamen dynamisch neu erstellt, wo der Klassenname stets bekannt sein muss. In \textit{onStart()} wird das eigentliche Ereignis ausgeführt. Hier wird überprüft, ob der Prozess bereits abgestürzt (hier eigentlich nicht notwendig, verbessert hier aber die Lesbarkeit) ist und gegebenenfalls wird der Prozess dann zum Absturz bewegt.
\begin{code}
package events.implementations;
@@ -190,14 +188,14 @@ extends VSAbstractEvent implements VSCopyableEvent { public void onStart() {
if (!process.isCrashed()) {
process.isCrashed(true);
- super.logg(prefs.getString("lang.crashed"));
+ super.log(prefs.getString("lang.crashed"));
}
}
}
\end{code}
-Der Task-Manager überprüft bereits, ob der Prozess abgestürzt ist oder nicht. Das heißt, dass ein Ereignis bei einem abgestürztem Prozess gar nicht erst ausgeführt wird. Die einzige Ausnahme bildet ein Wiederbelebungsereignis (\text{VSProcessRecover}), welches vom Task-Manager ausgeführt wird, auch wenn der Prozess abgestürzt ist. Mit \textit{logg} wird eine Nachricht (die über \textit{prefs} bezogen wird) in das Loggfenster geschrieben.
+Der Task-Manager überprüft bereits, ob der Prozess abgestürzt ist oder nicht. Das heißt, dass ein Ereignis bei einem abgestürztem Prozess gar nicht erst ausgeführt wird. Die einzige Ausnahme bildet ein Wiederbelebungsereignis (\text{VSProcessRecover}), welches vom Task-Manager ausgeführt wird, auch wenn der Prozess abgestürzt ist. Mit \textit{log} wird eine Nachricht (die über \textit{prefs} bezogen wird) in das Logfenster geschrieben.
-In der Datei \textit{events/VSRegisteredEvents.java} muss in der \textit{init}-Methode für jedes programmierbare Ereignis ein Eintrag existieren. Die \textit{init}-Methode wird einmal beim Starten des Simulators ausgeführt:
+In der Datei \textit{events/VSRegisteredEvents.java} muss in der \textit{init}-Methode für jedes Ereignis ein Eintrag existieren. Die \textit{init}-Methode wird einmal beim Starten des Simulators ausgeführt:
\begin{code}
public static void init(VSPrefs prefs_) {
@@ -216,9 +214,7 @@ Als Resultat kann das Prozessabsturzereignis nach Belieben via GUI programmiert- \section{Zeitformate, Prozesse, Nachrichten sowie Task-Manager}
-\subsection{Funktionsweise}
-
-Das Paket \textit{core.time} auf Abbildung \ref{fig:PackageCoreTime} stellt lediglich die Klassen für die Vektor- und Lamportzeitstempel zur Verfügung. Für die normale lokale Prozesszeit wird aus Performance-gründen keine eigene Klasse, sondern ein einfaches \textit{long}-Attribut des Prozessobjektes verwendet.
+Das Paket \textit{core.time} auf Abbildung \ref{fig:PackageCoreTime}. stellt lediglich die Klassen für die Vektor- und Lamport-Zeitstempel zur Verfügung. Für die normale lokale Prozesszeit wird, aus Performance-Gründen, keine eigene Klasse, sondern ein einfaches \textit{long}-Attribut des Prozessobjektes verwendet.
\begin{figure}[h]
\centering
@@ -227,10 +223,12 @@ Das Paket \textit{core.time} auf Abbildung \ref{fig:PackageCoreTime} stellt ledi \label{fig:PackageCoreTime}
\end{figure}
-Auf Abbildung \ref{fig:PackageCore} ist stark vereinfacht das Paket \textit{core} dargestellt. Für jedes auszuführendes Ereignis wird eine Instanz von \textit{VSTask} benötigt, welche die Ereigniseintrittszeit als Attribut abgespeichert hat sowie eine Referenz auf das Objekt des auszuführenden Ereignisses (\textit{VSAbstractEvent}) und dem Prozessobjekt (\textit{VSInternalProcess}) besitzt. Geplante \textit{VSTask}-Instanzen werden für eine spätere Ausführung dem Task-Manager übergeben.
+Auf Abbildung \ref{fig:PackageCore}. ist, stark vereinfacht, das Paket \textit{core} dargestellt. Für jedes auszuführende Ereignis wird eine Instanz von \textit{VSTask} benötigt, welche die Ereigniseintrittszeit als Attribut abgespeichert hat sowie eine Referenz auf das Objekt des auszuführenden Ereignisses (\textit{VSAbstractEvent}) und dem Prozessobjekt (\textit{VSInternalProcess}) besitzt. Ein \textit{VSTask} merkt sich auch, ob es sich um ein globales oder ein lokales Ereignis handelt. Geplante \textit{VSTask}-Instanzen werden für eine spätere Ausführung dem Task-Manager übergeben.
Die Kapselung eines \textit{VSAbstractEvent}-Objektes in einem \textit{VSTask}-Objekt erlaubt es, dass die selbe \textit{VSAbstractEvent}-Instanz mehrmals auf einmal im Task-Manager geplant werden kann. Ohne dieser Kapselung gäbe es für jedes Ereignis lediglich nur eine einzige mögliche Eintrittszeit. Von dieser Möglichkeit wird zum Beispiel bei den Server- und Clientanfragen eines Protokollobjektes Gebrauch gemacht. Für jedes Protokoll kann der Anwender in einer Simulation beliebig viele Anfragen programmieren, wobei für jede Anfrage stets das selbe Protokollobjekt als Ereignis verwendet wird.
+Jede Simulation besitzt genau eine Instanz von \textit{VSTaskManager}. Eine Instanz dieser Klasse stellt den Task-Manager dar. Er verwaltet alle \textit{VSTask}-Instanzen und überprüft periodisch, ob es auszuführende Ereignisse gibt. Der Task-Manager unterscheidet zwischen globalen und lokalen Ereignissen. Hierbei werden alle globalen Ereignisse (gekapselt in einem \textit{VSTask}-Objekt) in einer Prioritäts-Warteschlange abgelegt. Die Prioritäts-Warteschlange stellt hierbei die korrekte Ereigniseintrittsreihenfolge sicher. Da sich die lokalen Zeiten aller beteiligten Prozesse voneinander unterscheiden können, muss für jeden Prozess eine separate lokale Prioritäts-Warteschlange verwendet werden, auf die jedes Prozessobjekt seine eigene Referenz hat. In den lokalen Warteschlangen sind die geplanten lokalen Ereignisse (auch gekapselt in einem \textit{VSTask}-Objekt) abgelegt. Der Task-Manager greift über eine \textit{java.util.ArrayList} auf alle Prozessobjekte zu, und kann somit auch auf alle lokalen Warteschlangen zugreifen und verwalten.
+
\begin{figure}[h]
\centering
\includegraphics[width=10.0cm]{images/core}
@@ -238,9 +236,7 @@ Die Kapselung eines \textit{VSAbstractEvent}-Objektes in einem \textit{VSTask}-O \label{fig:PackageCore}
\end{figure}
-Jede Simulation besitzt genau eine Instanz von \textit{VSTaskManager}. Eine Instanz dieser Klasse stellt den Task-Manager dar. Er verwaltet alle \textit{VSTask}-Instanzen und überprüft periodisch, ob es auszuführende Ereignisse gibt. Der Task-Manager unterscheidet zwischen globalen und lokalen Ereignissen. Hierbei werden alle globalen Ereignisse (gekapselt in einem \textit{VSTask}-Objekt) in einer Prioritäts-Warteschlange abgelegt. Die Prioritäts-Warteschlange stellt hierbei die korrekte Ereigniseintrittsreihenfolge sicher. Da sich die lokalen Zeiten aller beteiligten Prozesse voneinander unterscheiden können, muss für jeden Prozess eine separate lokale Prioritäts-Warteschlange verwendet werden, auf die jedes Prozessobjekt seine eigene Referenz hat. In den lokalen Warteschlangen sind die geplanten lokalen Ereignisse (auch gekapselt in einem \textit{VSTask}-Objekt) abgelegt. Der Task-Manager greift über eine \textit{java.util.ArrayList} auf alle Prozessobjekte zu und kann somit auch auf alle lokalen Warteschlangen zugreifen und verwalten.
-
-Eine Instanz von \textit{VSMessage} stellt eine Nachricht dar, die von einem Prozess verschickt wird. Für jedes Versenden einer Nachricht wird hiervon eine Instanz gebildet, wo der Senderprozess die zu verschickende Daten ablegt. Da \textit{VSMessage} von \textit{VSPrefs} erbt, können zwischen zwei Prozessen beliebige Datentypen (Tabelle \ref{tb:VariablenDatentypen}) über eine Nachricht verschickt werden. Anschließend wird für jeden Empfängerprozess das neues Ereignisobjekt der Klasse \textit{VSMessageReceiveEvent} angelegt, welches eine Referenz der verschickten Nachricht besitzt (Abbildung \ref{fig:Wrapping}). Danach wird ein \textit{VSTask}-Objekt instantiiert, wo die Referenz auf das Ereignisobjekt und das dazugehörige Prozessobjekt sowie die Ereigniseintrittszeit als Attribute gespeichert werden. Das \textit{VSTask}-Objekt wird dann dem Task-Manager übergeben, der das dazugehörige Ereignis ausführt, wenn die Ereigniseintrittszeit eingetroffen ist. Via Java-Polymorphie wird hier das \textit{VSMessageReceiveEvent}-Objekt in ein \textit{VSAbstractEvent} umgewandelt.
+Eine Instanz von \textit{VSMessage} stellt eine Nachricht dar, die von einem Prozess verschickt wird. Für jedes Versenden einer Nachricht wird hiervon eine Instanz gebildet, wo der Senderprozess die zu verschickende Daten ablegt. Da \textit{VSMessage} von \textit{VSPrefs} erbt, können zwischen zwei Prozessen beliebige Datentypen (Tabelle \ref{tb:VariablenDatentypen}.) über eine Nachricht verschickt werden. Anschließend wird für jeden Empfängerprozess das neues Ereignisobjekt der Klasse \textit{VSMessageReceiveEvent} angelegt, welches eine Referenz der verschickten Nachricht besitzt (Abbildung \ref{fig:Wrapping}.). Danach wird ein \textit{VSTask}-Objekt instantiiert, wo die Referenz auf das Ereignisobjekt und das dazugehörige Prozessobjekt sowie die Ereigniseintrittszeit als Attribute gespeichert werden. Das \textit{VSTask}-Objekt wird dann dem Task-Manager übergeben, der das dazugehörige Ereignis ausführt, wenn die Ereigniseintrittszeit eingetroffen ist. Via Java-Polymorphie wird hier das \textit{VSMessageReceiveEvent}-Objekt in ein \textit{VSAbstractEvent} umgewandelt und so in \textit{VSTask} abgelegt.
\begin{figure}[h]
\centering
@@ -249,15 +245,15 @@ Eine Instanz von \textit{VSMessage} stellt eine Nachricht dar, die von einem Pro \label{fig:Wrapping}
\end{figure}
-Erwähnenswert ist auch die Klasse \textit{VSMessageStub}, welche ein \textit{VSMessage} kapselt. Ihr Zweck ist das Verstecken einiger Methoden vor dem Protokoll-API, welches für die Erstellung eigener Protokolle dient. Der Protokoll-Entwickler soll möglichst nichts falsch machen können und deswegen soll dem Protokoll-API ein eingeschränkter Funktionsumfang zur Verfügung gestellt werden. Da sich \textit{VSMessageStub} im selben Paket wie \textit{VSMessage} befindet, kann \textit{VSMessageStub} auf paket-private Methoden von \textit{VSMessage} zugreifen. Protokolle hingegen werden in einem anderen Paket implementiert und haben somit keinen Zugriff auf diese paket-privaten Methoden. Zwar kann der Protokollentwickler ein eigenes \textit{VSMessageStub}-Objekt anlegen, jedoch kann er auf diese Weise besser unterscheiden auf welche Methoden er zugreifen sollte und auf welche nicht. Das Protokoll-API wird später genauer behandelt.
+Erwähnenswert ist auch die Klasse \textit{VSMessageStub}, welche ein \textit{VSMessage} kapselt. Ihr Zweck ist das Verstecken einiger Methoden vor dem Protokoll-API, welches für die Erstellung eigener Protokolle dient. Der Protokoll-Entwickler soll möglichst nichts falsch machen können und deswegen soll dem Protokoll-API ein eingeschränkter Funktionsumfang zur Verfügung gestellt werden. Da sich \textit{VSMessageStub} im selben Paket wie \textit{VSMessage} befindet, kann \textit{VSMessageStub} auf paket-private Methoden von \textit{VSMessage} zugreifen. Protokolle hingegen werden in einem anderen Paket implementiert und haben somit keinen Zugriff auf diese paket-privaten Methoden. Zwar kann der Protokollentwickler ein eigenes \textit{VSMessageStub}-Objekt anlegen, jedoch kann er auf diese Weise besser unterscheiden, auf welche Methoden er zugreifen sollte, und auf welche nicht. Das Protokoll-API wird später genauer behandelt.
-Der Task-Manager speichert anschließend in der globalen Warteschlange die Nachrichtenempfangsereignisse. Die Nachricht kommt bei einem Empfängerprozess an, sobald das Ereignis für den Empfang eintritt. Für die korrekte Implementierung der Lamport- und Vektor-Zeitstempel wird jeder Nachricht automatisch eine Referenz auf die Lamport- sowie auf die Vektorzeit des sendenden Prozesses als Attribut beigefügt. Für die Überprüfung des Protokolls wird in jeder Nachricht auch der Klassenname des jeweiligen Protokolls abgespeichert.
+Der Task-Manager speichert anschließend die Nachrichtenempfangsereignisse in seiner globalen Warteschlange. Die Nachricht kommt bei einem Empfängerprozess an, sobald das Ereignis für den Empfang eintritt. Für die korrekte Implementierung der Lamport- und Vektor-Zeitstempel wird jeder Nachricht automatisch eine Referenz auf die Lamport- sowie auf die Vektor-Zeitstempel des sendenden Prozesses als Attribut beigefügt. Für die Überprüfung des Protokolls wird in jeder Nachricht auch der Klassenname des jeweiligen Protokolls abgespeichert.
-Eine Instanz von \textit{VSInternalProcess} repräsentiert einen simulierten Prozess. Ein \textit{VSInternalProcess} stellt alle vom Simulator intern verwendeten Methoden zur Verfügung, während ein \textit{VSAbstractProcess} lediglich Methoden hat, die der Protokollentwickler für die Erstellung eigener Protokolle verwenden darf. Da \textit{VSAbstractProcess} abstrakt ist und hiervon keine Instanz gebildet werden darf, muss für einen neuen Prozesses stets ein \textit{VSInternalProcess}-Objekt erstellt werden. Via Polymorphie wird dieses Objekt nach \textit{VSAbstractProcess} umgewandelt und so dem Protokoll-API zur Verfügung gestellt. Beispielsweise darf mit \textit{getTasks()} nur vom Simulator intern auf die Prioritäts-Warteschlangen zugegriffen werden, während man im Protokoll-API selbiges vermeiden sollte und auch gar nicht direkt möglich ist. Hierfür hätte man auch ein Stub-Objekt \textit{VSProcessStub} implementieren können. Da aber so gut wie alle paar Millisekunden auf die Methoden von \textit{VSInternalProcess} zugegriffen wird, wurde hier aus Performance-gründen der Weg über eine Vererbungungsstufe preferiert.
+Eine Instanz von \textit{VSInternalProcess} repräsentiert einen simulierten Prozess. Ein \textit{VSInternalProcess} stellt alle vom Simulator intern verwendeten Methoden zur Verfügung, während ein \textit{VSAbstractProcess} lediglich Methoden hat, die der Protokollentwickler für die Erstellung eigener Protokolle verwenden darf. Da \textit{VSAbstractProcess} abstrakt ist und hiervon keine Instanz gebildet werden darf, muss für einen neuen Prozesses stets ein \textit{VSInternalProcess}-Objekt erstellt werden. Via Polymorphie wird dieses Objekt nach \textit{VSAbstractProcess} umgewandelt und so dem Protokoll-API zur Verfügung gestellt. Beispielsweise darf mit \textit{getTasks()} nur vom Simulator intern auf die Prioritäts-Warteschlangen zugegriffen werden, während man im Protokoll-API selbiges vermeiden sollte und auch gar nicht direkt möglich ist. Hier wäre auch ein Stub-Objekt \textit{VSProcessStub} denkbar gewesen. Da aber so gut wie alle paar Millisekunden auf die Methoden von \textit{VSInternalProcess} zugegriffen wird, wurde hier aus Performance-Gründen der Weg über eine Vererbungungsstufe preferiert.
-Alle einstellbaren Prozessvariablen werden von der Klasse \textit{VSPrefs} vererbt. Damit bei Neuberechnungen die Variablen nicht dauernd über eine \textit{HashMap} von \textit{VSPrefs} zugegriffen werden muss, speichert \textit{VSInternalProcess} aus Performance-gründen einige Variablen als lokale Kopie ab. Zum Beispiel wird für die lokale Prozesszeit nicht auf das \textit{HashMap<String,Long>}-Objekt von \textit{VSPrefs}, sondern auf das Klassenattribut \textit{private long localTime} zugegriffen. Vor- und nach dem Editieren über den Prozesseditor werden die \textit{VSPrefs} beziehungsweise die lokalen Kopien auf den neusten Stand gebracht. Selbiges gilt für weitere Variablen wie zum Beispiel der Uhrabweichung eines Prozesses.
+Alle einstellbaren Prozessvariablen werden von der Klasse \textit{VSPrefs} vererbt. Damit bei Neuberechnungen die Variablen nicht dauernd über eine \textit{HashMap} von \textit{VSPrefs} zugegriffen werden muss, speichert \textit{VSInternalProcess} aus Performance-Gründen einige Variablen als lokale Kopie ab. Zum Beispiel wird für die lokale Prozesszeit nicht auf das \textit{HashMap<String,Long>}-Objekt von \textit{VSPrefs}, sondern auf das Klassenattribut \textit{private long localTime} zugegriffen. Vor- und nach dem Editieren über den Prozesseditor werden die \textit{VSPrefs}, beziehungsweise die lokalen Kopien, auf den neusten Stand gebracht. Selbiges gilt für weitere Variablen, wie zum Beispiel der Uhrabweichung eines Prozesses.
-\subsection{Beispiel für die Erstellung von Prozessereignissen}
+\subsubsection{Beispiel für die Erstellung von Prozessereignissen}
Anhand der Prozessabsturz- und Wiederbelebungsereignisse lässt sich wie folgt sehr gut demonstrieren, wie intern Ereignisse angelegt werden können:
\begin{code}
@@ -275,11 +271,11 @@ void createCrashAndRecoverExample(VSTaskManager taskManager, }
\end{code}
-In diesem Beispiel wurden zwei Ereignisse (Absturz- und Wiederbelebung eines gegebenen Prozesses) angelegt. Das Absturzereignis tritt bei der aktuellen lokalen Prozesszeit plus \textit{500ms} ein, während das Wiederbelebungsereignis bei einer globalen Zeit von \textit{2000ms} stattfindet. Für den Fall, dass das Wiederbelebungsereignis vor dem Absturzereignis eintritt wird es nicht ausgeführt, da der Prozess noch nicht abgestürzt ist.
+In diesem Beispiel wurden zwei Ereignisse (Absturz- und Wiederbelebung eines gegebenen Prozesses) angelegt. Das Absturzereignis tritt bei der aktuellen lokalen Prozesszeit plus \textit{500ms} ein, während das Wiederbelebungsereignis bei einer globalen Zeit von \textit{2000ms} stattfindet. Für den Fall, dass das Wiederbelebungsereignis vor dem Absturzereignis eintritt, wird es nicht ausgeführt, da der Prozess noch nicht abgestürzt ist.
-\section{Protokolle}
+\section{Protokoll-API}
-\subsection{Funktionsweise des Protokoll-APIs}
+In diesem Abschnitt wird auf die Implementierung der Protokolle und das Protokoll-API eingegangen. Im Protokoll-API wird in der Regel nicht direkt auf den Task-Manager und auf die explizite Instantiierung von Ereignisobjekten zurückgegriffen, da dies vom API automatisch durchgef\"{u}hrt wird.
\begin{figure}[h]
\centering
@@ -288,9 +284,7 @@ In diesem Beispiel wurden zwei Ereignisse (Absturz- und Wiederbelebung eines geg \label{fig:PackageProtocols}
\end{figure}
-In diesem Abschnitt wird auf die Implementierung der Protokolle und das Protokoll-API eingegangen. Im Protokoll-API wird in der Regel nicht direkt auf den Task-Manager und auf die explizite Instantiierung von Ereignisobjekten zurückgegriffen. Das wird alles vom API automatisch gemacht.
-
-Auf Abbildung \ref{fig:PackageProtocols} sind die Pakete \textit{protocols} und \textit{protocols.implementations} dargestellt, welche für die Protokollimplementierungen zuständig sind. \textit{VSAbstractProtocol} stellt lediglich gemeinsame Methoden und Attribute zur Verfügung, die von allen Protokollen verwendet werden können. Jedes Protokoll hat im Paket \textit{protocols.implementations} seine eigene Klasse, die von \textit{VSAbstractProtocol} erbt. Im Prinzip besitzt jedes Prozessobjekt von jedem Protokoll seine eigene Instanz. Bei \textit{10} Protokollen und \textit{3} beteiligten Prozessen werden also \textit{30} Protokollobjekte verwendet. Jedes Protokollobjekt verwaltet sowohl die Server- als auch die Clientseite eines Protokolls auf einmal. Dabei merkt sich \textit{VSAbstractProtocol} anhand einer Flagge ob der aktuelle Kontext server- oder clientbezogen ist und führt dementsprechend beim Eintreffen von Ereignissen die Server- beziehungsweise Clientmethoden des Protokolls auf. \textit{VSAbstractProtocol} überprüft auch, ob ein Client oder ein Server überhaupt aktiviert ist.
+Auf Abbildung \ref{fig:PackageProtocols}. sind die Pakete \textit{protocols} und \textit{protocols.implementations} dargestellt, welche für die Protokollimplementierungen zuständig sind. \textit{VSAbstractProtocol} stellt lediglich gemeinsame Methoden und Attribute zur Verfügung, die von allen Protokollen verwendet werden können. Jedes Protokoll hat im Paket \textit{protocols.implementations} seine eigene Klasse, die von \textit{VSAbstractProtocol} erbt. Im Prinzip besitzt jedes Prozessobjekt von jedem Protokoll seine eigene Instanz. Bei \textit{10} Protokollen und \textit{3} beteiligten Prozessen werden also \textit{30} Protokollobjekte verwendet. Jedes Protokollobjekt verwaltet sowohl die Server- als auch die Clientseite eines Protokolls auf einmal. Dabei merkt sich \textit{VSAbstractProtocol} anhand einer Flagge, ob der aktuelle Kontext server- oder clientbezogen ist, und führt dementsprechend beim Eintreffen von Ereignissen die Server- beziehungsweise Clientmethoden des Protokolls auf. \textit{VSAbstractProtocol} überprüft auch, ob ein Client oder ein Server überhaupt aktiviert ist.
\begin{figure}[h]
\centering
@@ -299,9 +293,9 @@ Auf Abbildung \ref{fig:PackageProtocols} sind die Pakete \textit{protocols} und \label{fig:Protokollvariablen}
\end{figure}
-Es ist bereits bekannt, dass Protokolle im Prozesseditor editierbare Variablen haben können. Da \textit{VSAbstractProtocol} von \textit{VSAbstractEvent} erbt, was wiederum von \textit{VSSerializablePrefs} erbt (und \textit{VSSerializablePrefs} erweitert \textit{VSPrefs}), werden alle Protokollvariablen einfach in die Mutterklasse \textit{VSPrefs} abgelegt. Zum Beispiel kann mit \textit{super.setBoolean(``test'', true);} eine neue Protokollvariable \textit{test} mit dem Standardwert \textit{true} angelegt werden. Diese Variable erscheint dann automatisch im Prozesseditor und kann vom Anwender konfiguriert werden.
+Es ist bereits bekannt, dass Protokolle im Prozesseditor editierbare Variablen haben können. Da \textit{VSAbstractProtocol} von \textit{VSAbstractEvent} erbt, was wiederum von \textit{VSSerializablePrefs} erbt (und \textit{VSSerializablePrefs} erweitert \textit{VSPrefs}), werden alle Protokollvariablen einfach in die Mutterklasse \textit{VSPrefs} abgelegt. Zum Beispiel kann mit \textit{super.setBoolean(``test'', true);} eine neue Protokollvariable \textit{test} mit dem Standardwert \textit{true} angelegt werden. Diese Variable erscheint dann automatisch im Prozesseditor und kann so vom Anwender konfiguriert werden.
-Da der Simulator dafür ausgelegt wurde eigene Protokolle zu implementieren, werden im Folgenden alle verfügbaren Protokoll-API-Methoden etwas ausführlicher als gewohnt beschrieben. Jede Protokollklasse muss die folgenden Methoden implementieren:
+Da der Simulator darauf ausgelegt wurde eigene Protokolle zu implementieren, werden im Folgenden alle verfügbaren Protokoll-API-Methoden etwas ausführlicher als gewohnt beschrieben. Jede Protokollklasse muss die folgenden Methoden implementieren:
\begin{itemize}
\setlength{\itemsep}{-2mm}
@@ -309,9 +303,15 @@ Da der Simulator dafür ausgelegt wurde eigene Protokolle zu implementieren, werd \item \textit{abstract public void onClientInit()}: Bevor das Protokollobjekt benutzt werden kann, muss es initialisiert werden. Diese Methode wird vor dem ersten Verwenden des Protokolls innerhalb einer Simulation ausgeführt. In der Regel werden hier Protokollvariablen unter Verwendung von \textit{VSPrefs} und Attribute der Protokollklasse initialisiert. Die hier initialisierten Protokollvariablen lassen sich vom Benutzer im Prozesseditor des jeweiligen Prozesses editieren.
\item \textit{abstract public void onClientReset()}: Diese Methode wird jedes Mal ausgeführt, wenn die Simulation zurückgesetzt wird.
\item \textit{abstract public void onClientStart()}: Diese Methode wird nur benötigt, wenn der Client immer die Anfragen startet. Diese Methode generiert in der Regel immer eine Clientanfrage, die via \textit{VSMessage}-Objekt an alle anderen beteiligten Prozesse verschickt wird.
- \item \textit{abstract public void onClientRecv(VSMessage message)}: Diese Methode wird jedes Mal Ausgeführt, wenn eine Servernachricht \textit{message} bei dem Client eintrifft.
+ \item \textit{abstract public void onClientRecv(VSMessage message)}: Diese Methode wird jedes Mal aufgerufen, wenn eine Servernachricht \textit{message} bei dem Client eintrifft.
\item \textit{abstract public void onClientSchedule()}: Diese Methode wird jedes Mal ausgeführt, wenn ein Weckerereignis eintritt.
- \item \textit{public String toString()}: Diese Methode ist nur optional. Hiermit lassen sich die Loggnachrichten eines Protokolls anpassen. Wenn diese Methode in einer Protokollimplementierung ausgelassen wird, so wird stets die \textit{toString}-Methode der Mutterklasse \textit{VSAbstractProtocol} verwendet.
+ \item \textit{public String toString()}: Diese Methode ist nur optional. Hiermit lassen sich die Lognachrichten eines Protokolls anpassen. Wenn diese Methode in einer Protokollimplementierung ausgelassen wird, so wird stets die \textit{toString}-Methode der Mutterklasse \textit{VSAbstractProtocol} verwendet. Bei Verwendung wird empfohlen die Logausgabe lediglich wie folgt zu erweitern:
+ \begin{code}
+public String toString() {
+ return super.toString() + "; Neue Loginformationen";
+}
+ \end{code}
+ Hierbei wird jede Lognachricht, die das aktuelle Protokoll betrifft, um die Ausgabe \textit{; Neue Loginformation} erweitert.
\end{itemize}
Für alle hier aufgelisteten Client-Methoden sind auch die korrespondierenden Server-Methoden anzugeben. Die Server-Methoden sind analog zu den Client-Methoden aufgebaut, wobei lediglich \textit{Client} durch \textit{Server} ausgetauscht werden muss.
@@ -324,12 +324,12 @@ Jede Protokollklasse bekommt folgende Methoden von \textit{VSAbstractProtocol} v \item \textit{pubic final boolean hasOnServerStart()}: Hiermit lässt sich bestimmen, ob der Server- oder der Client bei dem aktuellen Protokoll die Anfragen startet.
\item \textit{pubic final boolean isServer()}: Hiermit lässt sich bestimmen, ob der aktuelle Prozess das aktuelle Protokoll serverseitig aktiviert hat.
\item \textit{pubic final boolean isClient()}: Hiermit lässt sich bestimmen, ob der aktuelle Prozess das aktuelle Protokoll clientseitig aktiviert hat.
- \item \textit{pubic final void scheduleAt(long time)}: Diese Methode stellt einen Wecker dar, der zur angegebenen lokalen Prozesszeit eintritt. Nach Ablauf des Weckers wird, abhängig ob der aktuelle Kontext client- oder serverseitig ist, \textit{onClientSchedue} beziehungsweise \textit{onServerSchedule} ausgeführt.
- \item \textit{pubic final void removeSchedules()}: Entfernt alle gesetzten Wecker des aktuellen Kontextes (Server oder Client).
+ \item \textit{pubic final void scheduleAt(long time)}: Diese Methode erstellt einen Wecker, der zur angegebenen lokalen Prozesszeit eintritt. Nach Ablauf des Weckers wird, abhängig ob der aktuelle Kontext client- oder serverseitig ist, \textit{onClientSchedue} beziehungsweise \textit{onServerSchedule} ausgeführt.
+ \item \textit{pubic final void removeSchedules()}: Entfernt alle gesetzten Wecker des aktuellen Kontextes.
\item \textit{pubic final int getNumProcesses()}: Gibt die totale Anzahl an der Simulation beteiligten Prozesse zurück.
\end{itemize}
-Bei der Implementierung von Protokollen können zusätzlich auf die vererbten Attribute \textit{VSAbstractProcess process} und \textit{VSPrefs prefs} zugegriffen werden. Verfügbare Methoden von \textit{VSPrefs} wurden bereits behandelt. über \textit{prefs} lassen sich alle globalen Simulationseinstellungen abrufen (zum Beispiel die Simulationsvariable die Angibt, ob Prozesse eigene Nachrichten empfangen: \textit{bool recvOwn = prefs.getBoolean(``sim.message.own.recv'')}). Folgende Prozessmethoden dürfen auf \textit{process} aus dem Protokoll-API verwendet werden:
+Bei der Implementierung von Protokollen kann zusätzlich auf die vererbten Attribute \textit{VSAbstractProcess process} und \textit{VSPrefs prefs} zugegriffen werden. Verfügbare Methoden von \textit{VSPrefs} wurden bereits behandelt. über \textit{prefs} lassen sich alle globalen Simulationseinstellungen abrufen (zum Beispiel die Simulationsvariable die Angibt, ob Prozesse eigene Nachrichten empfangen: \textit{bool recvOwn = prefs.getBoolean(``sim.message.own.recv'')}). Folgende Prozessmethoden dürfen auf \textit{process} aus dem Protokoll-API verwendet werden:
\begin{itemize}
\setlength{\itemsep}{-2mm}
@@ -338,15 +338,15 @@ Bei der Implementierung von Protokollen können zusätzlich auf die vererbten Attr \item \textit{public long getGlobalTime()}: Gibt die aktuelle globale Simulationszeit zurück.
\item \textit{public long getTime()}: Gibt die aktuelle lokale Prozesszeit zurück.
\item \textit{public void setTime(long time)}: Setzt die aktuelle lokale Prozesszeit.
- \item \textit{public long getLamportTime()}: Gibt die aktuelle Lamportzeit des Prozesses zurück.
- \item \textit{public void setLamportTime(long lamportTime)}: Setzt die aktuelle Lamportzeit des Prozesses.
- \item \textit{public void increaseLamportTime()}: Inkrementiert die Lamportzeit um eins.
- \item \textit{public void updateLamportTime(long lamportTime)}: Erneuert die Lamportzeit. Siehe Kapitel 2.6.1 wie die Lamportzeiten erneuert werden.
- \item \textit{public VSVectorTime getVectorTime()}: Gibt die aktuelle Vektor-Zeit des Prozesses zurück.
- \item \textit{public VSTime[] getLamportTimeArray()}: Gibt die gesamte Lamportzeitstempelhistorie des Prozesses zurück. Kann jeweils nach VSLamportTime umgewandelt werden.
+ \item \textit{public long getLamportTime()}: Gibt den aktuelle Lamport-Zeitstempel des Prozesses zurück.
+ \item \textit{public void setLamportTime(long lamportTime)}: Setzt den aktuellen Lamport-Zeitstempel des Prozesses.
+ \item \textit{public void increaseLamportTime()}: Inkrementiert den Lamport-Zeitstempel um eins.
+ \item \textit{public void updateLamportTime(long lamportTime)}: Erneuert den Lamport-Zeitstempel. Siehe Kapitel 3.11.1., wie die Lamport-Zeitstempel erneuert werden.
+ \item \textit{public VSVectorTime getVectorTime()}: Gibt den aktuelle Vektor-Zeitstempel des Prozesses zurück.
+ \item \textit{public VSTime[] getLamportTimeArray()}: Gibt die gesamte Lamport-Zeitstempel-Historie des Prozesses zurück. Kann jeweils nach VSLamportTime umgewandelt werden.
\item \textit{public VSTime getVectorTimeArray()}: Gibt die gesamte Vektor-Zeitstempel-Historie des Prozesses zurück. Kann jeweils nach VSVectorTime umgewandelt werden.
- \item \textit{public void updateVectorTime(VSVectorTime vectorTimeUpdate)}: Erneuert die Vektorzeit. Siehe Kapitel 2.6.1 wie die Vektorzeiten erneuert werden.
- \item \textit{public void increaseVectorTime()}: Inkrementiert die Vektorzeit am lokalen Index um eins.
+ \item \textit{public void updateVectorTime(VSVectorTime vectorTimeUpdate)}: Erneuert den Vektor-Zeitstempel. Siehe Kapitel 3.11.1., wie die Vektor-Zeitstempel erneuert werden.
+ \item \textit{public void increaseVectorTime()}: Inkrementiert den Vektor-Zeitstempel am lokalen Index um eins.
\item \textit{public int getProcessID()}: Gibt die PID zurück.
\item \textit{public void setProcessID(int processID)}: Setzt die PID.
\item \textit{public int getProcessNum()}: Gibt die Prozessnummer zurück. Dieser Wert unterscheidet sich von der PID. Die Prozessnummer gibt an, um den wievielten Prozess, beginnend bei 0, es sich handelt. PIDs hingegen k\"{o}nnen alle m\"{o}glichen ganzstelligen positiven Zahlen sein.
@@ -365,23 +365,23 @@ In der Regel werden in Protokollen auch Nachrichten (\textit{VSMessage}) verschi \item \textit{public boolean equals(VSMessage message)}: Hiermit lässt sich überprüfen, ob eine weitere Nachricht die selbe NID besitzt (wobei es sich dann um die selbe Nachricht handeln würde).
\end{itemize}
-Folgende weitere Methoden von \textit{VSMessage} können bei Erhalt einer Nachricht verwendet werden:
+Folgende weitere Methoden von \textit{VSMessage} können nach Erhalt einer Nachricht verwendet werden:
\begin{itemize}
\setlength{\itemsep}{-2mm}
\item \textit{public String getName()}: Gibt den Namen des zur Nachricht dazugehörigen Protokolls zurück. Diese Methode funktioniert nur bei empfangenen Nachrichten richtig.
\item \textit{public String getProtocolClassname()}: Gibt den Klassennamen des zur Nachricht dazugehörigen Protokolls zurück. Diese Methode funktioniert nur bei empfangenen Nachrichten richtig.
\item \textit{public VSAbstractProcess getSendingProcess()}: Gibt eine Referenz auf den Senderprozess zurück. Diese Methode funktioniert nur bei empfangenen Nachrichten richtig.
- \item \textit{public long getLamportTime()}: Gibt die Lamportzeit des Senderprozesses zurück. Diese Methode funktioniert nur bei empfangenen Nachrichten richtig.
- \item \textit{public VSVectorTime getLamportTime()}: Gibt die Vektorzeit des Senderprozesses zurück. Diese Methode funktioniert nur bei empfangenen Nachrichten richtig.
+ \item \textit{public long getLamportTime()}: Gibt den Lamport-Zeitstempel des Senderprozesses zurück. Diese Methode funktioniert nur bei empfangenen Nachrichten richtig.
+ \item \textit{public VSVectorTime getVectorTime()}: Gibt den Vektor-Zeitstempel des Senderprozesses zurück. Diese Methode funktioniert nur bei empfangenen Nachrichten richtig.
\item \textit{public boolean isServerMessage()}: Hiermit lässt sich entscheiden, ob es sich um eine Server- oder eine Clientnachricht handelt. Diese Methode funktioniert nur bei empfangenen Nachrichten richtig.
\end{itemize}
Wenn über eine Nachricht Daten verschickt werden sollen, so werden die von \textit{VSPrefs} vererben Methoden verwendet.
-\subsection{Beispielimplementierung eines Protokolls}
+\subsubsection{Beispielimplementierung eines Protokolls}
-Im Folgenden wird die Implementierung des zuverlässigen Multicast-Protokolls \textit{VSReliableMulticastProtocol.java} als Beispiel aufgeführt. Die Funktionsweise des Protokolls wurde bereits in Kapitel 2.5.10 beschrieben. Client- und Serverseite werden in der selben Klasse implementiert.
+Im Folgenden wird die Implementierung des zuverlässigen Multicast-Protokolls \textit{VSReliableMulticastProtocol.java} als Beispiel aufgeführt. Die Funktionsweise des Protokolls wurde bereits in Kapitel 3.10. beschrieben. Client- und Serverseite werden in der selben Klasse implementiert.
Im Konstruktor muss stets angegeben werden, ob beim gegebenen Protokoll der Client oder der Server die Anfragen startet. Mit \textit{VSAbstractProtocol.HAS\_ON\_CLIENT\_START} wird dem API mitgeteilt, dass der Client die Anfragen startet. Für \textit{VSAbstractProtocol.HAS\_ON\_SERVER\_START} und Serveranfragen gilt Selbiges analog. Da ein Protokoll auch ein \textit{VSAbstractEvent} ist, muss auch hier mit \textit{setClassname} der Klassenname des aktuellen Protokolls angegeben werden:
@@ -401,9 +401,9 @@ public class VSReliableMulticastProtocol }
\end{code}
-\subsubsection{Clientseite des Protokolls}
+\textbf{Clientseite des Protokolls}
-Das private Klassenattribut \textit{pids} wird für die Zwischenspeicherung beteiligter PIDs benötigt. Hier sind alle PIDs abgelegt, von denen noch Bestätigungsnachrichten erwartet werden. Hier werden als Standard-PIDs \textit{1} und \textit{3} verwendet. Die Methoden \textit{initVector} und \textit{initLong} wurden von \textit{VSPrefs} vererbt und initialisieren die Protokollvariablen \textit{pids} und \textit{timeout}, welche vom Benutzer im Prozesseditor editiert werden können (siehe Abbildung \ref{fig:Protokollvariablen} unter ``Reliable Multicast Client'' ganz unten):
+Das private Klassenattribut \textit{pids} wird für die Zwischenspeicherung beteiligter PIDs benötigt. Hier sind alle PIDs abgelegt, von denen noch Bestätigungsnachrichten erwartet werden. Hier werden als Standard-PIDs \textit{1} und \textit{3} verwendet. Die Methoden \textit{initVector} und \textit{initLong} wurden von \textit{VSPrefs} vererbt und initialisieren die Protokollvariablen \textit{pids} und \textit{timeout}, welche vom Benutzer im Prozesseditor editiert werden können (siehe Abbildung \ref{fig:Protokollvariablen}. unter ``Reliable Multicast Client'' ganz unten):
\begin{code}
private ArrayList<Integer> pids;
@@ -427,7 +427,7 @@ Wenn die Simulation zurückgesetzt wird, dann wird auch \textit{pids} reinitialis }
\end{code}
-In \textit{onClientStart} wird geprüft, ob eine Clientanfrage gestartet werden soll. Wenn dies der Fall ist (wenn von mindestens einem beteiligten Prozess noch keine Bestätigung erhalten wurde), wird ein neues Nachrichtenobjekt erstellt, und mit dem Inhalt \textit{Boolean: isMulticast=true} verschickt (intern wird hier für jeden Empfängerprozess ein \textit{VSMessageReceiveEvent} erzeugt). Mit \textit{scheduleAt} wird ein Wecker festgelegt, zur welchen lokalen Prozesszeit die Methode \textit{onClientSchedule} aufgerufen werden soll (intern wird hier ein \textit{VSProtocolScheduleEvent} erzeugt):
+In \textit{onClientStart} wird geprüft, ob eine Clientanfrage gestartet werden soll. Wenn dies der Fall ist (wenn von mindestens einem beteiligten Prozess noch keine Bestätigung erhalten wurde), wird ein neues Nachrichtenobjekt erstellt, und mit dem Inhalt \textit{Boolean: isMulticast=true} verschickt (intern wird hier für jeden Empfängerprozess ein \textit{VSMessageReceiveEvent} erzeugt). Mit \textit{scheduleAt} wird ein Wecker festgelegt, zu welcher lokalen Prozesszeit die Methode \textit{onClientSchedule} aufgerufen werden soll (intern wird hier ein \textit{VSProtocolScheduleEvent} erzeugt):
\begin{code}
public void onClientStart() {
if (pids.size() != 0) {
@@ -442,7 +442,7 @@ In \textit{onClientStart} wird geprüft, ob eine Clientanfrage gestartet werden s }
\end{code}
-Wenn eine Serverantwort eintrifft, dann wird \textit{onClientRecv} aufgerufen. Hier wird überprüft, ob überhaupt noch Multicast-Bestätigungen benötigt werden. Wenn dies der Fall ist, dann wird geschaut, ob es sich bei der Antwort um eine noch nicht eingetroffene Bestätigung handelt. Gegebenenfalls wird die jeweilige PID aus \textit{pids} entfernt. Wenn \textit{pids} leer ist, dann wurde von allen beteiligten Prozessen eine Bestätigung erhalten und der Client entfernt mit \textit{removeSchedules} alle seine derzeit programmierten Wecker.
+Wenn eine Serverantwort eintrifft, dann wird \textit{onClientRecv} aufgerufen. Hier wird überprüft, ob überhaupt noch Multicast-Bestätigungen benötigt werden. Danach wird geschaut, ob es sich bei der Antwort um eine noch nicht eingetroffene Bestätigung handelt. Gegebenenfalls wird die jeweilige PID aus \textit{pids} entfernt. Wenn \textit{pids} leer ist, dann wurde von allen beteiligten Prozessen eine Bestätigung erhalten und der Client entfernt mit \textit{removeSchedules} alle seine derzeit programmierten Wecker.
\begin{code}
public void onClientRecv(VSMessage recvMessage) {
@@ -454,10 +454,10 @@ Wenn eine Serverantwort eintrifft, dann wird \textit{onClientRecv} aufgerufen. H else
return;
- super.logg("ACK von Prozess " + pid + " erhalten!");
+ super.log("ACK von Prozess " + pid + " erhalten!");
if (pids.size() == 0) {
- super.logg("ACKs von allen beteiligten " +
+ super.log("ACKs von allen beteiligten " +
" Prozessen erhalten!");
super.removeSchedules();
@@ -473,7 +473,7 @@ Für das erneute Verschicken einer Clientanfrage ruft \textit{onClientSchedule} l }
\end{code}
-\subsubsection{Serverseite des Protokolls}
+\textbf{Serverseite des Protokolls}
Die Serverseite des Protokolls speichert im Attribut \textit{ackSent} ab, ob es bereits eine Bestätigung des Multicasts verschickt hat oder nicht. In diesem Protokoll werden in \textit{onServerInit} keine Initialisierungen vorgenommen. Demnach gibt es für den Benutzer auch keine serverseitigen Protokollvariablen zu editieren. Beim Zurücksetzen der Simulation wird lediglich \textit{ackSent} auf den Ursprungswert \textit{false} gesetzt:
\begin{code}
@@ -486,7 +486,7 @@ Die Serverseite des Protokolls speichert im Attribut \textit{ackSent} ab, ob es }
\end{code}
-Wenn der Server eine Clientanfrage erhalten hat, so überprüft der Server, ob es sich um eine Multicast-Nachricht handelte. Anschließend wird gegebenenfalls die Bestätigungsnachricht mit \textit{Boolean: isAck=true} und der Server-PID verschickt. Je nachdem ob bereits eine Bestätigung verschickt wurde oder nicht wird eine andere Nachricht geloggt:
+Wenn der Server eine Clientanfrage erhalten hat, so überprüft der Server, ob es sich um eine Multicast-Nachricht handelte. Anschließend wird gegebenenfalls die Bestätigungsnachricht mit \textit{Boolean: isAck=true} und der Server-PID verschickt. Je nachdem ob bereits eine Bestätigung verschickt wurde oder nicht, wird eine andere Nachricht gelogt:
\begin{code}
public void onServerRecv(VSMessage recvMessage) {
if (recvMessage.getBoolean("isMulticast")) {
@@ -496,9 +496,9 @@ Wenn der Server eine Clientanfrage erhalten hat, so überprüft der Server, ob es super.sendMessage(message);
if (ackSent) {
- super.logg("ACK erneut versendet");
+ super.log("ACK erneut versendet");
} else {
- super.logg("ACK versendet");
+ super.log("ACK versendet");
ackSent = true;
}
}
@@ -511,7 +511,7 @@ Der Server benutzt in diesem Beispiel keinen Wecker. Dementsprechend hat die Met }
\end{code}
-\subsection{Erstellung eigener Protokolle (Schnelldurchlauf)}
+\subsubsection{Erstellung eigener Protokolle (Schnelldurchlauf)}
Hier werden alle Schritte zusammengefasst, die für die Erstellung eines eigenen Protokolls \textit{VSMyProtocol} durchgeführt werden müssen. Hierf\"{u}r muss der Protokoll-Entwickler das Java-SDK sowie Apache Ant installiert- und den Quelltext des Simulators vorliegen haben.
@@ -534,11 +534,9 @@ Wenn eine Simulatorversion versucht eine abgespeicherte Simulation eines nicht i \section{GUI sowie Simulationsvisualisierung}
-\subsection{Funktionsweise}
-
-Das Paket \textit{simulator} (vereinfacht auf Abbildung \ref{fig:PackageProtocols} dargestellt) implementiert die eigentliche graphische Benutzeroberfläche des Simulators. Ausnahmen sind die Editorklassen in \textit{prefs.editors} sowie \textit{utils.VSFrame}.
+Das Paket \textit{simulator} (vereinfacht auf Abbildung \ref{fig:PackageProtocols}. dargestellt) implementiert die eigentliche graphische Benutzeroberfläche des Simulators. Ausnahmen sind die Editorklassen in \textit{prefs.editors} sowie \textit{utils.VSFrame}.
-Beim Starten des Simulators wird auf die Main-Methode, welche sich in \textit{VSMain} befindet, aufgerufen. Sie instantiiert ein \textit{VSDefaultPrefs}-Objekt, wo alle Standardeinstellungen des Simulators abgelegt sind. Anschließend wird ein \textit{VSSimulatorFrame} erzeugt, welches ein Simulatorfenster (wie es schon auf Abbildung \ref{fig:NeuesFenster} zu sehen war) implementiert. Das Simulatorfenster erstellt für jede neue Simulation jeweils ein Objekt von \textit{VSSimulator}. Jede Simulation hat im Simulationsfenster einen eigenen Tab. Auf Abbildung \ref{fig:NeuErstellteSimulation} wurde bereits eine neue Simulation erstellt, wo auch unten links der dazugehörige Tab mit der Beschriftung ``Simulator 1'' zu sehen ist. Jede Simulation besitzt dabei eine eigene Simulationsnummer, die bei jeder neuen Simulation um eins inkrementiert wird. Jedes \textit{VSSimulator}-Objekt greift auf \textit{VSSimulatorVisualization} zurück, was die Simulationsvisualisierung (Abbildung \ref{fig:Visualisierung}) implementiert.
+Beim Starten des Simulators wird auf die Main-Methode, welche sich in \textit{VSMain} befindet, aufgerufen. Sie instantiiert ein \textit{VSDefaultPrefs}-Objekt, wo alle Standardeinstellungen des Simulators abgelegt sind. Anschließend wird ein \textit{VSSimulatorFrame} erzeugt, welches ein Simulatorfenster (wie es schon auf Abbildung \ref{fig:NeuesFenster}. zu sehen war) implementiert. Das Simulatorfenster erstellt für jede neue Simulation jeweils ein Objekt von \textit{VSSimulator}. Jede Simulation hat im Simulationsfenster einen eigenen Tab. Auf Abbildung \ref{fig:NeuErstellteSimulation}. wurde bereits eine neue Simulation erstellt, wo auch unten links der dazugehörige Tab mit der Beschriftung ``Simulator 1'' zu sehen ist. Jede Simulation besitzt dabei eine eigene Simulationsnummer, die bei jeder neuen Simulation um eins inkrementiert wird. Jedes \textit{VSSimulator}-Objekt greift auf \textit{VSSimulatorVisualization} zurück, was die Simulationsvisualisierung (Abbildung \ref{fig:Visualisierung}.) implementiert.
\begin{figure}[h]
\centering
@@ -547,15 +545,15 @@ Beim Starten des Simulators wird auf die Main-Methode, welche sich in \textit{VS \label{fig:PackageProtocols}
\end{figure}
-\textit{VSSimulatorVisualization} greift auf Java's Grafikbibliothek Java2D zurück und ist aus Performance-gründen mit dem Simulationsverlauf stark verzahnt \cite{Games}. Klassenattribute, dessen Wert sich nie ändert, wurden stets als \textit{final} deklariert. Attribute, die von Konfigurationen oder Einstellungen abhängig sind, die sich nur nach Konfigurationsänderung oder Vergrößern beziehungsweise Verkleinern des Simulationsfensters ändern (Werte, die für die Berechnung des Sekunden-Gatters notwendig sind), werden nur wenn es nötig ist neu berechnet.
+\textit{VSSimulatorVisualization} greift auf Java's Grafikbibliothek Java2D zurück und ist aus Performance-Gründen mit dem Simulationsverlauf stark verzahnt \cite{Games}. Klassenattribute, dessen Wert sich nie ändert, wurden stets als \textit{final} deklariert. Attribute, die von Konfigurationen oder Einstellungen abhängig sind, die sich nur nach Konfigurationsänderung oder Vergrößern beziehungsweise Verkleinern des Simulationsfensters ändern (Werte, die für die Berechnung des Sekunden-Gatters notwendig sind), werden nur wenn es nötig ist neu berechnet.
-Die Klasse \textit{VSMenuItemStates} wird für die Synchronisierung des Simulationsstatusses, der Toolbar und des Simulations-Menüs (beide Letztere auf Abbildung \ref{fig:Toolbar} zu sehen) verwendet. Abhängig davon kann der Benutzer bestimmte Aktionen durchführen oder nicht (beispielsweise kann eine Simulation nur pausiert werden, wenn sie aktuell abgespielt wird). Alle hier möglichen Aktionen wurden bereits in Kapitel 2.1 im Abschnitt ``Die Toolbar'' behandelt.
+Die Klasse \textit{VSMenuItemStates} wird für die Synchronisierung des Simulationsstatusses, der Toolbar und des Simulations-Menüs (beide Letztere auf Abbildung \ref{fig:Toolbar}. zu sehen) verwendet. Abhängig davon kann der Benutzer bestimmte Aktionen durchführen oder nicht (beispielsweise kann eine Simulation nur pausiert werden, wenn sie aktuell abgespielt wird). Alle hier möglichen Aktionen wurden bereits in Kapitel 2.1. im Abschnitt ``Die Toolbar'' behandelt.
-Die Klasse \textit{VSCreateTask} wird vom Ereigniseditor verwendet. Der Ereigniseditor (Abbildung \ref{fig:SidebarMitEreignissen}) wird in der Klasse \textit{VSSimulator} implementiert. Hinter jeder Ereignisauswahl verbirgt sich intern ein \textit{VSCreateTask}-Objekt, welches definiert wie das jeweilige Ereignis anzulegen ist.
+Die Klasse \textit{VSCreateTask} wird vom Ereigniseditor verwendet. Der Ereigniseditor (Abbildung \ref{fig:SidebarMitEreignissen}.) wird in der Klasse \textit{VSSimulator} implementiert. Hinter jeder Ereignisauswahl verbirgt sich intern ein \textit{VSCreateTask}-Objekt, welches definiert, wie das jeweilige Ereignis anzulegen ist.
-\textit{VSLogging} kapselt ein \textit{javax.swing.JTextArea}-Objekt, wo alle Nachrichten geloggt werden. Hier werden alle Loggfunktionen (inklusive Loggfilter sowie temporäre Deaktivierung des Loggen) implementiert. Die \textit{JTextArea} wird dem \textit{VSSimulator}-Objekt übergeben und dort dargestellt. Für den Loggfilter wird intern auf das Java-Standardpaket \textit{java.util.regex} zugegriffen, womit anhand von regulären Ausdrücken in Java-Syntax die Loggs gefiltert werden können.
+\textit{VSLogging} kapselt ein \textit{javax.swing.JTextArea}-Objekt, wo alle Nachrichten gelogt werden. Hier werden alle Logfunktionen (inklusive Logfilter sowie temporäre Deaktivierung des Logen) implementiert. Die \textit{JTextArea} wird dem \textit{VSSimulator}-Objekt übergeben und dort dargestellt. Für den Logfilter wird intern auf das Java-Standardpaket \textit{java.util.regex} zugegriffen, womit anhand von regulären Ausdrücken in Java-Syntax die Logs gefiltert werden können.
-\subsection{Threads und Zeitsynchronisierung}
+\subsubsection{Threads und Zeitsynchronisierung}
Ziel vom Simulator ist es bis auf jede Millisekunde genau simulieren zu können. Jede simulierte Sekunde soll relativ zur echten Zeit fortschreiten. Die Simulationsabspielgeschwindigkeit lässt sich bei den Simulationseinstellungen unter ``Abspielgeschwindigkeit der Simulation'' (Float: \textit{sim.clock.speed}) einstellen. Damit dies gewährleistet wird, muss folgendes berücksichtigt werden:
@@ -589,9 +587,7 @@ Jede Simulation besitzt somit seinen eigenen Simulationsthread. Bei mehreren par \section{Serialisierung und Deserialisierung von Simulationen}
-\subsection{Funktionsweise}
-
-Der Anwender kann eine erstellte Simulation im Datei-Menü speichern und/oder eine bereits abgespeicherte Simulation laden. Hierbei wird von den aus Java angebotenen Möglichkeit Objekte zu Serialisieren Gebrauch gemacht. Im Paket \textit{serialize} (Abbildung \ref{fig:PackageSerialize}) befinden sich Helfer, die bei einer Serialisierung und einer Deserialisierung einer Simulation unter die Arme greifen.
+Der Anwender kann eine erstellte Simulation im Datei-Menü speichern und/oder eine bereits abgespeicherte Simulation laden. Hierbei wird von den aus Java angebotenen Möglichkeit Objekte zu Serialisieren Gebrauch gemacht. Im Paket \textit{serialize} (Abbildung \ref{fig:PackageSerialize}.) befinden sich Helfer, die bei einer Serialisierung und einer Deserialisierung einer Simulation unter die Arme greifen.
Der Simulator serialisiert nur notwendige Daten, und nicht jedes existierende Objekt. Alle Serialisierbaren Klassen implementieren das Interface \textit{VSSerializable} mit folgenden zwei Methoden:
@@ -600,7 +596,7 @@ Der Simulator serialisiert nur notwendige Daten, und nicht jedes existierende Ob \item \textit{public void deserialize(VSSerialize serialize, ObjectInputStream ois)}: Diese Methode wird bei jedem Deserialisierungsvorgang aufgerufen (beim Laden einer Simulation).
\end{itemize}
-Die Methoden \textit{serialize} und \textit{deserialize} erhalten neben einen Dateistream auch ein \textit{VSSerialize}-Objekt. Für jeden (De)serialisierungsvorgang wird ein \textit{VSSerialize}-Objekt erzeugt, welches dabei Hilft die benötigten Aktionen durchzuführen. Eine zu serialisierende Simulation besteht aus vielen voneinander abhängigen Objekten. Jedes Objekt kann dabei Referenzen auf andere Objekte besitzen. Würde jedes Objekt komplett serialisiert werden, so würden Objekte, auf denen mehrere Referenzen existieren, in mehrfacher Ausführung behandelt (in eine Datei abgespeichert) werden. Bei Kreisverweisen (Objekt A hat eine Referenz auf Objekt B und Objekt B hat eine Referenz auf Objekt A als Attribut gespeichert) würde die Serialisierung sogar in einer Endlosschleife enden. \textit{VSSerialize} hilft hierbei dies zu vermeiden und merkt sich Informationen von allen bereits serialisierten Objekten, sodass jedes Objekt nur genau einmal serialisiert wird. Bei der Deserialisierung werden alle Objekte wieder automatisch mit den richtigen Referenzen ausgestattet, wobei kein Objekt doppelt deserialisiert wird.
+Die Methoden \textit{serialize} und \textit{deserialize} erhalten neben einen Dateistream auch ein \textit{VSSerialize}-Objekt. Für jeden (De)serialisierungsvorgang wird ein \textit{VSSerialize}-Objekt erzeugt, welches dabei Hilft die benötigten Aktionen durchzuführen. Eine zu serialisierende Simulation besteht aus vielen voneinander abhängigen Objekten. Jedes Objekt kann dabei Referenzen auf andere Objekte besitzen. Würde jedes Objekt komplett serialisiert werden, so würden Objekte, auf denen mehrere Referenzen existieren, in mehrfacher Ausführung behandelt (in eine Datei abgespeichert) werden. Bei Kreisverweisen (Objekt A hat eine Referenz auf Objekt B und Objekt B hat eine Referenz auf Objekt A als Attribut gespeichert) würde die Serialisierung sogar in einer Endlosschleife enden. \textit{VSSerialize} hilft hierbei dies zu vermeiden und merkt sich Informationen von allen bereits serialisierten Objekten, so dass jedes Objekt nur genau einmal serialisiert wird. Bei der Deserialisierung werden alle Objekte wieder automatisch mit den richtigen Referenzen ausgestattet, wobei kein Objekt doppelt deserialisiert wird.
\begin{figure}[h]
\centering
@@ -613,7 +609,7 @@ Alle Klassen, die \textit{VSSerializePrefs} erweitern, können automatisch sämtli Abgespeicherte Simulationen sollen auch mit zukünftigen Versionen des Simulators kompatibel bleiben. Deshalb werden alle Objekte derjenigen Klassen, die \textit{VSSerializable} implementieren, nicht komplett serialisiert. Bei der Serialisierung werden nur relevante Klassenattribute, die der Simulationsprogrammierung- und nicht beispielsweise GUI-Komponenten angehören, serialisiert.
-\subsection{Beispielimplementierung einer \textit{serialize}-Methode}
+\subsubsection{Beispielimplementierung einer \textit{serialize}-Methode}
Der folgende Quelltext-Ausschnitt zeigt eine Beispielimplementierung von \textit{serialize}:
@@ -633,13 +629,15 @@ Der folgende Quelltext-Ausschnitt zeigt eine Beispielimplementierung von \textit Vor- und nach der eigentlichen Objektserialisierung wird jeweils eine boolesche Flagge serialisiert, welche auf \textit{true} gesetzt wird, sobald in späteren Simulator-Versionen (was relativ unwahrscheinlich, aber möglich ist) weitere zu serialisierende Klassenattribute hinzukommen. Eine Deserialisierung kann die Flaggen dann abfragen und separat behandeln. Somit bleiben ältere bereits abgespeicherte Simulationen stets zur neusten Version des Simulators kompatibel. Wenn eine Flagge auf \textit{true} gesetzt wird, dann kann unter den neuen Attributserialisierungen eine weitere Flagge gesetzt werden. Somit können beliebig viele Erweiterungen in die Serialisierung Einzug halten.
-Das zu serialisierende Objekt besitzt hier lediglich zwei Attribute, die serialisiert werden sollen. Alle anderen Klassenattribute können vernachlässigt werden. Mit \textit{serialize.setObject} speichert \textit{serialize} eine Referenz auf das aktuelle Objekt ab, worauf andere Objektserialisierungen zurückgreifen können. Danach wird ein \textit{prefs} und \textit{someOtherSerializableObject} serialisiert. Die Deserialisierung folgt genau den Umgekehrten weg. Wobei hier zuerst die Instanzen der Klassen auf normalen Weg erstellt werden und dann nachträglich die relevanten Attribute deserialisiert und den Objekten zugewiesen werden. Hierbei werden auch mithilfe von \textit{VSSerialize} mehrere Referenzen auf das selbe Objekt korrekt behandelt.
+Das zu serialisierende Objekt besitzt hier lediglich zwei Attribute, die serialisiert werden sollen. Alle anderen Klassenattribute können vernachlässigt werden. Mit \textit{serialize.setObject} speichert \textit{serialize} eine Referenz auf das aktuelle Objekt ab, worauf andere Objektserialisierungen zurückgreifen können. Danach wird ein \textit{prefs} und \textit{someOtherSerializableObject} serialisiert. Die Deserialisierung folgt genau den Umgekehrten weg. Wobei hier zuerst die Instanzen der Klassen auf normalen Weg erstellt werden und dann nachträglich die relevanten Attribute deserialisiert und den Objekten zugewiesen werden. Hierbei werden auch mit Hilfe von \textit{VSSerialize} mehrere Referenzen auf das selbe Objekt korrekt behandelt.
-Wenn der Anwender \textit{Datei $\rightarrow$ Simulation speichern} wählt, dann wird zunächst ein \textit{VSSerialize}-Objekt erstellt. Ausgehend davon wird \textit{serialize} auf \textit{VSSimulator} ausgeführt (siehe Serialisierungssequenz auf Abbildung \ref{fig:SequenceSerialize}). Das Simulator-Objekt führt \textit{serialize} wiederum auf das \textit{VSSimulatorVisualization}-Objekt aus. Dort wird jeder Prozess inklusive alle Protokollobjekte serialisiert. Anschließend folgt der Task-Manager inklusive allen programmierten Ereignissen.
+Wenn der Anwender \textit{Datei $\rightarrow$ Simulation speichern} wählt, dann wird zunächst ein \textit{VSSerialize}-Objekt erstellt. Ausgehend davon wird \textit{serialize} auf \textit{VSSimulator} ausgeführt (siehe Serialisierungssequenz auf Abbildung \ref{fig:SequenceSerialize}.). Das Simulator-Objekt führt \textit{serialize} wiederum auf das \textit{VSSimulatorVisualization}-Objekt aus. Dort wird jeder Prozess inklusive alle Protokollobjekte serialisiert. Anschließend folgt der Task-Manager inklusive allen programmierten Ereignissen.
\section{Helferklassen und Klassen für Ausnahmebehandlungen}
+Es wurden noch nicht die Klassen der Pakete \textit{utils} (Abbildung \ref{fig:PackageUtils}.) sowie \textit{exceptions} (Abbildung \ref{fig:PackageExceptions}.) vorgestellt. \textit{utils} fasst lediglich einige Helferklassen zusammen, die vom restlichen Quelltext verwendet werden.
+
\begin{figure}[h]
\centering
\includegraphics[width=10cm]{images/utils}
@@ -647,8 +645,6 @@ Wenn der Anwender \textit{Datei $\rightarrow$ Simulation speichern} wählt, dann \label{fig:PackageUtils}
\end{figure}
-Es wurden noch nicht die Klassen der Pakete \textit{utils} (Abbildung \ref{fig:PackageUtils}) sowie \textit{exceptions} (Abbildung \ref{fig:PackageExceptions}) vorgestellt. \textit{utils} fasst lediglich einige Helferklassen zusammen, die vom restlichen Quelltext verwendet werden.
-
\begin{itemize}
\item \textit{VSFrame}: Alle Objekte, die ein eigenes Swing-Fenster besitzen, erben von der Klasse \textit{VSFrame}. Sie stellt sicher, dass neue Fenster an der richtigen Position der Bildfläche platziert werden und dass Unterfenster (Fenster, die aus einem anderen Fenster aus geöffnet wurden) automatisch mit-geschlossen werden, sobald eines ihrer ``Erzeugerfenster'' geschlossen wird.
\item \textit{VSAboutFrame}: Dieses Fenster implementiert die ``About-Anzeige'' die im Simulator über das Datei-Menü aufgerufen werden kann.
@@ -657,7 +653,7 @@ Es wurden noch nicht die Klassen der Pakete \textit{utils} (Abbildung \ref{fig:P \item \textit{VSHelper}: In dieser Klasse befinden sich statische Helfermethoden, die in keine andere Klasse passen.
\item \textit{VSPriorityQueue}: Diese Klasse wird für das Verwalten von \textit{core.VSTask}-Objekte im Task-Manager benötigt. \textit{VSPriorityQueue} passt die Prioritäts-Warteschlange aus der Java-Standardbibliothek den Anforderungen des Simulators an.
\item \textit{VSRandom}: Wird für Zufallsereignisse benötigt. Jedes Prozessobjekt besitzt einen solchen eigenen Pseudozufallsgenerator. Diese Klasse setzt gleichzeitig einen eigenen Seed basierend auf der lokalen Systemzeit und anderer Berechnungen fest.
- \item \textit{VSTupel}: Diese Klasse ist eine Implementierung eines sehr einfach aufgebauten 3-Tupel Datentyps. Alle 3 Elemente können von einem anderen Typ sein, was mithilfe der Java-Generics verwirklicht wurde. \textit{VSTupel} wird von den Editorklassen für die Generierung von GUI-Elementen benötigt.
+ \item \textit{VSTupel}: Diese Klasse ist eine Implementierung eines sehr einfach aufgebauten 3-Tupel Datentyps. Alle 3 Elemente können von einem anderen Typ sein, was mit Hilfe der Java-Generics verwirklicht wurde. \textit{VSTupel} wird von den Editorklassen für die Generierung von GUI-Elementen benötigt.
\end{itemize}
\begin{figure}[h]
@@ -693,8 +689,8 @@ Die Main-Methode befindet sich in der Klasse \textit{simulator.VSMain}. \item Eine Quelltext-Datei hat eine maximale Zeilenlänge von 80 Zeichen, was der Standardbreite eines UNIX-Terminals entspricht. Eine Ausnahme stellt die Klasse \textit{prefs.VSDefaultPrefs} dar, denn hier befinden sich auch längere Texte die in Strings abgespeichert werden, wo manuelle Zeilenumbrüche wenig Sinn ergeben.
\item Es werden zuerst Klassen aus der Java-Standardbibliothek importiert, bevor Klassen aus dem VS-Simulator selbst importiert werden.
\item Für die Einrückung des Quelltextes wird das Tool \textit{astyle} mit den Aufrufparametern \textit{--style=java --mode=java} verwendet. Hierbei wird eine Einrückungslänge von 4 Zeichen verwendet.
- \item Namen aller Klassen und Interfaces tragen als Prefix stets \textit{VS}, was für Verteilte Systeme steht.
- \item Namen abstrakter Klassen tragen als Prefix stets \textit{VSAbstract}.
+ \item Namen aller Klassen und Interfaces tragen als Präfix stets \textit{VS}, was für Verteilte Systeme steht.
+ \item Namen abstrakter Klassen tragen als Präfix stets \textit{VSAbstract}.
\item Namen aller Protokollklassen tragen als Postfix \textit{Protocol} (zum Beispiel \textit{VSPingPongProtocol}).
\item Namen aller Ereignisklassen, die keine Protokolle implementieren, tragen als Postfix \textit{Event} (zum Beispiel \textit{VSProcessCrashEvent}).
\item Namen aller dejenigen Klassen die ein Fenster implementieren tragen als Postfix \textit{Frame} (zum Beispiel \textit{VSSimulatorFrame}).
@@ -705,7 +701,7 @@ Die Main-Methode befindet sich in der Klasse \textit{simulator.VSMain}. In diesem Teilkapitel soll ein kleiner Einblick in die Umgebung, in der der Simulator entwickelt wurde, gewährt werden. Für diese Diplomarbeit wurde ausschließlich Open Source Software verwendet. Die einzige Ausnahme stellt Microsoft Windows XP dar, worauf der Simulator zusätzlich getestet wurde. Der Simulator wurde jedoch hauptsächlich unter dem Betriebssystem FreeBSD 7.0, was ein open source Unix-Derivat ist, programmiert.
-Wie bereits bekannt ist, wurde Sun's Java, was mittlerweile auch Open Source Software ist, in der Version 6 (1.6) als die Implementierungssprache gewählt und für die Quelltextdokumentation kam Javadoc- und für die automatische Quelltexteinrückung astyle zum Einsatz. Als Built-Tool wurde hier auf Apache Ant gesetzt. Für die Erstellung dieses PDF-Dokumentes wurde LaTeX in Verbindung mit dem Built-Tool GNU Make und Rubber verwendet. Eine Rechtschreibüberprüfung wurde mit aspell sowie OpenOffice.org durchgeführt. xPDF diente als PDF-Anzeigeprogramm.
+Wie bereits bekannt ist, wurde Sun's Java, was mittlerweile auch Open Source Software ist, in der Version 6 (1.6) als die Implementierungssprache gewählt und für die Quelltextdokumentation kam Javadoc-, für die automatische Quelltexteinrückung astyle und als Java-Referenz kam \cite{Javadoc} zum Einsatz. Als Built-Tool wurde hier auf Apache Ant gesetzt. Für die Erstellung dieses PDF-Dokumentes wurde LaTeX in Verbindung mit dem Built-Tool GNU Make und Rubber verwendet. Eine Rechtschreibüberprüfung wurde mit aspell sowie OpenOffice.org durchgeführt. xPDF diente als PDF-Anzeigeprogramm.
Als Versionierungssystem wurde SVN (Subversion) verwendet. Für den Zugriff auf das SVN-Repository mittels HTTPS (Hypertext Transfer Protocol Secure) wurde der Apache-Webserver mit WebDAV-Plugin verwendet. Zudem kam WebSVN als Webschnittstelle des SVN-Repository zum Einsatz. Mozilla Firefox diente für das Betrachten der Javadocs und der WebSVN-Oberfläche.
diff --git a/LaTeX/chapters/introduction.tex b/LaTeX/chapters/introduction.tex index 7cc65b3..1cec8e1 100644 --- a/LaTeX/chapters/introduction.tex +++ b/LaTeX/chapters/introduction.tex @@ -2,15 +2,15 @@ \section{Motivation} -In der Literatur findet man viele verschiedene Definitionen eines verteilten Systems. Vieler dieser Definitionen unterschieden sich untereinander, so dass es schwer fällt eine Definition zu finden, die als Alleinige als die Richtige gilt. Andrew Tanenbaum und Marten van Steen haben für die Beschreibung eins verteilten Systems die Folgende lockere Charakterisierung formuliert: +In der Literatur findet man viele verschiedene Definitionen eines verteilten Systems. Vieler dieser Definitionen unterschieden sich untereinander, so dass es schwer fällt eine Definition zu finden, die als Alleinige als die Richtige gilt. Andrew Tanenbaum und Marten van Steen w\"{a}hlten für die Beschreibung eines verteilten Systems die folgende lockere Charakterisierung: \cite{Tanenbaum} \textit{``Ein verteiltes System ist eine Menge voneinander unabhängiger Computer, die dem Anwender wie ein einzelnes, kohärentes System erscheinen''} -Der Anwender muss sich nur mit dem lokalen vor ihm befindenden Computer auseinandersetzen, während die Software des lokalen Computers die reibungslose Kommunikation mit den anderen beteiligten Computern des verteilten Systems sicherstellt. +Der Anwender muss sich nur mit dem lokalen, vor ihm befindlichen Computer auseinandersetzen, während die Software des lokalen Computers die reibungslose Kommunikation mit den anderen beteiligten Computern des verteilten Systems sicherstellt. -Diese Diplomarbeit soll den Gebrauchern die Betrachtung von verteilten Systemen aus einer anderen Perspektive erleichtern. Es soll nicht die Sichtweise eines Endbenutzers eingenommen werden, sondern es sollen die Funktionsweisen von Protokollen und deren Prozesse in verteilten Systemen begreifbar gemacht werden. Es sollen relevante Ereignisse eines verteilten Systems transparent dargestellt werden können. +Diese Diplomarbeit soll den Anwendern die Betrachtung von verteilten Systemen aus einer anderen Perspektive erleichtern. Hierbei wird nicht die Sichtweise eines Endbenutzers eingenommen, sondern es sollen die Funktionsweisen von Protokollen und deren Prozesse in verteilten Systemen begreifbar gemacht und gleichzeitig alle relevanten Ereignisse eines verteilten Systems transparent dargestellt werden. -Um dieses Ziel zu erreichen soll ein Simulator entwickelt werden. Der Simulator soll insbesondere für Lehr- und Lernzwecke an der Fachhochschule Aachen entwickelt werden. Beispielsweise sollen Protokolle aus den verteilten Systemen mit ihren wichtigsten Einflussfaktoren simuliert werden können. Der Simulator soll zu verstehen helfen wie die gegebenen Protokolle funktionieren und es soll viel Spielraum für eigene Experimente zur Verfügung stehen. Der Simulator soll nicht auf eine feste Anzahl von Protokollen beschränkt sein. Es muss daher dem Gebraucher ermöglicht werden, eigene Protokolle zu entwerfen. +Um dieses Ziel zu erreichen wurde, insbesondere f\"{u}r Lehr- und Lernzwecke an der Fachhochschule Aachen, ein Simulator entwickelt. Mit dem Simulator sollen Protokolle aus den verteilten Systemen mit ihren wichtigsten Einflussfaktoren anhand von Simulationen nachgeblidet werden k\"{o}nnen. Gleichzeitig muss für eigene Experimente ein großer Spielraum zur Verfügung stehen, wobei es keine Beschränkung auf eine feste Anzahl von Protokollen geben darf. Es ist also wichtig, dass es dem Anwender ermöglicht wird eigene Protokolle zu entwerfen. \section{Grundlagen} @@ -25,23 +25,21 @@ Für das Grundverständnis werden im Folgenden einige Grundlagen erläutert. Eine V \label{fig:ClientServer} \end{figure} -Der Simulator basiert auf dem Client/Server-Prinzip. Jeder Simulation besteht in der Regel aus einen teilnehmenden Client und einen Server, die miteinander über Nachrichten kommunizieren (Abbildung \ref{fig:ClientServer}). Bei komplexen Simulationen können auch mehrere Clients und/oder Server mitwirken. +Der Simulator basiert auf dem Client/Server-Prinzip. Jede Simulation besteht in der Regel aus einen teilnehmenden Client und einen Server, die miteinander über Nachrichten kommunizieren (Abbildung \ref{fig:ClientServer}.). Bei komplexen Simulationen können auch mehrere Clients und/oder Server mitwirken. \subsubsection{Prozesse und deren Rollen} -Ein verteiltes System wird anhand von Prozessen simuliert. Jeder Prozess nimmt hierbei eine oder mehrere Rollen ein. Beispielsweise kann ein Prozess die Rolle eines Clients einnehmen und ein weiterer Prozess die Rolle eines Servers. Ein Prozess kann auch Client und Server gleichzeitig sein. Es besteht auch die Möglichkeit, dass ein Prozess die Rollen mehrerer Server und Clients gleichzeitig einnimmt. Ob das sinnvoll ist hängt vom simulierten Szenario ab. Um einen Prozess zu kennzeichnen besitzt jeder Prozess eine \textbf{eindeutige} Prozess-Identifikationsnummer (PID). +Ein verteiltes System wird anhand von Prozessen simuliert. Jeder Prozess nimmt hierbei eine oder mehrere Rollen ein. Beispielsweise kann ein Prozess die Rolle eines Clients einnehmen und ein weiterer Prozess die Rolle eines Servers. Die M\"{o}glichkeit einem Prozess die Client- und Serverrolle gleichzeitig zuzuweisen ist ebenso gegeben. Ein Prozess k\"{o}nnte auch die Rollen mehrerer Server und Clients gleichzeitig einnehmen. Um einen Prozess zu kennzeichnen besitzt, jeder eine \textbf{eindeutige} Prozess-Identifikationsnummer (PID). \subsubsection{Nachrichten} -In einem verteiltem System müssen Nachrichten verschickt werden können. Eine Nachricht kann von einem Client- oder Serverprozess verschickt werden und kann beliebig viele Empfänger haben. Der Inhalt einer Nachricht hängt vom verwendeten Protokoll ab. Was unter einem Protokoll zu verstehen ist, wird später behandelt. Um eine Nachricht zu kennzeichnen besitzt jede Nachricht eine \textbf{eindeutige} Nachrichten-Identifikationsnummer (NID). +In einem verteilten System müssen Nachrichten verschickt werden können. Eine Nachricht kann von einem Client- oder Serverprozess verschickt werden und kann beliebig viele Empfänger haben. Der Inhalt einer Nachricht hängt vom verwendeten Protokoll ab. Was unter einem Protokoll zu verstehen ist, wird später behandelt. Um eine Nachricht zu kennzeichnen, besitzt jede Nachricht eine \textbf{eindeutige} Nachrichten-Identifikationsnummer (NID). \subsubsection{Lokale und globale Uhren} In einer Simulation gibt es \textbf{genau eine} globale Uhr. Sie stellt die aktuelle und \textbf{immer korrekte} Zeit dar. Eine globale Uhr geht nie falsch. -Zudem besitzt jeder beteiligter Prozess eine eigene lokale Uhr. Sie stellt die aktuelle Zeit des jeweiligen Prozesses dar. Im Gegensatz zu der globalen Uhr können lokale Uhren eine falsche Zeit anzeigen. Wenn die Prozesszeit nicht global-korrekt ist (nicht der globalen Zeit gleicht beziehungsweise eine falsche Zeit anzeigt), dann wurde sie entweder im Laufe einer Simulation neu gestellt, oder sie geht wegen einer Uhrabweichung falsch. Die Uhrabweichung gibt an, um welchen Faktor die Uhr falsch geht. Hierauf wird später genauer eingegangen. - -Neben den normalen Uhren sind auch die Vektor-Zeitstempel sowie die logischen Uhren von Lamport von Interesse. Jeder Prozess besitzt zusätzlich einen Vektor-Zeitstempel für seine Vektorzeit, sowie einen Lamportzeitstempel für seine Lamportzeit. Für die Vektor- und Lamportzeiten gibt es hier, im Gegensatz zu der normalen Zeit, keine globalen äquivalente. Konkrete Beispiele zu den Lamport- und Vektorzeiten werden später anhand einer Simulation behandelt. +Zudem besitzt jeder beteiligte Prozess eine eigene lokale Uhr. Sie stellt die aktuelle Zeit des jeweiligen Prozesses dar. Im Gegensatz zu der globalen Uhr können lokale Uhren eine falsche Zeit anzeigen. Wenn die Prozesszeit nicht global-korrekt ist (nicht der globalen Zeit gleicht, beziehungsweise eine falsche Zeit anzeigt), dann wurde sie entweder im Laufe einer Simulation neu gestellt, oder sie geht wegen einer Uhrabweichung falsch. Die Uhrabweichung gibt an, um welchen Faktor die Uhr falsch geht. Hierauf wird später genauer eingegangen. \begin{figure}[htbp] \centering @@ -50,15 +48,17 @@ Neben den normalen Uhren sind auch die Vektor-Zeitstempel sowie die logischen Uh \label{fig:ClientServerProtokolle} \end{figure} +Neben den normalen Uhren sind auch die Vektor-Zeitstempel sowie die logischen Uhren von Lamport von Interesse. Jeder Prozess besitzt zusätzlich einen Vektor-Zeitstempel für seine Vektorzeit, sowie einen Lamport-Zeitstempel für seine Lamportzeit. Für die Vektor- und Lamportzeiten gibt es hier, im Gegensatz zu der normalen Zeit, keine globalen Äquivalente. Konkrete Beispiele zu den Lamport- und Vektorzeiten werden später anhand einer Simulation behandelt. + \subsubsection{Ereignisse} -Eine Simulation besteht aus der Hintereinanderausführung von endlich vielen Ereignissen. Beispielsweise kann es ein Ereignis geben, welches einen Prozess eine Nachricht verschicken lässt. Denkbar wäre auch ein Prozessabsturzereignis. Jedes Ereignis tritt zu einem bestimmten Zeitpunkt ein. Ereignisse mit selber Eintrittszeit werden vom Simulator direkt hintereinander ausgeführt. Den Anwendern des Simulators hindert dies jedoch nicht, da Ereignisse aus ihrer Sicht parallel ausgeführt werden. +Eine Simulation besteht aus der Hintereinanderausführung von endlich vielen Ereignissen. Beispielsweise kann es ein Ereignis geben, welches einen Prozess eine Nachricht verschicken lässt. Denkbar wäre auch ein Prozessabsturzereignis. Jedes Ereignis tritt zu einem bestimmten Zeitpunkt ein. Ereignisse mit selber Eintrittszeit werden vom Simulator direkt hintereinander ausgeführt. Den Anwender des Simulators hindert dies jedoch nicht, da Ereignisse aus ihrer Sicht parallel ausgeführt werden. \subsubsection{Protokolle} -Eine Simulation besteht auch aus der Anwendung von Protokollen. Es wurde bereits erwähnt, dass ein Prozess die Rollen von Servern und/oder Clients annehmen kann. Bei jeder Server- und Clientrolle muss zusätzlich das dazugehörige Protokoll spezifiziert werden. Ein Protokoll definiert, wie ein Client und ein Server Nachrichten verschickt und wie bei Ankunft einer Nachricht reagiert wird. Ein Protokoll legt auch fest, welche Daten in einer Nachricht enthalten sind. Ein Prozess verarbeitet eine empfangene Nachricht nur, wenn er das jeweilige Protokoll versteht. +Eine Simulation besteht auch aus der Anwendung von Protokollen. Es wurde bereits erwähnt, dass ein Prozess die Rollen von Servern und/oder Clients annehmen kann. Bei jeder Server- und Clientrolle muss zusätzlich das dazugehörige Protokoll spezifiziert werden. Ein Protokoll definiert, wie ein Client und ein Server Nachrichten verschickt, und wie bei Ankunft einer Nachricht reagiert wird. Ein Protokoll legt auch fest, welche Daten in einer Nachricht enthalten sind. Ein Prozess verarbeitet eine empfangene Nachricht nur, wenn er das jeweilige Protokoll versteht. -In Abbildung \ref{fig:ClientServerProtokolle} sind 3 Prozesse dargestellt. Prozess 1 unterstützt serverseitig das Protokoll ``A'' und clientseitig das Protokoll ``B''. Prozess 2 unterstützt clientseitig das Protokoll ``A'' und Prozess 3 serverseitig das Protokoll ``B''. Das heißt, dass Prozess 1 mit Prozess 2 via Protokoll ``A'' und mit Prozess 3 via Protokoll ``B'' kommunizieren kann. Die Prozesse 2 und 3 sind zueinander inkompatibel und können voneinander erhaltene Nachrichten nicht verarbeiten. +In Abbildung \ref{fig:ClientServerProtokolle}. sind 3 Prozesse dargestellt. Prozess 1 unterstützt serverseitig das Protokoll ``A'' und clientseitig das Protokoll ``B''. Prozess 2 unterstützt clientseitig das Protokoll ``A'' und Prozess 3 serverseitig das Protokoll ``B''. Das heißt, dass Prozess 1 mit Prozess 2 via Protokoll ``A'' und mit Prozess 3 via Protokoll ``B'' kommunizieren kann. Die Prozesse 2 und 3 sind zueinander inkompatibel und können voneinander erhaltene Nachrichten nicht verarbeiten. -Clients können nicht mit Clients, und Server nicht mit Server kommunizieren. Für eine Kommunikation wird stets mindestens ein Client und ein Server benötigt. Diese Einschränkung kann aber umgangen werden, indem Prozesse ein gegebenes Protokoll sowohl server- als auch clientseitig unterstützen (siehe Broadcast-Sturm Protokoll später). Alle vom Simulator verfügbaren Protokolle werden später genauer behandelt. +Clients können nicht mit Clients, und Server nicht mit Servern kommunizieren. Für eine Kommunikation wird stets mindestens ein Client und ein Server benötigt. Diese Einschränkung kann aber umgangen werden, indem Prozesse ein gegebenes Protokoll sowohl server- als auch clientseitig unterstützen (siehe Broadcast-Sturm Protokoll später). Alle vom Simulator verfügbaren Protokolle werden später genauer behandelt. diff --git a/LaTeX/chapters/protokolle.tex b/LaTeX/chapters/protokolle.tex new file mode 100644 index 0000000..88eab6b --- /dev/null +++ b/LaTeX/chapters/protokolle.tex @@ -0,0 +1,749 @@ +\chapter{Protokolle und Beispiele}
+
+Im Folgenden werden alle verfügbaren Protokolle behandelt. Wie bereits beschrieben wird bei Protokollen zwischen Server- und Clientseite unterschieden. Server können auf Clientnachrichten, und Clients auf Servernachrichten antworten. Jeder Prozess kann beliebig viele Protokolle sowohl clientseitig als auch serverseitig unterstützen. Theoretisch ist es auch möglich, dass ein Prozess für ein bestimmtes Protokoll gleichzeitig der Server und der Client ist. Der Anwender kann auch weitere eigene Protokolle in der Programmiersprache Java mittels einer speziellen API (Application Programming Interface) erstellen. Wie eigene Protokolle erstellt werden können wird später behandelt.
+
+Im dieser Diplomarbeit mitgelieferten Verzeichnis \textit{saved-simulations} befinden sich alle Beispielsimulationen zum selbst-probieren als \textit{.dat} (Serialisierter Java-Bytecode) abgespeichert. Alle Protokolle, bis auf das Beispiel-, das Ping Pong- sowie das Broadcast-Protokoll, orientieren sich an den in \cite{Tanenbaum} und \cite{Vorlesung} behandelten Protokollen.
+
+\section{Beispiel (Dummy) Protokoll}
+
+Das Dummy-Protokoll dient lediglich als leeres Template für die Erstellung eigener Protokolle. Bei der Verwendung des Dummy-Protokolls werden bei Ereignissen lediglich Lognachrichten ausgegeben. Es werden aber keine weiteren Aktionen ausgeführt.
+
+\newpage
+\section{Das Ping-Pong Protokoll \small{\textit{(ping-pong.dat, ping-pong-sturm.dat)}}}
+
+\begin{figure}[h]
+ \centering
+ \fbox{\includegraphics[width=10cm]{images/ss-protokoll-ping-pong}}
+ \caption{Das Ping-Pong Protokoll}
+ \label{fig:PingPongProto}
+\end{figure}
+
+Bei dem Ping-Pong Protokoll (Abbildung \ref{fig:PingPongProto}.) werden zwischen zwei Prozessen, Client P1 und Server P2, ständig Nachrichten hin- und hergeschickt. Der Ping-Pong Client startet die erste Anfrage, worauf der Server dem Client antwortet. Auf diese Antwort wird vom Client ebenfalls geantwortet und so weiter. Jeder Nachricht wird ein Zähler mitgeschickt, der bei jeder Station um eins inkrementiert- und jeweils im Logfenster protokolliert wird. In Tabelle \ref{tb:PingPongTasks}. sind alle für dieses Beispiel programmierten Ereignisse aufgeführt.
+
+\begin{figure}[h]
+ \centering
+ \fbox{\includegraphics[width=10cm]{images/ss-protokoll-ping-pong-sturm}}
+ \caption{Das Ping-Pong Protokoll (Sturm)}
+ \label{fig:PingPongSturmProto}
+\end{figure}
+
+Wichtig ist, dass Prozess 1 seinen Ping-Pong Client aktiviert, bevor er eine Ping-Pong Clientanfrage startet! Wenn die Eintrittszeiten für die Aktivierung des Protokolls und das Starten der Anfrage identisch sind, so ordnet der Task-Manager (mehr dazu später) diese Ereignisse automatisch in der richtigen Reihenfolge an. Bei nicht-aktiviertem Ping-Pong Client könnte P1 auch keine Ping-Pong Anfrage starten. Bevor ein Prozess eine Anfrage starten kann, muss er das dazugehörige Protokoll unterstützen beziehungsweise aktiviert haben. Dies gilt natürlich für alle anderen Protokolle analog. Anhand diesem Beispiel ist erkennbar, dass die noch nicht ausgelieferte Nachrichten grün eingefärbt ist während alle ausgelieferten Nachrichten bereits die Farbe Blau tragen.
+
+Werden die Ereignisse wie in Tabelle \ref{tb:PingPongSturmTasks}. abgeändert, so lässt sich ein Ping-Pong Sturm realisieren. Dort wurde ein neuer Prozess 3 eingeführt, der als zusätzlicher Ping-Pong Server agiert. Da auf jede Clientnachricht stets zwei Serverantworten folgen, verdoppelt sich bei jedem Ping-Pong Durchgang die Anzahl der kursierenden Nachrichten. Auf Abbildung \ref{fig:PingPongSturmProto}. ist der dazugehörige Simulationsverlauf bis zum Zeitpunkt \textit{12676ms} dargestellt.
+
+\begin{table}
+ \centering
+ \fbox{
+ \begin{tabular}{c|c|l}
+ \textbf{Zeit (ms)} & \textbf{PID} & \textbf{Ereignis} \\
+ \hline
+ 0 & 1 & Ping Pong Client aktivieren\\
+ 0 & 2 & Ping Pong Server aktivieren\\
+ 0 & 1 & Ping Pong Clientanfrage starten
+ \end{tabular}
+ }
+ \caption{Programmierte Ping-Pong Ereignisse}
+ \label{tb:PingPongTasks}
+\end{table}
+
+\begin{table}
+ \centering
+ \fbox{
+ \begin{tabular}{c|c|l}
+ \textbf{Zeit (ms)} & \textbf{PID} & \textbf{Ereignis} \\
+ \hline
+ 0 & 1 & Ping Pong Client aktivieren\\
+ 0 & 2 & Ping Pong Server aktivieren\\
+ 0 & 3 & Ping Pong Server aktivieren\\
+ 0 & 1 & Ping Pong Clientanfrage starten
+ \end{tabular}
+ }
+ \caption{Programmierte Ping-Pong Ereignisse (Sturm)}
+ \label{tb:PingPongSturmTasks}
+\end{table}
+
+\begin{table}
+ \centering
+ \fbox{
+ \begin{tabular}{c|c|l}
+ \textbf{Zeit (ms)} & \textbf{PID} & \textbf{Ereignis} \\
+ \hline
+ 0000 & 1 & Broadcast Client aktivieren\\
+ 0000 & 2 & Broadcast Client aktivieren\\
+ 0000 & 3 & Broadcast Client aktivieren\\
+ 0000 & 4 & Broadcast Client aktivieren\\
+ 0000 & 5 & Broadcast Client aktivieren\\
+ 0000 & 6 & Broadcast Client aktivieren\\
+ 0000 & 1 & Broadcast Server aktivieren\\
+ 0000 & 2 & Broadcast Server aktivieren\\
+ 0000 & 3 & Broadcast Server aktivieren\\
+ 0000 & 4 & Broadcast Server aktivieren\\
+ 0000 & 5 & Broadcast Server aktivieren\\
+ 0000 & 6 & Broadcast Server aktivieren\\
+ 0000 & 1 & Broadcast Clientanfrage starten\\
+ 2500 & 1 & Broadcast Clientanfrage starten
+ \end{tabular}
+ }
+ \caption{Programmierte Broadcast Ereignisse}
+ \label{tb:BroadcastSturmTasks}
+\end{table}
+\section{Das Broadcast Protokoll \small{\textit{(broadcast.dat)}}}
+
+\begin{figure}[h]
+ \centering
+ \fbox{\includegraphics[width=10cm]{images/ss-protokoll-broadcast-sturm}}
+ \caption{Das Broadcast Protokoll}
+ \label{fig:BroadcastSturmProto}
+\end{figure}
+
+Das Broadcast Protokoll verhält sich ähnlich wie das Ping-Pong Protokoll. Der Unterschied besteht darin, dass sich das Protokoll anhand einer eindeutigen Broadcast-ID merkt, welche Nachrichten bereits verschickt wurden. Das Broadcast Protokoll (server- und clientseitig) verschickt alle erhaltenen Nachrichten, sofern sie vom jeweiligen Prozess noch nicht schon einmal verschickt wurden, erneut.
+
+Der Server und der Client unterscheiden sich in diesem Fall nicht und führen bei Ankunft einer Nachricht jeweils die selben Aktionen durch. Somit lässt sich, unter Verwendung mehrerer Prozesse (hier 6), wie auf Abbildung \ref{fig:BroadcastSturmProto}., ein Broadcast erzeugen. P1 ist der Client und startet je eine Anfrage nach \textit{0ms} und \textit{2500ms}. Die Simulationsdauer beträgt hier genau \textit{5000ms}. Da ein Client nur Servernachrichten und ein Server nur Clientnachrichten empfangen kann, ist in dieser Simulation jeder Prozess, wie in Tabelle \ref{tb:BroadcastSturmTasks}. angegeben, gleichzeitig Server und Client.
+
+
+\section{Das Protokoll zur internen Synchronisierung in einem synchronen System \small{\textit{(int-sync.dat)}}}
+
+Bisher wurden nur Protokolle vorgeführt, in denen die beteiligten Prozesse keine Uhrabweichung eingestellt hatten. Das Protokoll zur internen Synchronisierung ist ein Protokoll zur Synchronisierung der lokalen Prozesszeit, welches beispielsweise angewendet werden kann, wenn eine Prozesszeit aufgrund einer Uhrabweichung falsch geht. Wenn der Client seine falsche lokale Zeit $t_c$ mit einem Server synchronisieren möchte, so schickt er ihm eine Clientanfrage. Der Server schickt als Antwort seine eigene lokale Prozesszeit $t_s$ zurück, womit der Client seine neue und genauere Prozesszeit berechnen kann. Wie genau die neue Prozesszeit berechnet wird, ist im Folgenden beschrieben:
+
+\begin{figure}[h]
+ \centering
+ \fbox{\includegraphics[width=10cm]{images/ss-protokoll-time-sync}}
+ \caption{Das Protokoll zur internen Synchronisierung}
+ \label{fig:TimeSyncProto}
+\end{figure}
+
+Hier (Abbildung \ref{fig:TimeSyncProto}.) stellt P1 den Client und P2 den Server dar. Da die Übertragungszeit $t_u$ einer Nachricht angenommen zwischen $t'_{min}$ und $t'_{max}$ liegt, setzt der Client P1 nach Empfang der Serverantwort seine lokale Prozesszeit auf
+
+\begin{equation*}
+ t_c := t_s + \frac{1}{2} (t'_{min} + t'_{max})
+\end{equation*}
+
+Somit wurde die lokale Zeit von P1, bis auf einen Fehler von $< \frac{1}{2} (t'_{max} - t'_{min})$, synchronisiert.
+
+Der Clientprozess hat in der Abbildung \ref{fig:TimeSyncProto}. als Uhrabweichung den Wert \textit{0.1} und der Server hat als Uhrabweichung den Wert \textit{0.0} konfiguriert. Der Client startet, wie in Tabelle \ref{tb:InterneSyncTasks}. angegeben, nach \textit{0ms}, \textit{5000ms} und \textit{10000ms} seiner lokalen Prozesszeit jeweils eine Clientanfrage. In der Abbildung lässt sich erkennen, dass die 2. und die 3. Anfrage nicht synchron zu der globalen Zeit (siehe Sekunden-Gatter) gestartet wurden, was auf die Uhrabweichung von P1 zurückzuführen ist. Nach Simulationsende ist die Zeit von P1 bis auf \textit{15000ms} - \textit{15976ms} = \textit{-976ms} synchronisiert.
+
+\begin{table}
+ \centering
+ \fbox{
+ \begin{tabular}{c|c|l}
+ \textbf{Zeit (ms)} & \textbf{PID} & \textbf{Ereignis} \\
+ \hline
+ 00000 & 1 & Interne Sync. Client aktivieren \\
+ 00000 & 2 & Interne Sync. Server aktivieren\\
+ 00000 & 1 & Interne Sync. Clientanfrage starten\\
+ 05000 & 1 & Interne Sync. Clientanfrage starten\\
+ 10000 & 1 & Interne Sync. Clientanfrage starten\\
+ \end{tabular}
+ }
+ \caption{Programmierte Ereignisse zur internen Synchronisierung}
+ \label{tb:InterneSyncTasks}
+\end{table}
+
+\subsubsection{Protokollvariablen}
+
+Dieses Protokoll verwendet folgende zwei clientseitige Variablen, die in den Prozesseinstellungen unter dem Punkt ``Interne Sync. Client'' konfiguriert werden können. Serverseitig gibt es hier keine Variablen.
+
+\begin{itemize}
+ \item \textbf{Min. Übertragungszeit} \textit{(Long: 500)}: Gibt den Wert $t'_{min}$ in Millisekunden an
+ \item \textbf{Max. Übertragungszeit} \textit{(Long: 2000)}: Gibt den Wert $t'_{max}$ in Millisekunden an
+\end{itemize}
+
+$t'_{min}$ und $t'_{max}$ sind die bei den Protokollberechnungen verwendeten Werte. Sie können sich allerdings von den tatsächlichen Nachrichtenübertragungszeiten $t_{min}$ und $t_{max}$ (siehe Sektion über Prozesseinstellungen) unterscheiden. Somit lassen sich auch Szenarien simulieren, in denen das Protokoll falsch eingestellt wurde und wo in der Zeitsynchronisierung große Fehler auftreten können.
+
+
+\section{Christians Methode zur externen Synchronisierung \small{\textit{(ext-vs-int-sync.dat)}}}
+
+\begin{figure}[h]
+ \centering
+ \fbox{\includegraphics[width=10cm]{images/ss-protokoll-time-sync-2}}
+ \caption{Interne Synchronisierung und Christians Methode im Vergleich}
+ \label{fig:TimeSync2Proto}
+\end{figure}
+
+Ein weiteres Protokoll für die Synchronisierung von Uhrzeiten funktioniert nach der Christians Methode zur externen Synchronisierung. Die Christians Methode benutzt die RTT (Round Trip Time) $t_{rtt}$, um die Übertragungszeit von einzelnen Nachrichten zu approximieren.
+
+Wenn der Client seine lokale Zeit $t_c$ bei einem Server synchronisieren möchte, so verschickt er eine Anfrage, und misst dabei bis zur Ankunft der Serverantwort die dazugehörige RTT $t_{rtt}$. Die Serverantwort beinhaltet die lokale Prozesszeit $t_s$ vom Server von dem Zeitpunkt, als der Server die Antwort verschickte. Der Client setzt dann seine lokale Zeit neu auf:
+
+\begin{equation*}
+ t_c := t_s + \frac{1}{2} t_{rtt}
+\end{equation*}
+
+und zwar mit einer Genauigkeit von $\pm(\frac{1}{2} t_{rtt} - u_{min}$) wenn $u_{min}$ eine Schranke für eine Nachrichtenübertragung mit $t_{rtt} < u_{min}$ ist (siehe \cite{Vorlesung}).
+
+Im Prinzip sieht ein Verlauf einer Christians-Simulation so aus wie auf Abbildung \ref{fig:TimeSyncProto}., daher wird hier auf eine einfache Abbildung vom Christians-Protokoll verzichtet. Viel interessanter ist der direkte Vergleich zwischen dem Protokoll zur internen Synchronisierung und der Christians Methode der externen Synchronisierung (Abbildung \ref{fig:TimeSync2Proto}.). Hier stellt P1 den Client zur internen Synchronisierung und P3 den Client zur externen Synchronisierung dar. P2 fungiert für beide Protokolle gleichzeitig als Server. P1 und P3 starten jeweils zu den lokalen Prozesszeiten \textit{0ms}, \textit{5000ms} und \textit{10000ms} eine Clientanfrage (Tabelle \ref{tb:InterneSync2Tasks}.). P1 und P3 haben als Uhrabweichung \textit{0.1} eingestellt und die Simulationsdauer beträgt insgesamt \textit{15000ms}.
+
+Auf der Abbildung \ref{fig:TimeSync2Proto}. ist ablesbar, dass nach Ablauf der Simulation P1 seine Zeit bis auf \textit{15000ms} - \textit{14567ms} = \textit{433ms} und P3 seine Zeit bis auf \textit{15000ms} - \textit{15539ms} = \textit{-539ms} synchronisiert hat. In diesem Beispiel hat also das Protokoll zur internen Synchronisierung ein besseres Ergebnis geliefert. Dies ist allerdings nicht zwingend immer der Fall, da nach einer erneuten Simulationsausführung alle Nachrichten jeweils eine neue zufällige Übertragungszeit zwischen $t_{min}$ und $t_{max}$ haben werden, die auf das eine oder andere Protokoll wieder andere Auswirkungen haben können.
+
+\begin{table}
+ \centering
+ \fbox{
+ \begin{tabular}{c|c|l}
+ \textbf{Zeit (ms)} & \textbf{PID} & \textbf{Ereignis} \\
+ \hline
+ 00000 & 1 & Interne Sync. Client aktivieren \\
+ 00000 & 1 & Interne Sync. Clientanfrage starten\\
+ 00000 & 2 & Christians Server aktivieren\\
+ 00000 & 2 & Interne Sync. Server aktivieren\\
+ 00000 & 3 & Christians Client aktivieren \\
+ 00000 & 3 & Christians Clientanfrage starten\\
+ 05000 & 1 & Interne Sync. Clientanfrage starten\\
+ 05000 & 3 & Christians Clientanfrage starten\\
+ 10000 & 1 & Interne Sync. Clientanfrage starten\\
+ 10000 & 3 & Christians Clientanfrage starten\\
+ \end{tabular}
+ }
+ \caption{Programmierte Ereignisse, Vergleich interne und externe Synchronisierung}
+ \label{tb:InterneSync2Tasks}
+\end{table}
+
+
+\section{Der Berkeley Algorithmus zur internen Synchronisierung \small{\textit{(berkeley.dat)}}}
+
+\begin{figure}[h]
+ \centering
+ \fbox{\includegraphics[width=10cm]{images/ss-protokoll-berkeley}}
+ \caption{Der Berkeley Algorithmus zur internen Synchronisierung}
+ \label{fig:BerkeleyProto}
+\end{figure}
+
+Der Berkeley Algorithmus zur internen Synchronisierung ist eine weitere Möglichkeit lokale Uhrzeiten abzugleichen. Dies ist das erste Protokoll, wo der Server die Anfragen startet. Der Server stellt den Koordinator des Protokolls dar. Die Clients sind somit passiv und müssen warten, bis eine Serveranfrage eintrifft. Hierbei muss der Server wissen, welche Clientprozesse an dem Protokoll teilnehmen, was sich in den Protokolleinstellungen des Servers einstellen lässt.
+
+Wenn der Server seine eigene lokale Zeit $t_s$ und auch die lokalen Prozesszeiten $t_i$ der Clients ($i = 1, ..., n$) synchronisieren möchte, so verschickt er eine Serveranfrage. $n$ sei hierbei die Anzahl beteiligter Clients. Die Clients senden dann ihre lokalen Prozesszeiten in einer Nachricht zurück zum Server. Der Server hat dabei die RTTs $r_i$ bis zur Ankunft aller Clientantworten gemessen.
+
+Nachdem alle Antworten vorliegen, setzt er zunächst seine eigene Zeit $t_s$ auf den Mittelwert $t_{avg}$ aller bekannten Prozesszeiten (seiner eigenen Prozesszeit eingeschlossen). Die Übertragungszeit einer Clientantwort wird auf die Hälfte der RTT geschätzt und in der Berechnung berücksichtigt:
+
+\begin{equation*}
+ t_{avg} :=
+ \frac{1}{n+1} ( t_s +
+ \sum_{\substack{
+ i=1\\
+ }}^n
+ \frac{r_i}{2} + t_i
+ )
+\end{equation*}
+\begin{equation*}
+ t_s := t_{avg}
+\end{equation*}
+
+Anschließend berechnet der Server für jeden Client einen Korrekturwert $k_i := t_{avg} - t_i$, den er jeweils in einer separaten Nachricht zurückschickt. Die Clients setzten dann jeweils die lokalen Prozesszeiten auf $t'_i := t'_i + k_i$. Hierbei stellt $t'_i$ die derzeit aktuelle Prozesszeit des jeweiligen Clients dar, denn bis zum Eintreffen des Korrekturwertes ist inzwischen wieder neue Zeit verstrichen.
+
+Im Beispiel auf Abbildung \ref{fig:BerkeleyProto}. gibt es die 2 Clientprozesse P1 und P3 sowie den Serverprozess P2. Der Server startet nach jeweils \textit{0ms} und \textit{7500ms} eine Synchronisierungsanfrage (Tabelle \ref{tb:BerkeleyTasks}.). Hier fällt auf, dass der Server stets 2 Korrekturwerte verschickt, die jeweils P1 und P3 erreichen. Es werden hier also pro Synchronisierungsvorgang insgesamt 4 Korrekturwerte ausgeliefert. Eine Korrekturnachricht enthält neben dem Korrekturwert $k_i$ auch die PID des Prozesses, für den die Nachricht bestimmt ist. Indem das Protokoll die PID überprüft verarbeitet ein Client so nur die für ihn bestimmten Korrekturwerte.
+
+\begin{table}
+ \centering
+ \fbox{
+ \begin{tabular}{c|c|l}
+ \textbf{Zeit (ms)} & \textbf{PID} & \textbf{Ereignis} \\
+ \hline
+ 0000 & 1 & Berkeley Client aktivieren \\
+ 0000 & 2 & Berkeley Server aktivieren \\
+ 0000 & 3 & Berkeley Client aktivieren \\
+ 0000 & 2 & Berkeley Serveranfrage starten\\
+ 7500 & 2 & Berkeley Serveranfrage starten\\
+ \end{tabular}
+ }
+ \caption{Programmierte Ereignisse zum Berkeley Algorithmus}
+ \label{tb:BerkeleyTasks}
+\end{table}
+\subsubsection{Protokollvariablen}
+
+Dieses Protokoll verwendet folgende serverseitige Variable, die in den Prozesseinstellungen unter dem Punkt ``Berkeley Server'' konfiguriert werden kann. Clientseitig gibt es hier keine Variablen.
+
+\begin{itemize}
+ \item \textbf{PIDs beteiligter Prozesse} \textit{(Integer[]: [1,3])}: Dieser Vektor aus Integerwerten beinhaltet alle PIDs der Berkeley Clientprozesse, mit denen der Berkeley Server die Zeit synchronisieren soll. Das Protokoll funktioniert nicht, wenn hier eine PID angegeben wird die gar nicht existiert oder nicht das Berkeley Protokoll clientseitig gar nicht unterstützt. In diesem Fall würde ewig auf eine fehlende Clientantwort gewartet werden.
+\end{itemize}
+
+
+\section{Das Ein-Phasen Commit Protokoll \small{\textit{(one-phase-commit.dat)}}}
+
+\begin{figure}[h]
+ \centering
+ \fbox{\includegraphics[width=10cm]{images/ss-protokoll-one-phase-commit}}
+ \caption{Das Ein-Phasen Commit Protokoll}
+ \label{fig:OnePhaseCommitProto}
+\end{figure}
+
+Das Ein-Phasen Commit Protokoll ist dafür gedacht beliebig vielen Clients zu einer Festschreibung zu bewegen. Im realen Leben könnte dies beispielsweise das Erstellen oder Löschen einer Datei sein, von der auf jedem Client eine lokale Kopie existiert. Der Server ist der Koordinator und auch derjenige, der einen Festschreibewunsch initiiert. Hierbei verschickt der Server periodisch so oft den Festschreibewunsch, bis er von jedem Client eine Bestätigung erhalten hat. Der Server muss dabei die PIDs aller beteiligten Clientprozesse sowie einen Wecker für erneutes Versenden des Festschreibewunsches eingestellt bekommen.
+
+Die programmierten Ereignisse des Beispiels auf Abbildung \ref{fig:OnePhaseCommitProto}. sind in Tabelle \ref{tb:OnePhaseCommitTasks}. aufgelistet. P1 und P3 simulieren jeweils einen Client und P2 den Server. Damit die Simulation mehrere Festschreibewünsche verschickt, stürzt in der Simulation P1 nach \textit{1000ms} ab und nach \textit{5000ms} steht er wieder zur Verfügung. Die ersten beide Festschreibewünsche erreichen dadurch P1 nicht und erst der dritte Versuch verläuft erfolgreich. Bevor die Bestätigung von P1 bei P2 eintrifft, läuft jedoch der Wecker erneut ab, so dass ein weiterer Festschreibewunsch versendet wird. Da P1 und P3 jeweils schon eine Bestätigung verschickt haben, wird diese Festschreibewunschnachricht ignoriert. Jeder Client bestätigt auf einen Festschreibewunsch nur ein einziges Mal.
+
+\begin{table}
+ \centering
+ \fbox{
+ \begin{tabular}{c|c|l}
+ \textbf{Zeit (ms)} & \textbf{PID} & \textbf{Ereignis} \\
+ \hline
+ 0000 & 1 & 1-Phasen Commit Client aktivieren\\
+ 0000 & 2 & 1-Phasen Commit Server aktivieren\\
+ 0000 & 3 & 1-Phasen Commit Client aktivieren\\
+ 0000 & 2 & 1-Phasen Commit Serveranfrage starten\\
+ 1000 & 1 & Prozessabsturz\\
+ 5000 & 1 & Prozesswiederbelebung
+ \end{tabular}
+ }
+ \caption{Programmierte Ein-Phasen Commit Ereignisse}
+ \label{tb:OnePhaseCommitTasks}
+\end{table}
+
+\subsubsection{Protokollvariablen}
+
+Dieses Protokoll verwendet folgende serverseitige Variablen, die in den Prozesseinstellungen unter dem Punkt ``1-Phasen Commit Server'' konfiguriert werden können. Clientseitig gibt es hier keine Variablen.
+
+\begin{itemize}
+ \item \textbf{Zeit bis erneute Anfrage} \textit{(Long: timeout = 2500)}: Gibt die Anzahl von Millisekunden an, die gewartet werden sollen, bis der Festschreibewunsch erneut verschickt wird.
+ \item \textbf{PIDs beteiligter Prozesse} \textit{(Integer[]: pids = [1,3])}: Dieser Vektor aus Integerwerten beinhaltet alle PIDs der Clientprozesse, die festschreiben sollen.
+\end{itemize}
+
+
+\section{Das Zwei-Phasen Commit Protokoll \small{\textit{(two-phase-commit.dat)}}}
+
+\begin{figure}[h]
+ \centering
+ \fbox{\includegraphics[width=10cm]{images/ss-protokoll-two-phase-commit}}
+ \caption{Das Zwei-Phasen Commit Protokoll}
+ \label{fig:TwoPhaseCommitProto}
+\end{figure}
+
+Das Zwei-Phasen Commit Protokoll ist eine Erweiterung des Ein-Phasen Commit Protokolls. Der Server startet zunächst eine Anfrage an alle beteiligten Clients, ob festgeschrieben werden soll. Jeder Client antwortet dann mit \textit{true} oder \textit{false}. Der Server fragt so oft periodisch nach, bis alle Ergebnisse aller Clients vorliegen. Nach Erhalt aller Abstimmungen überprüft der Server, ob alle mit \textit{true} abgestimmt haben. Für den Fall dass mindestens ein Client mit \textit{false} abgestimmt hat, wird der Festschreibevorgang abgebrochen und als globales Abstimmungsergebnis \textit{false} verschickt. Wenn jedoch alle mit \textit{true} abstimmten, soll festgeschrieben werden. Dabei wird das globale Abstimmungsergebnis \textit{true} verschickt. Das globale Abstimmungsergebnis wird periodisch so oft erneut verschickt, bis von jedem Client eine Bestätigung des Erhalts vorliegt.
+
+In dem Beispiel (Abbildung \ref{fig:TwoPhaseCommitProto}.) sind P1 und P3 Clients und P2 der Server. Der Server verschickt nach \textit{0ms} seine erste Anfrage (Tabelle \ref{tb:TwoPhaseCommitTasks}.). Da diese Simulation recht unübersichtlich ist, liegen in den Tabellen \ref{tb:TwoPhaseCommitLogs}. und \ref{tb:TwoPhaseCommitLogs2}. Auszüge aus dem Logfenster vor. Auf die Lamport- und Vektor-Zeitstempel sowie die lokalen Prozesszeiten wurde hier wegen Irrelevanz verzichtet. Da keine Uhrabweichungen konfiguriert wurden, sind die lokalen Prozesszeiten stets gleich der globalen Zeit und deswegen wird in den Tabellen pro Logeintrag jeweils nur eine Zeit angegeben. Anhand der Nachrichten IDs lassen sich dort die einzelnen Sendungen zuordnen. In den Logs wird auch ständig der Inhalt der verschickten Nachricht sowie die dazugehörigen Datentypen aufgeführt. Hier stimmen P1 und P3 jeweils mit \textit{true}, d.h. es soll festgeschrieben werden, ab.
+
+\begin{table}
+ \centering
+ \fbox{
+ \begin{tabular}{c|c|l}
+ \textbf{Zeit (ms)} & \textbf{PID} & \textbf{Ereignis} \\
+ \hline
+ 0000 & 1 & 2-Phasen Commit Client aktivieren\\
+ 0000 & 2 & 2-Phasen Commit Server aktivieren\\
+ 0000 & 3 & 2-Phasen Commit Client aktivieren\\
+ 0000 & 2 & 2-Phasen Commit Serveranfrage starten
+ \end{tabular}
+ }
+ \caption{Programmierte Zwei-Phasen Commit Ereignisse}
+ \label{tb:TwoPhaseCommitTasks}
+\end{table}
+
+\subsubsection{Protokollvariablen}
+
+Dieses Protokoll verwendet folgende serverseitige Variablen, die in den Prozesseinstellungen unter dem Punkt ``2-Phasen Commit Server'' konfiguriert werden können:
+
+\begin{itemize}
+ \item \textbf{Zeit bis erneute Anfrage} \textit{(Long: timeout = 2500)}: Gibt die Anzahl von Millisekunden an, die gewartet werden sollen, bis der Festschreibewunsch erneut verschickt wird.
+ \item \textbf{PIDs beteiligter Prozesse} \textit{(Integer[]: pids = [1,3])}: Dieser Vektor aus Integerwerten beinhaltet alle PIDs der Clientprozesse die über eine Festschreibung abstimmen und anschließend gegebenenfalls festschreiben sollen.
+\end{itemize}
+
+Und folgende Clientvariable kann unter den Prozesseinstellungen unter dem Punkt ``2-Phasen Commit Client'' konfiguriert werden:
+
+\begin{itemize}
+ \item \textbf{Festschreibwahrscheinlichkeit} \textit{(Integer: ackProb = 50)}: Gibt die Wahrscheinlichkeit in Prozent an, die der Client mit \textit{true}, also für das Festschreiben, abstimmt.
+\end{itemize}
+
+\begin{table}
+ \centering
+ \fbox{
+ \begin{tabular}{c|c|l}
+ \textbf{Zeit (ms)} & \textbf{PID} & \textbf{Lognachricht} \\
+ \hline
+000000 & & Simulation gestartet\\
+\hline
+000000 & 1 & 2-Phasen Commit Client aktiviert\\
+\hline
+000000 & 2 & 2-Phasen Commit Server aktiviert\\
+\hline
+000000 & 2 & Nachricht versendet; ID: 94; Protokoll: 2-Phasen Commit\\
+ & & Boolean: wantVote=true\\
+\hline
+000000 & 3 & 2-Phasen Commit Client aktiviert\\
+\hline
+000905 & 3 & Nachricht erhalten; ID: 94; Protokoll: 2-Phasen Commit\\
+\hline
+000905 & 3 & Nachricht versendet; ID: 95; Protokoll: 2-Phasen Commit\\
+ & & Integer: pid=3; Boolean: isVote=true; vote=true\\
+\hline
+000905 & 3 & Abstimmung true versendet\\
+\hline
+001880 & 2 & Nachricht erhalten; ID: 95; Protokoll: 2-Phasen Commit\\
+\hline
+001880 & 2 & Abstimmung von Prozess 3 erhalten! Ergebnis: true\\
+\hline
+001947 & 1 & Nachricht erhalten; ID: 94; Protokoll: 2-Phasen Commit\\
+\hline
+001947 & 1 & Nachricht versendet; ID: 96; Protokoll: 2-Phasen Commit\\
+ & & Integer: pid=1; Boolean: isVote=true; vote=true\\
+\hline
+001947 & 1 & Abstimmung true versendet\\
+\hline
+002500 & 2 & Nachricht versendet; ID: 97; Protokoll: 2-Phasen Commit\\
+ & & Boolean: wantVote=true\\
+\hline
+003006 & 3 & Nachricht erhalten; ID: 97; Protokoll: 2-Phasen Commit\\
+\hline
+003006 & 3 & Nachricht versendet; ID: 98; Protokoll: 2-Phasen Commit\\
+ & & Integer: pid=3; Boolean: isVote=true; vote=true\\
+\hline
+003006 & 3 & Abstimmung true versendet\\
+\hline
+003137 & 2 & Nachricht erhalten; ID: 96; Protokoll: 2-Phasen Commit\\
+\hline
+003137 & 2 & Abstimmung von Prozess 1 erhalten! Ergebnis: true\\
+\hline
+003137 & 2 & Abstimmungen von allen beteiligten Prozessen erhalten!\\
+ & & Globales Ergebnis: true\\
+\hline
+003137 & 2 & Nachricht versendet; ID: 99; Protokoll: 2-Phasen Commit\\
+ & & Boolean: isVoteResult=true; voteResult=true\\
+\hline
+004124 & 1 & Nachricht erhalten; ID: 99; Protokoll: 2-Phasen Commit\\
+\hline
+004124 & 1 & Globales Abstimmungsergebnis erhalten. Ergebnis: true\\
+\hline
+004124 & 1 & Nachricht versendet; ID: 100; Protokoll: 2-Phasen Commit\\
+ & & Integer: pid=1; Boolean: isAck=true\\
+\hline
+004354 & 3 & Nachricht erhalten; ID: 99; Protokoll: 2-Phasen Commit\\
+\hline
+004354 & 3 & Globales Abstimmungsergebnis erhalten. Ergebnis: true\\
+\hline
+004354 & 3 & Nachricht versendet; ID: 101; Protokoll: 2-Phasen Commit\\
+ & & Integer: pid=3; Boolean: isAck=true\\
+\hline
+004434 & 1 & Nachricht erhalten; ID: 97; Protokoll: 2-Phasen Commit\\
+\hline
+004434 & 1 & Nachricht versendet; ID: 102; Protokoll: 2-Phasen Commit\\
+ & & Integer: pid=1; Boolean: isVote=true; vote=true\\
+ \end{tabular}
+ }
+ \caption{Auszug aus der Logausgabe des Zwei-Phasen Commit Beispiels}
+ \label{tb:TwoPhaseCommitLogs}
+\end{table}
+
+\begin{table}
+ \centering
+ \fbox{
+ \begin{tabular}{c|c|l}
+ \textbf{Zeit (ms)} & \textbf{PID} & \textbf{Lognachricht} \\
+ \hline
+004434 & 1 & Abstimmung true versendet\\
+\hline
+004527 & 2 & Nachricht erhalten; ID: 98; Protokoll: 2-Phasen Commit\\
+\hline
+004975 & 2 & Nachricht erhalten; ID: 101; Protokoll: 2-Phasen Commit\\
+\hline
+005311 & 2 & Nachricht erhalten; ID: 102; Protokoll: 2-Phasen Commit\\
+\hline
+005637 & 2 & Nachricht versendet; ID: 103; Protokoll: 2-Phasen Commit\\
+ & & Boolean: isVoteResult=true; voteResult=true\\
+\hline
+006051 & 2 & Nachricht erhalten; ID: 100; Protokoll: 2-Phasen Commit\\
+\hline
+006051 & 2 & Alle Teilnehmer haben die Abstimmung erhalten\\
+\hline
+006766 & 1 & Nachricht erhalten; ID: 103; Protokoll: 2-Phasen Commit\\
+\hline
+006766 & 1 & Globales Abstimmungsergebnis erhalten. Ergebnis: true\\
+\hline
+006766 & 1 & Nachricht versendet; ID: 104; Protokoll: 2-Phasen Commit\\
+ & & Integer: pid=1; Boolean: isAck=true\\
+\hline
+007279 & 2 & Nachricht erhalten; ID: 104; Protokoll: 2-Phasen Commit\\
+\hline
+007618 & 3 & Nachricht erhalten; ID: 103; Protokoll: 2-Phasen Commit\\
+\hline
+007618 & 3 & Globales Abstimmungsergebnis erhalten. Ergebnis: true\\
+\hline
+007618 & 3 & Nachricht versendet; ID: 105; Protokoll: 2-Phasen Commit\\
+ & & Integer: pid=3; Boolean: isAck=true\\
+\hline
+009170 & 2 & Nachricht erhalten; ID: 105; Protokoll: 2-Phasen Commit\\
+\hline
+010000 & & Simulation beendet
+ \end{tabular}
+ }
+ \caption{Auszug aus der Logausgabe des Zwei-Phasen Commit Beispiels (2)}
+ \label{tb:TwoPhaseCommitLogs2}
+\end{table}
+
+
+\section{Der ungenügende (Basic) Multicast \small{\textit{(basic-multicast.dat)}}}
+
+\begin{figure}[h]
+ \centering
+ \fbox{\includegraphics[width=10cm]{images/ss-protokoll-basic-multicast}}
+ \caption{Das Basic-Multicast Protokoll}
+ \label{fig:BasicMulticastProto}
+\end{figure}
+
+Das Basic-Multicast Protokoll ist sehr einfach aufgebaut. Im Beispiel auf Abbildung \ref{fig:BasicMulticastProto}. sind P1 und P3 Server und P2 der Client. Bei diesem Protokoll startet der Client immer die Anfrage, welche bei diesem Protokoll eine einfache Multicast-Nachricht darstellen soll. Die Basic-Multicast Server dienen lediglich für den Empfang einer Nachricht. Es werden keine Bestätigungen verschickt. Wie in Tabelle \ref{tb:BasicMulticastTasks}. aufgeführt verschickt P2 alle \textit{2500ms} jeweils eine Multicast-Nachricht, die alle voneinander völlig unabhängig sind.
+
+P1 kann jedoch erst nach \textit{2500ms} Multicast-Nachrichten empfangen, da er vorher das Protokoll nicht unterstützt während P3 von \textit{3000ms} bis \textit{6000ms} abgestürzt ist und in dieser Zeit auch keine Nachrichten empfangen kann. Je nach Interpretation könnte P1 einen Server simulieren, der erst später ans Netz angeschlossen wird. Da die Einstellung ``Nur relevante Nachrichten anzeigen'' aktiviert ist, wird die erste Multicast-Nachricht von P2 an P1 nicht dargestellt. Bei jedem Prozess wurde die Nachrichtenverlustwahrscheinlichkeit auf \textit{30} Prozent gestellt, weswegen alle in dieser Simulation verschickten Nachrichten mit einer Wahrscheinlichkeit von \textit{30} Prozent ausfallen.
+
+In diesem Beispiel ging die 3. Multicast-Nachricht auf den Weg zu P3- und die 5. sowie 6. Nachricht auf den Weg zu P1 verloren. Lediglich die 4. Multicast-Nachricht hat alle beiden Ziele auf einmal erreicht.
+
+\begin{table}
+ \centering
+ \fbox{
+ \begin{tabular}{c|c|l}
+ \textbf{Zeit (ms)} & \textbf{PID} & \textbf{Ereignis} \\
+ \hline
+ 00000 & 2 & Basic Multicast Client aktivieren\\
+ 00000 & 3 & Basic Multicast Server aktivieren\\
+ 00000 & 2 & Basic Multicast Clientanfrage starten\\
+ 02500 & 1 & Basic Multicast Server aktivieren\\
+ 02500 & 2 & Basic Multicast Clientanfrage starten\\
+ 03000 & 3 & Prozessabsturz\\
+ 05000 & 2 & Basic Multicast Clientanfrage starten\\
+ 06000 & 3 & Prozesswiederbelebung\\
+ 07500 & 2 & Basic Multicast Clientanfrage starten\\
+ 10000 & 2 & Basic Multicast Clientanfrage starten\\
+ 12500 & 2 & Basic Multicast Clientanfrage starten
+ \end{tabular}
+ }
+ \caption{Programmierte Basic-Multicast Ereignisse}
+ \label{tb:BasicMulticastTasks}
+\end{table}
+
+
+\section{Der zuverlässige (Reliable) Multicast \small{\textit{(reliable-multicast.dat)}}}
+
+\begin{figure}[h]
+ \centering
+ \fbox{\includegraphics[width=10cm]{images/ss-protokoll-reliable-multicast}}
+ \caption{Das Reliable-Multicast Protokoll}
+ \label{fig:ReliableMulticastProto}
+\end{figure}
+
+Bei dem zuverlässigen (Reliable) Multicast verschickt der Client so oft periodisch seine Multicast-Nachricht erneut, bis er von allen beteiligten Servern eine Bestätigung erhalten hat. Nach jedem erneuten Versuch vergisst der Client, von welchen Servern er bereits eine Bestätigung erhalten hat, womit jeder erneuter Versuch von allen Teilnehmern aufs Neue bestätigt werden muss. In dem Beispiel (Abbildung \ref{fig:ReliableMulticastProto}., Tabelle \ref{tb:ReliableMulticastTasks}., sowie den Logs in den Tabellen \ref{tb:ReliableMulticastLogs}. und \ref{tb:ReliableMulticastLogs2}.) ist P2 der Multicast-verschickende Client, während P1 und P3 die Server darstellen. Bei \textit{0ms} initiiert der Client seine Multicast-Nachricht. Die Nachrichtenverlustwahrscheinlichkeiten sind bei allen Prozessen auf \textit{30} Prozent eingestellt.
+
+In diesem Beispiel benötigt der Client bis zur erfolgreichen Auslieferung des zuverlässigen Multicasts genau 5 Versuche:
+
+\begin{enumerate}
+ \setlength{\itemsep}{-1mm}
+ \item Versuch:
+ \begin{itemize}
+ \setlength{\itemsep}{-2.5mm}
+ \item P1 unterstützt das Reliable-Multicast Protokoll noch nicht, und kann somit weder Multicast-Nachricht erhalten noch eine Bestätigung verschicken.
+ \item P3 empfängt die Multicast-Nachricht, jedoch geht seine Bestätigungsnachricht verloren.
+ \end{itemize}
+ \item Versuch:
+ \begin{itemize}
+ \setlength{\itemsep}{-2.5mm}
+ \item P1: Die Multicast-Nachricht geht unterwegs zu P1 verloren.
+ \item P3: Die Multicast-Nachricht erreicht P3, aber P3 ist abgestürzt und kann somit keine Nachricht verarbeiten.
+ \end{itemize}
+ \item Versuch:
+ \begin{itemize}
+ \setlength{\itemsep}{-2.5mm}
+ \item P1 empfängt die Multicast-Nachricht und seine Bestätigung kommt wie geplant bei P2 an.
+ \item P3: Die Multicast-Nachricht geht unterwegs zu P3 verloren.
+ \end{itemize}
+ \item Versuch:
+ \begin{itemize}
+ \setlength{\itemsep}{-2.5mm}
+ \item P1 empfängt die Multicast-Nachricht und seine Bestätigung kommt wie geplant bei P2 an.
+ \item P3: Die Multicast-Nachricht erreicht P3, aber P3 ist abgestürzt und kann somit keine Nachricht verarbeiten.
+ \end{itemize}
+ \item Versuch:
+ \begin{itemize}
+ \item P1 empfängt die Multicast-Nachricht und seine Bestätigung kommt wie geplant bei P2 an.
+ \setlength{\itemsep}{-2.5mm}
+ \item P3 empfängt die Multicast-Nachricht und seine Bestätigung kommt wie geplant bei P2 an.
+ \end{itemize}
+\end{enumerate}
+
+\begin{table}
+ \centering
+ \fbox{
+ \begin{tabular}{c|c|l}
+ \textbf{Zeit (ms)} & \textbf{PID} & \textbf{Ereignis} \\
+ \hline
+ 00000 & 3 & Reliable Multicast Server aktivieren\\
+ 00000 & 2 & Reliable Multicast Client aktivieren\\
+ 00000 & 2 & Reliable Multicast Clientanfrage starten\\
+ 02500 & 1 & Reliable Multicast Server aktivieren\\
+ 03000 & 3 & Prozessabsturz\\
+ 10000 & 3 & Prozesswiederbelebung\\
+ \end{tabular}
+ }
+ \caption{Programmierte Reliable-Multicast Ereignisse}
+ \label{tb:ReliableMulticastTasks}
+\end{table}
+
+\begin{table}
+ \centering
+ \fbox{
+ \begin{tabular}{c|c|l}
+ \textbf{Zeit (ms)} & \textbf{PID} & \textbf{Lognachricht} \\
+ \hline
+000000 & & Simulation gestartet\\
+\hline
+000000 & 2 & Reliable Multicast Client aktiviert\\
+\hline
+000000 & 2 & Nachricht versendet; ID: 280; Protokoll: Reliable Multicast;\\
+ & & Boolean: isMulticast=true\\
+\hline
+000000 & 3 & Reliable Multicast Server aktiviert\\
+\hline
+001590 & 3 & Nachricht erhalten; ID: 280; Protokoll: Reliable Multicast\\
+\hline
+001590 & 3 & Nachricht versendet; ID: 281; Protokoll: Reliable Multicast\\
+ & & Integer: pid=3; Boolean: isAck=true\\
+\hline
+001590 & 3 & ACK versendet\\
+\hline
+002500 & 1 & Reliable Multicast Server aktiviert\\
+\hline
+002500 & 2 & Nachricht versendet; ID: 282; Protokoll: Reliable Multicast\\
+ & & Boolean: isMulticast=true\\
+\hline
+003000 & 3 & Abgestürzt\\
+\hline
+005000 & 2 & Nachricht versendet; ID: 283; Protokoll: Reliable Multicast\\
+ & & Boolean: isMulticast=true\\
+\hline
+005952 & 1 & Nachricht erhalten; ID: 283; Protokoll: Reliable Multicast\\
+\hline
+005952 & 1 & Nachricht versendet; ID: 284; Protokoll: Reliable Multicast\\
+ & & Integer: pid=1; Boolean: isAck=true\\
+\hline
+005952 & 1 & ACK versendet\\
+\hline
+007500 & 2 & Nachricht versendet; ID: 285; Protokoll: Reliable Multicast\\
+ & & Boolean: isMulticast=true\\
+\hline
+007937 & 2 & Nachricht erhalten; ID: 284; Protokoll: Reliable Multicast\\
+\hline
+007937 & 2 & ACK von Prozess 1 erhalten!\\
+\hline
+008469 & 1 & Nachricht erhalten; ID: 285; Protokoll: Reliable Multicast\\
+\hline
+008469 & 1 & Nachricht versendet; ID: 286; Protokoll: Reliable Multicast\\
+ & & Integer: pid=1; Boolean: isAck=true\\
+\hline
+008469 & 1 & ACK erneut versendet\\
+\hline
+010000 & 2 & Nachricht versendet; ID: 287; Protokoll: Reliable Multicast\\
+ & & Boolean: isMulticast=true\\
+\hline
+010000 & 3 & Wiederbelebt\\
+\hline
+010395 & 2 & Nachricht erhalten; ID: 286; Protokoll: Reliable Multicast\\
+\hline
+010995 & 3 & Nachricht erhalten; ID: 287; Protokoll: Reliable Multicast\\
+\hline
+010995 & 3 & Nachricht versendet; ID: 288; Protokoll: Reliable Multicast\\
+ & & Integer: pid=3; Boolean: isAck=true\\
+\hline
+010995 & 3 & ACK erneut versendet\\
+\hline
+011213 & 1 & Nachricht erhalten; ID: 287; Protokoll: Reliable Multicast\\
+\hline
+011213 & 1 & Nachricht versendet; ID: 289; Protokoll: Reliable Multicast\\
+ & & Integer: pid=1; Boolean: isAck=true\\
+ \end{tabular}
+ }
+ \caption{Auszug aus der Logausgabe des Reliable-Multicast Beispiels}
+ \label{tb:ReliableMulticastLogs}
+\end{table}
+
+\begin{table}
+ \centering
+ \fbox{
+ \begin{tabular}{c|c|l}
+ \textbf{Zeit (ms)} & \textbf{PID} & \textbf{Lognachricht} \\
+ \hline
+011213 & 1 & ACK erneut versendet\\
+\hline
+011813 & 2 & Nachricht erhalten; ID: 288; Protokoll: Reliable Multicast\\
+\hline
+011813 & 2 & ACK von Prozess 3 erhalten!\\
+\hline
+011813 & 2 & ACKs von allen beteiligten Prozessen erhalten!\\
+\hline
+012047 & 2 & Nachricht erhalten; ID: 289; Protokoll: Reliable Multicast\\
+\hline
+015000 & & Simulation beendet\\
+ \end{tabular}
+ }
+ \caption{Auszug aus der Logausgabe des Reliable-Multicast Beispiels (2)}
+ \label{tb:ReliableMulticastLogs2}
+\end{table}
+
+\subsubsection{Protokollvariablen}
+
+Dieses Protokoll verwendet folgende serverseitige Variablen, die in den Prozesseinstellungen unter dem Punkt ``Reliable Multicast Server'' konfiguriert werden können:
+
+\begin{itemize}
+ \item \textbf{Zeit bis erneute Anfrage} \textit{(Long: timeout = 2500)}: Gibt die Anzahl von Millisekunden an, die gewartet werden sollen, bis der Muticast erneut verschickt wird.
+ \item \textbf{PIDs beteiligter Prozesse} \textit{(Integer[]: pids = [1,3])}: Dieser Vektor aus Integerwerten beinhaltet alle PIDs der Serverprozesse, die die Multicast-Nachricht erhalten sollen.
+\end{itemize}
+
+
+\section{Weitere Beispiele}
+
+Bisher wurden alle verfügbaren Protokolle anhand von Beispielen aufgeführt. Mit dem Simulator lassen sich allerdings noch viel mehr Szenarien simulieren. Daher soll hier auf weitere Anwendungsbeispiele eingegangen werden.
+
+\subsection{Simulation von Lamport- und Vektor-Zeitstempel}
+
+\begin{figure}[h]
+ \centering
+ \fbox{\includegraphics[width=10cm]{images/ss-protokoll-berkeley-lamport}}
+ \caption{Lamport-Zeitstempel}
+ \label{fig:Lamportzeit}
+\end{figure}
+
+Die Vektor- und Lamport-Zeitstempel lassen sich sehr gut am bereits behandeltem Beispiel des Berkeley-Protokoll's demonstrieren. Nach Aktivierung des Lamportzeit-Schalters erscheint bei jedem Ereignis eines Prozesses der aktuelle Lamport-Zeitstempel (Abbildung \ref{fig:Lamportzeit}.). Jeder Prozess besitzt einen eigenen Lamport-Zeitstempel, der bei jedem Versenden oder Erhalten einer Nachricht inkrementiert wird. Jeder Nachricht wird die aktuelle Lamportzeit $t_l(i)$ des Senderprozesses $i$ beigefügt. Wenn ein weiterer Prozess $j$ diese Nachricht erhält, so wird der aktuelle Lamport-Zeitstempel $t_l(j)$ von Prozess $j$ wie folgt neu berechnet:
+
+\begin{equation*}
+ t_l(j) := 1 + max(t_l(j), t_l(i))
+\end{equation*}
+
+Es wird also stets die größere Lamportzeit vom Sender- und Empfängerprozess verwendet und anschließend wird diese um \textit{1} inkrementiert. Nach Ablauf der Berkeley-Simulation hat P1 \textit{(16)}, P2 (\textit{14}) und P3 (\textit{15}) als Lamport-Zeitstempel abgespeichert.
+
+\begin{figure}[h]
+ \centering
+ \fbox{\includegraphics[width=10cm]{images/ss-protokoll-berkeley-vektor}}
+ \caption{Vektor-Zeitstempel}
+ \label{fig:Vektorzeit}
+\end{figure}
+
+Mit aktivem Vektorzeit-Schalter werden alle Vektor-Zeitstempel angezeigt (Abbildung \ref{fig:Vektorzeit}.). Wie bei den Lamport-Zeitstempel wird auch hier jeder Nachricht der aktuelle Vektor-Zeitstempel des Senderprozesses beigefügt. Bei $n$ beteiligten Prozessen hat der Vektor-Zeitstempel $v$ die Größe $n$. Somit gibt es für jeden beteiligten Prozess $i$ einen eigenen Index $i$. über $v(i)$ kann jeder Prozess auf seinen lokalen Eintrag zugreifen. Wenn $v$ der Vektor-Zeitstempel des Empfängerprozesses $j$ ist und $w$ der Vektor-Zeitstempel des Senderprozesses ist, dann wird der neue lokale Vektor-Zeitstempel wie folgt (hier in Pseudo-Code angegeben) neu berechnet:
+
+\begin{code}
+for (i := 0; i < n; i++) {
+ if (i = j) {
+ v(i)++;
+ } else if (v(i) < w(i)) {
+ v(i) := w(i);
+ }
+}
+\end{code}
+
+Standardmäßig wird der Vektor-Zeitstempel nur inkrementiert, wenn eine Nachricht verschickt- oder erhalten wird. Bei beiden Fällen inkrementiert der Sender- und Empfängerprozess jeweils seinen eigenen Index im Vektor-Zeitstempel mit $v(i) = v(i) + 1$. Beim Empfang einer Nachricht wird anschließend der lokale Vektor-Zeitstempel mit dem des Senderprozesses verglichen und für alle Indizes stets der größere Wert in den lokalen Vektor-Zeitstempel übernommen.
+
+Im Beispiel auf Abbildung \ref{fig:Vektorzeit}. hat P1 \textit{(8,10,6)}, P2 \textit{(6,10,6)}. und P3 \textit{(6,10,8)} als Vektor-Zeitstempel abgespeichert.
+
+Wenn während einer Simulation Prozesse entfernt- oder neue Prozesse hinzugefügt werden, so passt sich die Größe der Vektor-Zeitstempel aller anderen Prozesse automatisch der totalen Anzahl der Prozesse an.
+
+Wie bereits beschrieben gibt es in den Simulationseinstellungen die boolschen Variablen ``Lamportzeiten betreffen alle Ereignisse'' und ``Vektorzeiten betreffen alle Ereignisse'', die standardmäßig auf \textit{false} gesetzt sind. Mit \textit{true} werden alle Ereignisse, und nicht nur der Empfang oder das Versenden einer Nachricht, berücksichtigt. Für eine weitere Betrachtung der Lamport- sowie Vektor-Zeitstempel siehe \cite{Vorlesung} oder \cite{Tanenbaum}.
+
+\subsection{Simulation langsamer Verbindungen \small{\textit{(slow-connection.dat)}}}
+
+Mit dem Simulator lassen sich auch langsame Verbindungen zu einem bestimmten Prozess simulieren. Für die Demonstration wird das Beispiel aus Kapitel 3.5. wieder aufgegriffen, wo das Protokoll zur internen Synchronisation (P1) mit der Christians-Methode (P3) parallel simuliert wurden. P2 stellt den Server beider Protokolle zur Verfügung. In diesem Szenario soll P3 eine schlechte Netzwerkverbindung besitzen, so dass Nachrichten von- und an P3 stets eine längere Übertragungszeit benötigen.
+
+Die Ereignisse sind so wie bereits auf Tabelle \ref{tb:InterneSync2Tasks}. dargestellt wurde programmiert. In den Simulationseinstellungen ist hier die Einstellung ``Mittelwerte der Übertragungszeiten bilden'' aktiviert. In den Prozesseinstellungen von P3 wurde ``Minimale Übertragungszeit'' auf \textit{2000ms} und ``Maximale Übertragungszeit'' auf \textit{8000ms} gestellt. P1 und P2 behalten als Standardeinstellungen für die minimale und maximale Übertragungszeiten jeweils \textit{500ms} und \textit{2000ms} konfiguriert und die Simulationsdauer betr\"{a}gt nun \textit{20000ms}.
+
+\begin{figure}[h]
+ \centering
+ \fbox{\includegraphics[width=10cm]{images/ss-protokoll-time-sync-2-long-transfer}}
+ \caption{Simulation einer langsamen Verbindung}
+ \label{fig:TimeSync2LongTransferProto}
+\end{figure}
+
+Als Folge (Abbildung \ref{fig:TimeSync2LongTransferProto}.) benötigen Nachrichten, die von- und an P3 verschickt werden, für eine Übertragung immer mehr Zeit. Bevor P3 eine Antwort auf seine vorherige Anfrage bekommt, verschickt er eine erneute Anfrage. Da P3 die Serverantworten immer stets seiner letzten verschickten Anfrage zuordnet, berechnet er die RTTs allesamt falsch und seine lokale Zeit wird bei jedem Durchgang zusätzlich verfälscht. Die Berechnungsformeln der Übertragungszeiten wurde bereits in Kapitel 2.4.3. bei den Prozesseinstellungen behandelt. Konkret bedeutet dies hier für die Übertragungszeiten alle Nachrichten von- und an P3 jeweils:
+
+\begin{equation*}
+ \frac{1}{2} (rand(500, 2000) + rand(2000, 8000)) = \frac{1}{2} rand(2500, 10000) = rand(1250, 5000) ms
+\end{equation*}
+
+In dem Beispiel auf Abbildung \ref{fig:TimeSync2LongTransferProto}. ist die lokale Prozesszeit von P1 bis auf \textit{20000 - 21446 = - 1446ms} synchronisiert, w\"{a}hrend die Prozesszeit von P3 ganze \textit{20000 - 16557 = 3443ms} falsch geht.
diff --git a/LaTeX/chapters/simulator.tex b/LaTeX/chapters/simulator.tex index 3c854b3..5a9fc22 100644 --- a/LaTeX/chapters/simulator.tex +++ b/LaTeX/chapters/simulator.tex @@ -1,6 +1,6 @@ -\chapter{Der Simulator}
+\chapter{Grafische Benutzeroberfläche (GUI)}
-\section{Grafische Benutzeroberfläche (GUI)}
+\section{Einfacher Modus}
\begin{figure}[h]
\centering
@@ -9,11 +9,13 @@ \label{fig:NeuesFenster}
\end{figure}
-Der Simulator lässt sich mit dem Befehl \textit{java -jar VS-Sim.jar} starten und präsentiert sich danach wie auf Abbildung \ref{fig:NeuesFenster}. Für die Erstellung einer neuen Simulation wird im Menü ``Datei'' (Abbildung \ref{fig:DateiMenue}) der Punkt ``Neue Simulation'' ausgewählt, wo anschließend das Einstellungsfenster für die neue Simulation erscheint. Auf die einzelnen Optionen wird später genauer eingegangen und es werden nun nur die Standardeinstellungen übernommen. Die GUI mit einer frischen Simulation sieht aus wie auf Abbildung \ref{fig:NeuErstellteSimulation}.
+Der Simulator ben\"{o}tigt die JRE 6.0 (1.6) und lässt sich mit dem Befehl \textit{java -jar VS-Sim.jar} starten. Der Simulator präsentiert sich danach so wie auf Abbildung \ref{fig:NeuesFenster}. zu sehen ist. Für die Erstellung einer neuen Simulation wird im Menü ``Datei'' (Abbildung \ref{fig:DateiMenue}.) der Punkt ``Neue Simulation'' ausgewählt, wo anschließend das Einstellungsfenster für die neue Simulation erscheint. Auf die einzelnen Optionen wird später genauer eingegangen und es werden nun nur die Standardeinstellungen übernommen. Die GUI mit einer frischen Simulation sieht aus wie auf Abbildung \ref{fig:NeuErstellteSimulation}.
+
+Standardm\"{a}ßig wird der Simulator im ``einfachen Modus'' gestartet. Daneben gibt es noch einen ``Expertenmodus'', auf welchen sp\"{a}ter eingegangen wird.
\subsubsection{Die Menüzeile}
-Im Datei-Menü (Abbildung \ref{fig:DateiMenue}) lassen sich neue Simulationen erstellen oder die aktuell geöffnete Simulation schließen. Neue Simulationen öffnen sich standardmäßig in einem neuen Tab. Es können allerdings auch neue Simulationsfenster, die wiederum eigene Tabs besitzen, geöffnet oder geschlossen werden. In jedem Tab befindet sich eine von den Anderen vollständig unabhängige Simulation. Es können somit beliebig viele Simulationen parallel ausgeführt werden. Die Menüeinträge ``öffnen'', ``Speichern'' und ``Speichern unter'' dienen für das Laden und Speichern von Simulationen.
+Im Datei-Menü (Abbildung \ref{fig:DateiMenue}.) lassen sich neue Simulationen erstellen oder die aktuell geöffnete Simulation schließen. Neue Simulationen öffnen sich standardmäßig in einem neuen Tab. Es können allerdings auch neue Simulationsfenster, die wiederum eigene Tabs besitzen, geöffnet oder geschlossen werden. In jedem Tab befindet sich eine, von den anderen vollständig unabhängige Simulation. Es können somit beliebig viele Simulationen parallel ausgeführt werden. Die Menüeinträge ``Öffnen'', ``Speichern'' und ``Speichern unter'' dienen für das Laden und Speichern von Simulationen.
\begin{figure}[h]
\centering
@@ -29,13 +31,13 @@ Im Datei-Menü (Abbildung \ref{fig:DateiMenue}) lassen sich neue Simulationen ers \label{fig:NeuErstellteSimulation}
\end{figure}
-über das Editieren-Menü gelangt der Anwender zu den Simulationseinstellungen, worauf später genauer eingegangen wird. In diesem Menü werden auch alle beteiligten Prozesse zum Editieren aufgelistet. Wählt der Anwender dort einen Prozess aus, dann öffnet sich der dazugehörige Prozesseditor. Auf diesen wird ebenso später genauer eingegangen. Das Simulator-Menü bietet die selben Optionen wie die Toolbar, welche im nächsten Teilkapitel beschrieben wird, an.
+Über das Editieren-Menü gelangt der Anwender zu den Simulationseinstellungen, worauf später genauer eingegangen wird. In diesem Menü werden auch alle beteiligten Prozesse zum Editieren aufgelistet. Wählt der Anwender dort einen Prozess aus, dann öffnet sich der dazugehörige Prozesseditor. Auf diesen wird ebenso später genauer eingegangen. Das Simulator-Menü bietet die selben Optionen wie die Toolbar, welche im nächsten Teilkapitel beschrieben wird, an.
Einige Menüunterpunkte sind erst erreichbar, wenn im aktuellen Fenster bereits eine Simulation erstellt oder geladen wurde.
\subsubsection{Die Toolbar}
-Oben links im Simulator befindet sich die Toolbar (Abbildung \ref{fig:Toolbar}). Die Toolbar enthält die Funktionen die vom Anwender am häufigsten benötigt werden.
+Oben links im Simulator befindet sich die Toolbar (Abbildung \ref{fig:Toolbar}.). Die Toolbar enthält die Funktionen die vom Anwender am häufigsten benötigt werden.
Die Toolbar bietet vier verschiedene Funktionen an:
@@ -64,7 +66,7 @@ Die Toolbar bietet vier verschiedene Funktionen an: \label{fig:Visualisierung}
\end{figure}
-Mittig rechts befindet sich die grafische Simulationsvisualisierung. Die X-Achse gibt die Zeit in Millisekunden an und auf der Y-Achse sind alle beteiligten Prozesse aufgeführt. Die Demo-Simulation endet nach genau 15 Sekunden. Auf Abbildung \ref{fig:Visualisierung} sind 3 Prozesse (mit den PIDs 1, 2 und 3) dargestellt, die jeweils einen eigenen horizontalen schwarzen Balken besitzen. Auf diesen Prozessbalken kann der Anwender die jeweilige lokale Prozesszeit ablesen. Die vertikale rote Linie stellt die globale Simulationszeit dar.
+Mittig rechts befindet sich die grafische Simulationsvisualisierung. Die X-Achse gibt die Zeit in Millisekunden an und auf der Y-Achse sind alle beteiligten Prozesse aufgeführt. Die Demo-Simulation endet nach genau 15 Sekunden. Auf Abbildung \ref{fig:Visualisierung}. sind 3 Prozesse (mit den PIDs 1, 2 und 3) dargestellt, die jeweils einen eigenen horizontalen schwarzen Balken besitzen. Auf diesen Prozessbalken kann der Anwender die jeweilige lokale Prozesszeit ablesen. Die vertikale rote Linie stellt die globale Simulationszeit dar.
\begin{figure}[h]
\centering
@@ -73,16 +75,16 @@ Mittig rechts befindet sich die grafische Simulationsvisualisierung. Die X-Achse \label{fig:RechtsklickProzessbalken}
\end{figure}
-Die Prozessbalken dienen auch für Start- und Zielpunkte von Nachrichten. Wenn beispielsweise Prozess 1 eine Nachricht an Prozess 2 verschickt, so wird eine Linie vom einen Prozessbalken zum Anderen gezeichnet. Nachrichten, die ein Prozess an sich selbst verschickt, werden nicht visualisiert. Sie werden aber im Loggfenster (mehr dazu später) protokolliert.
+Die Prozessbalken dienen auch für Start- und Zielpunkte von Nachrichten. Wenn beispielsweise Prozess 1 eine Nachricht an Prozess 2 verschickt, so wird eine Linie vom einen Prozessbalken zum anderen gezeichnet. Nachrichten, die ein Prozess an sich selbst verschicken, werden nicht visualisiert. Sie werden aber im Logfenster (mehr dazu später) protokolliert.
-Eine andere Möglichkeit einen Prozesseditor aufzurufen ist ein Linksklick auf den zum Prozess gehörigen Prozessbalken. Dies muss also nicht immer über das Simulator-Menü geschehen. Ein Rechtsklick hingegen öffnet ein Popup-Fenster mit weiteren Auswahlmöglichkeiten (Abbildung \ref{fig:RechtsklickProzessbalken}). Ein Prozess kann über das Popup-Menü nur während einer laufenden Simulation zu einem Absturz oder einer Wiederbelebung bewegt werden.
+Eine andere Möglichkeit einen Prozesseditor aufzurufen ist ein Linksklick auf den zum Prozess gehörigen Prozessbalken. Dies muss also nicht immer über das Simulator-Menü geschehen. Ein Rechtsklick hingegen öffnet ein Popup-Fenster mit weiteren Auswahlmöglichkeiten (Abbildung \ref{fig:RechtsklickProzessbalken}.). Ein Prozess kann über das Popup-Menü nur während einer laufenden Simulation zu einem Absturz oder einer Wiederbelebung bewegt werden.
-Generell kann die Anzahl der Prozesse nach belieben variieren. Die Dauer der Simulation beträgt mindestens \textit{5} und höchstens \textit{120} Sekunden. Die Simulation endet erst, wenn sie die globale Zeit die angegebene Simulationsendzeit (hier \textit{15} Sekunden) erreicht hat, und nicht, wenn eine lokale Prozesszeit diese Endzeit erreicht.
+Generell kann die Anzahl der Prozesse nach Belieben variieren. Die Dauer der Simulation beträgt mindestens \textit{5} und höchstens \textit{120} Sekunden. Die Simulation endet erst, wenn sie die globale Zeit, die angegebene Simulationsendzeit (hier \textit{15} Sekunden) erreicht hat, und nicht, wenn eine lokale Prozesszeit diese Endzeit erreicht.
\subsubsection{Farbliche Differenzierung}
-Farben helfen dabei die Vorgänge einer Simulation besser zu deuten. Standardmäßig werden die Prozesse (Prozessbalken) und Nachrichten mit den Farben wie in Tabelle \ref{tb:Farben} aufgelistet dargestellt. Dies sind lediglich die Standardfarben, welche über die Einstellungen geändert werden können.
+Farben helfen dabei die Vorgänge einer Simulation besser zu deuten. Standardmäßig werden die Prozesse (Prozessbalken) und Nachrichten mit den Farben, wie in Tabelle \ref{tb:Farben}. aufgelistet, dargestellt. Dies sind lediglich die Standardfarben, welche über die Einstellungen geändert werden können.
\begin{table}
\fbox{
@@ -118,7 +120,7 @@ Farben helfen dabei die Vorgänge einer Simulation besser zu deuten. Standardmäßi \label{fig:Sidebar}
\end{figure}
-Mithilfe der Sidebar lassen sich Prozessereignisse programmieren. Oben auf Abbildung \ref{fig:Sidebar} ist der zu verwaltende Prozess selektiert (hier mit der PID 1). In dieser Prozessauswahl gibt es auch die Möglichkeit ``Alle Prozesse'' auszuwählen, womit die Ereignisse aller Prozesse gleichzeitig verwaltet werden können. Unter ``Lokale Ereignisse'' versteht man diejenigen Ereignisse, die auftreten, wenn eine bestimmte lokale Zeit des dazugehörigen Prozesses eingetreten ist. Die darunter liegende Ereignistabelle listet alle programmierten Ereignisse (hier noch keine vorhanden) mitsamt Eintrittszeiten sowie den PIDs auf.
+Mit Hilfe der Sidebar lassen sich Prozessereignisse programmieren. Oben auf Abbildung \ref{fig:Sidebar}. ist der zu verwaltende Prozess selektiert (hier mit der PID 1). In dieser Prozessauswahl gibt es auch die Möglichkeit ``Alle Prozesse'' auszuwählen, womit alle programmierten Ereignisse aller Prozesse gleichzeitig dargestellt werden. Unter ``Lokale Ereignisse'' versteht man diejenigen Ereignisse, die auftreten, wenn eine bestimmte lokale Zeit des dazugehörigen Prozesses eingetreten ist. Die darunter liegende Ereignistabelle listet alle programmierten Ereignisse (hier noch keine vorhanden) mitsamt Eintrittszeiten sowie den PIDs auf.
\begin{figure}[h]
\centering
@@ -127,7 +129,7 @@ Mithilfe der Sidebar lassen sich Prozessereignisse programmieren. Oben auf Abbil \label{fig:SidebarMitEreignissen}
\end{figure}
-Für die Erstellung eines neuen Ereignisses kann der Anwender entweder mit einem Rechtsklick auf einen Prozessbalken (Abbildung \ref{fig:RechtsklickProzessbalken}) klicken und dort ``Lokales Ereignis einfügen'' wählen, oder unterhalb der Ereignistabelle ein Ereignis auswählen (Abbildung \ref{fig:Ereignisauswahl}), im darunter liegenden Textfeld die Ereigniseintrittszeit eintragen und auf ``übernehmen'' gehen. Beispielsweise wurden auf Abbildung \ref{fig:SidebarMitEreignissen} drei Ereignisse hinzugefügt: Absturz nach \textit{123ms}, Wiederbelebung nach \textit{321ms} und erneuter Absturz nach \textit{3000ms} des Prozesses mit der ID 1.
+Für die Erstellung eines neuen Ereignisses kann der Anwender entweder mit einem Rechtsklick auf einen Prozessbalken (Abbildung \ref{fig:RechtsklickProzessbalken}.) klicken und dort ``Lokales Ereignis einfügen'' wählen, oder unterhalb der Ereignistabelle ein Ereignis auswählen (Abbildung \ref{fig:Ereignisauswahl}.), im darunter liegenden Textfeld die Ereigniseintrittszeit eintragen und auf ``Übernehmen'' gehen. Beispielsweise wurden auf Abbildung \ref{fig:SidebarMitEreignissen}. drei Ereignisse hinzugefügt: Absturz nach \textit{123ms}, Wiederbelebung nach \textit{321ms} und erneuter Absturz nach \textit{3000ms} des Prozesses mit der ID 1.
\begin{figure}[h]
\centering
@@ -136,24 +138,24 @@ Für die Erstellung eines neuen Ereignisses kann der Anwender entweder mit einem \label{fig:Ereignisauswahl}
\end{figure}
-Mit einem Rechtsklick auf den Ereigniseditor lassen sich alle selektierten Ereignisse entweder kopieren oder löschen. Mithilfe der Strg-Taste können auch mehrere Ereignisse gleichzeitig markiert werden. Die Einträge der Spalten für die Zeit und der PID lassen sich nachträglich editieren. Somit besteht eine komfortable Möglichkeit bereits programmierte Ereignisse auf eine andere Zeit zu verschieben oder einen anderen Prozess zuzuweisen. Allerdings sollte der Anwender darauf achten, dass er nach dem ändern der Ereigniseintrittszeit die Enter-Taste betätigt, da sonst die Änderung unwirksam ist.
+Mit einem Rechtsklick auf den Ereigniseditor lassen sich alle selektierten Ereignisse entweder kopieren oder löschen. Mit Hilfe der Strg-Taste können auch mehrere Ereignisse gleichzeitig markiert werden. Die Einträge der Spalten für die Zeit und der PID lassen sich nachträglich editieren. Somit besteht eine komfortable Möglichkeit bereits programmierte Ereignisse auf eine andere Zeit zu verschieben oder einen anderen Prozess zuzuweisen. Allerdings sollte der Anwender darauf achten, dass er nach dem ändern der Ereigniseintrittszeit die Enter-Taste betätigt, da sonst die Änderung unwirksam ist.
-In der Sidebar gibt es neben dem Ereignis-Tab einen weiteren Tab ``Variablen''. Hinter diesem Tab verbirgt sich der Prozesseditor des aktuell ausgewählten Prozesses (Abbildung \ref{fig:NeueSimulationVariablen} links). Dort können alle Variablen des Prozesses editiert werden und ist somit eine weitere Möglichkeit einen Prozesseditor aufzurufen.
+In der Sidebar gibt es neben dem Ereignis-Tab einen weiteren Tab ``Variablen''. Hinter diesem Tab verbirgt sich der Prozesseditor des aktuell ausgewählten Prozesses (Abbildung \ref{fig:NeueSimulationVariablen}. links). Dort können alle Variablen des Prozesses editiert werden und ist somit eine weitere Möglichkeit einen Prozesseditor aufzurufen.
-\subsubsection{Das Loggfenster}
+\subsubsection{Das Logfenster}
\begin{figure}[h]
\centering
\fbox{\includegraphics[width=16.5cm]{images/ss-loggfenster}}
- \caption{Das Loggfenster}
- \label{fig:Loggfenster}
+ \caption{Das Logfenster}
+ \label{fig:Logfenster}
\end{figure}
-Das Loggfenster (Abbildung \ref{fig:NeuErstellteSimulation}, unten) protokolliert in chronologischer Reihenfolge alle eingetroffenen Ereignisse. Auf Abbildung \ref{fig:Loggfenster} ist das Loggfenster nach Erstellung der Demo-Simulation zu sehen, an welcher 3 Prozesse beteiligt sind. Am Anfang eines Loggeintrages wird stets die globale Zeit in Millisekunden protokolliert. Bei jedem Prozess werden ebenso seine lokale Zeiten sowie die Lamport- und die Vektor-Zeitstempel aufgeführt. Hinter den Zeitangaben werden weitere Angaben, wie beispielsweise welche Nachricht mit welchem Inhalt verschickt wurde und welchem Protokoll sie angehört, gemacht. Dies wird später noch anhand von Beispielen demonstriert.
+Das Logfenster (Abbildung \ref{fig:NeuErstellteSimulation}., unten) protokolliert in chronologischer Reihenfolge alle eingetroffenen Ereignisse. Auf Abbildung \ref{fig:Logfenster}. ist das Logfenster nach Erstellung der Demo-Simulation zu sehen, an welcher 3 Prozesse beteiligt sind. Am Anfang eines Logeintrages wird stets die globale Zeit in Millisekunden protokolliert. Bei jedem Prozess werden ebenso seine lokalen Zeiten sowie die Lamport- und die Vektor-Zeitstempel aufgeführt. Hinter den Zeitangaben werden weitere Angaben, wie beispielsweise welche Nachricht mit welchem Inhalt verschickt wurde und welchem Protokoll sie angehört, gemacht. Dies wird später noch anhand von Beispielen demonstriert.
-Mit dem Deaktivieren des Logging-Schalters lässt sich das Loggen von Nachrichten temporär ausstellen. Mit deaktiviertem Loggen werden keine neuen Nachrichten mehr ins Loggfenster geschrieben. Nach Reaktivieren des Schalters werden alle ausgelassenen Nachrichten nachträglich in das Fenster geschrieben. Ein deaktiviertes Loggen kann zu verbessertem Leistungsverhalten des Simulators führen (z.B. kein Rucklen; ist vom verwendeten Computer, auf dem der Simulator läuft, abhängig). Dieser Umstand ist der sehr langsamen Java-Implementierung der JTextArea-Klasse zu verdanken, die schnelle Updates nur sehr träge durchführt.
+Mit dem Deaktivieren des Logging-Schalters lässt sich das Loggen von Nachrichten temporär ausstellen. Mit deaktiviertem Loggen werden keine neuen Nachrichten mehr ins Logfenster geschrieben. Nach Reaktivieren des Schalters werden alle ausgelassenen Nachrichten nachträglich in das Fenster geschrieben. Ein deaktiviertes Loggen kann zu verbessertem Leistungsverhalten des Simulators führen. Dieser Umstand ist der sehr langsamen Java-Implementierung der JTextArea-Klasse zu verdanken, die schnelle Updates nur sehr träge durchführt.
-über den Schalter ``Expertenmodus'' wird der Expertenmodus aktiviert beziehungsweise deaktiviert.
+Über den Schalter ``Expertenmodus'' wird der Expertenmodus aktiviert, beziehungsweise deaktiviert.
\section{Expertenmodus}
@@ -164,17 +166,17 @@ Mit dem Deaktivieren des Logging-Schalters lässt sich das Loggen von Nachrichten \label{fig:SimulationExpertenmodus}
\end{figure}
-Der Simulator kann in zwei verschiedenen Modi betrieben werden. Es gibt einen einfachen- und einen Expertenmodus. Der Simulator startet standardmäßig im einfachen Modus, sodass sich der Anwender nicht mit der vollen Funktionalität des Simulators auf einmal auseinandersetzen muss. Der einfache Modus ist übersichtlicher, bietet jedoch weniger Funktionen an. Der Expertenmodus eignet sich mehr für erfahrene Anwender und bietet dementsprechend auch mehr Flexibilität. Der Expertenmodus kann über den gleichnamigen Schalter unterhalb des Loggfensters oder über die Simulationseinstellungen aktiviert oder deaktiviert werden. Auf Abbildung \ref{fig:SimulationExpertenmodus} ist der Simulator im Expertenmodus zu sehen. Wenn der Expertenmodus mit dem normalen Modus verglichen wird, dann fallen einige Unterschiede auf:
+Der Simulator kann in zwei verschiedenen Modi betrieben werden. Es gibt einen einfachen und einen Expertenmodus. Der Simulator startet standardmäßig im einfachen Modus, so dass sich der Anwender nicht mit der vollen Funktionalität des Simulators auf einmal auseinandersetzen muss. Der einfache Modus ist übersichtlicher, bietet jedoch weniger Funktionen an. Der Expertenmodus eignet sich mehr für erfahrene Anwender und bietet dementsprechend auch mehr Flexibilität. Der Expertenmodus kann über den gleichnamigen Schalter unterhalb des Logfensters oder über die Simulationseinstellungen aktiviert oder deaktiviert werden. Auf Abbildung \ref{fig:SimulationExpertenmodus}. ist der Simulator im Expertenmodus zu sehen. Wenn der Expertenmodus mit dem einfachen Modus verglichen wird, so fallen einige Unterschiede auf:
\subsubsection{Neue Funktionen in der Sidebar}
-Der erste Unterschied ist in der Sidebar erkennbar (Abbildung \ref{fig:SidebarExpertenmodus}). Dort sind nun, zusätzlich den lokalen Ereignissen, auch globale Ereignisse editierbar. Wie bereits erwähnt sind unter lokale Ereignisse diejenigen Ereignisse zu verstehen, die auftreten, wenn eine bestimmte lokale Zeit des dazugehörigen Prozesses eingetreten ist. Globale Ereignisse hingegen sind diejenigen Ereignisse, die auftreten, wenn eine bestimmte globale Zeit eingetreten ist. Ein globales Ereignis nimmt die globale Zeit- und ein lokales Ereignis die lokale Prozesszeit als Eintrittskriterium. Globale Ereignisse machen somit nur einen Unterschied, wenn sich die lokalen Prozesszeiten von der globalen Zeit unterscheiden.
+Der erste Unterschied ist in der Sidebar erkennbar (Abbildung \ref{fig:SidebarExpertenmodus}.). Dort sind nun, zusätzlich zu den lokalen Ereignissen, auch globale Ereignisse editierbar. Wie bereits erwähnt sind unter lokale Ereignisse diejenigen Ereignisse zu verstehen, die auftreten, wenn eine bestimmte lokale Zeit des dazugehörigen Prozesses eingetreten ist. Globale Ereignisse hingegen sind diejenigen Ereignisse, die auftreten, wenn eine bestimmte globale Zeit eingetreten ist. Ein globales Ereignis nimmt die globale Simulationszeit und ein lokales Ereignis die lokale Prozesszeit als Eintrittskriterium. Globale Ereignisse machen somit nur einen Unterschied, wenn sich die lokalen Prozesszeiten von der globalen Zeit unterscheiden.
Des Weiteren kann der Anwender bei der Programmierung eines neuen Ereignisses direkt die dazugehörige PID selektieren. Im einfachen Modus wurde hier immer standardmäßig die PID des aktuell (in der obersten Combo-Box) ausgewählten Prozesses verwendet (hier mit PID 1).
\subsubsection{Lamportzeit-, Vektorzeit- und Anti-Aliasing Schalter}
-Weitere Unterschiede machen sich unterhalb des Loggfensters bemerkbar. Dort gibt es unter Anderem zwei neue Schalter ``Lamportzeit'' und ``Vektorzeit''. Aktiviert der Anwender einen dieser beiden Schalter, so wird die Lamport- beziehungsweise Vektorzeit in der Visualisierung dargestellt. Damit die Übersichtlichkeit nicht leidet, kann der Anwender nur jeweils einen dieser beiden Schalter zur gleichen Zeit aktiviert haben.
+Weitere Unterschiede machen sich unterhalb des Logfensters bemerkbar. Dort gibt es unter anderem zwei neue Schalter ``Lamportzeit'' und ``Vektorzeit''. Aktiviert der Anwender einen dieser beiden Schalter, so werden die Lamport- beziehungsweise die Vektor-Zeitstempel in der Visualisierung dargestellt. Damit die Übersichtlichkeit nicht leidet, kann der Anwender nur jeweils einen dieser beiden Schalter zur gleichen Zeit aktiviert haben.
\begin{figure}[h]
\centering
@@ -183,15 +185,15 @@ Weitere Unterschiede machen sich unterhalb des Loggfensters bemerkbar. Dort gibt \label{fig:SidebarExpertenmodus}
\end{figure}
-Der Anti-Aliasing-Schalter ermöglicht dem Anwender Anti-Aliasing zu aktivieren beziehungsweise zu deaktivieren. Mit Anti-Aliasing werden alle Grafiken der Visualisierung gerundet dargestellt. Aus Performance-gründen ist Anti-Aliasing standardmäßig nicht aktiv.
+Der Anti-Aliasing-Schalter ermöglicht dem Anwender Anti-Aliasing zu aktivieren beziehungsweise zu deaktivieren. Mit Anti-Aliasing werden alle Grafiken der Visualisierung gerundet dargestellt. Aus Performance-Gründen ist Anti-Aliasing standardmäßig nicht aktiv.
-\subsubsection{Der Loggfilter}
+\subsubsection{Der Logfilter}
-Je komplexer eine Simulation wird, desto unübersichtlicher werden die Einträge im Loggfenster. Hier fällt es zunehmend schwerer die Übersicht aller Ereignisse zu behalten. Um dem entgegenzuwirken gibt es im Expertenmodus einen Loggfilter, welcher es ermöglicht nur die wesentlichen Daten aus den Loggs zu filtern.
+Je komplexer eine Simulation wird, desto unübersichtlicher werden die Einträge im Logfenster. Hier fällt es zunehmend schwerer die Übersicht aller Ereignisse zu behalten. Um dem entgegenzuwirken gibt es im Expertenmodus einen Logfilter, welcher es ermöglicht nur die wesentlichen Daten aus den Logs zu filtern.
-Der Loggfilter wird anhand dem dazugehörigen Schalter ``Filter'' aktiviert und deaktiviert. In der dahinterliegenden Eingabezeile kann ein regulärer Ausdruck in Java-Syntax angegeben werden. Beispielsweise werden mit ``\textit{PID: (1|2)}'' nur Loggzeilen angezeigt, die entweder ``\textit{PID: 1}'' oder ``\textit{PID: 2}'' beinhalten. Alle anderen Zeilen, die zum Beispiel nur ``\textit{PID: 3}'' beinhalten, werden dabei nicht angezeigt. Mit Loggfilter werden nur die Loggzeilen angezeigt, auf die der angegebene reguläre Ausdruck passt. Der Loggfilter kann auch nachträglich aktiviert werden, da bereits protokollierte Ereignisse nach jeder Filteränderung erneut gefiltert werden.
+Der Logfilter wird anhand des dazugehörigen Schalters ``Filter'' aktiviert und deaktiviert. In der dahinterliegenden Eingabezeile kann ein regulärer Ausdruck in Java-Syntax, beschrieben in \cite{Regexp}, angegeben werden. Beispielsweise werden mit ``\textit{PID: (1|2)}'' nur Logzeilen angezeigt, die entweder ``\textit{PID: 1}'' oder ``\textit{PID: 2}'' beinhalten. Alle anderen Zeilen, die zum Beispiel nur ``\textit{PID: 3}'' beinhalten, werden dabei nicht angezeigt. Mit Logfilter werden nur die Logzeilen angezeigt, auf die der angegebene reguläre Ausdruck passt. Der Logfilter kann auch nachträglich aktiviert werden, da bereits protokollierte Ereignisse nach jeder Filteränderung erneut gefiltert werden.
-Der Loggfilter kann auch während einer laufenden Simulation verwendet werden. Bei Filterdeaktivierung werden alle Nachrichten wieder dargestellt. Loggnachrichten, die aufgrund des Filters noch nie angezeigt wurden, werden dann nachträglich angezeigt.
+Der Logfilter kann auch während einer laufenden Simulation verwendet werden. Bei Filterdeaktivierung werden alle Nachrichten wieder dargestellt. Lognachrichten, die aufgrund des Filters noch nie angezeigt wurden, werden dann nachträglich angezeigt.
\begin{figure}[h]
\centering
@@ -202,11 +204,11 @@ Der Loggfilter kann auch während einer laufenden Simulation verwendet werden. Be \section{Ereignisse}
-Es wird zwischen zwei Haupttypen von Ereignissen unterschieden: Programmierbare Ereignisse und nicht programmierbare Ereignisse. Programmierbare Ereignisse lassen sich im Ereigniseditor programmieren und editieren und deren Eintrittszeiten hängen von den lokalen Prozessuhren oder der globalen Uhr ab. Nicht-programmierbare Ereignisse lassen sich hingegen nicht im Ereigniseditor programmieren und treten nicht wegen einer bestimmten Uhrzeit ein, sondern aufgrund anderer Gegebenheiten wie zum Beispiel das Eintreffen einer Nachricht oder das Ausführen einer Aktion aufgrund eines Weckers, worauf später nochmal genauer eingegangen wird.
+Es wird zwischen zwei Haupttypen von Ereignissen unterschieden: Programmierbare Ereignisse und nicht programmierbare Ereignisse. Programmierbare Ereignisse lassen sich im Ereigniseditor programmieren und editieren und deren Eintrittszeiten hängen von den lokalen Prozessuhren oder der globalen Uhr ab. Nicht programmierbare Ereignisse lassen sich hingegen nicht im Ereigniseditor programmieren und treten nicht wegen einer bestimmten Uhrzeit ein, sondern aufgrund anderer Gegebenheiten wie zum Beispiel das Eintreffen einer Nachricht oder das Ausführen einer Aktion aufgrund eines Weckers, worauf später nochmal genauer eingegangen wird.
\subsubsection{Prozessabsturz- und Wiederbelebung (programmierbar)}
-Die beiden einfachsten Ereignisse sind ``Prozessabsturz'' sowie ``Prozesswiederbelebung''. Wenn ein Prozess abgestürzt ist, so wird sein Prozessbalken in rot dargestellt. Ein abgestürzter Prozess kann keine weiteren Ereignisse mehr verarbeiten und wenn bei ihm eine Nachricht eintrifft, dann kann sie nicht verarbeitet werden und geht deshalb verloren. Die einzige Ausnahme bildet ein Wiederbelebungsereignis. Ein abgestürzter Prozess kann nichts, außer wiederbelebt werden. Während eines Prozessabsturzes läuft die lokale Prozessuhr, abgesehen der Lamport- und Vektor-Uhren, normal weiter. Das heißt es besteht die Möglichkeit, dass ein Prozess einige seiner Ereignisse gar nicht ausführt, da er zu den Ereigniseintrittszeiten abgestürzt ist. Wenn im echten Leben ein Computer abstürzt oder abgeschaltet wird, dann läuft seine Hardware-Uhr unabhängig vom Betriebssystem auch weiter.
+Die beiden einfachsten Ereignisse sind ``Prozessabsturz'' sowie ``Prozesswiederbelebung''. Wenn ein Prozess abgestürzt ist, so wird sein Prozessbalken in rot dargestellt. Ein abgestürzter Prozess kann keine weiteren Ereignisse mehr verarbeiten und wenn bei ihm eine Nachricht eintrifft, dann kann sie nicht verarbeitet werden und geht deshalb verloren. Die einzige Ausnahme bietet ein Wiederbelebungsereignis. Ein abgestürzter Prozess kann nichts, außer wiederbelebt werden. Während eines Prozessabsturzes läuft die lokale Prozessuhr, abgesehen von den Lamport- und Vektor-Zeitstempel, normal weiter. Das heißt, es besteht die Möglichkeit, dass ein Prozess einige seiner Ereignisse gar nicht ausführt, da er zu den Ereigniseintrittszeiten abgestürzt ist. Wenn im echten Leben ein Computer abstürzt oder abgeschaltet wird, dann läuft seine Hardware-Uhr unabhängig vom Betriebssystem auch weiter.
\subsubsection{Aktivierung und Deaktivierung von Protokollen sowie Starten von Anfragen (programmierbar)}
Es ist bereits bekannt, dass ein Prozess mehrere Protokolle client- und auch serverseitig unterstützen kann. Welches Protokoll von einem Prozess unterstützt wird, kann der Anwender anhand von Protokollaktivierungs- und Protokolldeaktivierungsereignissen konfigurieren. Somit besteht die Möglichkeit, dass ein gegebener Prozess ein bestimmtes Protokoll erst zu einem bestimmten Zeitpunkt unterstützt und gegebenenfalls ein anderes Protokoll ablöst. Jedes Protokoll kann entweder server- oder clientseitig aktiviert beziehungsweise deaktiviert werden. Welche Protokolle es gibt wird später behandelt. Der Anwender hat somit die Auswahl zwischen fünf verschiedenen Protokollereignistypen:
@@ -219,11 +221,11 @@ Es ist bereits bekannt, dass ein Prozess mehrere Protokolle client- und auch ser \item Starten einer Client/Server-Anfrage eines gegebenen Protokolls
\end{itemize}
-Ob sich das Ereignis für das Starten einer Anfrage auf einen Client oder einen Server bezieht, hängt vom verwendeten Protokoll ab. Es gibt Protokolle, wo der Client die Anfragen starten muss, und es gibt Protokolle, wo der Server diese Aufgabe übernimmt. Beispielsweise startet bei dem ``Ping-Pong Protokoll'' der Client- und bei dem ``Commit-Protokollen'' der Server immer die Anfragen. Es gibt kein Protokoll, wo der Client und der Server jeweils Anfragen starten können.
+Ob sich das Ereignis für das Starten einer Anfrage auf einen Client oder einen Server bezieht, hängt vom verwendeten Protokoll ab. Es gibt Protokolle, wo der Client die Anfragen starten muss, und es gibt Protokolle, wo der Server diese Aufgabe übernimmt. Beispielsweise startet bei dem ``Ping-Pong Protokoll'' der Client und bei dem ``Commit-Protokollen'' der Server immer die Anfragen. Es gibt kein Protokoll, wo der Client und der Server jeweils Anfragen starten können.
\subsubsection{Nachrichtenempfang sowie Antwortnachrichten (nicht-programmierbar)}
-Nachdem ein Prozess eine Nachricht empfängt wird zuerst überprüft, ob er das dazugehörige Protokoll unterstützt. Wenn der Prozess das Protokoll unterstützt wird geschaut, ob es sich um eine Client- oder eine Servernachricht handelt. Wenn es sich um eine Clientnachricht handelt, so muss der Empfängerprozess das Protokoll serverseitig unterstützen und virce versa. Wenn alles passt, dann führt der Empfängerprozess die vom Protokoll definierten Aktionen aus. In der Regel berechnet der Prozess einen bestimmten Wert und schickt ihn über eine Antwortnachricht zurück. Es können aber auch beliebig andere Aktionen ausgeführt werden. Welche dies sind hängt vom Protokoll ab.
+Nachdem ein Prozess eine Nachricht empfängt wird zuerst überprüft, ob er das dazugehörige Protokoll unterstützt. Wenn der Prozess das Protokoll unterstützt, wird geschaut, ob es sich um eine Client- oder eine Servernachricht handelt. Wenn es sich um eine Clientnachricht handelt, so muss der Empfängerprozess das Protokoll serverseitig unterstützen und virce versa. Wenn alles passt, dann führt der Empfängerprozess die vom Protokoll definierten Aktionen aus. In der Regel berechnet der Prozess einen bestimmten Wert und schickt ihn über eine Antwortnachricht zurück. Es können aber auch beliebig andere Aktionen ausgeführt werden. Welche dies sind hängt vom Protokoll ab.
\subsubsection{Callback-Ereignisse (nicht-programmierbar)}
@@ -268,12 +270,12 @@ In diesem Abschnitt wird genauer auf die möglichen Konfigurationsmöglichkeiten e \end{figure}
-Der Simulator unterscheidet zwischen mehreren Datentypen, in denen die einstellbaren Variablen vorliegen können (Tabelle \ref{tb:VariablenDatentypen}). Jede Variable besitzt einen Namen, einen Wert und eine optionale Beschreibung. Wenn eine Variablenbeschreibung vorhanden ist, so wird sie anstelle des Variablennamen in einem Editor (mehr zu Editoren später) angezeigt. Der Variablenname wird vom Simulator lediglich für die interne Verwendung benötigt. Im folgenden bedeutet \textit{Typ: varname = wert}, dass die Variable vom Typ \textit{Typ} ist, der interne Variablenname \textit{varname} lautet, und standardmäßig den Wert \textit{wert} zugewiesen hat. Vom Anwender lassen sich lediglich die Variablenwerte, jedoch nicht die Variablentypen, Variablennamen und Beschreibungen ändern.
+Der Simulator unterscheidet zwischen mehreren Datentypen, in denen die einstellbaren Variablen vorliegen können (Tabelle \ref{tb:VariablenDatentypen}.). Jede Variable besitzt einen Namen, einen Wert und eine optionale Beschreibung. Wenn eine Variablenbeschreibung vorhanden ist, so wird sie anstelle des Variablennamen in einem Editor (mehr zu Editoren später) angezeigt. Der Variablenname wird vom Simulator lediglich für die interne Verwendung benötigt. Im folgenden bedeutet \textit{Typ: varname = wert}, dass die Variable vom Typ \textit{Typ} ist, der interne Variablenname \textit{varname} lautet, und standardmäßig den Wert \textit{wert} zugewiesen hat. Vom Anwender lassen sich lediglich die Variablenwerte, jedoch nicht die Variablentypen, Variablennamen und Beschreibungen ändern.
\subsection{Simulationseinstellungen}
-Beim Erstellen einer neuen Simulation erscheint zunächst das dazugehörige Einstellungsfenster (Abbildung \ref{fig:Simulationseinstellungen}). In der Regel reicht es, wenn der Anwender hier, bis auf die Anzahl beteiligter Prozesse, die Standardwerte übernimmt. Es besteht auch die Möglichkeit die Einstellungen nachträglich zu editieren, indem das Einstellungsfenster via ``Editieren $\rightarrow$ Einstellungen'' erneut aufgerufen wird.
+Beim Erstellen einer neuen Simulation erscheint zunächst das dazugehörige Einstellungsfenster (Abbildung \ref{fig:Simulationseinstellungen}.). In der Regel reicht es, wenn der Anwender hier, bis auf die Anzahl beteiligter Prozesse, die Standardwerte übernimmt. Es besteht auch die Möglichkeit die Einstellungen nachträglich zu editieren, indem das Einstellungsfenster via ``Editieren $\rightarrow$ Einstellungen'' erneut aufgerufen wird.
Im Folgenden werden alle in den Simulationseinstellungen verfügbaren Variablen beschrieben. Die Klammern geben die Typen, Namen und die Standardwerte an, in denen die Variablen vorliegen.
@@ -287,15 +289,15 @@ Im Folgenden werden alle in den Simulationseinstellungen verfügbaren Variablen b \begin{itemize}
\item \textbf{Prozesse empfangen eigene Nachrichten} \textit{(Boolean: sim.message.own.recv = false)}: Standardmäßig können Prozesse keine Nachrichten empfangen, die sie selbst verschickt haben. Dies trägt zur Übersichtlichkeit der Simulation bei. Wenn diese Variable jedoch auf \textit{true} gesetzt wird, dann kann ein Prozess auch selbst verschickte Nachrichten empfangen und auf diese ebenso antworten. Die Zeit für das Versenden und Empfangen einer Nachricht an sich selbst beträgt jedoch stets \textit{0ms}. Diese Variable sollte mit Vorsicht verwendet werden, da bedingt durch den \textit{0ms} Endlosschleifen entstehen können.
- \item \textbf{Mittelwerte der Nachrichtenverlustwahrscheinlichkeiten bilden} \textit{(Boolean: sim.message.prob.mean = true)}: Jede Nachricht die verschickt wird hat, je nach Einstellungen, eine vom verschickenden Prozess abhängige zufällige Verlustwahrscheinlichkeit. Wenn diese Option aktiviert ist, so wird hier der Mittelwert aus den Verlustwahrscheinlichkeiten vom Sender- und Empfängerprozess gebildet. Ansonsten wird stets die Verlustwahrscheinlichkeit, die beim Senderprozesses angegeben wurde, verwendet.
- \item \textbf{Mittelwerte der Übertragungszeiten bilden} \textit{(Boolean: sim.message.sendingtime.mean = true)}: Jede Nachricht die verschickt wird hat, je nach Einstellungen, eine vom verschickenden Prozess abhängige zufällige Übertragungszeit bis sie ihr Ziel erreicht (siehe Prozesseinstellungen später). Wenn diese Option aktiviert ist, so wird der Mittelwert vom Sender- und Empfängerprozess gebildet. Ansonsten wird stets die Übertragungszeit, die beim Senderprozesses angegeben wurde, verwendet.
+ \item \textbf{Mittelwerte der Nachrichtenverlustwahrscheinlichkeiten bilden} \textit{(Boolean: sim.message.prob.mean = true)}: Jede Nachricht, die verschickt wird, hat, je nach Einstellungen, eine vom verschickenden Prozess abhängige zufällige Verlustwahrscheinlichkeit. Wenn diese Option aktiviert ist, so wird hier der Mittelwert aus den Verlustwahrscheinlichkeiten vom Sender- und Empfängerprozess gebildet. Ansonsten wird stets die Verlustwahrscheinlichkeit, die beim Senderprozesses angegeben wurde, verwendet.
+ \item \textbf{Mittelwerte der Übertragungszeiten bilden} \textit{(Boolean: sim.message.sendingtime.mean = true)}: Jede Nachricht, die verschickt wird, hat, je nach Einstellungen, eine vom verschickenden Prozess abhängige zufällige Übertragungszeit bis sie ihr Ziel erreicht (siehe Prozesseinstellungen später). Wenn diese Option aktiviert ist, so wird der Mittelwert vom Sender- und Empfängerprozess gebildet. Ansonsten wird stets die Übertragungszeit, die beim Senderprozesses angegeben wurde, verwendet.
\item \textbf{Nur relevante Nachrichten anzeigen} \textit{(Boolean: sim.messages.relevant = true)}: Wenn nur alle relevanten Nachrichten angezeigt werden, dann werden Nachrichten an einen Prozess die er selbst nicht verarbeiten kann, weil er das dazugehörige Protokoll nicht unterstützt, nicht angezeigt. Dies verbessert die Übersicht.
- \item \textbf{Expertenmodus aktivieren} \textit{(Boolean: sim.mode.expert = false)}: Hier lässt sich der Expertenmodus aktivieren beziehungsweise deaktivieren. Alternativ kann dies über den gleichnamigen Schalter unterhalb des Loggfensters geschehen.
+ \item \textbf{Expertenmodus aktivieren} \textit{(Boolean: sim.mode.expert = false)}: Hier lässt sich der Expertenmodus aktivieren beziehungsweise deaktivieren. Alternativ kann dies über den gleichnamigen Schalter unterhalb des Logfensters geschehen.
\item \textbf{Simulation periodisch wiederholen} \textit{(Boolean: sim.periodic = false)}: Wenn diese Variable auf \textit{true} gesetzt ist, dann wird die Simulation jedes Mal nach Ablauf automatisch erneut gestartet.
- \item \textbf{Lamportzeiten betreffen alle Ereignisse} \textit{(Boolean: sim.update.lamporttime.all = false)}: Wenn diese Variable auf \textit{true} gesetzt ist, dann werden bei jedem Ereignis alle Lamportzeitstempel aller Prozesse jeweils inkrementiert. Bei einem Wert \textit{false} inkrementieren sich die Lamportzeitstempel jeweils nur, wenn eine Nachricht empfangen oder verschickt wurde.
+ \item \textbf{Lamportzeiten betreffen alle Ereignisse} \textit{(Boolean: sim.update.lamporttime.all = false)}: Wenn diese Variable auf \textit{true} gesetzt ist, dann werden bei jedem Ereignis alle Lamport-Zeitstempel aller Prozesse jeweils inkrementiert. Bei einem Wert \textit{false} inkrementieren sich die Lamport-Zeitstempel jeweils nur, wenn eine Nachricht empfangen oder verschickt wurde.
\item \textbf{Vektorzeiten betreffen alle Ereignisse} \textit{(Boolean: sim.update.vectortime.all = false)}: Wenn diese Variable auf \textit{true} gesetzt ist, dann werden bei jedem Ereignis alle Vektor-Zeitstempel aller Prozesse jeweils inkrementiert. Bei einem Wert \textit{false} inkrementieren sich die Vektor-Zeitstempel jeweils nur, wenn eine Nachricht empfangen oder verschickt wurde.
- Lamport- und Vektorzeitstempel werden später anhand eines Beispiels verdeutlicht.
+ Lamport- und Vektor-Zeitstempel werden später anhand eines Beispiels verdeutlicht.
\item \textbf{Abspielgeschwindigkeit der Simulation} \textit{(Float: sim.clock.speed = 0.5)}: Gibt den Faktor der Simulationsabspielgeschindigkeit an. Wenn als Faktor \textit{1} gewählt wird, dann dauert eine simulierte Sekunde so lange wie eine echte Sekunde. Der Faktor \textit{0.5} gibt somit an, dass die Simulation mit halber Echtzeitgschwindigkeit abgespielt wird.
\item \textbf{Anzahl der Prozesse} \textit{(Integer: sim.process.num = 3)}: Gibt die Anzahl beteiligter Prozesse an. Der Anwender kann auch nachträglich via Rechtsklick auf den Prozessbalken den jeweiligen Prozess aus der Simulation entfernen oder weitere Prozesse hinzufügen.
\item \textbf{Dauer der Simulation} \textit{(Integer: sim.seconds = 15)}: Gibt die Dauer der Simulation in Sekunden an.
@@ -362,758 +364,5 @@ Im selben Fenster (im Prozesseditor) lassen sich auch die Protokollvariablen edi \label{tb:Farbeinstellungen}
\end{table}
-Im Expertenmodus lassen sich zusätzliche Variablen, wie beispielsweise diverse Farbwerte und Anzahl oder Pixel verschiedener der GUI-Elemente, editieren. Auf Abbildung \ref{fig:SimulationseinstellungenExperten} sieht der Anwender alle einstellbaren Farben. Die fett-gedruckten Schlüssel in Tabelle \ref{tb:Farbeinstellungen} dienen nur als Standardwerte für die neu zu erstellenden Prozesse und sind auch jeweils in den Prozesseinstellungen für jeden Prozess separat editierbar.
-
-\newpage
-\section{Protokolle}
-
-Im Folgenden werden alle verfügbaren Protokolle behandelt. Wie bereits beschrieben wird bei Protokollen zwischen Server- und Clientseite unterschieden. Server können auf Clientnachrichten, und Client auf Servernachrichten antworten. Jeder Prozess kann beliebig viele Protokolle sowohl clientseitig als auch serverseitig unterstützen. Theoretisch ist es auch möglich, dass ein Prozess für ein bestimmtes Protokoll gleichzeitig der Server und der Client ist. Der Anwender kann auch weitere eigene Protokolle in der Programmiersprache Java mittels einer speziellen API (Application Programming Interface) erstellen. Wie eigene Protokolle erstellt werden können wird später behandelt.
-
-Im mitgelieferten Verzeichnis \textit{saved-simulations} befinden sich alle Beispielsimulationen zum Selbst probieren als \textit{.dat} (Java-Serialisierungsobjekt) abgespeichert.
-
-\subsection{Beispiel (Dummy) Protokoll}
-
-Das Dummy-Protokoll dient lediglich als leeres Template für die Erstellung eigener Protokolle. Bei der Verwendung des Dummy-Protokolls werden bei Ereignissen lediglich Loggnachrichten ausgegeben. Es werden aber keine weiteren Aktionen ausgeführt.
-
-\newpage
-\subsection{Das Ping-Pong Protokoll \small{\textit{(ping-pong.dat, ping-pong-sturm.dat)}}}
-
-\begin{figure}[h]
- \centering
- \fbox{\includegraphics[width=10cm]{images/ss-protokoll-ping-pong}}
- \caption{Das Ping-Pong Protokoll}
- \label{fig:PingPongProto}
-\end{figure}
-
-Bei dem Ping-Pong Protokoll (Abbildung \ref{fig:PingPongProto}) werden zwischen zwei Prozessen, Client P1 und Server P2, ständig Nachrichten hin- und hergeschickt. Der Ping-Pong Client startet die erste Anfrage, worauf der Server dem Client antwortet. Auf diese Antwort wird vom Client ebenfalls geantwortet und so weiter. Jeder Nachricht wird ein Zähler mitgeschickt, der bei jeder Station um eins inkrementiert- und jeweils im Loggfenster protokolliert wird. In Tabelle \ref{tb:PingPongTasks} sind alle für dieses Beispiel programmierten Ereignisse aufgeführt.
-
-\begin{figure}[h]
- \centering
- \fbox{\includegraphics[width=10cm]{images/ss-protokoll-ping-pong-sturm}}
- \caption{Das Ping-Pong Protokoll (Sturm)}
- \label{fig:PingPongSturmProto}
-\end{figure}
-
-Wichtig ist, dass Prozess 1 seinen Ping-Pong Client aktiviert, bevor er eine Ping-Pong Clientanfrage startet! Wenn die Eintrittszeiten für die Aktivierung des Protokolls und das Starten der Anfrage identisch sind, so ordnet der Task-Manager (mehr dazu später) diese Ereignisse automatisch in der richtigen Reihenfolge an. Wenn der Ping-Pong Client nicht aktiviert werden würde, dann könnte P1 auch keine Ping-Pong Anfrage starten. Bevor ein Prozess eine Anfrage starten kann, muss er das dazugehörige Protokoll unterstützen beziehungsweise aktiviert haben. Dies gilt natürlich für alle anderen Protokolle analog. Anhand diesem Beispiel ist erkennbar, dass die noch nicht ausgelieferte Nachrichten grün eingefärbt ist. Alle ausgelieferten Nachrichten tragen bereits die Farbe Blau.
-
-Werden die Ereignisse wie in Tabelle \ref{tb:PingPongSturmTasks} abgeändert, so lässt sich ein Ping-Pong Sturm realisieren. Dort wurde ein neuer Prozess 3 eingeführt, der als zusätzlicher Ping-Pong Server agiert. Da auf jede Clientnachricht stets zwei Serverantworten folgen, verdoppelt sich bei jedem Ping-Pong Durchgang die Anzahl der kursierenden Nachrichten. Auf Abbildung \ref{fig:PingPongSturmProto} ist der dazugehörige Simulationsverlauf bis zum Zeitpunkt \textit{12676ms} dargestellt.
-
-\begin{table}
- \centering
- \fbox{
- \begin{tabular}{c|c|l}
- \textbf{Zeit (ms)} & \textbf{PID} & \textbf{Ereignis} \\
- \hline
- 0 & 1 & Ping Pong Client aktivieren\\
- 0 & 2 & Ping Pong Server aktivieren\\
- 0 & 1 & Ping Pong Clientanfrage starten
- \end{tabular}
- }
- \caption{Programmierte Ping-Pong Ereignisse}
- \label{tb:PingPongTasks}
-\end{table}
-
-\begin{table}
- \centering
- \fbox{
- \begin{tabular}{c|c|l}
- \textbf{Zeit (ms)} & \textbf{PID} & \textbf{Ereignis} \\
- \hline
- 0 & 1 & Ping Pong Client aktivieren\\
- 0 & 2 & Ping Pong Server aktivieren\\
- 0 & 3 & Ping Pong Server aktivieren\\
- 0 & 1 & Ping Pong Clientanfrage starten
- \end{tabular}
- }
- \caption{Programmierte Ping-Pong Ereignisse (Sturm)}
- \label{tb:PingPongSturmTasks}
-\end{table}
-
-\newpage
-
-\begin{table}
- \centering
- \fbox{
- \begin{tabular}{c|c|l}
- \textbf{Zeit (ms)} & \textbf{PID} & \textbf{Ereignis} \\
- \hline
- 0000 & 1 & Broadcast Client aktivieren\\
- 0000 & 2 & Broadcast Client aktivieren\\
- 0000 & 3 & Broadcast Client aktivieren\\
- 0000 & 4 & Broadcast Client aktivieren\\
- 0000 & 5 & Broadcast Client aktivieren\\
- 0000 & 6 & Broadcast Client aktivieren\\
- 0000 & 1 & Broadcast Server aktivieren\\
- 0000 & 2 & Broadcast Server aktivieren\\
- 0000 & 3 & Broadcast Server aktivieren\\
- 0000 & 4 & Broadcast Server aktivieren\\
- 0000 & 5 & Broadcast Server aktivieren\\
- 0000 & 6 & Broadcast Server aktivieren\\
- 0000 & 1 & Broadcast Clientanfrage starten\\
- 2500 & 1 & Broadcast Clientanfrage starten
- \end{tabular}
- }
- \caption{Programmierte Broadcast Ereignisse}
- \label{tb:BroadcastSturmTasks}
-\end{table}
-\subsection{Das Broadcast Protokoll \small{\textit{(broadcast.dat)}}}
-
-\begin{figure}[h]
- \centering
- \fbox{\includegraphics[width=10cm]{images/ss-protokoll-broadcast-sturm}}
- \caption{Das Broadcast Protokoll}
- \label{fig:BroadcastSturmProto}
-\end{figure}
-
-Das Broadcast Protokoll verhält sich ähnlich wie das Ping-Pong Protokoll. Der Unterschied besteht darin, dass sich das Protokoll anhand einer eindeutigen Broadcast-ID merkt, welche Nachrichten bereits verschickt wurden. Das Broadcast Protokoll (server- und clientseitig) verschickt alle erhaltenen Nachrichten, sofern sie vom jeweiligen Prozess noch nicht schon einmal verschickt wurden, erneut.
-
-Der Server und der Client unterscheiden sich in diesem Fall nicht und führen bei Ankunft einer Nachricht jeweils die selben Aktionen durch. Somit lässt sich, unter Verwendung mehrerer Prozesse (hier 6), wie auf Abbildung \ref{fig:BroadcastSturmProto}, ein Broadcast erzeugen. P1 ist der Client und startet je eine Anfrage nach \textit{0ms} und \textit{2500ms}. Die Simulationsdauer beträgt hier genau \textit{5000ms}. Da ein Client nur Servernachrichten und ein Server nur Clientnachrichten empfangen kann, ist in dieser Simulation jeder Prozess, wie in Tabelle \ref{tb:BroadcastSturmTasks} angegeben, gleichzeitig Server und Client.
-
-\newpage
-\subsection{Das Protokoll zur internen Synchronisierung in einem synchronen System \small{\textit{(int-sync.dat)}}}
-
-Bisher wurden nur Protokolle vorgeführt, in denen die beteiligten Prozesse keine Uhrabweichung eingestellt hatten. Das Protokoll zur internen Synchronisierung ist ein Protokoll zur Synchronisierung der lokalen Prozesszeit, welches beispielsweise angewendet werden kann, wenn eine Prozesszeit aufgrund einer Uhrabweichung falsch geht. Wenn der Client seine falsche lokale Zeit $t_c$ mit einem Server synchronisieren möchte, so schickt er ihm eine Clientanfrage. Der Server schickt als Antwort seine eigene lokale Prozesszeit $t_s$ zurück, womit der Client seine neue und genauere Prozesszeit berechnen kann. Wie genau die neue Prozesszeit berechnet wird, ist im Folgenden beschrieben:
-
-\begin{figure}[h]
- \centering
- \fbox{\includegraphics[width=10cm]{images/ss-protokoll-time-sync}}
- \caption{Das Protokoll zur internen Synchronisierung}
- \label{fig:TimeSyncProto}
-\end{figure}
-
-Hier (Abbildung \ref{fig:TimeSyncProto}) stellt P1 den Client und P2 den Server dar. Da die Übertragungszeit $t_u$ einer Nachricht angenommen zwischen $t'_{min}$ und $t'_{max}$ liegt, setzt der Client P1 nach Empfang der Serverantwort seine lokale Prozesszeit auf
-
-\begin{equation*}
- t_c := t_s + \frac{1}{2} (t'_{min} + t'_{max})
-\end{equation*}
-
-Somit wurde die lokale Zeit von P1, bis auf einen Fehler von $< \frac{1}{2} (t'_{max} - t'_{min})$, synchronisiert.
-
-Der Clientprozess hat in der Abbildung \ref{fig:TimeSyncProto} als Uhrabweichung den Wert \textit{0.1} und der Server hat als Uhrabweichung den Wert \textit{0.0} konfiguriert. Der Client startet, wie in Tabelle \ref{tb:InterneSyncTasks} angegeben, nach \textit{0ms}, \textit{5000ms} und \textit{10000ms} seiner lokalen Prozesszeit jeweils eine Clientanfrage. In der Abbildung lässt sich erkennen, dass die 2. und die 3. Anfrage nicht synchron zu der globalen Zeit (siehe Sekunden-Gatter) gestartet wurden, was auf die Uhrabweichung von P1 zurückzuführen ist. Nach Simulationsende ist die Zeit von P1 bis auf \textit{15000ms} - \textit{15976ms} = \textit{-976ms} synchronisiert.
-
-\begin{table}
- \centering
- \fbox{
- \begin{tabular}{c|c|l}
- \textbf{Zeit (ms)} & \textbf{PID} & \textbf{Ereignis} \\
- \hline
- 00000 & 1 & Interne Sync. Client aktivieren \\
- 00000 & 2 & Interne Sync. Server aktivieren\\
- 00000 & 1 & Interne Sync. Clientanfrage starten\\
- 05000 & 1 & Interne Sync. Clientanfrage starten\\
- 10000 & 1 & Interne Sync. Clientanfrage starten\\
- \end{tabular}
- }
- \caption{Programmierte Ereignisse zur internen Synchronisierung}
- \label{tb:InterneSyncTasks}
-\end{table}
-
-\subsubsection{Protokollvariablen}
-
-Dieses Protokoll verwendet folgende zwei clientseitige Variablen, die in den Prozesseinstellungen unter dem Punkt ``Interne Sync. Client'' konfiguriert werden können. Serverseitig gibt es hier keine Variablen.
-
-\begin{itemize}
- \item \textbf{Min. Übertragungszeit} \textit{(Long: 500)}: Gibt den Wert $t'_{min}$ in Millisekunden an
- \item \textbf{Max. Übertragungszeit} \textit{(Long: 2000)}: Gibt den Wert $t'_{max}$ in Millisekunden an
-\end{itemize}
-
-$t'_{min}$ und $t'_{max}$ sind die bei den Protokollberechnungen verwendeten Werte. Sie können sich allerdings von den tatsächlichen Nachrichtenübertragungszeiten $t_{min}$ und $t_{max}$ (siehe Sektion über Prozesseinstellungen) unterscheiden. Somit lassen sich auch Szenarien simulieren, in denen das Protokoll falsch eingestellt wurde und wo in der Zeitsynchronisierung große Fehler auftreten können.
-
-\newpage
-\subsection{Christians Methode zur externen Synchronisierung \small{\textit{(ext-vs-int-sync.dat)}}}
-
-\begin{figure}[h]
- \centering
- \fbox{\includegraphics[width=10cm]{images/ss-protokoll-time-sync-2}}
- \caption{Interne Synchronisierung und Christians Methode im Vergleich}
- \label{fig:TimeSync2Proto}
-\end{figure}
-
-Ein weiteres Protokoll für die Synchronisierung von Uhrzeiten funktioniert nach der Christians Methode zur externen Synchronisierung. Die Christians Methode benutzt die RTT (Round Trip Time) $t_{rtt}$, um die Übertragungszeit von einzelnen Nachrichten zu approximieren.
-
-Wenn der Client seine lokale Zeit $t_c$ bei einem Server synchronisieren möchte, so verschickt er eine Anfrage, und misst dabei bis zur Ankunft der Serverantwort die dazugehörige RTT $t_{rtt}$. Die Serverantwort beinhaltet die lokale Prozesszeit $t_s$ vom Server von dem Zeitpunkt, als der Server die Antwort verschickte. Der Client setzt dann seine lokale Zeit neu auf:
-
-\begin{equation*}
- t_c := t_s + \frac{1}{2} t_{rtt}
-\end{equation*}
-
-und zwar mit einer Genauigkeit von $\pm(\frac{1}{2} t_{rtt} - u_{min}$) wenn $u_{min}$ eine Schranke für eine Nachrichtenübertragung mit $t_{rtt} < u_{min}$ ist (siehe \cite{Vorlesung}).
-
-Im Prinzip sieht ein Verlauf einer Christians-Simulation so aus wie auf Abbildung \ref{fig:TimeSyncProto}, daher wird hier auf eine einfache Abbildung vom Christians-Protokoll verzichtet. Viel Interessanter ist der direkte Vergleich zwischen dem Protokoll zur internen Synchronisierung und der Christians Methode der externen Synchronisierung (Abbildung \ref{fig:TimeSync2Proto}). Hier stellt P1 den Client zur internen Synchronisierung und P3 den Client zur externen Synchronisierung dar. P2 fungiert für beide Protokolle gleichzeitig als Server. P1 und P3 starten jeweils zu den lokalen Prozesszeiten \textit{0ms}, \textit{5000ms} und \textit{10000ms} eine Clientanfrage (Tabelle \ref{tb:InterneSync2Tasks}). P1 und P3 haben als Uhrabweichung \textit{0.1} eingestellt und die Simulationsdauer beträgt insgesamt \textit{15000ms}.
-
-Auf der Abbildung \ref{fig:TimeSync2Proto} ist ablesbar, dass nach Ablauf der Simulation P1 seine Zeit bis auf \textit{15000ms} - \textit{14567ms} = \textit{433ms} und P3 seine Zeit bis auf \textit{15000ms} - \textit{15539ms} = \textit{-539ms} synchronisiert hat. In diesem Beispiel hat also das Protokoll zur internen Synchronisierung ein besseres Ergebnis geliefert. Dies ist allerdings nicht zwingend immer der Fall, da nach einer erneuten Simulationsausführung alle Nachrichten jeweils eine neue zufällige Übertragungszeit zwischen $t_{min}$ und $t_{max}$ haben werden, die auf das eine oder andere Protokoll wieder andere Auswirkungen haben können.
-
-\begin{table}
- \centering
- \fbox{
- \begin{tabular}{c|c|l}
- \textbf{Zeit (ms)} & \textbf{PID} & \textbf{Ereignis} \\
- \hline
- 00000 & 1 & Interne Sync. Client aktivieren \\
- 00000 & 1 & Interne Sync. Clientanfrage starten\\
- 00000 & 2 & Christians Server aktivieren\\
- 00000 & 2 & Interne Sync. Server aktivieren\\
- 00000 & 3 & Christians Client aktivieren \\
- 00000 & 3 & Christians Clientanfrage starten\\
- 05000 & 1 & Interne Sync. Clientanfrage starten\\
- 05000 & 3 & Christians Clientanfrage starten\\
- 10000 & 1 & Interne Sync. Clientanfrage starten\\
- 10000 & 3 & Christians Clientanfrage starten\\
- \end{tabular}
- }
- \caption{Programmierte Ereignisse, Vergleich interne und externe Synchronisierung}
- \label{tb:InterneSync2Tasks}
-\end{table}
-
-\newpage
-\subsection{Der Berkeley Algorithmus zur internen Synchronisierung \small{\textit{(berkeley.dat)}}}
-
-\begin{figure}[h]
- \centering
- \fbox{\includegraphics[width=10cm]{images/ss-protokoll-berkeley}}
- \caption{Der Berkeley Algorithmus zur internen Synchronisierung}
- \label{fig:BerkeleyProto}
-\end{figure}
-
-Der Berkeley Algorithmus zur internen Synchronisierung ist eine weitere Möglichkeit lokale Uhrzeiten abzugleichen. Dies ist das erste Protokoll, wo der Server die Anfragen startet. Der Server stellt den Koordinator des Protokolls dar. Die Clients sind somit passiv und müssen warten, bis eine Serveranfrage eintrifft. Hierbei muss der Server wissen, welche Clientprozesse an dem Protokoll teilnehmen, was sich in den Protokolleinstellungen des Servers einstellen lässt.
-
-Wenn der Server seine eigene lokale Zeit $t_s$ und auch die lokalen Prozesszeiten $t_i$ der Clients ($i = 1, ..., n$) synchronisieren möchte, so verschickt er eine Serveranfrage. $n$ sei hierbei die Anzahl beteiligter Clients. Die Clients senden dann ihre lokalen Prozesszeiten in einer Nachricht zurück zum Server. Der Server hat dabei die RTTs $r_i$ bis zur Ankunft aller Clientantworten gemessen.
-
-Nachdem alle Antworten vorliegen, setzt er zunächst seine eigene Zeit $t_s$ auf den Mittelwert $t_{avg}$ aller bekannten Prozesszeiten (seiner eigenen Prozesszeit eingeschlossen). Die Übertragungszeit einer Clientantwort wird auf die Hälfte der RTT geschätzt und wird in der Berechnung berücksichtigt:
-
-\begin{equation*}
- t_{avg} :=
- \frac{1}{n+1} ( t_s +
- \sum_{\substack{
- i=1\\
- }}^n
- \frac{r_i}{2} + t_i
- )
-\end{equation*}
-\begin{equation*}
- t_s := t_{avg}
-\end{equation*}
-
-Anschließend berechnet der Server für jeden Client einen Korrekturwert $k_i := t_{avg} - t_i$, den er jeweils in einer separaten Nachricht zurückschickt. Die Clients setzten dann jeweils die lokale Prozesszeit auf $t'_i := t'_i + k_i$. Hierbei stellt $t'_i$ die derzeit aktuelle Prozesszeit des jeweiligen Clients dar. Denn bis zum Eintreffen des Korrekturwertes ist inzwischen wieder neue Zeit verstrichen.
-
-Im Beispiel auf Abbildung \ref{fig:BerkeleyProto} gibt es die 2 Clientprozesse P1 und P3 sowie den Serverprozess P2. Der Server startet nach jeweils \textit{0ms} und \textit{7500ms} eine Synchronisierungsanfrage (Tabelle \ref{tb:BerkeleyTasks}). Hier fällt auf, dass der Server stets 2 Korrekturwerte verschickt, die jeweils P1 und P3 erreichen. Es werden hier also pro Synchronisierungsvorgang insgesamt 4 Korrekturwerte ausgeliefert. Eine Korrekturnachricht enthält neben dem Korrekturwert $k_i$ auch die PID des Prozesses, für den die Nachricht bestimmt ist. Indem das Protokoll die PID überprüft verarbeitet ein Client so nur die für ihn bestimmten Korrekturwerte.
-
-\begin{table}
- \centering
- \fbox{
- \begin{tabular}{c|c|l}
- \textbf{Zeit (ms)} & \textbf{PID} & \textbf{Ereignis} \\
- \hline
- 0000 & 1 & Berkeley Client aktivieren \\
- 0000 & 2 & Berkeley Server aktivieren \\
- 0000 & 3 & Berkeley Client aktivieren \\
- 0000 & 2 & Berkeley Serveranfrage starten\\
- 7500 & 2 & Berkeley Serveranfrage starten\\
- \end{tabular}
- }
- \caption{Programmierte Ereignisse zum Berkeley Algorithmus}
- \label{tb:BerkeleyTasks}
-\end{table}
-\subsubsection{Protokollvariablen}
-
-Dieses Protokoll verwendet folgende serverseitige Variable, die in den Prozesseinstellungen unter dem Punkt ``Berkeley Server'' konfiguriert werden kann. Clientseitig gibt es hier keine Variablen.
-
-\begin{itemize}
- \item \textbf{PIDs beteiligter Prozesse} \textit{(Integer[]: [1,3])}: Dieser Vektor aus Integerwerten beinhaltet alle PIDs der Berkeley Clientprozesse, mit denen der Berkeley Server die Zeit synchronisieren soll. Das Protokoll funktioniert nicht, wenn hier eine PID angegeben wird die gar nicht existiert oder nicht das Berkeley Protokoll clientseitig gar nicht unterstützt. In diesem Fall würde ewig auf eine fehlende Clientantwort gewartet werden.
-\end{itemize}
-
-\newpage
-\subsection{Das Ein-Phasen Commit Protokoll \small{\textit{(one-phase-commit.dat)}}}
-
-\begin{figure}[h]
- \centering
- \fbox{\includegraphics[width=10cm]{images/ss-protokoll-one-phase-commit}}
- \caption{Das Ein-Phasen Commit Protokoll}
- \label{fig:OnePhaseCommitProto}
-\end{figure}
-
-Das Ein-Phasen Commit Protokoll ist dafür gedacht beliebig vielen Clients zu einer Festschreibung zu bewegen. Im realen Leben könnte dies beispielsweise das Erstellen oder Löschen einer Datei sein, von der auf jedem Client eine lokale Kopie existiert. Der Server ist der Koordinator und auch derjenige, der einen Festschreibewunsch initiiert. Hierbei verschickt der Server periodisch so oft den Festschreibewunsch, bis er von jedem Client eine Bestätigung erhalten hat. Der Server muss dabei die PIDs aller beteiligten Clientprozesse sowie einen Wecker für erneutes Versenden des Festschreibewunsches eingestellt bekommen.
-
-Die programmierten Ereignisse des Beispiels auf Abbildung \ref{fig:OnePhaseCommitProto} sind in Tabelle \ref{tb:OnePhaseCommitTasks} aufgelistet. P1 und P3 simulieren jeweils einen Client und P2 den Server. Damit die Simulation mehrere Festschreibewünsche verschickt, stürzt in der Simulation P1 nach \textit{1000ms} ab und nach \textit{5000ms} steht er wieder zur Verfügung. Die ersten beide Festschreibewünsche erreichen dadurch P1 nicht und erst der dritte Versuch verläuft erfolgreich. Bevor die Bestätigung von P1 bei P2 eintrifft, läuft jedoch der Wecker erneut ab, sodass ein weiterer Festschreibewunsch versendet wird. Da P1 und P3 jeweils schon eine Bestätigung verschickt haben, wird diese Festschreibewunschnachricht ignoriert. Jeder Client bestätigt auf einen Festschreibewunsch nur ein einziges Mal.
-
-\begin{table}
- \centering
- \fbox{
- \begin{tabular}{c|c|l}
- \textbf{Zeit (ms)} & \textbf{PID} & \textbf{Ereignis} \\
- \hline
- 0000 & 1 & 1-Phasen Commit Client aktivieren\\
- 0000 & 2 & 1-Phasen Commit Server aktivieren\\
- 0000 & 3 & 1-Phasen Commit Client aktivieren\\
- 0000 & 2 & 1-Phasen Commit Serveranfrage starten\\
- 1000 & 1 & Prozessabsturz\\
- 5000 & 1 & Prozesswiederbelebung
- \end{tabular}
- }
- \caption{Programmierte Ein-Phasen Commit Ereignisse}
- \label{tb:OnePhaseCommitTasks}
-\end{table}
-
-\subsubsection{Protokollvariablen}
-
-Dieses Protokoll verwendet folgende serverseitige Variablen, die in den Prozesseinstellungen unter dem Punkt ``1-Phasen Commit Server'' konfiguriert werden können. Clientseitig gibt es hier keine Variablen.
-
-\begin{itemize}
- \item \textbf{Zeit bis erneute Anfrage} \textit{(Long: timeout = 2500)}: Gibt die Anzahl von Millisekunden an, die gewartet werden sollen, bis der Festschreibewunsch erneut verschickt wird.
- \item \textbf{PIDs beteiligter Prozesse} \textit{(Integer[]: pids = [1,3])}: Dieser Vektor aus Integerwerten beinhaltet alle PIDs der Clientprozesse, die festschreiben sollen.
-\end{itemize}
-
-\newpage
-\subsection{Das Zwei-Phasen Commit Protokoll \small{\textit{(two-phase-commit.dat)}}}
-
-\begin{figure}[h]
- \centering
- \fbox{\includegraphics[width=10cm]{images/ss-protokoll-two-phase-commit}}
- \caption{Das Zwei-Phasen Commit Protokoll}
- \label{fig:TwoPhaseCommitProto}
-\end{figure}
-
-Das Zwei-Phasen Commit Protokoll ist eine Erweiterung des Ein-Phasen Commit Protokolls. Der Server startet zunächst eine Anfrage an alle beteiligten Clients, ob festgeschrieben werden soll. Jeder Client antwortet dann mit \textit{true} oder \textit{false}. Der Server fragt so oft periodisch nach, bis alle Ergebnisse aller Clients vorliegen. Nach Erhalt aller Abstimmungen überprüft der Server, ob alle mit \textit{true} abgestimmt haben. Für den Fall dass mindestens ein Client mit \textit{false} abgestimmt hat, wird der Festschreibevorgang abgebrochen und als globales Abstimmungsergebnis \textit{false} verschickt. Wenn jedoch alle mit \textit{true} abstimmten, soll festgeschrieben werden. Dabei wird das globale Abstimmungsergebnis \textit{true} verschickt. Das globale Abstimmungsergebnis wird periodisch so oft erneut verschickt, bis von jedem Client eine Bestätigung des Erhalts vorliegt.
-
-In dem Beispiel (Abbildung \ref{fig:TwoPhaseCommitProto}) sind P1 und P3 Clients und P2 der Server. Der Server verschickt nach \textit{0ms} seine erste Anfrage (Tabelle \ref{tb:TwoPhaseCommitTasks}). Da diese Simulation recht unübersichtlich ist, liegen in den Tabellen \ref{tb:TwoPhaseCommitLoggs} und \ref{tb:TwoPhaseCommitLoggs2} Auszüge aus dem Loggfenster vor. Auf die Lamport- und Vektorzeitstempel sowie die lokalen Prozesszeiten wurde hier wegen Irrelevanz verzichtet. Da keine Uhrabweichungen konfiguriert wurden, sind die lokalen Prozesszeiten stets gleich der globalen Zeit und deswegen wird in den Tabellen pro Loggeintrag jeweils nur eine Zeit angegeben. Anhand der Nachrichten IDs lassen sich dort die einzelnen Sendungen zuordnen. In den Loggs wird auch ständig der Inhalt der verschickten Nachricht sowie die dazugehörigen Datentypen aufgeführt. Hier stimmen P1 und P3 jeweils mit \textit{true}, d.h. es soll festgeschrieben werden, ab.
-
-\begin{table}
- \centering
- \fbox{
- \begin{tabular}{c|c|l}
- \textbf{Zeit (ms)} & \textbf{PID} & \textbf{Ereignis} \\
- \hline
- 0000 & 1 & 2-Phasen Commit Client aktivieren\\
- 0000 & 2 & 2-Phasen Commit Server aktivieren\\
- 0000 & 3 & 2-Phasen Commit Client aktivieren\\
- 0000 & 2 & 2-Phasen Commit Serveranfrage starten
- \end{tabular}
- }
- \caption{Programmierte Zwei-Phasen Commit Ereignisse}
- \label{tb:TwoPhaseCommitTasks}
-\end{table}
-
-\subsubsection{Protokollvariablen}
-
-Dieses Protokoll verwendet folgende serverseitige Variablen, die in den Prozesseinstellungen unter dem Punkt ``2-Phasen Commit Server'' konfiguriert werden können:
-
-\begin{itemize}
- \item \textbf{Zeit bis erneute Anfrage} \textit{(Long: timeout = 2500)}: Gibt die Anzahl von Millisekunden an, die gewartet werden sollen, bis der Festschreibewunsch erneut verschickt wird.
- \item \textbf{PIDs beteiligter Prozesse} \textit{(Integer[]: pids = [1,3])}: Dieser Vektor aus Integerwerten beinhaltet alle PIDs der Clientprozesse die über eine Festschreibung abstimmen und anschließend gegebenenfalls festschreiben sollen.
-\end{itemize}
-
-Und folgende Clientvariable kann unter den Prozesseinstellungen unter dem Punkt ``2-Phasen Commit Client'' konfiguriert werden:
-
-\begin{itemize}
- \item \textbf{Festschreibwahrscheinlichkeit} \textit{(Integer: ackProb = 50)}: Gibt die Wahrscheinlichkeit in Prozent an, die der Client mit \textit{true}, also für das Festschreiben, abstimmt.
-\end{itemize}
-
-\begin{table}
- \centering
- \fbox{
- \begin{tabular}{c|c|l}
- \textbf{Zeit (ms)} & \textbf{PID} & \textbf{Loggnachricht} \\
- \hline
-000000 & & Simulation gestartet\\
-\hline
-000000 & 1 & 2-Phasen Commit Client aktiviert\\
-\hline
-000000 & 2 & 2-Phasen Commit Server aktiviert\\
-\hline
-000000 & 2 & Nachricht versendet; ID: 94; Protokoll: 2-Phasen Commit\\
- & & Boolean: wantVote=true\\
-\hline
-000000 & 3 & 2-Phasen Commit Client aktiviert\\
-\hline
-000905 & 3 & Nachricht erhalten; ID: 94; Protokoll: 2-Phasen Commit\\
-\hline
-000905 & 3 & Nachricht versendet; ID: 95; Protokoll: 2-Phasen Commit\\
- & & Integer: pid=3; Boolean: isVote=true; vote=true\\
-\hline
-000905 & 3 & Abstimmung true versendet\\
-\hline
-001880 & 2 & Nachricht erhalten; ID: 95; Protokoll: 2-Phasen Commit\\
-\hline
-001880 & 2 & Abstimmung von Prozess 3 erhalten! Ergebnis: true\\
-\hline
-001947 & 1 & Nachricht erhalten; ID: 94; Protokoll: 2-Phasen Commit\\
-\hline
-001947 & 1 & Nachricht versendet; ID: 96; Protokoll: 2-Phasen Commit\\
- & & Integer: pid=1; Boolean: isVote=true; vote=true\\
-\hline
-001947 & 1 & Abstimmung true versendet\\
-\hline
-002500 & 2 & Nachricht versendet; ID: 97; Protokoll: 2-Phasen Commit\\
- & & Boolean: wantVote=true\\
-\hline
-003006 & 3 & Nachricht erhalten; ID: 97; Protokoll: 2-Phasen Commit\\
-\hline
-003006 & 3 & Nachricht versendet; ID: 98; Protokoll: 2-Phasen Commit\\
- & & Integer: pid=3; Boolean: isVote=true; vote=true\\
-\hline
-003006 & 3 & Abstimmung true versendet\\
-\hline
-003137 & 2 & Nachricht erhalten; ID: 96; Protokoll: 2-Phasen Commit\\
-\hline
-003137 & 2 & Abstimmung von Prozess 1 erhalten! Ergebnis: true\\
-\hline
-003137 & 2 & Abstimmungen von allen beteiligten Prozessen erhalten!\\
- & & Globales Ergebnis: true\\
-\hline
-003137 & 2 & Nachricht versendet; ID: 99; Protokoll: 2-Phasen Commit\\
- & & Boolean: isVoteResult=true; voteResult=true\\
-\hline
-004124 & 1 & Nachricht erhalten; ID: 99; Protokoll: 2-Phasen Commit\\
-\hline
-004124 & 1 & Globales Abstimmungsergebnis erhalten. Ergebnis: true\\
-\hline
-004124 & 1 & Nachricht versendet; ID: 100; Protokoll: 2-Phasen Commit\\
- & & Integer: pid=1; Boolean: isAck=true\\
-\hline
-004354 & 3 & Nachricht erhalten; ID: 99; Protokoll: 2-Phasen Commit\\
-\hline
-004354 & 3 & Globales Abstimmungsergebnis erhalten. Ergebnis: true\\
-\hline
-004354 & 3 & Nachricht versendet; ID: 101; Protokoll: 2-Phasen Commit\\
- & & Integer: pid=3; Boolean: isAck=true\\
-\hline
-004434 & 1 & Nachricht erhalten; ID: 97; Protokoll: 2-Phasen Commit\\
-\hline
-004434 & 1 & Nachricht versendet; ID: 102; Protokoll: 2-Phasen Commit\\
- & & Integer: pid=1; Boolean: isVote=true; vote=true\\
- \end{tabular}
- }
- \caption{Auszug aus der Loggausgabe des Zwei-Phasen Commit Beispiels}
- \label{tb:TwoPhaseCommitLoggs}
-\end{table}
-
-\begin{table}
- \centering
- \fbox{
- \begin{tabular}{c|c|l}
- \textbf{Zeit (ms)} & \textbf{PID} & \textbf{Loggnachricht} \\
- \hline
-004434 & 1 & Abstimmung true versendet\\
-\hline
-004527 & 2 & Nachricht erhalten; ID: 98; Protokoll: 2-Phasen Commit\\
-\hline
-004975 & 2 & Nachricht erhalten; ID: 101; Protokoll: 2-Phasen Commit\\
-\hline
-005311 & 2 & Nachricht erhalten; ID: 102; Protokoll: 2-Phasen Commit\\
-\hline
-005637 & 2 & Nachricht versendet; ID: 103; Protokoll: 2-Phasen Commit\\
- & & Boolean: isVoteResult=true; voteResult=true\\
-\hline
-006051 & 2 & Nachricht erhalten; ID: 100; Protokoll: 2-Phasen Commit\\
-\hline
-006051 & 2 & Alle Teilnehmer haben die Abstimmung erhalten\\
-\hline
-006766 & 1 & Nachricht erhalten; ID: 103; Protokoll: 2-Phasen Commit\\
-\hline
-006766 & 1 & Globales Abstimmungsergebnis erhalten. Ergebnis: true\\
-\hline
-006766 & 1 & Nachricht versendet; ID: 104; Protokoll: 2-Phasen Commit\\
- & & Integer: pid=1; Boolean: isAck=true\\
-\hline
-007279 & 2 & Nachricht erhalten; ID: 104; Protokoll: 2-Phasen Commit\\
-\hline
-007618 & 3 & Nachricht erhalten; ID: 103; Protokoll: 2-Phasen Commit\\
-\hline
-007618 & 3 & Globales Abstimmungsergebnis erhalten. Ergebnis: true\\
-\hline
-007618 & 3 & Nachricht versendet; ID: 105; Protokoll: 2-Phasen Commit\\
- & & Integer: pid=3; Boolean: isAck=true\\
-\hline
-009170 & 2 & Nachricht erhalten; ID: 105; Protokoll: 2-Phasen Commit\\
-\hline
-010000 & & Simulation beendet
- \end{tabular}
- }
- \caption{Auszug aus der Loggausgabe des Zwei-Phasen Commit Beispiels (2)}
- \label{tb:TwoPhaseCommitLoggs2}
-\end{table}
-
-\newpage
-\subsection{Der ungenügende (Basic) Multicast \small{\textit{(basic-multicast.dat)}}}
-
-\begin{figure}[h]
- \centering
- \fbox{\includegraphics[width=10cm]{images/ss-protokoll-basic-multicast}}
- \caption{Das Basic-Multicast Protokoll}
- \label{fig:BasicMulticastProto}
-\end{figure}
-
-Das Basic-Multicast Protokoll ist sehr einfach aufgebaut. Im Beispiel auf Abbildung \ref{fig:BasicMulticastProto} sind P1 und P3 Server und P2 der Client. Bei diesem Protokoll startet der Client immer die Anfrage, welche bei diesem Protokoll eine einfache Multicast-Nachricht darstellen soll. Die Basic-Multicast Server dienen lediglich für den Empfang einer Nachricht. Es werden keine Bestätigungen verschickt. Wie in Tabelle \ref{tb:BasicMulticastTasks} aufgeführt verschickt P2 alle \textit{2500ms} jeweils eine Multicast-Nachricht, die alle voneinander völlig unabhängig sind.
-
-P1 kann jedoch erst nach \textit{2500ms} Multicast-Nachrichten empfangen, da er vorher das Protokoll nicht unterstützt während P3 von \textit{3000ms} bis \textit{6000ms} abgestürzt ist und in dieser Zeit auch keine Nachrichten empfangen kann. Je nach Interpretation könnte P1 einen Server simulieren, der erst später ans Netz angeschlossen wird. Da die Einstellung ``Nur relevante Nachrichten anzeigen'' aktiviert ist, wird die erste Multicast-Nachricht von P2 an P1 nicht dargestellt. Bei jedem Prozess wurde die Nachrichtenverlustwahrscheinlichkeit auf \textit{30} Prozent gestellt, weswegen alle in dieser Simulation verschickten Nachrichten mit einer Wahrscheinlichkeit von \textit{30} Prozent ausfallen.
-
-In diesem Beispiel ging die 3. Multicast-Nachricht auf den Weg zu P3- und die 5. sowie 6. Nachricht auf den Weg zu P1 verloren. Lediglich die 4. Multicast-Nachricht hat alle beiden Ziele auf einmal erreicht.
-
-\begin{table}
- \centering
- \fbox{
- \begin{tabular}{c|c|l}
- \textbf{Zeit (ms)} & \textbf{PID} & \textbf{Ereignis} \\
- \hline
- 00000 & 2 & Basic Multicast Client aktivieren\\
- 00000 & 3 & Basic Multicast Server aktivieren\\
- 00000 & 2 & Basic Multicast Clientanfrage starten\\
- 02500 & 1 & Basic Multicast Server aktivieren\\
- 02500 & 2 & Basic Multicast Clientanfrage starten\\
- 03000 & 3 & Prozessabsturz\\
- 05000 & 2 & Basic Multicast Clientanfrage starten\\
- 06000 & 3 & Prozesswiederbelebung\\
- 07500 & 2 & Basic Multicast Clientanfrage starten\\
- 10000 & 2 & Basic Multicast Clientanfrage starten\\
- 12500 & 2 & Basic Multicast Clientanfrage starten
- \end{tabular}
- }
- \caption{Programmierte Basic-Multicast Ereignisse}
- \label{tb:BasicMulticastTasks}
-\end{table}
-
-\newpage
-\subsection{Der zuverlässige (Reliable) Multicast \small{\textit{(reliable-multicast.dat)}}}
-
-\begin{figure}[h]
- \centering
- \fbox{\includegraphics[width=10cm]{images/ss-protokoll-reliable-multicast}}
- \caption{Das Reliable-Multicast Protokoll}
- \label{fig:ReliableMulticastProto}
-\end{figure}
-
-Bei dem zuverlässigen (Reliable) Multicast verschickt der Client so oft periodisch seine Multicast-Nachricht erneut, bis er von allen beteiligten Servern eine Bestätigung erhalten hat. Nach jedem erneuten Versuch vergisst der Client, von welchen Servern er bereits eine Bestätigung erhalten hat, womit jeder erneuter Versuch von allen Teilnehmern aufs Neue bestätigt werden muss. In dem Beispiel (Abbildung \ref{fig:ReliableMulticastProto}, Tabelle \ref{tb:ReliableMulticastTasks}, sowie den Loggs in den Tabellen \ref{tb:ReliableMulticastLoggs} und \ref{tb:ReliableMulticastLoggs2}) ist P2 der Multicast-verschickende Client, während P1 und P3 die Server darstellen. Bei \textit{0ms} initiiert der Client seine Multicast-Nachricht. Die Nachrichtenverlustwahrscheinlichkeiten sind bei allen Prozessen auf \textit{30} Prozent eingestellt.
-
-In diesem Beispiel benötigt der Client bis zur erfolgreichen Auslieferung des zuverlässigen Multicasts genau 5 Versuche:
-
-\begin{enumerate}
- \setlength{\itemsep}{-1mm}
- \item Versuch:
- \begin{itemize}
- \setlength{\itemsep}{-2.5mm}
- \item P1 unterstützt das Reliable-Multicast Protokoll noch nicht, und kann somit weder Multicast-Nachricht erhalten noch eine Bestätigung verschicken.
- \item P3 empfängt die Multicast-Nachricht, jedoch geht seine Bestätigungsnachricht verloren.
- \end{itemize}
- \item Versuch:
- \begin{itemize}
- \setlength{\itemsep}{-2.5mm}
- \item P1: Die Multicast-Nachricht geht unterwegs zu P1 verloren.
- \item P3: Die Multicast-Nachricht erreicht P3, aber P3 ist abgestürzt und kann somit keine Nachricht verarbeiten.
- \end{itemize}
- \item Versuch:
- \begin{itemize}
- \setlength{\itemsep}{-2.5mm}
- \item P1 empfängt die Multicast-Nachricht und seine Bestätigung kommt wie geplant bei P2 an.
- \item P3: Die Multicast-Nachricht geht unterwegs zu P3 verloren.
- \end{itemize}
- \item Versuch:
- \begin{itemize}
- \setlength{\itemsep}{-2.5mm}
- \item P1 empfängt die Multicast-Nachricht und seine Bestätigung kommt wie geplant bei P2 an.
- \item P3: Die Multicast-Nachricht erreicht P3, aber P3 ist abgestürzt und kann somit keine Nachricht verarbeiten.
- \end{itemize}
- \item Versuch:
- \begin{itemize}
- \item P1 empfängt die Multicast-Nachricht und seine Bestätigung kommt wie geplant bei P2 an.
- \setlength{\itemsep}{-2.5mm}
- \item P3 empfängt die Multicast-Nachricht und seine Bestätigung kommt wie geplant bei P2 an.
- \end{itemize}
-\end{enumerate}
-
-\begin{table}
- \centering
- \fbox{
- \begin{tabular}{c|c|l}
- \textbf{Zeit (ms)} & \textbf{PID} & \textbf{Ereignis} \\
- \hline
- 00000 & 3 & Reliable Multicast Server aktivieren\\
- 00000 & 2 & Reliable Multicast Client aktivieren\\
- 00000 & 2 & Reliable Multicast Clientanfrage starten\\
- 02500 & 1 & Reliable Multicast Server aktivieren\\
- 03000 & 3 & Prozessabsturz\\
- 10000 & 3 & Prozesswiederbelebung\\
- \end{tabular}
- }
- \caption{Programmierte Reliable-Multicast Ereignisse}
- \label{tb:ReliableMulticastTasks}
-\end{table}
-
-\begin{table}
- \centering
- \fbox{
- \begin{tabular}{c|c|l}
- \textbf{Zeit (ms)} & \textbf{PID} & \textbf{Loggnachricht} \\
- \hline
-000000 & & Simulation gestartet\\
-\hline
-000000 & 2 & Reliable Multicast Client aktiviert\\
-\hline
-000000 & 2 & Nachricht versendet; ID: 280; Protokoll: Reliable Multicast;\\
- & & Boolean: isMulticast=true\\
-\hline
-000000 & 3 & Reliable Multicast Server aktiviert\\
-\hline
-001590 & 3 & Nachricht erhalten; ID: 280; Protokoll: Reliable Multicast\\
-\hline
-001590 & 3 & Nachricht versendet; ID: 281; Protokoll: Reliable Multicast\\
- & & Integer: pid=3; Boolean: isAck=true\\
-\hline
-001590 & 3 & ACK versendet\\
-\hline
-002500 & 1 & Reliable Multicast Server aktiviert\\
-\hline
-002500 & 2 & Nachricht versendet; ID: 282; Protokoll: Reliable Multicast\\
- & & Boolean: isMulticast=true\\
-\hline
-003000 & 3 & Abgestürzt\\
-\hline
-005000 & 2 & Nachricht versendet; ID: 283; Protokoll: Reliable Multicast\\
- & & Boolean: isMulticast=true\\
-\hline
-005952 & 1 & Nachricht erhalten; ID: 283; Protokoll: Reliable Multicast\\
-\hline
-005952 & 1 & Nachricht versendet; ID: 284; Protokoll: Reliable Multicast\\
- & & Integer: pid=1; Boolean: isAck=true\\
-\hline
-005952 & 1 & ACK versendet\\
-\hline
-007500 & 2 & Nachricht versendet; ID: 285; Protokoll: Reliable Multicast\\
- & & Boolean: isMulticast=true\\
-\hline
-007937 & 2 & Nachricht erhalten; ID: 284; Protokoll: Reliable Multicast\\
-\hline
-007937 & 2 & ACK von Prozess 1 erhalten!\\
-\hline
-008469 & 1 & Nachricht erhalten; ID: 285; Protokoll: Reliable Multicast\\
-\hline
-008469 & 1 & Nachricht versendet; ID: 286; Protokoll: Reliable Multicast\\
- & & Integer: pid=1; Boolean: isAck=true\\
-\hline
-008469 & 1 & ACK erneut versendet\\
-\hline
-010000 & 2 & Nachricht versendet; ID: 287; Protokoll: Reliable Multicast\\
- & & Boolean: isMulticast=true\\
-\hline
-010000 & 3 & Wiederbelebt\\
-\hline
-010395 & 2 & Nachricht erhalten; ID: 286; Protokoll: Reliable Multicast\\
-\hline
-010995 & 3 & Nachricht erhalten; ID: 287; Protokoll: Reliable Multicast\\
-\hline
-010995 & 3 & Nachricht versendet; ID: 288; Protokoll: Reliable Multicast\\
- & & Integer: pid=3; Boolean: isAck=true\\
-\hline
-010995 & 3 & ACK erneut versendet\\
-\hline
-011213 & 1 & Nachricht erhalten; ID: 287; Protokoll: Reliable Multicast\\
-\hline
-011213 & 1 & Nachricht versendet; ID: 289; Protokoll: Reliable Multicast\\
- & & Integer: pid=1; Boolean: isAck=true\\
- \end{tabular}
- }
- \caption{Auszug aus der Loggausgabe des Reliable-Multicast Beispiels}
- \label{tb:ReliableMulticastLoggs}
-\end{table}
-
-\begin{table}
- \centering
- \fbox{
- \begin{tabular}{c|c|l}
- \textbf{Zeit (ms)} & \textbf{PID} & \textbf{Loggnachricht} \\
- \hline
-011213 & 1 & ACK erneut versendet\\
-\hline
-011813 & 2 & Nachricht erhalten; ID: 288; Protokoll: Reliable Multicast\\
-\hline
-011813 & 2 & ACK von Prozess 3 erhalten!\\
-\hline
-011813 & 2 & ACKs von allen beteiligten Prozessen erhalten!\\
-\hline
-012047 & 2 & Nachricht erhalten; ID: 289; Protokoll: Reliable Multicast\\
-\hline
-015000 & & Simulation beendet\\
- \end{tabular}
- }
- \caption{Auszug aus der Loggausgabe des Reliable-Multicast Beispiels (2)}
- \label{tb:ReliableMulticastLoggs2}
-\end{table}
-
-\subsubsection{Protokollvariablen}
-
-Dieses Protokoll verwendet folgende serverseitige Variablen, die in den Prozesseinstellungen unter dem Punkt ``Reliable Multicast Server'' konfiguriert werden können:
-
-\begin{itemize}
- \item \textbf{Zeit bis erneute Anfrage} \textit{(Long: timeout = 2500)}: Gibt die Anzahl von Millisekunden an, die gewartet werden sollen, bis der Muticast erneut verschickt wird.
- \item \textbf{PIDs beteiligter Prozesse} \textit{(Integer[]: pids = [1,3])}: Dieser Vektor aus Integerwerten beinhaltet alle PIDs der Serverprozesse, die die Multicast-Nachricht erhalten sollen.
-\end{itemize}
-
-\newpage
-\section{Weitere Beispiele}
-
-Bisher wurden alle verfügbaren Protokolle anhand von Beispielen aufgeführt. Mit dem Simulator lassen sich allerdings noch viel mehr Szenarien simulieren. Daher soll hier auf weitere Anwendungsbeispiele eingegangen werden.
-
-\subsection{Simulation von Vektor- und Lamportzeitstempel}
-
-\begin{figure}[h]
- \centering
- \fbox{\includegraphics[width=10cm]{images/ss-protokoll-berkeley-lamport}}
- \caption{Lamportzeitstempel}
- \label{fig:Lamportzeit}
-\end{figure}
-
-Die Vektor- und Lamportzeitstempel lassen sich sehr gut am bereits behandeltem Beispiel des Berkeley-Protokoll's demonstrieren. Nach Aktivierung des Lamportzeit-Schalters erscheint bei jedem Ereignis eines Prozesses der aktuelle Lamportzeitstempel (Abbildung \ref{fig:Lamportzeit}). Jeder Prozess besitzt einen eigenen Lamportzeitstempel, der bei jedem Versenden oder Erhalten einer Nachricht inkrementiert wird. Jeder Nachricht wird die aktuelle Lamportzeit $t_l(i)$ des Senderprozesses $i$ beigefügt. Wenn ein weiterer Prozess $j$ diese Nachricht erhält, so wird der aktuelle Lamportzeitstempel $t_l(j)$ von Prozess $j$ wie folgt neu berechnet:
-
-\begin{equation*}
- t_l(j) := 1 + max(t_l(j), t_l(i))
-\end{equation*}
-
-Es wird also stets die größere Lamportzeit vom Sender- und Empfängerprozess verwendet und anschließend wird diese um \textit{1} inkrementiert. Nach Ablauf der Berkeley-Simulation hat P1 \textit{(16)}, P2 (\textit{14}) und P3 (\textit{15}) als Lamportzeitstempel abgespeichert.
-
-\begin{figure}[h]
- \centering
- \fbox{\includegraphics[width=10cm]{images/ss-protokoll-berkeley-vektor}}
- \caption{Vektorzeitstempel}
- \label{fig:Vektorzeit}
-\end{figure}
-
-Mit aktivem Vektorzeit-Schalter werden alle Vektor-Zeitstempel angezeigt (Abbildung \ref{fig:Vektorzeit}). Wie bei den Lamportzeitstempel wird auch hier jeder Nachricht der aktuelle Vektor-Zeitstempel des Senderprozesses beigefügt. Bei $n$ beteiligten Prozessen hat der Vektor-Zeitstempel $v$ die Größe $n$. Somit gibt es für jeden beteiligten Prozess $i$ einen eigenen Index $i$. über $v(i)$ kann jeder Prozess auf seinen lokalen Eintrag zugreifen. Wenn $v$ der Vektor-Zeitstempel des Empfängerprozesses $j$ ist und $w$ der Vektor-Zeitstempel des Senderprozesses ist, dann wird der neue lokale Vektorzeitstempel wie folgt (hier in Pseudo-Code angegeben) neu berechnet:
-
-\begin{code}
-for (i := 0; i < n; i++) {
- if (i = j) {
- v(i)++;
- } else if (v(i) < w(i)) {
- v(i) := w(i);
- }
-}
-\end{code}
-
-Standardmäßig wird der Vektor-Zeitstempel nur inkrementiert, wenn eine Nachricht verschickt- oder erhalten wird. Bei beiden Fällen inkrementiert der Sender- und Empfängerprozess jeweils seinen eigenen Index im Vektor-Zeitstempel mit $v(i) = v(i) + 1$. Beim Empfang einer Nachricht wird anschließend der lokale Vektor-Zeitstempel mit dem des Senderprozesses verglichen und für alle Indizes stets der größere Wert in den lokalen Vektor-Zeitstempel übernommen.
-
-Im Beispiel auf Abbildung \ref{fig:Vektorzeit} hat P1 \textit{(8,10,6)}, P2 \textit{(6,10,6)} und P3 \textit{(6,10,8)} als Vektor-Zeitstempel abgespeichert.
-
-Wenn während einer Simulation Prozesse entfernt- oder neue Prozesse hinzugefügt werden, so passt sich die Größe der Vektor-Zeitstempel aller anderen Prozesse automatisch der totalen Anzahl der Prozesse an.
-
-Wie bereits beschrieben gibt es in den Simulationseinstellungen die boolschen Variablen ``Lamportzeiten betreffen alle Ereignisse'' und ``Vektorzeiten betreffen alle Ereignisse'', die standardmäßig auf \textit{false} gesetzt sind. Mit \textit{true} werden alle Ereignisse, und nicht nur der Empfang oder das Versenden einer Nachricht, berücksichtigt. Für eine weitere Betrachtung der Lamport- sowie Vektor-Zeitstempel siehe \cite{Vorlesung} oder \cite{Tanenbaum}.
-
-\newpage
-\subsection{Simulation langsamer Verbindungen \small{\textit{(slow-connection.dat)}}}
-
-Mit dem Simulator lassen sich auch langsame Verbindungen zu einem bestimmten Prozess simulieren. Für die Demonstration wird das Beispiel aus Kapitel 2.5.5 wieder aufgegriffen, wo das Protokoll zur internen Synchronisation (P1) mit der Christians-Methode (P3) parallel simuliert wurden. P2 stellt den Server beider Protokolle zur Verfügung. In diesem Szenario soll P3 eine schlechte Netzwerkverbindung besitzen, sodass Nachrichten von- und an P3 stets eine längere Übertragungszeit benötigen.
-
-Die Ereignisse sind so wie bereits auf Tabelle \ref{tb:InterneSync2Tasks} dargestellt wurde programmiert. In den Simulationseinstellungen ist hier die Einstellung ``Mittelwerte der Übertragungszeiten bilden'' aktiviert. In den Prozesseinstellungen von P3 wurde ``Minimale Übertragungszeit'' auf \textit{2000ms} und ``Maximale Übertragungszeit'' auf \textit{8000ms} gestellt. P1 und P2 behalten als Standardeinstellungen für die minimale und maximale Übertragungszeiten jeweils \textit{500ms} und \textit{2000ms} eingestellt. Die Simulationsdauer wurde auf \textit{20000ms} gestellt.
-
-\begin{figure}[h]
- \centering
- \fbox{\includegraphics[width=10cm]{images/ss-protokoll-time-sync-2-long-transfer}}
- \caption{Simulation einer langsamen Verbindung}
- \label{fig:TimeSync2LongTransferProto}
-\end{figure}
-
-Als Folge (Abbildung \ref{fig:TimeSync2LongTransferProto}) benötigen Nachrichten, die von- und an P3 verschickt werden, für eine Übertragung immer mehr Zeit. Bevor P3 eine Antwort auf seine vorherige Anfrage bekommt, verschickt er eine erneute Anfrage. Da P3 die Serverantworten immer stets seiner letzten verschickten Anfrage zuordnet, berechnet er die RTTs allesamt falsch und seine lokale Zeit wird bei jedem Durchgang zusätzlich verfälscht. Die Berechnungsformeln der Übertragungszeiten wurde bereits in Kapitel 2.4.3 bei den Prozesseinstellungen behandelt. Konkret bedeutet dies für die Übertragungszeiten alle Nachrichten von- und an P3 jeweils:
-
-\begin{equation*}
- \frac{1}{2} (rand(500, 2000) + rand(2000, 8000)) = \frac{1}{2} rand(2500, 10000) = rand(1250, 5000) ms
-\end{equation*}
+Im Expertenmodus lassen sich zusätzliche Variablen, wie beispielsweise diverse Farbwerte und Anzahl oder Pixel verschiedener der GUI-Elemente, editieren. Auf Abbildung \ref{fig:SimulationseinstellungenExperten}. sieht der Anwender alle einstellbaren Farben. Die fett-gedruckten Schlüssel in Tabelle \ref{tb:Farbeinstellungen}. dienen nur als Standardwerte für die neu zu erstellenden Prozesse und sind auch jeweils in den Prozesseinstellungen für jeden Prozess separat editierbar.
-In dem Beispiel auf Abbildung \ref{fig:TimeSync2LongTransferProto} ist die lokale Prozesszeit von P1 bis auf \textit{20000 - 21446 = - 1446ms} synchronisiert, w\"{a}hrend die Prozesszeit von P3 satte \textit{20000 - 16557 = 3443ms} falsch geht.
diff --git a/LaTeX/chapters/titlepage.tex b/LaTeX/chapters/titlepage.tex index 677d83f..9530e85 100644 --- a/LaTeX/chapters/titlepage.tex +++ b/LaTeX/chapters/titlepage.tex @@ -65,9 +65,9 @@ \textbf{\LARGE Erkl\"{a}rung} \vspace*{1.5cm} -Ich versichere hiermit, dass ich die vorliegende Arbeit selbstst\"{a}ndig verfasst und keine anderen als die im Literaturverzeichnis angegebenen Quellen benutzt habe. +Ich versichere hiermit, dass ich die vorliegende Arbeit selbstst\"{a}ndig verfasst und keine anderen, als die im Literaturverzeichnis angegebenen Quellen benutzt habe. -Stellen, die w\"{o}rtlich oder sinngem\"{a}ß aus ver\"{o}ffentlichen oder noch nicht ver\"{o}ffentlichen Quellen entnommen sind, sind als solche kenntlich gemacht. +Stellen, die w\"{o}rtlich oder sinngem\"{a}ß aus ver\"{o}ffentlichten oder noch nicht ver\"{o}ffentlichten Quellen entnommen sind, sind als solche kenntlich gemacht. Die Zeichnungen oder Abbildungen in dieser Arbeit sind von mir selbst erstellt worden oder mit einem entsprechenden Quellennachweis versehen. @@ -79,7 +79,7 @@ Aachen, \today \\ \textbf{\LARGE Geheimhaltung} \vspace*{1.5cm} -Diese Diplomarbeit darf weder vollst\"{a}ndig noch auszugsweise ohne schriftliche Zustimmung des Autors, des betreuenden Referenzen bzw. der Fachhochschule Aachen vervielf\"{a}ltigt, ver\"{o}ffentlicht oder Dritten zug\"{a}nglich gemacht werden. +Diese Diplomarbeit darf weder vollst\"{a}ndig, noch auszugsweise ohne schriftliche Zustimmung des Autors, des betreuenden Referenten bzw. der Fachhochschule, Aachen vervielf\"{a}ltigt, ver\"{o}ffentlicht oder Dritten zug\"{a}nglich gemacht werden. \newpage @@ -95,14 +95,17 @@ Ohne die Hilfe folgender Personen w\"{a}re die Anfertigung dieser Diplomarbeit i \begin{itemize} \item Prof. Oßmann als 1. Pr\"{u}fer sowie Prof. Fassbender als 2. Pr\"{u}fer + \item Albena Angelova \item Andre Herbst \item Carrie Callahan + \item Claudia Steudter \item Florian B\"{u}tow \item J\"{o}rn B\"{u}tow + \item Jochen Demmer \item Leslie B\"{u}tow \end{itemize} -Auch vielen Dank an die Open Source Gemeinde, denn diese Diplomarbeit wurde ausschließlich mithilfe von Open Source Software angefertigt +Auch vielen Dank an die Open Source Gemeinde, denn diese Diplomarbeit wurde ausschließlich mit Hilfe von Open Source Software angefertigt. \newpage \thispagestyle{empty} |