Changeset 2374

Timestamp:

11/24/06 14:12:02 (7 years ago)

Author:

stud-matfried

Message:

thesis: Corrected the NF state machine (missing transition).
Added two diagrams showing the test setups used during development.

Location:

natfw-nslp/trunk/thesis

Files:

• Bilder/Test_Setup_1.eps (added)
• Bilder/Test_Setup_2.eps (added)
• Bilder/nf_session.eps (modified) (previous)
• Diagramme/Test_Setup_1.dia (added)
• Diagramme/Test_Setup_2.dia (added)
• Diagramme/nf_session.dia (modified) (previous)
• Gnuplot/nf_vergleich.eps (modified) (previous)
• Gnuplot/nf_vergleich.gpl (modified) (1 diff)
• diplarb.bib (modified) (2 diffs)
• entwurf.tex (modified) (2 diffs)
• eval.tex (modified) (10 diffs)

natfw-nslp/trunk/thesis/Gnuplot/nf_vergleich.gpl

@@ -6 +6 @@
 set boxwidth 0.8
 set grid ytics
-set ylabel "Mittlere Verarbeitungszeit in µs"
+set ylabel "Mittlere Verarbeitungszeit in µs"
 set xtics border nomirror ('CREATE' 1.5, 'RESPONSE' 4.5)
 plot [0:6] [0:60] \

natfw-nslp/trunk/thesis/diplarb.bib

@@ -91 +91 @@
 @techreport{state_machine,
         title           = {NAT/FW NSLP State Machine},
-        editor          = {Constantin Werner and others},
+        editor          = {Constantin Werner},
         institution     = {IETF NSIS Working Group},
         type            = {Working Draft},
@@ -244 +244 @@
   year          = 1996,
 }
+
+
+@article{GISTka,
+  author        = {Thomas Herzog},
+  title         = {Implementierung und Evaluierung des NSIS Transport Layer
+                   Protocols zum Transport von Signalisierungsnachrichten
+                   im Internet},
+  month         = jan,
+  year          = 2006,
+}

natfw-nslp/trunk/thesis/entwurf.tex

@@ -217 +217 @@
 
 Um die Verwaltung der Sitzungen kümmert sich der Session-Manager
-(Klasse \texttt{session\_manager}). Seine Aufgabe ist es, Sessions
-verschiedener Typen abzuspeichern, sie über einen Schlüssel (die
-Session-ID) aufzufinden und auf Anfrage zu löschen. Er dient außerdem
-als Fabrik für neue Sessions, die er basierend auf der Konfiguration
-des lokalen Knotens erzeugt. Der Session-Manager ist ein reiner
-Datenspeicher, der nur auf Anfrage von außen aktiv wird und von mehreren
-Worker-Threads genutzt werden kann. Ein Mutex stellt sicher, dass
-hierbei innerhalb des Session-Managers keine Race Conditions auftreten
-können.
+(eine Instanz der Klasse \texttt{session\_manager}). Seine Aufgabe
+ist es, Sessions verschiedener Typen abzuspeichern, sie über einen
+Schlüssel (die Session-ID) aufzufinden und auf Anfrage zu löschen. Er
+dient außerdem als Fabrik für neue Sessions, die er basierend auf der
+Konfiguration des lokalen Knotens erzeugt. Der Session-Manager ist ein
+reiner Datenspeicher, der nur auf Anfrage von außen aktiv wird und von
+mehreren Worker-Threads genutzt werden kann. Ein Mutex stellt sicher,
+dass hierbei innerhalb des Session-Managers keine Race Conditions
+auftreten können.
 
 Für alle Session-Typen wurde eine gemeinsame abstrakte Oberklasse
@@ -868 +868 @@
 
 Basiskomponente für NATFWka ist Thomas Herzogs prototypische
