foo

2 files changed, 41 insertions, 10 deletions

diff --git a/LaTeX/chapters/appendix-b.tex b/LaTeX/chapters/appendix-b.tex
index 73c7a12..dd86e21 100644
--- a/LaTeX/chapters/appendix-b.tex
+++ b/LaTeX/chapters/appendix-b.tex
@@ -1,5 +1,6 @@
 \chapter{Akronyms}

 \begin{acronym}

+\acro{API}{Application Programming Interface}

 \acro{GUI}{Graphical User Interface}

 \acro{NID}{Nachrichten-Identifikationsnummer}

 \acro{PID}{Prozess-Identifikationsnummer}

diff --git a/LaTeX/chapters/simulator.tex b/LaTeX/chapters/simulator.tex
index 11791f0..2ebc9a6 100644
--- a/LaTeX/chapters/simulator.tex
+++ b/LaTeX/chapters/simulator.tex
@@ -7,8 +7,8 @@
 	\fbox{\includegraphics{images/ss-neues-fenster-klein}}

 	\caption{Der Simulator nach dem ersten Starten}

 	\label{fig:NeuesFenster}

-

 \end{figure}

+

 Der Simulator pr\"{a}sentiert sich nach dem ersten Starten wie in Abbildung \ref{fig:NeuesFenster}. F\"{u}r die Erstellung einer neuen Simulation wird im Men\"{u} ``Datei'' (Abbildung \ref{fig:DateiMenue}) der Punkt ``Neue Simulation'' ausgew\"{a}hlt, wo anschließend das Einstellungsfenster f\"{u}r die neue Simulation erscheint.  Auf die einzelnen Optionen wird sp\"{a}ter genauer eingegangen und es werden nun nur die Standardeinstellungen \"{u}bernommen. Die GUI mit einer frischen Simulation sieht dann wie in Abbildung \ref{fig:NeuErstellteSimulation} aus.

 

 \begin{figure}[htbp]

@@ -220,6 +220,45 @@ Nachdem ein Prozess eine Anfragenachricht versendet hat, und ein weiterer Prozes
 Ein Callback-Ereignis kann von einem Protokoll ausgel\"{o}st werden. Das Protokoll setzt einen Wecker zur welcher lokalen Uhrzeit eine weitere Aktion ausgef\"{u}hrt werden soll. Zum Beispiel lassen sich hiermit Timeouts realisieren, wenn ein Protokoll eine Antwort erwartet, diese aber nicht eintrifft. Nach dem Timeout kann dann eine Anfrage erneuert verschickt werden! Es k\"{o}nnen beliebig viele Callback-Ereignisse definiert werden. Wenn sie noch nicht ausgef\"{u}hrt wurden und aufgrund eines anderen Ereignisses nicht mehr ben\"{o}tigt werden, k\"{o}nnen sie vom Protokoll auch wieder entfernt werden. Wenn ein Callback-Ereignis ausgef\"{u}hrt wird, kann es sich selbst wieder f\"{u}r eine weitere Ausf\"{u}hrung erneuert planen. So lassen sich periodisch wiedereintreffende Ereignisse realisieren. Beispielsweise verwendet das ``Reliable Multicast Protokoll'' Callback-Ereignisse, indem solange Anfragen verschickt werden, bis alle ben\"{o}tigten Antworten vorliegen.

 

 \section{Protokolle}

+

+Im Folgenden werden alle bisher verf\"{u}gbaren Protokolle behandelt. Wie bereits beschrieben wird bei Protokollen zwischen Server- und Clientseite unterschieden. Server k\"{o}nnen auf Clientnachrichten, und Client auf Servernachrichten antworten. Jeder Prozess kann beliebig viele Protokolle sowohl Clientseitig als auch Serverseitig untest\"{u}tzen. Theoretisch ist es auch m\"{o}glich, dass ein Prozess f\"{u}r ein bestimmtes Protokoll gleichzeitig Server und Client ist. Der Benutzer kann auch weitere eigene Protokolle in der Programmiersprache Java mittels einer speziellen API (Application Programming Interface) erstellen. Wie eigene Protokolle erstellt werden k\"{o}nnen wird sp\"{a}ter behandelt. 

+

+\subsection{Beispiel (Dummy) Protokoll}

+

+Das Dummy-Protokoll dient lediglich als leeres Template f\"{u}r die Erstellung eigener Protokolle. Bei der Verwendung des Dummy-Protokolls werden bei Ereignissen lediglich Loggnachrichten ausgegeben, jedoch keine weiteren Aktionen ausgef\"{u}hrt.

+

+\subsection{Das Ping-Pong Protokoll}

+

+\begin{figure}[htbp]

+	\centering

+	\fbox{\includegraphics[width=9cm]{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 Client und Server st\"{a}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 wiederum geantwortet und so weiter. Jeder Nachricht wird ein Z\"{a}hler mitgeschickt, der bei jeder Station um eins inkrementiert wird und jeweils im Loggfenster protokolliert wird. Es werden erst keine Nachrichten mehr versendet, wenn entweder eine Nachricht verloren geht, oder wenn die Simulationszeit das Ende erreicht hat.

+

+\begin{figure}[htbp]

+	\centering

+	\fbox{\includegraphics[width=9cm]{images/ss-protokoll-ping-pong-lamport}}

+	\caption{Das Ping-Pong Protokoll mit Lamport-Zeitstempel}

+	\label{fig:PingPongLamport}

+\end{figure}

+

+Das Ping-Pong Beispiel eignet sich auch f\"{u}r ein erstes Beispiel der Lamport- und Vektorzeitangaben. In Abbildung \ref{fig:PingPongLamport} wurde im Simulator die Lamportzeit-Checkbox aktiviert und in Abbildung \ref{fig:PingPongVektor} die der Vektorzeit. Selbstverst\"{a}ndlich lassen sich die Lamport- und Vektorzeiten auch bei jedem anderen Protokoll darstellen.

+

+\begin{figure}[htbp]

+	\centering

+	\fbox{\includegraphics[width=9cm]{images/ss-protokoll-ping-pong-vektor}}

+	\caption{Das Ping-Pong Protokoll mit Vektor-Zeitstempel}

+	\label{fig:PingPongVektor}

+\end{figure}

+

+\subsection{Das Broadcast-Sturm Protokoll}

+

+\subsection{Das Protokoll zur internen Synchronisierung in einem synchronen System}

+

+\subsection{Christians Methode zur externen Synchronisierung}

  lsdkfjds lfjds flsjfsljsd flsdjf sldkfjsdlfkj 

  lsdkfjds lfjds flsjfsljsd flsdjf sldkfjsdlfkj 

  lsdkfjds lfjds flsjfsljsd flsdjf sldkfjsdlfkj 

@@ -385,15 +424,6 @@ Ein Callback-Ereignis kann von einem Protokoll ausgel\"{o}st werden. Das Protoko
 

 

 

-\subsection{Beispiel (Dummy) Protokoll}

-

-\subsection{Das Ping-Pong Protokoll}

-

-\subsection{Das Broadcast-Sturm Protokoll}

-

-\subsection{Das Protokoll zur internen Synchronisierung in einem synchronen System}

-

-\subsection{Christians Methode zur externen Synchronisierung}

 

 \subsection{Berkeley Algorithmus zur internen Synchronisation}