summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorPaul Buetow <paul@buetow.org>2008-07-26 02:10:34 +0000
committerPaul Buetow <paul@buetow.org>2008-07-26 02:10:34 +0000
commit52954fe482b5c52f0d2db57491d22759cdf3b856 (patch)
tree32c35b2e53e31c0f16f97568b7e3ceec6f685ed9
parent7978f11e1f8db492c149a8aa8ebc222f20370353 (diff)
typos
-rw-r--r--LaTeX/chapters/introduction.tex6
-rw-r--r--LaTeX/chapters/simulator.tex40
-rw-r--r--LaTeX/chapters/titlepage.tex4
-rw-r--r--LaTeX/diplomarbeit.pdf2142
4 files changed, 1091 insertions, 1101 deletions
diff --git a/LaTeX/chapters/introduction.tex b/LaTeX/chapters/introduction.tex
index ddf06c0..79b8b35 100644
--- a/LaTeX/chapters/introduction.tex
+++ b/LaTeX/chapters/introduction.tex
@@ -13,9 +13,9 @@ In der Literatur findet man viele verschiedene Definitionen eins verteiltes Syst
\label{fig:VerteiltesSystem}
\end{figure}
-Der Benutzer muss sich nur mit dem lokalen vor ihm befindenden Computer auseinandersetzen (Abbildung \ref{fig:VerteiltesSystem}) w\"{a}hrend die Software des lokalen Computers die reibungslose Kommunikation mit den anderen betiligten Computern des verteilten Systems sicherstellt.
+Der Benutzer muss sich nur mit dem lokalen vor ihm befindenden Computer auseinander setzen (Abbildung \ref{fig:VerteiltesSystem}) w\"{a}hrend die Software des lokalen Computers die reibungslose Kommunikation mit den anderen beteiligten Computern des verteilten Systems sicherstellt.
-Der Sinn und der Zweck dieser Diplomarbeit ist die Betrachtung von verteilten Systemen aus einer anderen Perspektive zu vereinfachen. Wir nehmen nicht die Sichtweise eines Endbenutzers ein, sondern wollen die grundlegenen Funktionsweisen von Protokollen und deren Prozesse in verteilten Systemen begreifen. Es sollen alle relevanten Ereignisse eines verteilten Systems transparent dargestellt werden k\"{o}nnen.
+Der Sinn und der Zweck dieser Diplomarbeit ist die Betrachtung von verteilten Systemen aus einer anderen Perspektive zu vereinfachen. Wir nehmen nicht die Sichtweise eines Endbenutzers ein, sondern wollen die Funktionsweisen von Protokollen und deren Prozesse in verteilten Systemen begreifen. Es sollen alle relevanten Ereignisse eines verteilten Systems transparent dargestellt werden k\"{o}nnen.
Um dieses Ziel zu erreichen soll ein Simulator entwickelt werden, der dies erm\"{o}glicht. Der Simulator soll insbesondere f\"{u}r Lehr- und Lernzwecke entwickelt werden. Beispielsweise sollen Protokolle aus den verteilten Systemen mit ihren wichtigsten Einflussfaktoren simuliert werden k\"{o}nnen. Der Simulator soll helfen zu verstehen wie die gegebenen Protokolle funktionieren und es soll viel Spielraum f\"{u}r eigene Experimente zur Verf\"{u}gung stehen. Der Simulator soll nicht auf eine feste Anzahl von Protokollen beschr\"{a}nkt werden, daher muss die M\"{o}glichkeit gegeben werden eigene Protokolle selbst entwerfen zu k\"{o}nnen.
@@ -36,7 +36,7 @@ Der Simulator basiert auf dem Client/Server Prinzip. Jeder Simulation besteht in
\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 ist auch m\"{o}glich, dass ein Prozess die Rollen mehrerer Server und Clients aufeinmal einnimmt. Ob das sinnvoll ist h\"{a}ngt vom 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. Ein Prozess kann auch Client und Server gleichzeitig sein. Es ist auch m\"{o}glich, dass ein Prozess die Rollen mehrerer Server und Clients auf einmal einnimmt. Ob das sinnvoll ist h\"{a}ngt vom Szenario ab. Um einen Prozess zu kennzeichnen besitzt jeder Prozess eine \textbf{eindeutige} Prozess-Identifikationsnummer (PID).
\subsubsection{Nachrichten}
diff --git a/LaTeX/chapters/simulator.tex b/LaTeX/chapters/simulator.tex
index 4ff1f41..38f2ba2 100644
--- a/LaTeX/chapters/simulator.tex
+++ b/LaTeX/chapters/simulator.tex
@@ -20,7 +20,7 @@ Der Simulator pr\"{a}sentiert sich nach dem ersten Starten wie in Abbildung \ref
\subsubsection{Die Men\"{u}zeile}
-Im Datei-Men\"{u} (Abbildung \ref{fig:DateiMenue}) lassen sich neue Simulationen erstellen oder die aktuell ge\"{o}ffnete Simulation schliessen. Neue Simulationen \"{o}ffnen sich standardm\"{a}ig in einem neuen Tab. Es k\"{o}nnen allerdings auch neue Simulationsfenster, die wiederrum eigene Tabs besitzen, ge\"{o}ffnet oder geschlossen werden. In jedem Tab befindet sich eine von den Anderen vollst\"{a}ndig unabh\"{a}ngige Simulation. Es k\"{o}nnen somit beliebig viele Simulationen parallel ausgef\"{u}hrt werden. Die Men\"{u}eintr\"{a}ge ``\"{O}ffnen'', ``Speichern'' und ``Speichern unter'' dienen f\"{u}r das Laden und Speichern von Simulationen.
+Im Datei-Men\"{u} (Abbildung \ref{fig:DateiMenue}) lassen sich neue Simulationen erstellen oder die aktuell ge\"{o}ffnete Simulation schlieen. Neue Simulationen \"{o}ffnen sich standardm\"{a}ig in einem neuen Tab. Es k\"{o}nnen allerdings auch neue Simulationsfenster, die wiederum eigene Tabs besitzen, ge\"{o}ffnet oder geschlossen werden. In jedem Tab befindet sich eine von den Anderen vollst\"{a}ndig unabh\"{a}ngige Simulation. Es k\"{o}nnen somit beliebig viele Simulationen parallel ausgef\"{u}hrt werden. Die Men\"{u}eintr\"{a}ge ``\"{O}ffnen'', ``Speichern'' und ``Speichern unter'' dienen f\"{u}r das Laden und Speichern von Simulationen.
\begin{figure}[htbp]
\centering
@@ -94,7 +94,7 @@ Farben helfen dabei die Vorg\"{a}nge einer Simulation zu deuten. Standardm\"{a}
Orange & Die Maus befindet sich \"{u}ber den Prozessbalken\\
Rot & Der Prozess ist abgest\"{u}rzt\\
& \\
- \textbf{Nachrichtfarbe} & \textbf{Bedeutung} \\
+ \textbf{Nachrichtenfarbe} & \textbf{Bedeutung} \\
\hline
Gr\"{u}n & Die Nachricht ist noch unterwegs und hat das Ziel noch nicht erreicht\\
Blau & Die Nachricht hat das Ziel erfolgreich erreicht\\
@@ -118,7 +118,7 @@ Mithilfe der Sidebar lassen sich Prozessereignisse programmieren. Ganz oben in A
\label{fig:Sidebar}
\end{figure}
-F\"{u}r die Erstellung eines neuen Ereignisses kann der Benutzer entweder mit einem Rechtsklick auf einen Prozessbalken (Abbildung \ref{fig:RechtsklickProzessbalken}) klicken, oder unterhalb der Ereignistabelle ein Ereignis ausw\"{a}hlen (Abbildung \ref{fig:Ereignisauswahl}), im darunterliegendem Textfeld die Zeit eintragen und auf ``\"{U}bernehmen'' klicken. Beispielsweise wurden auf Abbildung \ref{fig:SidebarMitEreignissen} drei Ereignisse hinzugef\"{u}gt: Absturz nach 123ms, Wiederbelebung nach 321ms und erneuter Absturz nach 3000ms des Prozesses mit der ID 1.
+F\"{u}r die Erstellung eines neuen Ereignisses kann der Benutzer entweder mit einem Rechtsklick auf einen Prozessbalken (Abbildung \ref{fig:RechtsklickProzessbalken}) klicken, oder unterhalb der Ereignistabelle ein Ereignis ausw\"{a}hlen (Abbildung \ref{fig:Ereignisauswahl}), im darunter liegendem Textfeld die Zeit eintragen und auf ``\"{U}bernehmen'' klicken. Beispielsweise wurden auf Abbildung \ref{fig:SidebarMitEreignissen} drei Ereignisse hinzugef\"{u}gt: Absturz nach 123ms, Wiederbelebung nach 321ms und erneuter Absturz nach 3000ms des Prozesses mit der ID 1.
\begin{figure}[htbp]
\centering
@@ -162,7 +162,7 @@ Mit dem Deaktivieren der Checkbox ``Logging'' l\"{a}t sich das Loggen von Nachr
\label{fig:SimulationExpertenmodus}
\end{figure}
-Der Simulator kann in zwei verschiedenen Modi betrieben werden. Es gibt einen einfachen- und einen Expertenmodus. Der Simulator started standardm\"{a}ig im einfachen Modus, sodass sich der Benutzer nicht mit der vollen Funktionalit\"{a}t des Simulators auf einmal auseinandersetzen mu. Der einfache Modus ist \"{u}bersichtlicher, bietet jedoch weniger Funktionen an. Der Expertenmodus eigent sich f\"{u}r mehr erfahrene Anwender und bietet dementsprechend auch mehr Flexibilit\"{a}t. Der Expertenmodus kann \"{u}ber die gleichnamige Checkbox unterhalb des Loggfensters oder \"{u}ber die Simulationseinstellungen aktiviert oder deaktiviert werden. Auf Abbildung \ref{fig:SimulationExpertenmodus} ist der Simulator im Expertenmodus zu sehen. Wenn der Benutzer den Simulator im Expertenmodus mit Abbildung \ref{fig:NeuErstellteSimulation} vergleicht, dann fallen einige Unterschiede auf, die nun behandelt werden.
+Der Simulator kann in zwei verschiedenen Modi betrieben werden. Es gibt einen einfachen- und einen Expertenmodus. Der Simulator startet standardm\"{a}ig im einfachen Modus, sodass sich der Benutzer nicht mit der vollen Funktionalit\"{a}t des Simulators auf einmal auseinandersetzen mu. Der einfache Modus ist \"{u}bersichtlicher, bietet jedoch weniger Funktionen an. Der Expertenmodus eignet sich f\"{u}r mehr erfahrene Anwender und bietet dementsprechend auch mehr Flexibilit\"{a}t. Der Expertenmodus kann \"{u}ber die gleichnamige Checkbox unterhalb des Loggfensters oder \"{u}ber die Simulationseinstellungen aktiviert oder deaktiviert werden. Auf Abbildung \ref{fig:SimulationExpertenmodus} ist der Simulator im Expertenmodus zu sehen. Wenn der Benutzer den Simulator im Expertenmodus mit Abbildung \ref{fig:NeuErstellteSimulation} vergleicht, dann fallen einige Unterschiede auf, die nun behandelt werden.
\begin{figure}[htbp]
\centering
@@ -187,10 +187,10 @@ Es wird zwischen zwei verschiedenen Haupttypen von Ereignissen unterschieden: Pr
\subsubsection{Prozessabsturz- und Wiederbelebung (programmierbar)}
-Die beiden grundliegensten Ereignisse sind ``Prozessabsturz'' sowie ``Prozesswiederbelebung''. Wenn ein Prozess abgest\"{u}rzt ist, so wird sein Prozessbalken in rot dargestellt. Ein abgest\"{u}rzter Prozess kann keine weiteren Ereignisse mehr verarbeiten und, wenn er eine Nachricht empfangen sollte, geht diese verloren. Die einzige Ausnahme bildet ein Wiederbelebungsereignis. Ein abgest\"{u}rzter Prozess kann nichts, ausser wiederbelebt werden. W\"{a}hrend eines Prozessabsturzes l\"{a}uft die lokale Prozessuhr, abgesehen der Lamport- und Vektor-Uhren, wie gewohnt weiter. D.h. es k\"{o}nnte sein, dass ein Prozess einige seiner Ereignisse gar nicht ausf\"{u}hrt, da er zu den Ereigniseintrittszeiten abgest\"{u}rzt ist. Wenn im echten Leben ein Computer abst\"{u}rzt oder abgeschaltet wird, dann l\"{a}uft dort die Hardwareuhr, unabh\"{a}ngig vom Betriebssystem, auch weiter.
+Die beiden grundliegensten Ereignisse sind ``Prozessabsturz'' sowie ``Prozesswiederbelebung''. Wenn ein Prozess abgest\"{u}rzt ist, so wird sein Prozessbalken in rot dargestellt. Ein abgest\"{u}rzter Prozess kann keine weiteren Ereignisse mehr verarbeiten und, wenn er eine Nachricht empfangen sollte, geht diese verloren. Die einzige Ausnahme bildet ein Wiederbelebungsereignis. Ein abgest\"{u}rzter Prozess kann nichts, auer wiederbelebt werden. W\"{a}hrend eines Prozessabsturzes l\"{a}uft die lokale Prozessuhr, abgesehen der Lamport- und Vektor-Uhren, wie gewohnt weiter. D.h. es k\"{o}nnte sein, dass ein Prozess einige seiner Ereignisse gar nicht ausf\"{u}hrt, da er zu den Ereigniseintrittszeiten abgest\"{u}rzt ist. Wenn im echten Leben ein Computer abst\"{u}rzt oder abgeschaltet wird, dann l\"{a}uft dort die Hardware-Uhr, unabh\"{a}ngig vom Betriebssystem, auch weiter.
\subsubsection{Aktivierung und Deaktivierung von Protokollen sowie Starten von Anfragen (programmierbar)}
-Wir wissen bereits, dass ein Prozess mehrere Protokolle Client- und auch Serverseitig unterst\"{u}tzen kann. Welches Protokoll von einem Prozess unterst\"{u}tzt wird, kann der Benutzer anhand von Protokollaktivierungs- und Protokolldeaktivierungsereignissen konfigurieren. Somit besteht die M\"{o}glichkeit, dass ein gegebener Prozess ein bestimmtes Protokoll erst zu einem bestimmten Zeitpunkt unterst\"{u}tzt und gegebenenfalls ein anderes Protokoll abl\"{o}st. Jedes Protokoll kann entwender Server- oder Clientseitig aktiviert beziehungsweise deaktiviert werden. Welche Protokolle es gibt wird sp\"{a}ter behandelt. Der Benutzer hat die Auswahl zwischen f\"{u}nf verschiedenen Protokollereignistypen:
+Wir wissen bereits, dass ein Prozess mehrere Protokolle Client- und auch Serverseitig unterst\"{u}tzen kann. Welches Protokoll von einem Prozess unterst\"{u}tzt wird, kann der Benutzer anhand von Protokollaktivierungs- und Protokolldeaktivierungsereignissen konfigurieren. Somit besteht die M\"{o}glichkeit, dass ein gegebener Prozess ein bestimmtes Protokoll erst zu einem bestimmten Zeitpunkt unterst\"{u}tzt und gegebenenfalls ein anderes Protokoll abl\"{o}st. Jedes Protokoll kann entweder Server- oder Clientseitig aktiviert beziehungsweise deaktiviert werden. Welche Protokolle es gibt wird sp\"{a}ter behandelt. Der Benutzer hat die Auswahl zwischen f\"{u}nf verschiedenen Protokollereignistypen:
\begin{itemize}
\item Aktivierung des Clients eines gegebenen Protokolls
@@ -210,7 +210,7 @@ Nachdem ein Prozess eine Nachricht empf\"{a}ngt wird zuerst \"{u}berpr\"{u}ft ob
\subsubsection{Callback-Ereignisse (nicht-programmierbar)}
-Ein Callback-Ereignis kann von einem Protokoll ausgel\"{o}st werden. Das Protokoll setzt einen Wecker, der angibt 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, dann kann nach einer bestimmten Zeit eine Anfrage erneut 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 erneut planen. So lassen sich periodisch wiedereintreffende Ereignisse realisieren. Beispielsweise verwenden die ``Commit-Protokolle'' (mehr dazu sp\"{a}ter) Callback-Ereignisse, indem solange Anfragen verschickt werden, bis alle ben\"{o}tigten Antworten vorliegen.
+Ein Callback-Ereignis kann von einem Protokoll ausgel\"{o}st werden. Das Protokoll setzt einen Wecker, der angibt 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, dann kann nach einer bestimmten Zeit eine Anfrage erneut 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 erneut planen. So lassen sich periodisch wieder-eintreffende Ereignisse realisieren. Beispielsweise verwenden die ``Commit-Protokolle'' (mehr dazu sp\"{a}ter) Callback-Ereignisse, indem solange Anfragen verschickt werden, bis alle ben\"{o}tigten Antworten vorliegen.
\subsubsection{Zufallsereignisse (nicht-programmierbar)}
@@ -241,7 +241,7 @@ In diesem Abschnitt wird auf die m\"{o}glichen Konfigurationsm\"{o}glichkeiten g
\label{tb:VariablenDatentypen}
\end{table}
-Der Simulator unterscheid zwischen mehreren Datentypen, in denen die einstellbaren Variablen vorliegen k\"{o}nnen (Tabelle \ref{tb:VariablenDatentypen}). Im folgenden bedeutet (\texttt{Prefix}: \textit{wert}), dass die Variable vom Typ \texttt{Prefix} ist, und standardm\"{a}ssig den Wert \textit{wert} zugewiesen hat. Lediglich die Variablenwerte, jedoch nicht die Variablentypen sowie Variablennamen, lassen sich vom Benutzer \"{a}ndern.
+Der Simulator unterscheidet zwischen mehreren Datentypen, in denen die einstellbaren Variablen vorliegen k\"{o}nnen (Tabelle \ref{tb:VariablenDatentypen}). Im folgenden bedeutet (\texttt{Prefix}: \textit{wert}), dass die Variable vom Typ \texttt{Prefix} ist, und standardm\"{a}ssig den Wert \textit{wert} zugewiesen hat. Lediglich die Variablenwerte, jedoch nicht die Variablentypen sowie Variablennamen, lassen sich vom Benutzer \"{a}ndern.
\subsection{Simulationseinstellungen}
@@ -264,7 +264,7 @@ Im Folgenden werden alle in den Simulationseinstellungen verf\"{u}gbaren Variabl
\item \textbf{Expertenmodus aktivieren} \textit{(Boolean, false)}: Hier l\"{a}sst sich der Expertenmodus auf einen alternativen Weg aktivieren beziehungsweise wieder deaktivieren.
\item \textbf{Simulation periodisch wiederholen} \textit{(Boolean: false)}: Wenn diese Variable auf true gesetzt ist, so wird die Simulation jedes Mal nach Ablauf automatisch erneut gestartet.
\item \textbf{Abspielgeschwindigkeit der Simulation} \textit{(Float: 0.5)}: Gibt den Faktor der Simulationsabspielgeschindigkeit an. Wenn als Faktor 1 gew\"{a}hlt wird, dann dauert eine simulierte Sekunde so lange wie eine Sekunde in echt. Der Faktor 0.5 gibt somit an, dass die Simulation mit halber Echtzeitgschwindigkeit abgespielt wird.
- \item \textbf{Anzahl der Prozesse} \textit{(Integer: 3)}: Gibt an, wieviele Prozesse an der Simulation teilnehmen sollen. Wie schon erw\"{a}hnt kann der Benutzer auch nachtr\"{a}glich via Rechtsklick auf den Prozessbalken den jeweiligen Prozess aus der Simulation entfernen oder weitere Prozesse hinzuf\"{u}gen.
+ \item \textbf{Anzahl der Prozesse} \textit{(Integer: 3)}: Gibt an, wie viele Prozesse an der Simulation teilnehmen sollen. Wie schon erw\"{a}hnt kann der Benutzer auch nachtr\"{a}glich via Rechtsklick auf den Prozessbalken den jeweiligen Prozess aus der Simulation entfernen oder weitere Prozesse hinzuf\"{u}gen.
\item \textbf{Dauer der Simulation} \textit{(Integer: 15)}: Gibt die Dauer der Simulation in Sekunden an.
\end{itemize}
@@ -275,8 +275,8 @@ Die weiteren Einstellungen unter ``Einstellungen f\"{u}r neue Prozesse'' sowie `
Jeder Prozess besitzt folgende Variablen, die entweder via dem Variablen-Tab in der Sidebar oder ``Editieren $\rightarrow$ Prozess \textit{PID}'' oder Linksklick auf den Prozessbalken editiert werden k\"{o}nnen. Das Fenster f\"{u}r die Prozesseinstellungen wird auch als Prozesseditor bezeichnet.
\begin{itemize}
- \item \textbf{Uhrabweichung} \textit{(Float: 0.0)}: Gibt den Faktor $f$ an, um den die lokale Prozessuhr abweicht. Der Faktor 0.0 besagt beispielsweise, dass die Uhr keine Abweichung hat. Ein Faktor von 1 w\"{u}rde hingegen bedeuten, dass die Uhr mit doppelter Geschwindigkeit liefe. F\"{u}r $f$ sind nur Werte $> -1.0$ erlaubt, da sonst die Prozessuhr r\"{u}ckw\"{a}rts laufen k\"{o}nnte. Bei allen anderen Werten wird der Faktor wieder automatisch auf 0.0 gesetzt. Da der Simulator intern mit Fliesskommazahlen doppelter Genauigkeit arbeitet, kann es zu kleinen, jedoch vernachl\"{a}ssigbaren, Rundungsfehlern kommen.
- \item \textbf{Prozessausfallwahrscheinlichkeit} \textit{(Integer: 0)}: Gibt eine Wahrscheinlichkeit in Prozent an, ob der gegebene Prozess w\"{a}hrend der Simulation zuf\"{a}llig abst\"{u}rzt. Die Wahrscheinlichkeit bezieht sich auf die komplette Simulationsdauer. Bei einer Einstellung von 100 Prozent und der Simulationsdauer von 15 Sekunden st\"{u}rzt der Prozess auf jeden Fall zwischen 0ms und 15000ms ab. An welcher Stelle dies geschieht wird zuf\"{a}llig bestimmt. Wenn der Prozess nach seinem Absturz wiederbelebt wird, st\"{u}rzt er nicht nocheinmal zuf\"{a}llig ab. Dies gilt allerdings nicht, wenn die Prozesseinstelungen nach dem Zufallsabsturz erneut ge\"{a}ndert und \"{u}bernommen wurden, da dann das Zufallsabst\"{u}rzereignis erneut erstellt wird.
+ \item \textbf{Uhrabweichung} \textit{(Float: 0.0)}: Gibt den Faktor $f$ an, um den die lokale Prozessuhr abweicht. Der Faktor 0.0 besagt beispielsweise, dass die Uhr keine Abweichung hat. Ein Faktor von 1 w\"{u}rde hingegen bedeuten, dass die Uhr mit doppelter Geschwindigkeit liefe. F\"{u}r $f$ sind nur Werte $> -1.0$ erlaubt, da sonst die Prozessuhr r\"{u}ckw\"{a}rts laufen k\"{o}nnte. Bei allen anderen Werten wird der Faktor wieder automatisch auf 0.0 gesetzt. Da der Simulator intern mit Fliekommazahlen doppelter Genauigkeit arbeitet, kann es zu kleinen, jedoch vernachl\"{a}ssigbaren, Rundungsfehlern kommen.
+ \item \textbf{Prozessausfallwahrscheinlichkeit} \textit{(Integer: 0)}: Gibt eine Wahrscheinlichkeit in Prozent an, ob der gegebene Prozess w\"{a}hrend der Simulation zuf\"{a}llig abst\"{u}rzt. Die Wahrscheinlichkeit bezieht sich auf die komplette Simulationsdauer. Bei einer Einstellung von 100 Prozent und der Simulationsdauer von 15 Sekunden st\"{u}rzt der Prozess auf jeden Fall zwischen 0ms und 15000ms ab. An welcher Stelle dies geschieht wird zuf\"{a}llig bestimmt. Wenn der Prozess nach seinem Absturz wiederbelebt wird, st\"{u}rzt er nicht noch einmal zuf\"{a}llig ab. Dies gilt allerdings nicht, wenn die Prozesseinstellungen nach dem Zufallsabsturz erneut ge\"{a}ndert und \"{u}bernommen wurden, da dann das Zufallsabst\"{u}rzereignis erneut erstellt wird.
\item \textbf{Lokale Zeit} \textit{(Long: 0)}: Gibt die aktuelle lokale Prozesszeit in Millisekunden an. Es empfiehlt sich daher die Simulation, bevor Prozesseinstellungen vorgenommen werden, zu pausieren.
\item \textbf{Nachrichtenverlustwahrscheinlichkeit} \textit{(Integer: 0)}: Gibt eine Wahrscheinlichkeit in Prozent an, ob eine vom aktuell ausgew\"{a}hlten Prozess verschickte Nachricht unterwegs verloren geht. An welcher Stelle die Nachricht zwischen dem Sende- und Empfangsprozess verloren geht wird vom Simulator zuf\"{a}llig gew\"{a}hlt.
\item \textbf{Maximale \"{U}bertragungszeit} \textit{(Long: 2000)}: Gibt die Dauer in Millisekunden an, die eine vom Prozess verschickte Nachricht maximal ben\"{o}tigt, bis sie einen Empf\"{a}ngerprozess erreicht. Im weiteren Verlauf wird dieser Wert mit $t_{max}$ bezeichnet. Der tats\"{a}chlich verwendete Wert wird zuf\"{a}llig zwischen der minimalen- und der maximalen Zeit (jeweils inklusive) gew\"{a}hlt.
@@ -324,7 +324,7 @@ Im selben Fenster lassen sich auch die Protokollvariablen editieren. Die Protoko
\label{tb:Farbeinstellungen}
\end{table}
-Im Expertenmodus lassen sich zus\"{a}tzliche Variablen, wie beispielsweise diverse Farbwerte und Anzahl der Pixel verschiedener der GUI-Elemente, editieren. In Abbildung \ref{fig:SimulationseinstellungenExperten} sieht der Benutzer alle einstellbaren Farben. Die fettgedruckten Schl\"{u}ssel in Tabelle \ref{tb:Farbeinstellungen} dienen nur als Standardwerte f\"{u}r neuzuerstellende Prozesse und sind auch jeweils in den Prozesseinstellungen separat editierbar.
+Im Expertenmodus lassen sich zus\"{a}tzliche Variablen, wie beispielsweise diverse Farbwerte und Anzahl der Pixel verschiedener der GUI-Elemente, editieren. In Abbildung \ref{fig:SimulationseinstellungenExperten} sieht der Benutzer alle einstellbaren Farben. Die fett-gedruckten Schl\"{u}ssel in Tabelle \ref{tb:Farbeinstellungen} dienen nur als Standardwerte f\"{u}r neuzuerstellenen Prozesse und sind auch jeweils in den Prozesseinstellungen separat editierbar.
\section{Protokolle}
@@ -395,7 +395,7 @@ Werden die Ereignisse wie in Tabelle \ref{tb:PingPongSturmTasks} abge\"{a}ndert,
\label{fig:BroadcastSturmProto}
\end{figure}
-Das Broadcast-Sturm Protokoll verh\"{a}lt sich \"{a}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-Sturm Protokoll (Server- und Clientseitig) verschickt alle erhaltenen Nachrichten, sofern sie vom jeweiligen Prozess noch nicht schoneinmal verschickt wurden, erneut. Somit l\"{a}sst sich, unter Verwendung mehrerer Prozesse (hier 6), wie auf Abbildung \ref{fig:BroadcastSturmProto}, ein Broadcast-Sturm erzeugen. P1 ist der Client und startet je eine Anfrage nach 0ms und 2500ms. Die Simulationsdauer betr\"{a}gt hier genau 5000ms. Da Client nur Servernachrichten und Server nur Clientnachrichten empfangen k\"{o}nnen, ist in dieser Simulation jeder Prozess, wie in Tabelle \ref{tb:BroadcastSturmTasks} angegeben, gleichzeitig Server und Client.
+Das Broadcast-Sturm Protokoll verh\"{a}lt sich \"{a}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-Sturm Protokoll (Server- und Clientseitig) verschickt alle erhaltenen Nachrichten, sofern sie vom jeweiligen Prozess noch nicht schon einmal verschickt wurden, erneut. Somit l\"{a}sst sich, unter Verwendung mehrerer Prozesse (hier 6), wie auf Abbildung \ref{fig:BroadcastSturmProto}, ein Broadcast-Sturm erzeugen. P1 ist der Client und startet je eine Anfrage nach 0ms und 2500ms. Die Simulationsdauer betr\"{a}gt hier genau 5000ms. Da Client nur Servernachrichten und Server nur Clientnachrichten empfangen k\"{o}nnen, ist in dieser Simulation jeder Prozess, wie in Tabelle \ref{tb:BroadcastSturmTasks} angegeben, gleichzeitig Server und Client.
\begin{table}
\centering
@@ -425,7 +425,7 @@ Das Broadcast-Sturm Protokoll verh\"{a}lt sich \"{a}hnlich wie das Ping-Pong Pro
\subsection{Das Protokoll zur internen Synchronisierung in einem synchronen System}
-Bisher haben wir uns nur mit Protokollen besch\"{a}ftigt, in denen die beteiligten Prozesse keine Uhrabweichung hatten. Das Protokoll zur internen Synchronisierung ist ein Protokoll zur Synchronisierung der lokalen Prozesszeit, welches beispielsweise angewand weden kann, wenn eine Prozesszeit aufgrund einer Uhrabweichung falsch geht. Wenn der Client seine falsche lokale Zeit $t_c$ mit einem Server synchronisieren m\"{o}chte, so schickt er ihm eine Clientanfrage. Der Server schickt als Antwort seine eigene lokale Prozesszeit $t_s$ zur\"{u}ck, womit der Client seine neue und genauere Prozesszeit berechnen kann. Wie genau die neue Prozesszeit berechnet wird, wird im Folgenden beschrieben.
+Bisher haben wir uns nur mit Protokollen besch\"{a}ftigt, in denen die beteiligten Prozesse keine Uhrabweichung hatten. Das Protokoll zur internen Synchronisierung ist ein Protokoll zur Synchronisierung der lokalen Prozesszeit, welches beispielsweise angewandt werden kann, wenn eine Prozesszeit aufgrund einer Uhrabweichung falsch geht. Wenn der Client seine falsche lokale Zeit $t_c$ mit einem Server synchronisieren m\"{o}chte, so schickt er ihm eine Clientanfrage. Der Server schickt als Antwort seine eigene lokale Prozesszeit $t_s$ zur\"{u}ck, womit der Client seine neue und genauere Prozesszeit berechnen kann. Wie genau die neue Prozesszeit berechnet wird, wird im Folgenden beschrieben.
\begin{table}
\centering
@@ -548,7 +548,7 @@ Wenn der Server seine eigene lokale Zeit $t_s$ und auch die lokalen Prozesszeite
t_s := t_{avg}
\end{equation*}
-Anschliessend berechent der Server f\"{u}r jeden Client einen Korrekturwert $k_i := t_{avg} - t_i$, den er jeweils in einer separaten Nachricht zur\"{u}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 Zeit verstrichen.
+Anschlieend berechnet der Server f\"{u}r jeden Client einen Korrekturwert $k_i := t_{avg} - t_i$, den er jeweils in einer separaten Nachricht zur\"{u}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 Zeit verstrichen.
In den Beispiel in Abbildung \ref{fig:BerkeleyProto} gibt es 2 Clientprozesse P1 und P3 sowie den Serverprozess P2. Der Server startet nach jeweils 0ms und 7500ms eine Synchronisationsanfrage (Tabelle \ref{tb:BerkeleyTasks}). In der Abbildung ist zu erkennen, dass der Server stets 2 Korrekturwerte verschickt, die jeweils P1 und P2 erreichen. Es werden hier also pro Synchronisierungsvorgang 4 Korrekturwerte ausgeliefert. Eine Korrekturnachricht enth\"{a}lt neben dem Korrekturwert $k_i$ auch die PID des Prozesses, f\"{u}r den die Nachricht bestimmt ist. Ein Client verarbeiten so nur die f\"{u}r ihn bestimmten Korrekturwerte, indem das Protokoll die PID vorher \"{u}berpr\"{u}ft.
@@ -584,7 +584,7 @@ Die programmierten Ereignisse des Beispiels in Abbildung \ref{fig:OnePhaseCommit
0000 & 3 & 1-Phasen Commit Client aktivieren\\
0000 & 2 & 1-Phasen Commit Serveranfrage starten\\
1000 & 1 & Prozessabsturz\\
- 5000 & 1 & Prozessweiderbelebung
+ 5000 & 1 & Prozesswiederbelebung
\end{tabular}
}
\caption{Programmierte Ein-Phasen Commit Ereignisse}
@@ -609,7 +609,7 @@ Dieses Protokoll verwendet folgende serverseitige Variablen, die in den Prozesse
\label{fig:TwoPhaseCommitProto}
\end{figure}
-Das Zwei-Phasen Commit Protokoll ist eine Erweiterung des Ein-Phasen Commit Protokolls. Der Server statet zun\"{a}chst eine Anfrage an alle beteiligten Clients, ob festgeschrieben werden soll. Jeder Client antwortet dann mit true oder false. Der Server fragt so oft periodisch nach, bis ein Ergebnis aller Clients vorliegt. Nach Erhalt aller Abstimmungen \"{u}berpr\"{u}ft der Server, ob alle mit true abgestimmt haben. F\"{u}r den Fall dass mindestens ein Client mit false abgestimmt hat, wird der Festschreibevorgang abgebrochen und als globales Abstimmungsergebnis false verschickt. Wenn alle jedoch mit true abstimmten, soll festgeschrieben werden. Dabei wird das globale Abstimmungsergebnis true verschickt. Das globale Abstimmungsergebnis wird periodisch so oft erneut verschickt, bis von jedem Client eine Best\"{a}tigung des Erhalts vorliegt.
+Das Zwei-Phasen Commit Protokoll ist eine Erweiterung des Ein-Phasen Commit Protokolls. Der Server startet zun\"{a}chst eine Anfrage an alle beteiligten Clients, ob festgeschrieben werden soll. Jeder Client antwortet dann mit true oder false. Der Server fragt so oft periodisch nach, bis ein Ergebnis aller Clients vorliegt. Nach Erhalt aller Abstimmungen \"{u}berpr\"{u}ft der Server, ob alle mit true abgestimmt haben. F\"{u}r den Fall dass mindestens ein Client mit false abgestimmt hat, wird der Festschreibevorgang abgebrochen und als globales Abstimmungsergebnis false verschickt. Wenn alle jedoch mit true abstimmten, soll festgeschrieben werden. Dabei wird das globale Abstimmungsergebnis true verschickt. Das globale Abstimmungsergebnis wird periodisch so oft erneut verschickt, bis von jedem Client eine Best\"{a}tigung des Erhalts vorliegt.
\begin{table}
\centering
@@ -760,7 +760,7 @@ Dieses Protokoll verwendet folgende serverseitige Variablen, die in den Prozesse
\begin{itemize}
\item \textbf{Zeit bis erneute Anfrage} \textit{(Long: 2500)}: Gibt die Anzahl von Millisekunden an, die gewartet werden sollen, bis der Festschreibewunsch erneut verschickt wird.
- \item \textbf{PIDs beteiliger Prozesse} \textit{(Integer[]: [1,3])}: Dieser Vektor aus Integerwerten beinhaltet alle PIDs der Clientprozesse, die \"{u}ber eine Festschreibung abstimmen, und anschliessend gegebenenfalls festschreiben sollen.
+ \item \textbf{PIDs beteiliger Prozesse} \textit{(Integer[]: [1,3])}: Dieser Vektor aus Integerwerten beinhaltet alle PIDs der Clientprozesse, die \"{u}ber eine Festschreibung abstimmen, und anschlieend gegebenenfalls festschreiben sollen.
\end{itemize}
Und folgende Clientvariable kann unter den Prozesseinstellungen unter dem Punkt ``2-Phasen Commit Client'' konfiguriert werden:
@@ -990,13 +990,13 @@ Bisher wurden alle verf\"{u}gbaren Protokolle mit jeweils mindestens einem Beisp
\label{fig:Lamportzeit}
\end{figure}
-Die Vektor- und Lamportzeitstempel lassen sich sehr gut am bereits behandelten Beispiel zum Berkeley-Protokoll demonstrieren. Nach Aktivierung der Lamportzeit-Checkbox erscheinen bei jedem Ereignis die zum jeweiligen Prozess geh\"{o}rigen 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 sendenden Prozesses $i$ beigef\"{u}gt. Wenn ein anderer Prozess $j$ diese Nachricht erh\"{a}lt, so wird sein aktueller Lamportzeitstempel $t_l(j)$ wie folgt neuberechnet:
+Die Vektor- und Lamportzeitstempel lassen sich sehr gut am bereits behandelten Beispiel zum Berkeley-Protokoll demonstrieren. Nach Aktivierung der Lamportzeit-Checkbox erscheinen bei jedem Ereignis die zum jeweiligen Prozess geh\"{o}rigen 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 sendenden Prozesses $i$ beigef\"{u}gt. Wenn ein anderer Prozess $j$ diese Nachricht erh\"{a}lt, so wird sein aktueller Lamportzeitstempel $t_l(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\"{o}ssere Lamportzeit vom Sende- und Emfpangsprozess verwendet und anschliessend um 1 inkrementiert. Nach Ablauf der Berkeley-Simulation hat P1 (16), P2 (14) und P3 (15) als Lamportzeitstempel.
+Es wird also stets die gr\"{o}ssere Lamportzeit vom Sende- und Empfangsprozess verwendet und anschlieend um 1 inkrementiert. Nach Ablauf der Berkeley-Simulation hat P1 (16), P2 (14) und P3 (15) als Lamportzeitstempel.
\begin{figure}[htbp]
\centering
diff --git a/LaTeX/chapters/titlepage.tex b/LaTeX/chapters/titlepage.tex
index 04da040..0f2d1f4 100644
--- a/LaTeX/chapters/titlepage.tex
+++ b/LaTeX/chapters/titlepage.tex
@@ -77,8 +77,8 @@ Ohne die Hilfe folgender Personen w\"{a}re die Anfertigung dieser Diplomarbeit i
\item Martin Omann f\"{u}r die Betreuung der Diplomarbeit und der Bereitstellung des f\"{u}r mich sehr interessanten Themas
\item Andre Herbst, f\"{u}r das Testen des Simulators; durch seine Hilfe wurden viele M\"{a}ngel und Bugs aufgedeckt
\item Mein Bruder Florian B\"{u}tow, f\"{u}r Tipps und Tricks rund um Java, f\"{u}r die Bereitstellung eines Buches sowie f\"{u}r das Testen des Simulators
- \item Meine Eltern J\"{o}rn und Leslie B\"{u}tow, die mir das Studium erm\"{o}glichten und stets f\"{u}r alle Dinge ein offenes Ohr hatten sowie f\"{u}r das Sponsoring eines weiteren Buches
- \item Die Open Source Gemeinde; diese Diplomarbeit wurde ausschlilich mithilfe von Open Source Software angefertigt
+ \item Meine Eltern J\"{o}rn und Leslie B\"{u}tow, die mir das Studium erm\"{o}glichten und stets f\"{u}r alle Dinge ein offenes Ohr hatten sowie f\"{u}r das Sponsoren eines weiteren Buches
+ \item Die Open Source Gemeinde; diese Diplomarbeit wurde ausschlielich mithilfe von Open Source Software angefertigt
\end{itemize}
diff --git a/LaTeX/diplomarbeit.pdf b/LaTeX/diplomarbeit.pdf
index 9d89030..3aa6a00 100644
--- a/LaTeX/diplomarbeit.pdf
+++ b/LaTeX/diplomarbeit.pdf
@@ -425,16 +425,15 @@ endobj
/ProcSet [ /PDF /Text /ImageC ]
>> endobj
177 0 obj <<
-/Length 1029
+/Length 1028
/Filter /FlateDecode
>>
stream
-xڍVێ8}H04QFRmtpkD&\ȨN\UGI@<h_B
-,M#o1.ܼ=J=A۔U!~!:/`o
-ٙ 3Co MLIQɵAO^_Mu`dq'0F
-f|`~񮊣w pH냕^;^m/IYc]bIc OHє #qv)V 1F)c2nQa)pj^rx amLLP>GKֵj'a;G(1PdZQy$;Zr蠘Z6GV!{QP%OEͱž7za{cدT3N}2.a?JRoaVGi;۷(S2.̥-]ߜU6jZ8F@ֲ?HcJSW>M1ӆ|K8j!}}7f@NPID{/\k|4DBu6tdMnk !FUo?JPqG7M|l-:ù[U^˞\4Hrz^.9rC\ưkw )Vu"aꢛx,dm]QG(Zw}ɍ6(kTD^IQU6aL}M:5O 5"&"} ^o NɼQ3žIju IM`WzbNzzoko~vd_̔~
-YRWO Xb5'ӈ (>}wV #˂#|>8
-QN$ xx  jendstream
+xڍVێ8}HDZJ>Ia/ȅZUuqّ_Qe Q;܏7r
+ٙc١ 4 e&(1A0E?Eȷ~c˂7tj &M0n*m!H!j4!惋z)^:& zUz XLc )vGL3TmB%88Dg5)]G'@:!^2f#>xyIIdql,Aq!9I(
+Xƚ&NK1mkTFa>}-TQb<]=4U.pM(֛ p3m;G8CN;m:YcȒ70Z^
+ lC9(~t
+B1rumC88K7c{ꅽkGaB$'o>T}vF6~Uf.*}2oF}q]ψ64]5E_ोZ!GZy?1>CS$tڐoG7=ou}5ȊRԙc1^%>Ds>> 'P8f/Zv]1*~1ۏS1|0![+Gt:ù՜^L=C$$HP=/QԜ\rC\ưRlmCE:^E78b)R"=n<kPvڠa^aKFh@WRU$f%yY:Wڄ5aF-fP[y;O$~>e$Ffy>S4"x^L1 a4:&+qv; P]Cw*;etvfzIs ɼSjwW}JšMo彖a?>A9WoЇWG!#}`q|g;c4 㡦xx endstream
endobj
176 0 obj <<
/Type /Page
@@ -1296,20 +1295,17 @@ endobj
/ProcSet [ /PDF /Text ]
>> endobj
355 0 obj <<
-/Length 1711
+/Length 1697
/Filter /FlateDecode
>>
stream
-xڭXݏ6 _GhT_{]vmsQ!svHQrǹpECQI?RyRTAK 8w((a]˝ /үog/y@e\ɣC`:]"B8+SWt}?"bYs>MdC 9KTXfqG{8ܝ-Zs!dXIXE
--\ɚ͎"Q4#֛yšզ.`Y`` \8[\1yxѫ%4j"<Pª8TSXAS}~bh"G؋QR{=Sv!x'4eBhٯG_8JD>)n_h
- :%rgJ+C(k6qܧG܌Hlj[PwEvҴ]/Fk5f`T3`p!PFN
-fNlIALqq z2it g֯kFS֛WXCD;"WfID&:yUzT:~ڏP<Q^kd_Qぱ 1DAҥ" [b拏쳀;o1֖ Da5|%
-ô݂<4 %5syD5(FN+S֦weɱ?]wIKhJMF
-oӗN&I]N/zjdEʂ~uBd&cj8U!suh\tHE}/+6D,lȼR9(KM@4jhϲ-Έ typ$97Ɛyɓ>U*@NIIh8a6Ƴ1l;JpYpNPzwT;U P&'c 40]RŤ/ {a gO6D׮C׺e꺎LB J`8߀F &#q.6
-y 4݊kGⵛnvE]D ?TDuƆn¢ٯ
-4OE\YcyfuK@qyxϣLf<{e9fnjee0e엜*Lfp2T| "20by'{ e
-t9Ģ\[`d/tKXEgHT8\#څ rӗ"Oc,a";㥾̙1
-Y̤դ[gI
+xڭXێ6}WQbFַ\6AHm $yMۄey#v3Re9 bx4gFC(?助L p&I/`<;~y;y&OXYytY<z]~Wt&"l:K$1MMwhϷ&7jHXeǠ֗DqpZ<υZә,dR7Sći8hwNg->ؚ 6ޑPU שH}K.ƛ,]f^w.,]6M-6;9+nG`X.I 0r$<KP8+TYRTᏥQIl9I#t9(
+XCC3;\b)*wRM A&-~=bkڒNg6
+[%@~YJO72c7;r2D#DQG12Vyl7rv^:A1#S$wu?j"E͡",n8K}QqgRPCf_Č&ǃ vFXih2XX*Ij5H`.x?XBό=xr6*EҴjךr׶O̲V|SX?|A_NtQƫ憊I]ucMh|:_[G(%'kd.JHh+%<H$0.4TN檥_yB?Y ǽ1T`I1yNѷh`zG*8i|ڙ);ͦ GY..
+PYV:D*z 8þoZlk vdw۠XV:vB)_
+݈?0u\0siz.T7E<mCϮ҂nZQE<e4ާ
+!y
+qy wX}>"47, o
endobj
354 0 obj <<
/Type /Page
@@ -1394,13 +1390,16 @@ endobj
/Filter /FlateDecode
>>
stream
-xڕX_s6OGy&k7iwvs3wl$:c6
-FloFEzJZ۟]OnR-Ee6H_ۦmÁRyii4l۵ѹ#Ugq:QOi?edZQX#4>a,/ljw5]oua?djp$8 Q(5:w_0Xg@Ke8sh{̒DJe~TF7$ҺyP!Γ/Zi7~g^^уL?(~!FT.2u kBD:ի@~JPLuji4O }eB$̆YxRon{ A|g,ypScpSˀ
-LJ8s݁&Zs8ӉM #0^F)%d'!w:Q,8Aw~ABٓ}Ǩ\mXlaq98֟G OqHˍ 3v6>K| N ~aW<2dY!<Ջ1@T"[,E\$ c.:33sϩc
-j^,(=s鏰6ۡC@хSF,뗁1>a~k,<l2-'<Go [iLq7=l!F` EhSZmPXaQ⛷7,֥y^+hL(%ޟU3o]_^diaDӹy
-!OuYhSgz]uW_Rp?@Orlb6$DDSc6MB Y8Z Pxx?N_rg9x=
-AV>/]0sMgy
-.Ύ ]KBp| {ST ayӆg
+xڕX_o6 OGhtqu[a;0`Dh"vv[?Hrm7h(HZHS<,E^@(شo䢆_Ų K}Z()ʲ:EYt^DJ,Wѭu?xs{?j),ʹA6]mNK3*mJFZWDF=qg"%׿藑_KFaȺ' f;=8tօXラ!0p~rQjv:u_0Xg@Ke8kz̒DJeH*ZCD gi]M`jc7>l_jZvuiw U=T~Fm39r)TcXC"'ű^(Qj3'WKyJ+T$.'6Lszu۫p_^"`>6f '7 qL?YxClv4њNlJf 7VJ)!8L׉b) s ʞ4gtraus?ʹ^T恗;;f̱mstk|U7I^He(T&
+Fh˫Tѱ[
+Z̲?R@>#u$fjk;lvm\u| pѯz=" ԶX˃܁ 6M 񅎣LFxV ۷U3>S1e&6JDtG"{<"3W1z؊no$d6ƇEO'ew|D3tQKFW6"Ɍ e[s9
+Vw
+#^ ȟ4EZ;Zv
+YbHlOIYPZK]|#,oI&<
+*|u8Zi\4dA0s\2r%2$]
+rFoD_AXBzHR/Y,3dx{:fڼa=p?#\{ea#NJEvF8U.2`Xڮ{h<u& .U곇Z8Px\ iz}jߟL42By(SY+WqCĊɳ7hR ˆykpQ
+Dv6,zڐ ؖ~·llb ] =&H;ܛy;0W94N]^S/.,<4c?)ɰHqU͆ {
+MlP p: gdQd}H $("
endobj
364 0 obj <<
/Type /Page
@@ -1633,17 +1632,19 @@ endobj
/ProcSet [ /PDF /Text /ImageC ]
>> endobj
399 0 obj <<
-/Length 1582
+/Length 1581
/Filter /FlateDecode
>>
stream
xڭnF]_G
-07{[ӻvч(P#R1HZ0sp ßb4OC/N
-G͏gi֓*лSPvZ2N|Aȹm-kSuqݠ8%Q$ʁznLfwSDZf]+0cT4~Z7UmjBЕ{cy,>l^ _wN ٙ]SLKG9zQq wDR@@YDd:<p05k&!PvDh1q'Q_-;#j|5ъ
-02BFLFqR)BzI <i!
--XV\@^Y$:כZ2v|T2A҂n)a4 g@q小9&TzE2v B$H󢈏(:q!K1@%K}yơ [ePrO@9DuR4e(S͑BL*q)ReT@5ڣgߓpWLQML^e.:ŜH3)xтS7Ol咹o"|P.RsPf)]Ŗ1TD(eeb=LWlRШT0ys> ZԆŒ*yĄ(:S *gVؒ&V\ƼzUL_Jm
-sӖ]4VPB8E)2Fwv pp}͆sYpk
-R"+:?dłsl&%3`0#}?L6Mh܃L4Ig:yArlendstream
+7{[ӻvч(XS#R1HZ0sp ßb4OC/N
+خ(( "MUP=ve޴T ·uםSjvf?T;) `E^qrm?T:o.2PP-:a2unus8
+n8ZL'lIkK,!hENQM^V{}!#&8b@D}cwy=$`*shdjf, K+.roz\Y$:?7;e!SyʄM gKS/LI,_V>s
+.^VErT9I ]B-Y$x 
+g= j}Q ȷ7Ȼj@7Q,Qpp0o)sP!JF``\
+Tf$0c"iD*d?\1SqzCf \2W\e)_LgfAqh) '6Zr\[7E{i(@Zxh9TX键bx*"2/}(+LѨT0ys> ZԆ%U %Q%u BK9SN%Uά%+M.y3ux.BWmm[-d:of=96ڿ6G3mp bWyhMy
+8Ui6JԠ5r.`H־FvV8rGIb?Xwk!k͡5AJ$<&g:G r9;Y7 <7h8oUo 08XCW<fJh i-q-`i,F( %*'2FG,;8xȾfù^KPZou CX4Y@x
+tzM0-t.Hmp;W rO&@ʭ
endobj
398 0 obj <<
/Type /Page
@@ -2050,19 +2051,23 @@ endobj
/ProcSet [ /PDF /Text /ImageC ]
>> endobj
430 0 obj <<
-/Length 1998
+/Length 1995
/Filter /FlateDecode
>>
stream
xڭYKs6W(D(ޏqI۴i^@Y0ŚRgKiQr2`\,v}S,#N% X0ohw."bH}}{[Fs$ ^ޮ~N/ n쌓BQ:UovEl_?]/V56)D*mgDki@hD8?W_
-~vO6WRNS\}}ȊiE9,[Gk
-Jc;Ft61.Dc5t뇴Zh2C QXH Ie ݳ\t< DYދJ}W~칤̮ho1d+%NjY.<v$(Dq`n &H~4gjVӨ
-GxN ۣ:R aV )wMxZyyQnyGݓk'ҽޯ2_7)İ7f|y ƌѨcl,f'k1w
-Ci9NP"N( QB]6<Ϣ(Ѓ9X|ֿm!-S|Ph.̀YdedB];Vb[r/oc^կ381^}7j=ƐY'ΘclOh[G<'rRF `
-ƃ"`0 YyAw+ꎦ;5LX(ړ;Co tQkJ^v@jT t?̼;F=ɢK){`IhjaJ#U8XCL~b|~<*(QvAtJQbtd9_ez4J )3 &3ej%7QlLO2E^t=[
-VDBhlj&GÓp]ZjL2^e^&ڦQ⁡*K:3gNQAs5I"K:(PNm# ~|Ǎgivɟ_MX0̾$ߗ|'<\Ni]Ϡ~X8Kp8,ݡ
-
-γUYV`4Ȕ;2QCݫ ϏgYc`q P_is4:n`_} UcM)
+~vO6W"q|ӊhsY8HY쏌0=\1vHmtb%\jl/
+1,ͫ.3_
+Q˕,YѼweL̫h68K]/^hM(n ϧms
+uFڽ3deUۧ"#4S5(
+CPϳ(J 'ta/x_p[di$4ߝ=9,ɺ(2gX\rvCb m
+vlb"yw(T>{Iܨ%ZʋvCgqc8cB=m "ʱOL/!.0H^nt!-< yJ+溣qM8 ȩ=Iz:vΠuI(|Fk0ci /9%R(;\(B&3ywFߍi{ܕES8*QPALxpO+.a0T 375 xU(; D:(1Bq2=& } TA2X|țu^ˀ(6'kz"/ڎ-?+sX"HlDfI8.-a]Fyv^/2/VmSTA(hTI%qi
+3d'ss`eh"<3I$zR) =mbu/ø^| uQ?6686k> ٗ2r_p "P6F8aje/46KwG8Ň;ui# c@zǹx&7aDcp-8۠7wmeU}AGto 9&2LP0x#Y!"X+TcZt$ n.Xp~!idX`
+@o_J#g^*\M )>],^vtK[ͦN\o~5 ;46|)l@\Qqk#Y|unbdN݉T}*dZ' a7+:/VD,׭M ˦Ci{H[x5Ml.+r*
+uM%5 ;$XNbvpI<2f~G.nCUn/̶\ -MQe 2d0CWF, u~͋=zNw=99p /9%$&*MyC M'~[[ǽ ;;f\|@4vYWp~QY
+1+6ٰuӲ{
+,
+E7^a'
endobj
429 0 obj <<
/Type /Page
@@ -2117,16 +2122,25 @@ endobj
/ProcSet [ /PDF /Text /ImageC ]
>> endobj
438 0 obj <<
-/Length 1549
+/Length 1551
/Filter /FlateDecode
>>
stream
-xڭ]oF~6 -6"%J
-֊*7`Ș9+,%Q<ќNS+dk +T=gUaѱPۘtqWkD3ôm fDHb]>
-ȶ,P\fetz|Q!_
-\@le6qCw7[#K/ED(܌K!'&2J
-E0QRyDMǼӸ'coNLN`{9\`F|iEQlfwS2eqGp}~r ̈'iT |f_S\T(hl p`Vl0-9
-F]%{+ښMn \ec,pe=}w-ž%==g%!xfg۹"0E!Nu3Q4
+xڭnF>2NۤF 4΁arH.٥(J Ёy)q(OYʋ, v5:>Mq2~wx(L]FR8Z}/6D&ld#e]
+ruWFřh-_fH}j4S3ǻg\:32QĶnmKnYl*15
+Mfose1:cYԭ
+.䧻Ax"nAFgvMl4KE(4@ҫ'V"c xRZ!<q !I%Q
+<ɔNS̉
+§܊yճzOą`"@Ź窄0@vڶ+)gŇmVe7,Eܡ5
+Rs6~  $<컕\u#ad|y)ә
+|(N0έH^DzWPzPm}ܯbR㘽a=_!ⶼ c!նǾN-<0xxG8D|ܘ{JO8{B;yT9K'4y.osߎpAO! Ck2s)$g^?߾hDQh
+fq2ʃ@ΟFyг0ŔW@cP\
+=(?l.v 62s.C %-ї"ed
+7Rs{I ^
+SHpvtQ,ZNzΘSqh̅ka䆉EQnvw]ledK⬩J@Ol jR@ΦdP4>. 7?L wN
+Fm${+MxX65:9GSY/w;O7A{X:\}m /r(P
+~xf=g׹#0E!^u3Q4p
+_HVm+<,::=ue$Bӆ+Ms{Y@c|dl ]yǝo [sLku[-1ZĿմ;MJO,8@s
endobj
437 0 obj <<
/Type /Page
@@ -2174,7 +2188,7 @@ endobj
441 0 obj <<
/Type /Annot
/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [217.1735 738.4065 234.454 750.9357]
+/Rect [216.3544 738.4065 233.6349 750.9357]
/Subtype /Link
/A << /S /GoTo /D (figure.2.8)