% ****************************************************************************
% ****************************************************************************
% ****************************************************************************
\appendix
\part*{Anhang}
\addcontentsline{toc}{part}{Anhang}

% ****************************************************************************
\chapter{Architektur des Sindrion-Systems}

% ----------------------------------------------------------------------------
\section{Der Sindrion Application Manager}
\label{sec:Anhang_Architektur_des_AMs}

Im Rahmen der vorliegenden Arbeit wurde eine Software für die Lebenszyklusverwaltung von Proxies für das Sindrion-Projekt -- der \emph{Sindrion Application Manager} -- spezifiziert~\cite{sc03_appman} und implementiert. Die Implementierung erfolgte in Java unter Verwendung der Java Standard Edition~6. Der Grund für die Wahl von Java liegt primär in der Fähigkeit von Java, Klassen zur Laufzeit in die JVM zu laden und dynamisch zu binden. Dies ist eine wichtige Anforderung an die Ausführung von Proxies (siehe Abschnitt \ref{sec:Ausführen_und_Beenden_der_Proxies}). Die Architektur des {\am}s folgt dem \emph{Observer Design Pattern} \cite{ga95_patterns} -- die einzelnen Komponenten des {\am}s kommunizieren über Ereignisnachrichten. Die Architektur des {\am}s ist in Abbildung~\ref{fig:AppMan_Overview} dargestellt. Die einzelnen Komponenten der Architektur werden in den folgenden Abschnitten näher erläutert. Für eine nähere Beschreibung von Abläufen innerhalb des {\am}s sei auf Abschnitt \ref{sec:Anhang_Zustandsautomaten} verwiesen.

\begin{figure}[htbp]
  \hspace{-2cm}
  \includegraphics[width=18.5cm,angle=0]{fig/AppMan_Overview.pdf}
  \setzeBreite
  \caption{Architektur des Sindrion Application Managers.}
  \label{fig:AppMan_Overview}
\end{figure}

\minisec{Discovery Manager}

Aufgabe des Discovery Managers ist es, UPnP-Geräte und speziell Sin\-dri\-on-Geräte in der Netzwerkumgebung zu finden. Im Falle von herkömmlichen UPnP-Geräten wird ein Discovery-Event einfach an den Device Item Manager (s. u.) durchgereicht. Weiterhin wird jedes UPnP-Gerät auf Vorhandensein der Sindrion-Merkmale (siehe Abschnitt \ref{sec:Discovery_limitierter_Geräte}) geprüft. Sofern diese Merkmale vorhanden sind, wird der Device Item Manager entsprechend benachrichtigt. Allgemein ist der Discovery Manager in der Lage, folgende Gerätetypen zu unterscheiden:

\begin{itemize}

\item Herkömmliche UPnP-Geräte

\item Sindrion-Transceiver

\item Sindrion-Proxies

\item Andere Application Manager

\end{itemize}

\minisec{Device Item Manager}

Vom Discovery Manager entdeckte Geräte werden in einem "`Weltmodell"' innerhalb des Device Item Managers abgebildet. Die Abbildung eines realen, \emph{äußeren} Gerätes ist ein \emph{Device Item}. Jedes Device Item hat seinen eigenen Typ, der dem Typ des äußeren Gerätes entspricht. Darüber hinaus enthält jedes Device Item einen Zustandsautomaten, dessen Übergänge durch äußere Events angeregt werden und der in der Lage ist, Kontrollnachrichten an das System abzusetzen. Als Beispiel sei eine Nachricht genannt, die von einem Device Item gesendet wird, um einen Proxy zu starten. Die Zustandsautomaten der Device Items werden in Abschnitt \ref{sec:Anhang_Zustandsautomaten} näher beschrieben.

\minisec{Proxy/SCP Manager}

Events zum Starten bzw. Beenden von Proxies und Specific {\cp}s (SCPs) werden von den jeweiligen Device Items an den Proxy/SCP Manager gesendet. Es ist Aufgabe des Proxy/SCP Managers Proxies bzw. SCPs auszuführen. Die Ausführung erfolgt entweder als Thread oder als Prozess -- also in einer separaten VM. Doch bevor eine Komponente ausgeführt werden kann, muss der entsprechende Code vom Resource Manager bereitgestellt werden.

\minisec{Resource Manager}