-GIST-Implemen"-tierung GISTka, die im Rahmen seiner Diplomarbeit entstand.
-Außerdem kommt für das Lesen und Schreiben von Protokollnachrichten die
-am Institut für Telematik entwickelte Bibliothek ProtLib zum Einsatz.
+GIST-Implemen"-tierung GISTka, die im Rahmen seiner Diplomarbeit
+\cite{GISTka} entstand. Außerdem kommt für das Lesen und Schreiben
+von Protokollnachrichten die am Institut für Telematik entwickelte
+Bibliothek ProtLib zum Einsatz.
 
 Beide Softwarepakete mussten zunächst zunächst angepasst werden, bevor

natfw-nslp/trunk/thesis/eval.tex

@@ -7 +7 @@
 
 Bei der vorliegenden prototypischen Implementierung wurde das
-Hauptaugenmerk auf ein übersichtliches Design und leicht lesbaren Code
-gelegt. Eine Optimierung zugunsten des Durchsatzes war nicht explizit
-gefordert, aber trotzdem sollen Messungen durchgeführt werden, um die
-Leistungsfähigkeit der Implementierung einschätzen zu können.
-
-
-%% ==============================
-\section{Die Testsuite}
+Hauptaugenmerk auf ein übersichtliches Design, leicht lesbaren
+Code und eine vollständige Abdeckung der Funktionalität
+des NATFW-Drafts gelegt. Dieses Kapitel beschreibt in
+Abschnitt~\ref{ch:Evaluierung:sub:funktionale_tests} die funktionalen
+funktionalen Tests, die während der Entwicklungseit durchgeführt wurden,
+um ein ordnungsgemäßes Funktionieren des Codes sicherzustellen.
+
+Eine Optimierung zugunsten des Durchsatzes war nicht explizit
+gefordert, aber trotzdem wurden Messungen durchgeführt, um die
+Leistungsfähigkeit der Implementierung grob einschätzen zu können.
+Während der Implementierung standen zu diesem Zweck vier Rechner aus
+dem Router-Testbett des Instituts für Telematik zur Verfügung. Das
+Testbett besteht aus Linux-Rechnern, die mittels eines Switchs zu
+virtuellen Netzen zusammengeschaltet werden können. Der Zugriff auf die
+Rechner erfolgte über SSH; der zu testende Code wurde mit Hilfe von
+\texttt{rsync} auf die einzelnen Knoten verteilt.
+
+Sämtliche Messungen wurden auf Testrechnern mit der folgenden Konfiguration
+durchgeführt:
+
+\begin{itemize}
+  \item Prozessor: Intel Pentium IV HT
+  \item Arbeitsspeicher: 2 GB DDR-400
+  \item Betriebssystem: SuSE Linux 9.3 mit Kernel 2.6.11
+  \item Compiler: g++ 3.3.5 (Teil der GNU Compiler Collection)
+  \item Standardbibliothek: libstdc++ 5
+\end{itemize}
+
+Die Ergebnisse der Messungen werden im zweiten Teil des Kapitels in
+Abschnitt~\ref{ch:Evaluierung:sub:leistungstests} vorgestellt.
+
+
+%% ==============================
+\section{Funktionale Tests}
+%% ==============================
+\label{ch:Evaluierung:sub:funktionale_tests}
+
+% Die Funktionalität der Implementierung 
+
+
+%% ==============================
+\subsection{Die Testsuite}
 %% ==============================
 
@@ -49 +83 @@
 
 %% ==============================
