-In our infrastructure the database stores all the parsed logging data. For its implementation we choose sqlite[referinta todo] because it provides an easy and fast way to manage a database: the entire database is stored as a single file. During the experiment all the peers store their status and verbose information in a local sqlite database file. All the files eventually get merged to form our database.
+In our infrastructure the database stores all the parsed logging data. For its implementation we choose sqlite because it provides an easy and fast way to manage a database: the entire database is stored as a single file. During the experiment all the peers store their status and verbose information in a local sqlite database file. All the files eventually get merged to form our database.
-In Figure [todo] we have a detailed look on the database schema. The tables in the database store the following information:
+\begin{figure}[h]
+\begin{center}
+\includegraphics[width = 2.2in, height = 4in]{img/DB.png}
+\end{center}
+\caption{Database Schema for BitTorrent Experiments}
+\label{db}
+\end{figure}
+
+In Figure \ref{db} we have a detailed look on the database schema. The tables in the database store the following information:
\begin{itemize}
\item swarms: information about a BitTorrent session(swarm)
\item btclients: information about the tested the BitTorrent clients
\item verbose\_messages: information about sent/received BitTorrent messages; extracted from verbose log files
\end{itemize}
+
\subsubsection{Database Helper Objects}
Our infrastructure also provides database helper objects to make database operations easier:
\begin{figure}[h]
\begin{center}
-\includegraphics[width = 6.0in, height = 3.5in]{img/general-arch.png}
+\includegraphics[width = 6.0in, height = 6in]{img/general-arch.png}
\end{center}
\caption{Overall Architecture of BitTorrent Performance Evaluation Infrastructure}
-\label{genarh}
+\label{genarch}
\end{figure}
Each virtual machine contains the basic tools for running and compiling BitTorrent clients. The used clients are instrumented which means that they output status and logging information required for subsequent analysis and result interpretation. As the infrastructure aims to be generic among different client implementations, the addition of a new type of BitTorrent client resumes only at adding the required scripts and instrumentation.
The old infrastructure also uses for each virtual machine a set of scripts to enable starting, configuration, stopping and result gathering for BitTorrent clients. A test/command system starts a series of clients automatically through the use of a scripted interface. The command system uses SSH to connect to the virtual machines (SSH is installed and communication is enabled through DNAT/iptables) and command the BitTorrent implementations. The SSH connection uses the virtual machine local scripts to configure and start the clients.
-As we can see the old infrastructure relies heavily on the scripted interface and static configurations. Although this works fairly well it has some major drawbacks: it is very hard to maintain and it doesn't scale well. To resolve this issues we proposed a new approach for the interaction between the command system and the virtual machines.
+As we can see the old infrastructure relies heavily on the scripted interface and static configurations. Although this works fairly well it has some major drawbacks: it is very hard to maintain and it doesn't scale well. To resolve this issues we proposed two solutions:
+\begin{itemize}
+ \item use a client-server architecture for interaction with virtual machines
+ \item use global configuration files
+\end{itemize}
+
+\subsection{Global Configuration files}
+
+All the configurations for the testing infrastructure and the BitTorrent experiment are placed in two files:
+\begin{itemize}
+ \item swarm.xml: contains configuration information relevant to swarm experiment (BitTorrent client, download/upload speed limit, etc.)
+ \item nodes.xml: contains configuration information for the virtual machines (public/private ip, public/private port, etc.)
+\end{itemize}
+
+These files are parsed by the commander at startup.
-\subsection{New approach}
+\subsection{Client-Server interaction}
-The new testing infrastructure is implemented as a client-server architecture, in which the command system starts a server daemon on the virtual machines and then acts as a client making requests to the server daemon.
+The new testing infrastructure uses a client-server type of interaction, in which a commander daemon running on command system sends commands to a server daemon running on the virtual machines.
\subsubsection{Communication protocol}
The Commander communicates with the Server using the following types of messages:
\caption{Client-Server architecture for interaction with BitTorrent clients.}
\label{fig:test-arch}
\end{figure}
-\subsubsection{Commander}\label{sec:comm}
+\subsubsection{Server daemon}\label{sec:server}
+\input{test/server.tex}
+\subsubsection{Commander daemon}\label{sec:comm}
\input{test/comm.tex}
-\subsubsection{Server}\label{sec:server}
-\input{test/server.tex}
\ No newline at end of file
+The commander daemon uses both SSH and sockets for communication and performs several functions:
+\begin{enumerate}
+ \item parses the file that describes the systems involved in the experiment: \textit{nodes.xml} and the file containing swarm information: \textit{swarm.xml}
+\item applies traffic control rules upon hardware nodes using \textit{TrafficControl.py} script. The traffic control rules are applied using SSH commands on the system.
+\item starts the Server daemon using SSH on the described nodes(OpenVZ containers). In order to connect, the commander
+uses the public IP address of the hardware node and the port.
+\item monitors the nodes using the server daemon. It interacts using the messages described in section [to do section protocol]. A special port is assigned to this communication.
+\end{enumerate}
\ No newline at end of file
-The server application resides in a virtual machine on which several BT clients are installed. It
-is started by connecting remotely using ssh, and executes as a daemon process\cite{daemon1}.This server is written in Python, using modules for socket communication and process handling with functions similar to the ones from POSIX C. The daemon behavior is obtained by using an open source implementation that can be found in \cite{daemon2}.\\
+The server daemon resides in a virtual machine on which several BT clients are installed. It is started by connecting remotely using ssh, and executes as a daemon process\cite{daemon1}.This server is written in Python, using modules for socket communication and process handling with functions similar to the ones from POSIX C. The daemon behavior is obtained by using an open source implementation that can be found in \cite{daemon2}.\\
Using sockets, the server listens to connections initiated by the commander on a certain port, and
after the exchange of messages is completed, it closes the connection. It also maintains a list of
projects / cs-p2p-next.git / commitdiff