Es ist Aufgabe des Resource Managers, den Code für Proxies bzw. SCPs auf Anfrage bereitzustellen. Dies kann aus drei unterschiedlichen Quellen erfolgen:

\begin{enumerate}

\item Aus dem lokalen Repository

\item Aus einem Remote-Repository

\item Direkt vom {\trans}

\end{enumerate}

Im lokalen Repository wird der Code zusammen mit Zeit-, Namens- und Versionsinformationen vorgehalten. Über die Zeitangaben lassen sich die ältesten Komponenten bei Bedarf entfernen, um den Speicherbedarf zu reduzieren.

\minisec{Configurator}

Im Package \emph{Configurator} befinden sich sämtliche GUI-Komponenten, die zum Betrieb bzw. zur Konfiguration des {\am}s erforderlich sind. Abbildung~\ref{fig:Sindrion_GUIs} zeigt als Beispiel den \emph{Sindrion Explorer} sowie das \emph{Sindrion Application Center}.

\minisec{Supplemental}

Das Package \emph{Supplemental} enthält Hilfskomponenten, die für den Betrieb des {\am}s notwendig sind, wie {\zb} eine Konfigurationsverwaltung, Logger oder eine Schnittstelle zum Windows System Tray (siehe Abschnitt \ref{sec:Sindrion_AM}).

% ----------------------------------------------------------------------------
\subsection{Beschreibung der Abläufe in den Zustandsautomaten}
\label{sec:Anhang_Zustandsautomaten}

Abbildungen~\ref{fig:Zustandsdiagramm_AM_Type_Detection} bis \ref{fig:Zustandsdiagramm_FSM_AM} zeigen die Zustandsdiagramme der Automaten, die mit Ausnahme der Gerätetyperkennung im \emph{Device Item Manager} ausgeführt werden. Alle Automaten durchlaufen Zustände, die den Lebenszyklen der jeweils repräsentierten Geräte entsprechen.

\minisec{Discovery und Detektion des Gerätetyps}

Der Zustandsautomat für die Erkennung des Gerätetyps ist im \emph{Discovery Manager} realisiert. Abbildung~\ref{fig:Zustandsdiagramm_AM_Type_Detection} zeigt den entsprechenden Zustandsautomaten. Der Discovery Manager setzt auf den UPnP-Stack auf und empfängt eine Nachricht, sobald ein neues UPnP Device entdeckt wurde. Anschließend prüft er das Device auf Merkmale, die auf den genauen Typ des Gerätes schließen lassen. Handelt es sich um ein UPnP Basic Device und verweist der Eintrag der Presentation Page in der UPnP Description auf die Datei \emph{SindrionTX.html}, so wird das Gerät als Sindrion Transceiver eingestuft. Anschließend wird ein entsprechendes \emph{Device Item} im \emph{Device Item Manager} erzeugt und initialisiert. Für eine Einstufung als Sindrion Application Manager muss die Datei der Presentation Page den Namen \emph{SindrionAM.html} tragen, wobei das Gerät ein vollständiges UPnP Device (also kein Basic Device) sein muss. Ein Sindrion Proxy ist ein vollständiges UPnP Device, dessen Presentation Page den Dateinamen \emph{SindrionProxy.html} hat. Trifft keines dieser Erkennungsmerkmale zu, wird das Gerät als \emph{Plain UPnP Device} eingestuft. Falls bei der Bearbeitung eines Device Items ein Fehler auftritt, kann das Gerät auch nachträglich als Plain UPnP Device eingestuft werden. Hier liegt die Überlegung zu Grunde, dass ein unvollständiges bzw. fehlerhaftes Sindrion UPnP Device nicht mehr als ein herkömmliches UPnP Device ist.

\minisec{Sindrion Transceiver Device Item}

