From d49b270484f0d1d069e4ad2300a6d99dbe10e0ba Mon Sep 17 00:00:00 2001 From: Paul Buetow Date: Sun, 10 Aug 2008 22:53:18 +0000 Subject: fixes --- LaTeX/chapters/implementierung.tex | 10 +- LaTeX/chapters/introduction.tex | 12 +- LaTeX/chapters/simulator.tex | 47 +- LaTeX/diplomarbeit.pdf | 4462 ++++++++++++++++++------------------ 4 files changed, 2293 insertions(+), 2238 deletions(-) diff --git a/LaTeX/chapters/implementierung.tex b/LaTeX/chapters/implementierung.tex index 8d281ce..ed70dc3 100644 --- a/LaTeX/chapters/implementierung.tex +++ b/LaTeX/chapters/implementierung.tex @@ -137,7 +137,7 @@ In der Implementierung wird zwischen drei Haupttypen von Ereignissen unterschied \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 durchfhren. \begin{itemize} \item \textit{VSAbstractInternalEvent}: Diese Klasse stellt weitere Methoden zur Verfgung, die von allen internen Ereignissen bentigt werden. Derzeit betrifft dies nur Methoden zur Serialisierung der gegebenen Objekte. Auf die Serialisierung (Abspeichern/Laden) von Simulationen wird spter noch genauer eingegangen. - \item \textit{VSMessageReceiveEvent}: Diese Klasse wird fr die Ankunft einer Nachricht bei einem Empfangsprozess bentigt. Sie kapselt die eigentliche Nachricht und berprft, ob der Empfangsprozess das zur Nachricht dazugehrige Protokoll versteht. Diese Klasse berprft auch die Simulationseinstellung ``Nur relevante Nachrichten anzeigen'' und entscheidet, ob die Nachricht nach Eintreffen in der Visualisierung und im Loggfenster bercksichtigt werden soll oder nicht. + \item \textit{VSMessageReceiveEvent}: Diese Klasse wird fr die Ankunft einer Nachricht bei einem Empfngerprozess bentigt. Sie kapselt die eigentliche Nachricht und berprft, ob der Empfngerprozess das zur Nachricht dazugehrige Protokoll versteht. Diese Klasse berprft auch die Simulationseinstellung ``Nur relevante Nachrichten anzeigen'' und entscheidet, ob die Nachricht nach Eintreffen in der Visualisierung und im Loggfenster bercksichtigt 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 verfgbaren Protokolle automatisch alle mglichen Kombinationen und bietet sie dem Anwender in seiner Auswahl an. Fr alle dieser vier Ereignisse wird jeweils ein Objekt von \textit{VSProtocolEvent} verwendet, jedoch mit jeweils anderen Attributwerten. \item \textit{VSProtocolScheduleEvent}: Diese Klasse wird fr die Wecker-Ereignisse bentigt. Wecker-Ereignisse knnen nur von Protokollen (mehr dazu spter) 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} @@ -241,7 +241,7 @@ Die Kapselung eines \textit{VSAbstractEvent}-Objektes in einem \textit{VSTask}-O 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 berprft periodisch, ob es auszufhrende Ereignisse gibt. Der Task-Manager unterscheidet zwischen globalen und lokalen Ereignissen. Hierbei werden alle globalen Ereignisse (gekapselt in einem \textit{VSTask}-Objekt) in einer Prioritts-Warteschlange abgelegt. Die Prioritts-Warteschlange stellt hierbei die korrekte Ereigniseintrittsreihenfolge sicher. Da sich die lokalen Zeiten aller beteiligten Prozesse voneinander unterscheiden knnen, muss fr jeden Prozess eine separate lokale Prioritts-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. Fr jedes Versenden einer Nachricht wird hiervon eine Instanz gebildet, wo der Senderprozess die zu verschickende Daten ablegt. Da \textit{VSMessage} von \textit{VSPrefs} erbt, knnen zwischen zwei Prozessen beliebige Datentypen (Tabelle \ref{tb:VariablenDatentypen}) ber eine Nachricht verschickt werden. Anschlieend wird fr jeden Empfangsprozess 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 dazugehrige Prozessobjekt sowie die Ereigniseintrittszeit als Attribute gespeichert werden. Das \textit{VSTask}-Objekt wird dann dem Task-Manager bergeben, der das dazugehrige Ereignis ausfhrt, wenn die Ereigniseintrittszeit eingetroffen ist. Via Java-Polymorphie wird das \textit{VSMessageReceiveEvent}-Objekt in ein \textit{VSAbstractEvent} umgewandelt. +Eine Instanz von \textit{VSMessage} stellt eine Nachricht dar, die von einem Prozess verschickt wird. Fr jedes Versenden einer Nachricht wird hiervon eine Instanz gebildet, wo der Senderprozess die zu verschickende Daten ablegt. Da \textit{VSMessage} von \textit{VSPrefs} erbt, knnen zwischen zwei Prozessen beliebige Datentypen (Tabelle \ref{tb:VariablenDatentypen}) ber eine Nachricht verschickt werden. Anschlieend wird fr jeden Empfngerprozess 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 dazugehrige Prozessobjekt sowie die Ereigniseintrittszeit als Attribute gespeichert werden. Das \textit{VSTask}-Objekt wird dann dem Task-Manager bergeben, der das dazugehrige Ereignis ausfhrt, wenn die Ereigniseintrittszeit eingetroffen ist. Via Java-Polymorphie wird das \textit{VSMessageReceiveEvent}-Objekt in ein \textit{VSAbstractEvent} umgewandelt. Erwhnenswert ist auch die Klasse \textit{VSMessageStub}, welche ein \textit{VSMessage} kapselt. Ihr Zweck ist das Verstecken einiger Methoden vor dem Protokoll-API, welches fr die Erstellung eigener Protokolle dient. Der Protokoll-Entwickler soll mglichst nichts falsch machen knnen und deswegen soll den Protokoll-API ein eingeschrnkter Funktionsumfang zur Verfgung 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 spter genauer behandelt. @@ -252,7 +252,7 @@ Erw \label{fig:Wrapping} \end{figure} -Der Task-Manager speichert anschlieend in der globalen Warteschlange die Nachrichtenempfangsereignisse. Die Nachricht kommt bei einem Empfangsprozess an, sobald das Ereignis fr den Empfang eintritt. Fr 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 beigefgt. Fr die berprfung des Protokolls wird in jeder Nachricht auch der Klassenname des jeweiligen Protokolls abgespeichert. +Der Task-Manager speichert anschlieend in der globalen Warteschlange die Nachrichtenempfangsereignisse. Die Nachricht kommt bei einem Empfngerprozess an, sobald das Ereignis fr den Empfang eintritt. Fr 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 beigefgt. Fr die berprfung des Protokolls wird in jeder Nachricht auch der Klassenname des jeweiligen Protokolls abgespeichert. Eine Instanz von \textit{VSInternalProcess} reprsentiert einen simulierten Prozess. Ein \textit{VSInternalProcess} stellt alle vom Simulator intern verwendeten Methoden zur Verfgung, whrend ein \textit{VSAbstractProcess} lediglich Methoden hat, die der Protokollentwickler fr die Erstellung eigener Protokolle verwenden darf. Da \textit{VSAbstractProcess} abstrakt ist und hiervon keine Instanz gebildet werden darf, muss fr 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 Verfgung gestellt. Beispielsweise darf mit \textit{getTasks()} nur vom Simulator intern auf die Prioritts-Warteschlangen zugegriffen werden, whrend man im Protokoll-API selbiges vermeiden sollte und auch gar nicht direkt mglich ist. Hierfr htte man auch ein Stub-Objekt \textit{VSProcessStub} implementieren knnen. Da aber so gut wie alle paar Millisekunden auf die Methoden von \textit{VSInternalProcess} zugegriffen wird, wurde hier aus Performancegrnden der Weg ber eine Vererbungungsstufe preferiert. @@ -426,7 +426,7 @@ Wenn die Simulation zur } \end{code} -In \textit{onClientStart} wird geprft, ob eine Clientanfrage gestartet werden soll. Wenn dies der Fall ist (wenn von mindestens einem beteiligten Prozess noch keine Besttigung erhalten wurde), wird ein neues Nachrichtenobjekt erstellt, und mit dem Inhalt \textit{Boolean: isMulticast=true} verschickt (intern wird hier fr jeden Empfangsprozess 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 geprft, ob eine Clientanfrage gestartet werden soll. Wenn dies der Fall ist (wenn von mindestens einem beteiligten Prozess noch keine Besttigung erhalten wurde), wird ein neues Nachrichtenobjekt erstellt, und mit dem Inhalt \textit{Boolean: isMulticast=true} verschickt (intern wird hier fr jeden Empfngerprozess 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): \begin{code} public void onClientStart() { if (pids.size() != 0) { @@ -580,7 +580,7 @@ for (i = s; i < s + v + p && i < e; i++) \item Bei Punkt 2 mit neuer Startzeit $s := s + v + p$ weitermachen. \end{enumerate} -Hinzu kommt noch die Bercksichtigung der Simulationsvariable \textit{sim.clock.speed}, die wegen der bersicht im Algorithmus nicht dargestellt wurde. Intern hat der Simulator die echte Zeit und die Simulationszeit abgespeichert. Es werden stndig die verstrichenen echten Zeiten gemessen und anschlieend anhand von \textit{sim.clock.speed} die neuen tatschlichen Simulationszeiten berechnet. Rundungsfehler werden pro Durchgang in eine \textit{double}-Variable (Fliekommazahl doppelter Genauigkeit) abgespeichert und wenn der Betrag der Rundungsfehler $>= 1$ ist, dann werden davon die ganzen Wertanteile in der Simulationszeit bercksichtigt. +Hinzu kommt noch die Bercksichtigung der Simulationsvariable \textit{sim.clock.speed}, die wegen der bersicht im Algorithmus nicht dargestellt wurde. Intern hat der Simulator die echte Zeit und die Simulationszeit abgespeichert. Es werden stndig die verstrichenen echten Zeiten gemessen und anschlieend anhand von \textit{sim.clock.speed} die neuen tatschlichen Simulationszeiten berechnet. Rundungsfehler werden pro Durchgang in eine \textit{double}-Variable (Fliekommazahl doppelter Genauigkeit) abgespeichert und wenn der Betrag der Rundungsfehler $>= 1$ ist, dann werden davon die ganzen Wertanteile in der Simulationszeit bercksichtigt. F\"{u}r jede lokale Prozesszeit sowie der dazugeh\"{o}rigen lokalen Uhrabweichung und den lokale Ereignisse wird \"{a}hnlich verfahren. Jede Simulation besitzt somit seinen eigenen Simulationsthread. Bei mehreren parallel laufenden Simulationen laufen auch mehrere parallele voneinander unabhngige Threads. Des Weiteren gibt es noch den Java Swing-Thread, der fr die GUI und der Anwenderinteraktion zustndig ist. Der Anwender kann zu jedem Zeitpunkt in die Simulation eingreifen. Anwendereingriffe werden deswegen synchronisiert, da es ansonsten zu zeitgleichen Zugriffen/nderungen gleicher Objekte kommen kann und somit eine Java-Ausnahme geworfen wird die das Stoppen eines Threads verursacht. diff --git a/LaTeX/chapters/introduction.tex b/LaTeX/chapters/introduction.tex index 0ff4fd1..7cc65b3 100644 --- a/LaTeX/chapters/introduction.tex +++ b/LaTeX/chapters/introduction.tex @@ -25,7 +25,7 @@ F \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 knnen auch mehrere Clients und/oder Server mitwirken. +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 knnen auch mehrere Clients und/oder Server mitwirken. \subsubsection{Prozesse und deren Rollen} @@ -39,6 +39,10 @@ In einem verteiltem System m 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 knnen 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 spter genauer eingegangen. + +Neben den normalen Uhren sind auch die Vektor-Zeitstempel sowie die logischen Uhren von Lamport von Interesse. Jeder Prozess besitzt zustzlich einen Vektor-Zeitstempel fr seine Vektorzeit, sowie einen Lamportzeitstempel fr seine Lamportzeit. Fr die Vektor- und Lamportzeiten gibt es hier, im Gegensatz zu der normalen Zeit, keine globalen quivalente. Konkrete Beispiele zu den Lamport- und Vektorzeiten werden spter anhand einer Simulation behandelt. + \begin{figure}[htbp] \centering \includegraphics{images/client-server-protokolle} @@ -46,13 +50,9 @@ In einer Simulation gibt es \textbf{genau eine} globale Uhr. Sie stellt die aktu \label{fig:ClientServerProtokolle} \end{figure} -Zudem besitzt jeder beteiligter Prozess eine eigene lokale Uhr. Sie stellt die aktuelle Zeit des jeweiligen Prozesses dar. Im Gegensatz zu der globalen Uhr knnen 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 spter genauer eingegangen. - -Neben den normalen Uhren sind auch die Vektor-Zeitstempel sowie die logischen Uhren von Lamport von Interesse. Jeder Prozess besitzt zustzlich einen Vektor-Zeitstempel fr seine Vektorzeit, sowie einen Lamportzeitstempel fr seine Lamportzeit. Fr die Vektor- und Lamportzeiten gibt es hier, im Gegensatz zu der normalen Zeit, keine globalen quivalente. Konkrete Beispiele zu den Lamport- und Vektorzeiten werden spter anhand einer Simulation behandelt. - \subsubsection{Ereignisse} -Eine Simulation besteht aus der Hintereinanderausfhrung von endlich vielen Ereignissen. Beispielsweise kann es ein Ereignis geben, welches einen Prozess eine Nachricht verschicken lsst. Denkbar wre auch ein Prozessabsturzereignis. Jedes Ereignis tritt zu einem bestimmten Zeitpunkt ein. Ereignisse mit selber Eintrittszeit werden vom Simulator direkt hintereinander ausgefhrt. Den Anwendern des Simulators hindert dies jedoch nicht, da Ereignisse aus seiner Sicht parallel ausgefhrt werden knnen. +Eine Simulation besteht aus der Hintereinanderausfhrung von endlich vielen Ereignissen. Beispielsweise kann es ein Ereignis geben, welches einen Prozess eine Nachricht verschicken lsst. Denkbar wre auch ein Prozessabsturzereignis. Jedes Ereignis tritt zu einem bestimmten Zeitpunkt ein. Ereignisse mit selber Eintrittszeit werden vom Simulator direkt hintereinander ausgefhrt. Den Anwendern des Simulators hindert dies jedoch nicht, da Ereignisse aus ihrer Sicht parallel ausgefhrt werden. \subsubsection{Protokolle} diff --git a/LaTeX/chapters/simulator.tex b/LaTeX/chapters/simulator.tex index 6a3e162..7dd24f0 100644 --- a/LaTeX/chapters/simulator.tex +++ b/LaTeX/chapters/simulator.tex @@ -138,8 +138,7 @@ F Mit einem Rechtsklick auf den Ereigniseditor lassen sich alle selektierten Ereignisse entweder kopieren oder lschen. Mithilfe der Strg-Taste knnen auch mehrere Ereignisse gleichzeitig markiert werden. Die Eintrge der Spalten fr die Zeit und der PID lassen sich nachtrglich editieren. Somit besteht eine komfortable Mglichkeit 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 bettigt, 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 ausgewhlten Prozesses (Abbildung \ref{fig:NeueSimulationVariablen} links). Dort knnen alle Variablen des Prozesses editiert werden und ist somit eine weitere Mglichkeit einen Prozesseditor aufzurufen. Der Prozesseditor wird spter genauer behandelt. - +In der Sidebar gibt es neben dem Ereignis-Tab einen weiteren Tab ``Variablen''. Hinter diesem Tab verbirgt sich der Prozesseditor des aktuell ausgewhlten Prozesses (Abbildung \ref{fig:NeueSimulationVariablen} links). Dort knnen alle Variablen des Prozesses editiert werden und ist somit eine weitere Mglichkeit einen Prozesseditor aufzurufen. \subsubsection{Das Loggfenster} @@ -150,7 +149,7 @@ In der Sidebar gibt es neben dem Ereignis-Tab einen weiteren Tab ``Variablen''. \label{fig:Loggfenster} \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 aufgefhrt. Letztere werden spter genauer behandelt. Hinter den Zeitangaben werden weitere Angaben, wie beispielsweise welche Nachricht mit welchem Inhalt verschickt wurde und welchem Protokoll sie angehrt, gemacht. Dies wird spter noch anhand von Beispielen demonstriert. +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 aufgefhrt. Hinter den Zeitangaben werden weitere Angaben, wie beispielsweise welche Nachricht mit welchem Inhalt verschickt wurde und welchem Protokoll sie angehrt, gemacht. Dies wird spter noch anhand von Beispielen demonstriert. Mit dem Deaktivieren des Logging-Schalters lt sich das Loggen von Nachrichten temporr ausstellen. Mit deaktiviertem Loggen werden keine neuen Nachrichten mehr ins Loggfenster geschrieben. Nach Reaktivieren des Schalters werden alle ausgelassenen Nachrichten nachtrglich in das Fenster geschrieben. Ein deaktiviertes Loggen kann zu verbessertem Leistungsverhalten des Simulators fhren (z.B. kein Rucklen; ist vom verwendeten Computer, auf dem der Simulator luft, abhngig). Dieser Umstand ist der sehr langsamen Java-Implementierung der JTextArea-Klasse zu verdanken, die schnelle Updates nur sehr trge durchfhrt. @@ -171,7 +170,7 @@ Der Simulator kann in zwei verschiedenen Modi betrieben werden. Es gibt einen ei Der erste Unterschied ist in der Sidebar erkennbar (Abbildung \ref{fig:SidebarExpertenmodus}). Dort sind nun, zustzlich den lokalen Ereignissen, auch globale Ereignisse editierbar. Wie bereits erwhnt sind unter lokale Ereignisse diejenigen Ereignisse zu verstehen, die auftreten, wenn eine bestimmte lokale Zeit des dazugehrigen 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. -Des Weiteren kann der Anwender bei der Programmierung eines neuen Ereignisses direkt die dazugehrige PID selektieren. Im einfachen Modus wurde hier immer standardmig die PID des aktuell (in der obersten Combo-Box) ausgewhlten Prozesses verwendet (hier mit PID 1). In dieser Combo-Box sollte der Anwender gegebenenfalls ``Alle Prozesse'' selektieren, damit im Ereigniseditor stets die Ereignisse aller Prozesse aufgelistet werden. +Des Weiteren kann der Anwender bei der Programmierung eines neuen Ereignisses direkt die dazugehrige PID selektieren. Im einfachen Modus wurde hier immer standardmig die PID des aktuell (in der obersten Combo-Box) ausgewhlten Prozesses verwendet (hier mit PID 1). \subsubsection{Lamportzeit-, Vektorzeit- und Anti-Aliasing Schalter} @@ -220,11 +219,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 fr das Starten einer Anfrage auf einen Client oder einen Server bezieht hngt 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 knnen. +Ob sich das Ereignis fr das Starten einer Anfrage auf einen Client oder einen Server bezieht, hngt 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 knnen. \subsubsection{Nachrichtenempfang sowie Antwortnachrichten (nicht-programmierbar)} -Nachdem ein Prozess eine Nachricht empfngt wird zuerst berprft, ob er das dazugehrige Protokoll untersttzt. Wenn der Prozess das Protokoll untersttzt wird geschaut, ob es sich um eine Client- oder eine Servernachricht handelt. Wenn es sich um eine Clientnachricht handelt, so mu der Empfangsprozess das Protokoll serverseitig untersttzen und virce versa. Wenn alles passt, dann fhrt der Empfangsprozess die vom Protokoll definierten Aktionen aus. In der Regel berechnet der Prozess einen bestimmten Wert und schickt ihn ber eine Antwortnachricht zurck. Es knnen aber auch beliebig andere Aktionen ausgefhrt werden. Welche dies sind hngt vom Protokoll ab. +Nachdem ein Prozess eine Nachricht empfngt wird zuerst berprft, ob er das dazugehrige Protokoll untersttzt. Wenn der Prozess das Protokoll untersttzt wird geschaut, ob es sich um eine Client- oder eine Servernachricht handelt. Wenn es sich um eine Clientnachricht handelt, so mu der Empfngerprozess das Protokoll serverseitig untersttzen und virce versa. Wenn alles passt, dann fhrt der Empfngerprozess die vom Protokoll definierten Aktionen aus. In der Regel berechnet der Prozess einen bestimmten Wert und schickt ihn ber eine Antwortnachricht zurck. Es knnen aber auch beliebig andere Aktionen ausgefhrt werden. Welche dies sind hngt vom Protokoll ab. \subsubsection{Callback-Ereignisse (nicht-programmierbar)} @@ -269,7 +268,7 @@ In diesem Abschnitt wird genauer auf die m \end{figure} -Der Simulator unterscheidet zwischen mehreren Datentypen, in denen die einstellbaren Variablen vorliegen knnen (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 spter) angezeigt. Der Variablenname wird vom Simulator lediglich fr die interne Verwendung bentigt. Im folgenden bedeutet \textit{Typ: varname = wert}, dass die Variable vom Typ \textit{Typ} ist, der interne Variablenname \textit{varname} lautet, und standardmig 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 knnen (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 spter) angezeigt. Der Variablenname wird vom Simulator lediglich fr die interne Verwendung bentigt. Im folgenden bedeutet \textit{Typ: varname = wert}, dass die Variable vom Typ \textit{Typ} ist, der interne Variablenname \textit{varname} lautet, und standardmig den Wert \textit{wert} zugewiesen hat. Vom Anwender lassen sich lediglich die Variablenwerte, jedoch nicht die Variablentypen, Variablennamen und Beschreibungen ndern. \subsection{Simulationseinstellungen} @@ -288,8 +287,8 @@ Im Folgenden werden alle in den Simulationseinstellungen verf \begin{itemize} \item \textbf{Prozesse empfangen eigene Nachrichten} \textit{(Boolean: sim.message.own.recv = false)}: Standardmig knnen Prozesse keine Nachrichten empfangen, die sie selbst verschickt haben. Dies trgt 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 fr das Versenden und Empfangen einer Nachricht an sich selbst betrgt jedoch stets \textit{0ms}. Diese Variable sollte mit Vorsicht verwendet werden, da bedingt durch den \textit{0ms} Endlosschleifen entstehen knnen. - \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 abhngige zufllige Verlustwahrscheinlichkeit. Wenn diese Option aktiviert ist, so wird die der Mittelwert aus den Verlustwahrscheinlichkeiten vom Sender- und Empfangsprozess 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 abhngige zufllige bertragungszeit bis sie ihr Ziel erreicht (siehe Prozesseinstellungen spter). Wenn diese Option aktiviert ist, so wird der Mittelwert vom Sender- und Empfangsprozess 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 abhngige zufllige Verlustwahrscheinlichkeit. Wenn diese Option aktiviert ist, so wird hier der Mittelwert aus den Verlustwahrscheinlichkeiten vom Sender- und Empfngerprozess 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 abhngige zufllige bertragungszeit bis sie ihr Ziel erreicht (siehe Prozesseinstellungen spter). Wenn diese Option aktiviert ist, so wird der Mittelwert vom Sender- und Empfngerprozess 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 dazugehrige Protokoll nicht untersttzt, nicht angezeigt. Dies verbessert die bersicht. \item \textbf{Expertenmodus aktivieren} \textit{(Boolean: sim.mode.expert = false)}: Hier lsst sich der Expertenmodus aktivieren beziehungsweise deaktivieren. Alternativ kann dies ber den gleichnamigen Schalter unterhalb des Loggfensters 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. @@ -312,27 +311,27 @@ Jeder Prozess besitzt folgende Variablen, die entweder via dem Variablen-Tab in \item \textbf{Uhrabweichung} \textit{(Float: process.clock.variance = 0.0)}: Gibt den Wert an, um den die lokale Prozessuhr abweicht. Der Wert \textit{0.0} besagt beispielsweise, dass die Uhr keine Abweichung hat und somit global-korrekt luft. Ein Wert von \textit{1.0} wrde hingegen bedeuten, dass die Uhr mit doppelter Geschwindigkeit- und ein Wert von \textit{-0.5}, dass die lokale Prozessuhr mit halber Geschwindigkeit der globalen Uhr fortschreitet. Es sind nur Werte > \textit{-1.0} erlaubt, da sonst die Prozessuhr rckwrts laufen knnte. Bei allen anderen Werten wird die Einstellung wieder automatisch auf \textit{0.0} gesetzt. Da der Simulator intern mit Fliekommazahlen doppelter Genauigkeit arbeitet, kann es zu kleinen, jedoch vernachlssigbaren, Rundungsfehlern kommen. \item \textbf{Prozessausfallwahrscheinlichkeit} \textit{(Integer: process.prob.crash = 0)}: Gibt eine Wahrscheinlichkeit in Prozent an, ob der gegebene Prozess whrend der Simulation zufllig abstrzt. Die Wahrscheinlichkeit bezieht sich auf die komplette Simulationsdauer. Bei einer Einstellung von \textit{100} Prozent und der Simulationsdauer von \textit{15} Sekunden strzt der Prozess auf jeden Fall zwischen \textit{0ms} und \textit{15000ms} ab. An welcher Stelle dies geschieht wird zufllig bestimmt. Wenn der Prozess nach seinem Absturz wiederbelebt wird, strzt er nicht noch einmal zufllig ab. Dies gilt allerdings nicht, wenn die Prozesseinstellungen nach dem Zufallsabsturz erneut gendert und bernommen werden, da dann das Zufallsabstrzereignis erneut erstellt wird. \item \textbf{Lokale Zeit} \textit{(Long: process.localtime = 0)}: Gibt die lokale Prozesszeit in Millisekunden an. - \item \textbf{Nachrichtenverlustwahrscheinlichkeit} \textit{(Integer: message.prob.crash = 0)}: Gibt eine Wahrscheinlichkeit in Prozent an, ob eine vom aktuell ausgewhlten Prozess verschickte Nachricht unterwegs verloren geht. An welcher Stelle die Nachricht zwischen dem Sende- und Empfangsprozess verloren geht wird vom Simulator zufllig gewhlt. - \item \textbf{Maximale bertragungszeit} \textit{(Long: message.sendingtime.max = 2000)}: Gibt die Dauer in Millisekunden an, die eine vom Prozess verschickte Nachricht maximal bentigt, bis sie einen Empfangsprozess erreicht. Im weiteren Verlauf wird dieser Wert mit $t_{max}$ bezeichnet. - \item \textbf{Minimale bertragungszeit} \textit{(Long: message.sendingtime.min = 500)}: Gibt die Dauer in Millisekunden an, die eine vom Prozess verschickte Nachricht minimal bentigt, bis sie einen Empfangsprozess erreicht. Im weiteren Verlauf wird dieser Wert mit $t_{min}$ bezeichnet. + \item \textbf{Nachrichtenverlustwahrscheinlichkeit} \textit{(Integer: message.prob.crash = 0)}: Gibt eine Wahrscheinlichkeit in Prozent an, ob eine vom aktuell ausgewhlten Prozess verschickte Nachricht unterwegs verloren geht. An welcher Stelle die Nachricht zwischen dem Sende- und Empfngerprozess verloren geht wird vom Simulator zufllig gewhlt. + \item \textbf{Maximale bertragungszeit} \textit{(Long: message.sendingtime.max = 2000)}: Gibt die Dauer in Millisekunden an, die eine vom Prozess verschickte Nachricht maximal bentigt, bis sie einen Empfngerprozess erreicht. Im weiteren Verlauf wird dieser Wert mit $t_{max}$ bezeichnet. + \item \textbf{Minimale bertragungszeit} \textit{(Long: message.sendingtime.min = 500)}: Gibt die Dauer in Millisekunden an, die eine vom Prozess verschickte Nachricht minimal bentigt, bis sie einen Empfngerprozess erreicht. Im weiteren Verlauf wird dieser Wert mit $t_{min}$ bezeichnet. -Wenn die bertragungszeiten von Nachrichten immer exakt die selbe Zeit in Anspruch nehmen sollen, dann mssen alle Prozesseinstellungen mit $t_{min} = t_{max}$ konfiguriert werden. Wenn die aktuelle globale Zeit $t_g$ ist und die Simulationseinstellung ``Mittelwerte der bertragungszeit'' nicht aktiv ist, dann wird die Ereigniseintrittszeit $t_e$ fr den Empfang der Nachricht wie folgt berechnet: +Wenn die bertragungszeiten von Nachrichten immer exakt die selbe Zeit in Anspruch nehmen sollen, dann mssen alle Prozesseinstellungen mit $t_{min} = t_{max}$ konfiguriert werden. Wenn die aktuelle globale Zeit $t_g$ ist und die Simulationseinstellung ``Mittelwerte der bertragungszeiten bilden'' nicht aktiv ist, dann wird die Ereigniseintrittszeit $t_e$ fr den Empfang der Nachricht wie folgt berechnet: \begin{equation*} t_e := t_g + rand(t_{min}, t_{max}) \end{equation*} -Das heit, dass die Nachricht nach einer zuflligen Zeit zwischen $t_{min}$ und $t_{max}$ beim Empfnger eintrifft. Fr jeden Empfnger wird hierbei ein neuer Zufalls-wert gewhlt. Fr den Fall, dass die Einstellung ``Mittelwerte der bertragungszeiten whlen'' aktiviert ist, und wenn $t'_{min}$ und $t'_{max}$ die beim Empfangsprozess eingestellten Werte entsprechen, dann wird die Nachrichtenempfangszeit wie folgt berechnet: +Das heit, dass die Nachricht nach einer zuflligen Zeit zwischen $t_{min}$ und $t_{max}$ beim Empfnger eintrifft. Fr jeden Empfnger wird hierbei ein neuer Zufalls-wert gewhlt. Fr den Fall, dass die Einstellung ``Mittelwerte der bertragungszeiten bilden'' aktiviert ist, und wenn $t'_{min}$ und $t'_{max}$ die beim Empfngerprozess eingestellten Werte entsprechen, dann wird die Nachrichtenempfangszeit wie folgt berechnet: \begin{equation*} t_e := t_g + \frac{1}{2} (rand(t_{min}, t_{max}) + rand(t'_{min}, t'_{max})) \end{equation*} -Das heit, dass stets der Mittelwert der Nachrichtenbertragungszeiten des Sender- und Empfangsprozesses verwendet wird. +Das heit, dass stets der Mittelwert der Nachrichtenbertragungszeiten des Sender- und Empfngerprozesses verwendet wird. \end{itemize} -Im selben Fenster lassen sich auch die Protokollvariablen editieren. Die Protokollvariablen werden jedoch spter bei den Protokollen beschrieben. +Im selben Fenster (im Prozesseditor) lassen sich auch die Protokollvariablen editieren. Die Protokollvariablen werden jedoch spter bei den Protokollen beschrieben. \subsection{Einstellungen im Expertenmodus} @@ -620,7 +619,7 @@ Im Beispiel auf Abbildung \ref{fig:BerkeleyProto} gibt es die 2 Clientprozesse P 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 beteiliger 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 untersttzt. In diesem Fall wrde ewig auf eine fehlende Clientantwort gewartet werden. + \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 untersttzt. In diesem Fall wrde ewig auf eine fehlende Clientantwort gewartet werden. \end{itemize} \newpage @@ -661,7 +660,7 @@ Dieses Protokoll verwendet folgende serverseitige Variablen, die in den Prozesse \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 beteiliger Prozesse} \textit{(Integer[]: pids = [1,3])}: Dieser Vektor aus Integerwerten beinhaltet alle PIDs der Clientprozesse, die festschreiben sollen. + \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 @@ -700,7 +699,7 @@ Dieses Protokoll verwendet folgende serverseitige Variablen, die in den Prozesse \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 beteiliger Prozesse} \textit{(Integer[]: pids = [1,3])}: Dieser Vektor aus Integerwerten beinhaltet alle PIDs der Clientprozesse die ber eine Festschreibung abstimmen und anschlieend gegebenenfalls festschreiben sollen. + \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 anschlieend gegebenenfalls festschreiben sollen. \end{itemize} Und folgende Clientvariable kann unter den Prozesseinstellungen unter dem Punkt ``2-Phasen Commit Client'' konfiguriert werden: @@ -1045,7 +1044,7 @@ Dieses Protokoll verwendet folgende serverseitige Variablen, die in den Prozesse \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 beteiliger Prozesse} \textit{(Integer[]: pids = [1,3])}: Dieser Vektor aus Integerwerten beinhaltet alle PIDs der Serverprozesse, die die Multicast-Nachricht erhalten sollen. + \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 @@ -1068,7 +1067,7 @@ Die Vektor- und Lamportzeitstempel lassen sich sehr gut am bereits behandeltem B t_l(j) := 1 + max(t_l(j), t_l(i)) \end{equation*} -Es wird also stets die grere Lamportzeit vom Sender- und Empfangsprozess verwendet und anschlieend 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. +Es wird also stets die grere Lamportzeit vom Sender- und Empfngerprozess verwendet und anschlieend 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 @@ -1077,7 +1076,7 @@ Es wird also stets die gr \label{fig:Vektorzeit} \end{figure} -Mit aktiven 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 beigefgt. Bei $n$ beteiligten Prozessen hat der Vektor-Zeitstempel $v$ die Gre $n$. Somit gibt es fr 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 Empfangsprozesses $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: +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 beigefgt. Bei $n$ beteiligten Prozessen hat der Vektor-Zeitstempel $v$ die Gre $n$. Somit gibt es fr 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 Empfngerprozesses $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++) { @@ -1089,7 +1088,7 @@ for (i := 0; i < n; i++) { } \end{code} -Standardmig wird der Vektor-Zeitstempel nur inkrementiert, wenn eine Nachricht verschickt- oder erhalten wird. Bei beiden Fllen inkrementiert der Sender- und Empfangsprozess jeweils seinen eigenen Index im Vektor-Zeitstempel mit $v(i) = v(i) + 1$. Beim Empfang einer Nachricht wird anschlieend der lokale Vektor-Zeitstempel mit dem des Senderprozesses verglichen und fr alle Indizes stets der grere Wert in den lokalen Vektor-Zeitstempel bernommen. +Standardmig wird der Vektor-Zeitstempel nur inkrementiert, wenn eine Nachricht verschickt- oder erhalten wird. Bei beiden Fllen inkrementiert der Sender- und Empfngerprozess jeweils seinen eigenen Index im Vektor-Zeitstempel mit $v(i) = v(i) + 1$. Beim Empfang einer Nachricht wird anschlieend der lokale Vektor-Zeitstempel mit dem des Senderprozesses verglichen und fr alle Indizes stets der grere 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. @@ -1116,3 +1115,5 @@ Als Folge (Abbildung \ref{fig:TimeSync2LongTransferProto}) ben \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 satte \textit{20000 - 16557 = 3443ms} falsch geht. diff --git a/LaTeX/diplomarbeit.pdf b/LaTeX/diplomarbeit.pdf index b3e2acc..42a6c51 100644 --- a/LaTeX/diplomarbeit.pdf +++ b/LaTeX/diplomarbeit.pdf @@ -321,7 +321,7 @@ endobj stream xڍUMs6W(͔ͮWvҦZD#.d%`xb$)b:KV #[ܻ@RSŅ[[ܼ|GUbĘhrN2k΄42쳘ؗ pvX79,@n yɈyQ2@Ŵ`dQaձ+y9$Ùfj _/'oqMR \Sokzxb9{k<ũT\P +EpM髮,lyΫ\m4m~\dyr̲i]0u9"+F ι>wyW 7Ve{'} n4~' ,T$Z%UԭoVH!/"4`( %Ҙ给b|UhWEKZ^ gZR@!~r1d*RvXʧhu,L!q5Dk;N(̞+ -ŨF&qeXd˩ʝgZN p.ͩ2):os>0]e{JK|hF"{gj,wy*fxIϫ608J|-_`_K_!sPӱ bk{>>3(~Zuh엗qDh\P@4w1ωuȷgH%Աf`.O{F,s>`ϮbtEEiOԡӀpFu<|9ҊPypΎ|L^K S rt!8c'4(ܳendstream +ŨF&qeXd˩ʝgZN p.ͩ2):os>0]e{JK|hF"{gj,wy*fxIϫ608J|-_`_K_!sPӱ bk{>>3(~Zuh엗qDh\P@4w1ωuȷgH%Աf`.O{F,s>`ϮbtEEiOԡӀpFu<|9ҊPypΎ|L^K S Um1{Nqsܴendstream endobj 214 0 obj << /Type /Page @@ -527,13 +527,9 @@ endobj /Filter /FlateDecode >> stream -xڍUˎ8W1`^%hUY@+D95TWOբ_%93I;}y(qx됧," z1-$y].23Kq2U*2.r޿Veo桘< b!({Ru1$-ν"q4BR&ަ -5&l,P>n-|ZS+Uy(6Ѫ%)>r3[Ib/џmi˸巄 -Y{C1 D\q{oJ6H/ tV+9ԯi 0=m'{[wS?D@endstream +xڍUn8+tF =H`)qR-@ƀ~YAX{=> / *)!ip`z_ʘe;^"K,:ǻ_2H5e{&gip쿄o)glY}=:,ICYe +"/t "'UjM"{kJ1#"-B)U7>,"466U/Q}WՓ-ʒ {kU>?H} a0C ?XY͊vQ~:dJ؄U2rkRnΎy1ێV,+H?ƅZ$Y[%ڀh$ +qPhb`=yEv$m+ŵxG[n˸k~謩, hShՒD`9BO϶e[Ndzo޿"ȸQ7PTڂ\fYT $wN",F%_-'f(@6}qOb@{^Q|=#{&Z=1 uXY~]mL$k%$4Բ ]S1 ꂔlrw( _A!kO#VqJϘYL)`1RXoPf᫧!KoN I{뻗LpjB7U?Fi1z]%'=]ɞrg4b?\G1[nV."qn_պ{ʙ>ԯi5 0+=m'[wS?4@endstream endobj 232 0 obj << /Type /Page @@ -827,21 +823,18 @@ endobj /ProcSet [ /PDF /Text ] >> endobj 287 0 obj << -/Length 2233 +/Length 2232 /Filter /FlateDecode >> stream xK6I2ڹҔ[ 0pZ!- :ubi$uȈ EyS^Ỗmq9ӃPde(|R6$4բPCZ~[jGOχ;"2T݇H58)ojV<Fl]E"*Rc3Pl$ƣ&"y0Z'i AC+qz3ƾLߗw)x -S>)d+Rkf`NoD>֖yNcvl9JWBZ)Ϥ#L*$y TNWy}Z]cy^2$v/ƯzcSvǵH -vQlx'$@pEc8LP0<>߿V"h,v\"0/<1팲Сh*7UfS`8pģUi 27ZpEdM)/.zw%%cR{כ]Md]|#>:'-r$/r}kiL[+oxz*Ɍ}ltg<\i!3>">/4&r4ILiJJxE1w`}ҢrT(`RBV*,T<]u~a[>2\YI,twdlTY5K/;ǣUI@s [QMoer[ڬzEkD8xQ'm~` ~&gVQp'4l^S?=P@wGK -Z׸pE$U.2/ov|=]st,ӎEh`ciT wۖ߭eC0*bPL3Yą@p -VT'!f>gPۊMHdq1U1j#GmWӛZ8_.M=,b\~˭BYR%is -t<:gI0{˧b:m;dc>cE\c{! o'h -udG&vP&AQ\9|PUI&Mv~}pR{U.?Ou2(K|ɐ:RrSxiC*0^;UJCl22 mxݨt }1r2 Ÿiy`8vp2*7WM8S\ru/>۫8fpl 7~%\kͨ:b&vՇDF|; 5n yUUMLXCGendstream +կn^;2I:ڹҔ[ 0pZ!- :ubi$uȈ EyS^Ỗmq9ӃPde(|R6$4բPCZ~[jGOχ;"2T݇H58)ojV<Fl]E"*Rc3Pl$ƣ&"y0Z'i AC+qz3ƾLߗw)x +S1)d+Rkf`NoD>֖yNcvl9JWBZ)Ϥ#L*$y TNWy}Z]cy^2$v/ƯzcSvǵH +vQlx'$@pEc8LP0<>߿V"h,v\"0/<1팲Сh*7UfS`8pģp(<duVfQkܵ?[0ֶ´}Stq\jz,6oG'En|a]o-C<휉rkmOZ<:ǣU$i!3>">/4&r4ILiJJxE1w`}ҢrT(`RBV*,T<]u~a[>2\YI,twdlTY5K/;ǣUI@s [QMoer[ڬzEkD8xQ'm~` ~&gVQ> stream xKoFM:-x)SFt:P! -C#5Z|_(wS~<7X$nw>kH  @&UY䍋ԩ~9ϓ$R,* 摊z&Cn쌪,%HR~ؖko;U5 䥵rPdʸr欳IHsmfv7ZR3޴o17uDx7->8F6Ǒ"B] ]$7jÇ> 5%t5)t쭆ZOCME]5 LECye u@Q LILWp*yCp;KUqՊ&Z+R0 (gtV3iN䂠 f^0 KjP8`etAF~Ae]Xd5|U&6Xmh*lhM M -{79uQ -߳5`Ogpx/HlbL`nI_'lJlR[M6&t@tFlh~olwM5 3_e##,|?6C_,vq4O]>?PkK! %f}{'!J &KOT%s;8 yA87 .šo-IXi<~V3$2pgibo5jx2꒶ ~}"ymCˊnWm wݻNWFq1eR"<^eZd/fBo_l2I)_@)_쭦tzR-p eCsy>)g^| y6tݓ`AphBhJW%.rє!kQ3jhRhE&{~sp!+\af1LYcYchR3ѴбJi7MF]2|(jۉixs@kޏ+ xeCauO)!r)rFtz+ -0CJ'*~om-KL=ϣ+֪JO0Efuendstream +C#5Z|_(wS~<7X$nw>kH  @&UY䍋ԩ~9ϓ$R,* 摊z&Cn쌪,%HR~ؖko;U5 䥵rPdʸr欳IHsmfv7ZR3޴o97uDx7->8F6Ǒ"B] ]$7jÇ> 5%t5)t쭆.Rcn<Բ:Fƨ$W Z+pz8޼ϡeSScxq*ej|)S3VZiL +'|erAPj T3V/>2꒱:v]_jY9Y)geFhlh4V3w +.`S`*  My'{38$a61f&f0/Z6%~@6)&[LME]Dv +L:wB:#O64de;eΦYYnﲑEs +eXySWMy;8.|iDZwV3ILھr=S%%jK*꒹CNzY< z:I0L 8J4!v4vRMhʐ55G4?4X3r߂Ǧ 4pڨ#זyV\ofyN~8RcK7hF N3>&E @&U(OQuf@:Ӛ[eSSw&aB#{Lqc/ˮ&叽Ut2J)I;o埛UH̹Åp!ŜV3g +.g=IDBjwɨKeSVm;@76 ϲ`?T?q-cq%uD=l:L.)%D T|ՈNo%S!4`HDŔ}ﭭeytZ@ZU Bl_fyendstream endobj 375 0 obj << /Type /Page @@ -1413,18 +1407,13 @@ endobj /Filter /FlateDecode >> stream -xYoF)(f1n`$FZAiL:Ɵjr8vP)q43ϳ7,2#Ne `,; t)5Jxq=gVi}Ъ 41%V'/pM .ί-M/Q^\mY|u$sVʊhR弶,k/:.hdZle*ȋD >z3V gy9t4/n;zU܌Z}/AmY}ӘѢ_-cVy֦/~^֟kW! ,}_UR!-iBWǿ$+Fu;ɱQTvZZ -A(5Phf!*gvF5ʗ7tB8d֟?XUu~]˭ װMkc8$YnTΪGPo oDeJ]I4>!LGfg5{1/=4'XDF$tV= 1HO)=!X`Ѻ|݅LED5#ZHXg~LQ&(Alr^e^`ʣ>4֪'q1Կdb D {4i2ȔR#q2[LY[oFwEZK,, 3mzf~d%=bTb D{:hK{&QM>bz}5]{"L ^X$ay -P.VQiTbQJ/élj*͑T7M *u^Dz]/\{ ->ZK¥Y%xc#NnO7<U{%KE,# _gTgCy^\4 ~_G*Qf7ĸvUO%$fb_{FS†{`I a~KvF5l{]347|<<>׷^gfh}{oX,1,L>nyUFz]OrN2!`CbRĢjJjǙlp -U2ɢN`?Et(*mv`۱Q-Nv4< ZC8 -:C =i dA((%jŭ55tߡg$+I䫂/4,řF }寧mVf/f -#huq7k_;^ՑdcAPnc2[kf1L].թS?4C*8gQÙxTκC~hPXI* صV=<廒*vI0=h[ZzQF3QC^# smendstream +xYoF)(f1n`$FZiL:ƟԊC9l;( Ĕ8كPaDR\0\ݝd~:aH 8pwޞ3>hfRyoN[MH$NΧNlȊO~:ctWSu[_?>o# Ub Z$`9ld5O˷k@Kf)";6i-ڪ5"8ad:ӂOLY]N9,l:N^77SVYqg+P&b^4j,gfuV-ӫz +#!S﫵P*%R=^6/yu_9kObX .{+^E`@Rf8nrH +akTAklus!_|`U_Uu.wƃ\V`F~N?4Kr>_dmLޞPٿ}*avJkX TBr*#06<[ /؈X4yakT澸Cs˓-2sub76w6ڎ#NX hǝ|v/X&:J&U?XQ PIB 8QNJF3۴q 6SD'&ajk⤣/Nʼn/NШ009kBv=-8}R"I]#\CxƛXIDJe8sƨW~[Ť0Yu9û2k$4lʆpxX (FDXu4>"aPu7N?Cq)8s՜G?䇶 9PI]c5 X8QޕU ꉽ/jѨc@9~ơ5A :]l"T$L)FsK6PNuER;RJ׼h1ВHƦ&QGlў]xVH<naP4(θ?H# Q͙y,&wI!6Pڮ(:Z~ް;8a{o0Ԏ+֨|f}7' +ܴެ7AtK+J¸NpV':  {/Z؛FX1äakTS,< Ç].+fg !w@-B\!?e&߽Svsna\\r*X =)S=JqKhv`NLg%Tއ h^c3d+~wjmendstream endobj 411 0 obj << /Type /Page @@ -1619,24 +1608,27 @@ endobj /Font << /F26 222 0 R /F28 225 0 R /F63 272 0 R >> /ProcSet [ /PDF /Text ] >> endobj -463 0 obj << -/Length 1854 +462 0 obj << +/Length 1853 /Filter /FlateDecode >> stream -xڭXs6 _GR%۶~\ֵAX$n,YrvA@ Sbydாb^Fp4T:T7d1LޔۙjL<^E cKTvf˛X"XT|gJJ,Tgc3gR\9)n`8$, )bYYE45qTrG92֊'ΛW2SU$ˢEBcNwW" ;nRMؖDf_nlk},U)؍k 1+4qpXŴ.֯mYZM2&\́'cx"n{ƒ,?j'GsuFBOW4HXљw΀ -X6 4)4Bbk6>D\y+5zNuꗉ5@iZnnKmg7m̝aoXL&ܑ"#e{oSDb#dPa}i4 21\$;]"6fIڛ.q${8u - %#.zD.\]W ך~}=Erax]iwxuWo_PU;"M,X|YJĀԡB'l~rX< K/R pX@ƞc; MHS{BwQP1L^ydBPFZBji8q!<1czi +;p>TZS?#aWEgnW,O:*b4dܤe]|+}s`b".28Nj_GA2Z@'%ce2NZkT| 8bT=! q xwԬS[`@(!Ӕp$FAGg=(#MQ kx.nHm횸 3Ȓ;R$"KPFikgs6-):E$F;B (@ˎF E`Co݅*bc,¯j`AIZbAk?"jI‰uKuۖrR1 ~S$="<4_gǖq2q*ĸ+Z;L`Tt43M@n@9Ňܽ+5Mꀵ%U+$Rq, ND K)t"fg= ^-g> N ӯB5]͕7!%*"(3&^Vw+beǼZzs)pxLR*P00;8CCvuRS +Xt@6ᆴ#hAht6 $5뿤`aJzr|m2I|c 5uo %zdC1D6bOS&ٿ6rS)z +ĨɆ<ޝA6x53:y rOy_ bSendstream endobj -462 0 obj << +461 0 obj << /Type /Page -/Contents 463 0 R -/Resources 461 0 R +/Contents 462 0 R +/Resources 460 0 R /MediaBox [0 0 595.2757 841.8898] -/Parent 469 0 R -/Annots [ 466 0 R ] +/Parent 468 0 R +/Annots [ 465 0 R ] >> endobj 459 0 obj << /Type /XObject @@ -1644,16 +1636,16 @@ endobj /FormType 1 /PTEX.FileName (/usr/home/buetow/svn/vs/trunk/LaTeX/images/client-server.pdf) /PTEX.PageNumber 1 -/PTEX.InfoDict 470 0 R +/PTEX.InfoDict 469 0 R /Matrix [1.00000000 0.00000000 0.00000000 1.00000000 0.00000000 0.00000000] /BBox [0.00000000 0.00000000 382.00000000 112.00000000] /Resources << /ProcSet [ /PDF /Text ] /ExtGState << -/R7 471 0 R ->>/Font << /R8 472 0 R >> +/R7 470 0 R +>>/Font << /R8 471 0 R >> >> -/Length 473 0 R +/Length 472 0 R /Filter /FlateDecode >> stream @@ -1661,78 +1653,77 @@ x ªcGTl/.]/=荧Age]i1OexʠpqQ<=:KeCljeXlu aVH;8O-KiD-w2ǃkC8p ]Z뱵@Աb7i {QB{7bw"C|ܥ|<[@_ۼO.~f-g/8撁4<냳( |`ԗtj>RvO%oXBǼ۟u^s |Q?۝ITL0 /?DZendstream endobj -470 0 obj +469 0 obj << /Producer (GPL Ghostscript 8.61) /CreationDate (D:20080810233611Z00'00') /ModDate (D:20080810233611Z00'00') >> endobj -471 0 obj +470 0 obj << /Type /ExtGState /OPM 1 >> endobj -472 0 obj +471 0 obj << /BaseFont /Helvetica /Type /Font /Subtype /Type1 >> endobj -473 0 obj +472 0 obj 460 endobj -466 0 obj << +465 0 obj << /Type /Annot /Border[0 0 0]/H/I/C[1 0 0] /Rect [439.9225 458.2842 454.378 468.8664] /Subtype /Link /A << /S /GoTo /D (figure.1.1) >> >> endobj -464 0 obj << -/D [462 0 R /XYZ 74.4095 793.4011 null] +463 0 obj << +/D [461 0 R /XYZ 74.4095 793.