-\section{Das Testnetz}
-%% ==============================
-
-Obwohl die Unit-Tests eine große Hilfe während der Entwicklungszeit waren,
-ist ein echter Netzwerktest dadurch nicht zu ersetzen. Während der
-Implementierung standen zu diesem Zweck vier Rechner aus dem Router-Testbett
-des Instituts für Telematik zur Verfügung. Das Testbett besteht aus
-Linux-Rechnern, die mittels eines Switchs zu virtuellen Netzen
-zusammengeschaltet werden können. Der Zugriff auf die Rechner erfolgte
-über SSH; der zu testende Code wurde mit Hilfe von \texttt{rsync} auf die
-einzelnen Knoten verteilt.
-
-Sämtliche Messungen wurden auf Testrechnern mit der folgenden Konfiguration
-durchgeführt:
-
-\begin{itemize}
-  \item Prozessor: Intel Pentium IV HT
-  \item Arbeitsspeicher: 2 GB DDR-400
-  \item Betriebssystem: SuSE Linux 9.3 mit Kernel 2.6.11
-  \item Compiler: g++ 3.3.5 (Teil der GNU Compiler Collection)
-  \item Standardbibliothek: libstdc++ 5
-\end{itemize}
-
-
-%% ==============================
-\section{Messmethoden}
+\subsection{Das Testnetz}
+%% ==============================
+
+Obwohl die Unit-Tests eine große Hilfe während der Entwicklungszeit
+waren, und ihre häufige Ausführung dabei half, Fehler früh aufzudecken,
+können sie einen echten Netzwerktest nicht ersetzen. Tests auf Systemen
+im Netzwerk sind weniger statisch als Unit-Tests und ermöglichen es,
+unter anderem durch Analyse der Logging-Meldungen, die Implementierung
+und ihr Verhalten in verschiedenen Szenarien zu untersuchen.
+
+Der Schwerpunkt der durchgeführten Tests lag darin, alle Knoten-Typen
+im Zusammenspiel miteinander zu testen.
+
+Die in \ref{GISTka} durchgeführten Tests wurden als funktionierend
+vorausgesetzt.
+
+\begin{figure}[h]
+\begin{center}
+\includegraphics[width=12cm,angle=0]{Bilder/Test_Setup_1}
+\caption{Test Setup 1}
+\label{img:Test_Setup_1}
+\end{center}
+\end{figure}
+
+\begin{figure}[h]
+\begin{center}
+\includegraphics[width=12cm,angle=0]{Bilder/Test_Setup_2}
+\caption{Test Setup 2}
+\label{img:Test_Setup_2}
+\end{center}
+\end{figure}
+
+
+%% ==============================
+\subsection{Interop-Tests}
+%% ==============================
+
+Interop-Tests Mitte Oktober 2006 in Coimbra, Portugal.
+
+
+
+%% ==============================
+\section{Leistungsmessungen}
+%% ==============================
+\label{ch:Evaluierung:sub:leistungstests}
+
+
+%% ==============================
+\subsection{Messmethoden}
 %% ==============================
 \label{ch:Evaluierung:sec:Messmethoden}
@@ -134 +191 @@
 
 %% ==============================
-\section{Leistungsbestimmung des NATFW-Codes}
+\subsection{Leistungsbestimmung des NATFW-Codes}
 %% ==============================
 \label{ch:Evaluierung:sec:NATFW}
@@ -187 +244 @@
 
 %% ==============================
-\subsection{Leistungsbestimmung eines NI-Knotens}
+\subsubsection{Leistungsbestimmung eines NI-Knotens}
 %% ==============================
 
@@ -277 +334 @@
 
 %% ==============================
-\subsection{Leistungsbestimmung eines NF-Knotens}
+\subsubsection{Leistungsbestimmung eines NF-Knotens}
 %% ==============================
 
@@ -447 +504 @@
 \begin{center}
 \includegraphics[angle=0]{Gnuplot/nf_vergleich}
-\caption{Verarbeitung von Nachrichten auf einem NF-Knoten}
+\caption{NF: Verarbeitung von Nachrichten}
 \label{img:nf_vergleich}
 \end{center}
@@ -476 +533 @@
 allozierte.
 
-\begin{figure}[ht]
+\begin{figure}[p]
 \begin{center}
 \includegraphics[angle=0]{Gnuplot/nf_1_session_mgr}
@@ -492 +549 @@
 unter dieser Grenze liegen.
 
-\begin{figure}[ht]
+\begin{figure}[p]
 \begin{center}
 \includegraphics[angle=0]{Gnuplot/nf_3_session_mgr}
@@ -595 +652 @@
 
 %% ==============================
-\subsection{Leistungsbestimmung eines NR-Knotens}
+\subsubsection{Leistungsbestimmung eines NR-Knotens}
 %% ==============================
 
@@ -635 +692 @@
 
 %% ==============================
-\section{Optimierungsmöglichkeiten}
+\subsection{Optimierungsmöglichkeiten}
 %% ==============================
 \label{ch:Evaluierung:sec:optimierung}