Der Zustandsautomat des \emph{Sindrion Transceiver Device Item} ist in Abbildung~\ref{fig:Zustandsdiagramm_FSM_Transceiver} dargestellt. Es ist Aufgabe des Sindrion Transceiver Device Items, den Transceiver zu repräsentieren und die Ausführung des Proxys zu überwachen. Im ersten Schritt lädt das Sindrion Transceiver Device Item die \emph{Sindrion Description} vom Transceiver herunter. Die entsprechende Adresse wurde zuvor vom Discovery Manager übergeben. Anschließend erfolgt die Auswertung der Sindrion Description. Sofern bei diesen Schritten kein Fehler (fehlende oder korrupte XML-Datei) auftritt, geht der Automat anschließend in den \emph{No Proxy State} über. Dieser repräsentiert den Zustand, dass für den Transceiver noch kein Proxy vorhanden ist. Der Start eines Proxys kann nun entweder auf dem lokalen {\am} oder aber auf einem entfernten {\am} erfolgen. Erfolgt der Start entfernt, so geht der Automat in den Zustand \emph{External Proxy State} über. Der AM bemerkt den Start des entfernten Proxys, da ein UPnP Device mit der UUID des Proxys entdeckt wurde, das nicht vom lokalen AM selbst ausgeführt wird. Wird der Start des Proxys vom lokalen AM selbst initiiert, nimmt der Automat den Zustand \emph{Negotiating Proxy State} ein. In dieser Phase wird der Code des Proxys vom \emph{Proxy/SCP Manager} bezogen und ausgeführt. Sobald der Proxy gestartet ist, nimmt der Automat den Zustand \emph{Local Proxy State} ein.

\minisec{Sindrion Proxy Device Item}

Die linke Seite von Abbildung~\ref{fig:Zustandsdiagramm_FSM_Proxy_and_Plain} illustriert den Ablauf innerhalb des \emph{Sindrion Proxy Device Item}. Der Zustandsautomat durchläuft ebenfalls, wie im obrigen Fall, die Zustände \emph{Downloading Description} und \emph{Parsing Description}. Anschließend geht der Automat über in den Zustand \emph{Proxy Active}.

\minisec{Plain UPnP Device Item}

Der Zustandsautomat des \emph{Plain UPnP Device Item} (Abbildung~\ref{fig:Zustandsdiagramm_FSM_Proxy_and_Plain} rechts) repräsentiert den Lebenszyklus eines herkömmlichen UPnP-Gerätes. Dabei kann es sich auch um ein Gerät handeln, das zuerst als Sindrion-Gerät eingestuft und aufgrund eines Fehlers "`umgestuft"' wurde.

\minisec{Sindrion AM Device Item}

Das \emph{Sindrion AM Device Item} repräsentiert einen entfernten {\am}. Sein Zustandsautomat ist in Abbildung~\ref{fig:Zustandsdiagramm_FSM_AM} dargestellt. Normalerweise befindet sich der Automat im Zustand \emph{Idle}. Zu Beginn oder wenn der Inhalt des Repositorys des entfernten AMs sich geändert hat, spring der Automat in den Zustand \emph{Downloading Catalog State}. Nach erfolgreichem Download wird der Katalog ausgewertet (\emph{Parsing Catalog State}). Nach erfolgreicher Auswertung geht der Automat wieder in den Zustand \emph{Idle} über.

\vspace{1cm}

\begin{figure}[htbp]
  \begin{center}
    \includegraphics[width=12.5cm,angle=0]{fig/diagramme/Zustandsdiagramm_Type_Detection.pdf}
    \setzeBreite
    \caption[Zustandsdiagramm der Gerätetyperkennung.]{Zustandsdiagramm der Gerätetyperkennung des Discovery Managers.}
    \label{fig:Zustandsdiagramm_AM_Type_Detection}
  \end{center}
\end{figure}

\begin{figure}[htbp]
  \begin{center}
    \includegraphics[width=12.5cm,angle=0]{fig/diagramme/Zustandsdiagramm_FSM_Transceiver.pdf}
    \setzeBreite
    \caption{Zustandsdiagramm des \emph{Transceiver Device}.}
    \label{fig:Zustandsdiagramm_FSM_Transceiver}
  \end{center}
\end{figure}

\begin{figure}[htbp]
  \begin{center}
    \includegraphics[width=12.5cm,angle=0]{fig/diagramme/Zustandsdiagramm_FSM_Proxy_and_Plain.pdf}
    \setzeBreite
    \caption{Zustandsdiagramme von \emph{Proxy Device} sowie \emph{Plain \mbox{UPnP} Device}.}
    \label{fig:Zustandsdiagramm_FSM_Proxy_and_Plain}
  \end{center}
\end{figure}

\begin{figure}[htbp]
  \begin{center}
    \includegraphics[width=12.5cm,angle=0]{fig/diagramme/Zustandsdiagramm_FSM_AM.pdf}
    \setzeBreite
    \caption{Zustandsdiagramm des \emph{AM Device}.}
    \label{fig:Zustandsdiagramm_FSM_AM}
  \end{center}
\end{figure}

% ----------------------------------------------------------------------------
\subsection{Beispiel eines Proxy-Lebenszyklus}

Im Folgenden wird beispielhaft der Lebenszyklus eines im Sindrion {\am} ausgeführten Proxys beschrieben.

\begin{enumerate}

\item Der \emph{Discovery Manager} detektiert ein neues Gerät und stellt fest, dass es sich um einen Sindrion-Transceiver handelt.

\item Im \emph{Device Item Manager} wird ein neues Transceiver Device Item erzeugt. Dieses durchläuft den in Abbildung~\ref{fig:Zustandsdiagramm_FSM_Transceiver} dargestellten Zustandsautomaten. Es initiiert die Auswertung der \emph{Sindrion Description}.

\item Entsprechend der Angaben in der Sindrion Description wird der \emph{Resource Manager} beauftragt, den Code für den Proxy zu beziehen. Zuerst überprüft er das lokale Repository. Wir gehen davon aus, dass er den Code dort nicht vorfindet. Nun fragt er die Repositories sämtlicher erkannter {\am} ab, um herauszufinden, ob einer von ihnen den Code vorhält. Ist auch das nicht der Fall, initiiert er den Download direkt vom Transceiver und fügt den Code in sein lokales Repository ein.

\item Der \emph{Proxy/SCP Manager} führt den Proxy als Thread oder als Prozess (separate VM) aus. Der Proxy verbindet sich mit dem Transceiver. Die Präsenz des Proxys wird von den {\am}n im System detektiert. Die entsprechenden Proxy Device Items werden erzeugt und gehen schließlich über in den Zustand \emph{External Proxy} -- das lokale Device Item nimmt hingegen den Zustand \emph{Local Proxy} ein (siehe Abbildung~\ref{fig:Zustandsdiagramm_FSM_Proxy_and_Plain}).

\item Sobald der Sindrion {\trans} die Netzgemeinschaft wieder verlässt und der {\am}, der den Proxy ausführt, eine \emph{Byebye-Message} vom {\trans} empfängt, wird auch der Proxy wieder beendet. Zuvor sendet der Proxy selbst Byebye-Messages, worauf alle entsprechenden \emph{Sindrion Proxy Device Items} aus den {\am}n (lokal und remote) entfernt werden.

\end{enumerate}

% ----------------------------------------------------------------------------
%\subsection{Integration in das OSGi-Framework}
%
%Die Referenzimplementierung des Sindrion {\am} lässt sich als Bundle in ein OSGi-Framework integrieren. Hierzu wird eine Klasse \emph{BundleActivator} verwendet, die Methoden zur Integration in das Framework enthält. Beim Beenden des AM ist es wichtig, dass die einzelnen Komponenten ohne Aufruf von \texttt{System.exit()} beendet werden können, da ein derartiger Aufruf das gesamte OSGi-Framework beendet oder vom System abgefangen wird und damit wirkungslos ist.

% ----------------------------------------------------------------------------
\section{Der Sindrion-Transceiver}
\label{sec:Anhang_Sindrion_Transceiver}

\enlargethispage{.5cm}

Der Prototyp des Sindrion-Transceivers basiert auf einem PCB\footnote{Printed Circuit Board} mit herkömmlichen Bauteilen \cite{ba06_sindrion}. Der RF-Part basiert auf einem ISM-Band-Transceiver (433 MHz - 915 MHz), der eine Bruttodatenrate von 50 kbit/s bereit stellt. Kern des Transceivers ist ein 16-Bit Mikrocontroller, der mit 9 MHz betrieben wird. Der Programmspeicher ist 64 kB groß, während 16 kB Arbeitsspeicher zur Verfügung stehen. Die durchschnittliche Leistungsaufnahme liegt bei weniger als 1 mW. Wie in Abbildung \ref{fig:Transceiver_Power_Domains} dargestellt, besitzt der Sindrion {\trans} drei \emph{Power Domains}: Im Standby ist lediglich das \emph{RF Front End} (Domain~1) aktiv. Sobald Funksignale empfangen werden, wird der MAC-Layer (Domain~2) aktiviert und versucht, aus den empfangenen Signalen gültige Daten-Frames zu ermitteln. Sobald dies gelingt, wird die eigentliche Service Application und die Unterstützung für das Sindrion Control Protokoll (Domain~3) aktiviert.

\begin{figure}[htbp]
  \begin{center}
    \includegraphics[width=15cm,angle=0]{fig/Transceiver-Powerdomains.png}
    \setzeBreite
    \caption[Power Domains des Sindrion Transceivers.]{Power Domains des Sindrion Transceivers. {\tiny(Quelle: Infineon)}}
    \label{fig:Transceiver_Power_Domains}
  \end{center}
\end{figure}

% ****************************************************************************
\chapter{Beispiele von UPnP und Sindrion Descriptions}
\label{sec:Anhang_Description_Beispiele}

Die XML-basierten UPnP Device und Service Descriptions dienen der Beschreibung der Eigenschaften und Schnittstellen von UPnP Devices \cite{upnp_spec}. Die Dateien werden vom eingebetteten Webserver der UPnP-Geräte zum Download bereit gestellt und von UPnP Control Points bezogen und ausgewertet. Device und Service Descriptions werden in separaten Dateien bereitgestellt, damit ein Control Point gezielt die Service Descriptions beziehen kann, die er benötigt.

Die Sindrion Description ist in Anlehnung an die UPnP Descriptions entstanden. Sie wird vom Sindrion Transceiver bereit gestellt und gibt Auskunft über die Bezugsmöglichkeiten des Sindrion Proxys und des SCPs \cite{st03_sindrion}.

% ----------------------------------------------------------------------------
\section{UPnP Device Description}

Listing \ref{lst:Beispiel_Device_Description} zeigt die Device Description eines \emph{DimmableLight}. Die Zeilen 2~-~6 erklären, dass es sich um eine standardisierte Device Description handelt, die in der Version 1.0 vorliegt. Die Angabe des Geräte-Typs steht in Zeile 8. Neben allgemeinen Geräteinformationen (Zeilen 9 - 16) und Angaben über bereitgestellte Icon-Dateien zur Anzeige im Control Point (Zeilen 18 - 26), enthält Zeile 17 die UUID des Devices. Die Zeilen 27~-~42 enthalten eine Liste der bereitgestellten Services des Gerätes. Neben einer Angabe des standardisierten Service-Typs ({\zb} \emph{DimmingService}, Zeile 36) wird auf die zugehörige Service Description (Zeile~38) verwiesen.

\lstinputlisting[basicstyle=\footnotesize, breaklines=true, breakatwhitespace=false, caption=Beispiel einer UPnP Device Description., label=lst:Beispiel_Device_Description]{fig/listings/UPnP_Device_Description.xml}

% ----------------------------------------------------------------------------
\section{UPnP Service Description}

Die Service Description des \emph{DimmingService} (Listing \ref{lst:Beispiel_Service_Description}) gibt Auskunft über die von dem Service bereitgestellten Actions. Die Action \emph{GetLoadLevelTarget} {\zb} ist in den Zeilen 18 - 27 beschrieben. Die Action hat als Rückgabewert den aktuellen Lichtwert des \emph{DimmableLight} (siehe Zeilen 22, 23) und verweist auf die zugehörige Zustandsvariable \emph{LoadLevelTarget}, die in den Zeilen 40 - 48 durch ihren Datentyp, ihren Default-Wert und ihren zulässigen Wertebereich beschrieben ist.

\lstinputlisting[basicstyle=\footnotesize, breaklines=true, breakatwhitespace=false, caption=Beispiel einer UPnP Service Description., label=lst:Beispiel_Service_Description]{fig/listings/UPnP_Service_Description.xml}

% ----------------------------------------------------------------------------
\section{Sindrion Description}

Listing \ref{lst:Beispiel_Sindrion_Description} zeigt die Sindrion Description eines Transceivers, der als Thermometer arbeitet. Die Datei enthält Angaben zum Sindrion Proxy (Zeilen 8~-~17), zum Specific Control Point (Zeilen 18~-~25), sowie zu dem ebenfalls vom Transceiver bereit gestellten Java Applet {Zeilen 26~-~33}. Innerhalb eines Bereichs wird auf die Dateien verwiesen, aus denen sich die jeweilige Komponente zusammen setzt. Dabei ist es durchaus möglich, dass mehrere Komponenten die selben Dateien verwenden. Zum Beispiel die Datei \emph{JAR001}, die sowohl vom Proxy (Zeile 11), als auch vom SCP (Zeile 20) verwendet wird, da es sich um die Kernkomponente des UPnP-Stacks handelt, wie in den Zeilen 36~-~43 zu sehen ist. Dort wird neben Angabe der Haupt- und Nebenversionsnummer der Komponente (Zeilen 39~-~42) auf den Dateinamen verwiesen, über den die Datei vom Transceiver bezogen werden kann (Zeile~38).

\lstinputlisting[basicstyle=\footnotesize, breaklines=true, breakatwhitespace=false, caption=Beispiel einer Sindrion Description., label=lst:Beispiel_Sindrion_Description]{fig/listings/Sindrion_Description.xml}

% ****************************************************************************
\chapter{{\rr}-Protokoll "`Manetho"'}
\label{sec:Recovery-Protokoll_Manetho}

\sidenote{Recovery-Vorgang} Listing \ref{lst:Manethoalgorithmus} zeigt beispielhaft die Prozeduren eines aus der Arbeit von Elnozahy et al. \cite{el92_manetho} entnommenen Recovery-Algorithmus für das Manetho-Protokoll. Zu Beginn des Recovery-Vorgangs stellt eine RU ihren letzten durch einen Checkpoint gesicherten Zustand mit Hilfe des {\stst} wieder her. Anschließend ruft sie die lokale Prozedur \texttt{RECOVER} auf. Parameter dieser Prozedur sind die Kennung der RU $p$, der Index des aktuellen (wiederhergestellten) Zustandsintervalls $c$, die aktuelle Inkarnationsnummer $INCNUM$, sowie die Menge aller im System befindlichen RUs $S$. Bei Aufruf der Prozedur legt die RU zuerst die Inkarnationsnummer $INCNUM$ auf dem {\stst} ab. Anschließend wird ein neuer Graph $G$ erzeugt, der dem Antezedenzgraphen $AG{\sigma_{p,c}}$ entspricht, der bei Wiederherstellung des Checkpoints vom {\stst} bezogen wurde.

Nun ruft die RU $p$ die Prozedur \texttt{GET\_RU} auf jeder \emph{anderen} RU im System auf. Bei Aufruf auf einer RU $q$ legt \texttt{GET\_AG} zuerst den aktuellen $AG$ auf dem {\stst} ab. Nun bestimmt $q$ das \emph{jüngste} Zustandsintervall $k$ der RU $p$, $\sigma_{p,k}$, das sich im Antezedenzgraphen $AG$ von $q$ befindet. Anschießend wird $k$ dem Vektor $REJECTVEC$ hinzugefügt. Solange die Prozedur \texttt{SEND\_INC} nicht aufgerufen wird, verweigert $q$ jede Nachricht von anderen RUs deren beigefügter $AG$ den Knoten eines Zustandsintervalls $\sigma_{p,i}$ enthält mit $i > k$. Am Ende der Prozedur \texttt{GET\_AG} liefert $q$ den Wert $AG(\sigma_{p,k})$ zurück. Kehrt \texttt{GET\_AG} nach Aufruf aus \texttt{RECOVER} zurück, fügt $p$ den zurückgelieferten Graphen $AG$ in seinen Arbeitsgraphen $G$ ein. Weiterhin wird die Inkarnationummer von $q$ zu dem Vektor $INCVEC$ hinzugefügt.

Nun ruft $p$ auf allen anderen RUs die Prozedur \texttt{SEND\_INC} auf mit den Argumenten $p$ und $INCVEC$. Auf der RU $q$ aktualisiert \texttt{SEND\_INC} den lokalen Vektor $INCVEC$ und hebt die {\og} Beschränkungen bzgl. des Nachrichtenempfangs auf. Zuletzt stellt $p$ den Zustand direkt vor dem Ausfall $\sigma_{p,m}$ her. Dabei bezieht $p$ Nachrichten von den Message-Logs der jeweiligen Sender und führt interne Events bei Bedarf erneut aus. RU $p$ sendet keinerlei Nachrichten in die Außenwelt oder an andere RUs. Allerdings legt es die Nachrichten, die es gesendet \emph{hätte} in seinem flüchtigen Message-Log ab.

\newpage

\lstinputlisting[basicstyle=\footnotesize, caption=Recoveryalgorithmus für das Manetho-Protokoll., mathescape, keywords={procedure, save, for, all, do, remote, call, max, while, if, then, else, return}, keywordstyle=\color{black}\bfseries\underbar, label=lst:Manethoalgorithmus]{fig/listings/Manethoalgorithmus}
