The log files analysis takes into consideration two open-source implementations of the BitTorrent protocol.
The experiments prior to our research evaluated the performances of several BitTorrent clients that offered a command line interface (CLI), as described in \cite{rdeval}. Based on these results we have chosen \textbf{rasterbar libtorrent},
-which in the comparison proved to be the fastest solution, and \textbf{Tribler}.
+which in the comparison proved to be the fastest solution, and \textbf{Tribler}.\\
+
Libtorrent, developed by Rasterbar \cite{libt2} \cite{libt1}, is a C++ library that implements BitTorrent protocol and
its extensions. It aims to be CPU and memory efficient, easy to use and suitable for many environments and platforms.
Due to its high performance it is used by many BitTorrent applications, like FireTorrent, Deluge, qBitTorrent, SharkTorrent,
-Miro and Hrktorrent \cite{hrk}, the one we chose to work with. Hrktorrent is a lightweight torrent client written in C++ and it was appropriate for our testing infrastructure because it offered a command line interface.
+Miro and Hrktorrent \cite{hrk}, the one we chose to work with. Hrktorrent is a lightweight torrent client written in C++ and it was appropriate for our testing infrastructure because it offered a command line interface.\\
Tribler \cite{tribler}, developed at the Delft University of Technology, is a BitTorrent client written in Python, aimed to enhance the user experience by offering features like online video streaming and content search. Unlike hrktorrent, Tribler is a GUI oriented client, as well providing a command line interface. It also represents a key technology in the P2P-Next project
-because it allows watching BitTorrent-hosted peer-to-peer digital media distribution of video on demand and plays live Tribler streaming media \cite{tribler_wiki}.
+because it allows watching BitTorrent-hosted peer-to-peer digital media distribution of video on demand and plays live Tribler streaming media \cite{tribler_wiki}. \\
%[todo : ce versiuni de libtorrent si hrktorrent folosim?]
When talking about logs, we differentiate between two categories: status logs and verbose logs.
\textbf{Status logs} contain information about current file transfers, like download/upload speed, eta (estimated time of arrival). This information is given by the Tribler's core classes, that deal with connections, download, upload.
-The command line interface mode is implemented by the file \textit{Tools/cmdlined.py}. In its original form, its does not output all the information need for status messages, lacking timestamp, number of peers and eta. It was modified to write the necessary information in a file. Additionally, \textit{Core/APIImplementation/SingleDownload.py} file now writes status information like file path, torrent name at the start-up/end of a file download.
+The command line interface mode is implemented by the file \textit{Tools/cmdlined.py}. In its original form, its does not output all the information need for status messages, lacking timestamp, number of peers and eta. It was modified to write the necessary information in a file. Additionally, \textit{Core/APIImplementation/SingleDownload.py} file now writes status information like file path, torrent name at the start-up/end of a file download.\\
\textbf{Verbose data} consists of information about BitTorrent protocol messages exchanged between peers during transfers. The sources
dealing with protocol implementation are located in the \textit{Core/} directory of the Tribler code, and lack in documentation, comments. After identifying the files that need to be modified several bash scripts were created in order to automate the process of changing them. These scripts are as follows:
Almost all the source files contain the DEBUG flag that is set to True when print statements are enables, false otherwise.
All the prints statements for verbose information output it to stderr, while all status information is written to a status file,
\textit{status\_msg.log}. Unlike libtorrent, which kept separate log files for each peer, Tribler verbose logs are kept
-in one file.
+in one file.\\
The modified Tribler code and the scripts can be found in \cite{repo}.
In order to fill the database's \textit{status\_messages} and \textit{verbose\_messages tables},
the log files need to be parsed. For each BitTorrent client we implemented in Python two parsers for status and
verbose information, which use the database communication methods discussed in section \ref{database} to save
-the parsed data in the database.
+the parsed data in the database.\\
All these scripts receive as arguments a client id corresponding to a row in \textit{clients} table, the log file
-and the database. An instance of DatabaseCommander checks the \textit{client\_id} and an instance of DatabaseWriter based on the \textit{database} argument is used to write the messages information (timestamp, message type etc).
-
+and the database. An instance of DatabaseCommander checks the \textit{client\_id} and an instance of DatabaseWriter based on the \textit{database} argument is used to write the messages information (timestamp, message type etc).\\
The verbose parser searches a given log for the following bit torrent messages taking into consideration
the direction of the message, that indicates if it is received or send from/to a peer. The following table
Commander application start the Server application and then acts as a client requesting the Server to start BitTorrent clients.
This system is described in figure \ref{fig:test-arch}.\\
-
The Commander communicates with the Server using the following types of messages:
\begin{itemize}
\item ERROR - contains $"ERROR <error-message>``$ sent by the server when the parameters received are incorrect or the BT client can not be started.
\end{itemize}
We intend to extend this communication protocol with status messages sent by the Commander to check
-the BT client's progress.
+the BT client's progress.\\
+
+The messages with information stored in data structures are transmited serialized using \textit{pickle} module \cite{pickle}, Python's most common method to serialize/deserialize object data.
\begin{figure}[h]
\begin{center}
-The server application resides on 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{daemon}.
-This server is written in Python, using modules for socket communication and process handling with
-functions similar to the ones from POSIX C.
+
+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 behaviour 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 mantains a list of
+process ids for all the BT Client that it started. \\
+
+In order to start the BitTorrent client the Server needs to create a command string to pass to the function
+that creates a child process. This string contains information about the client and the data received from the
+Commander, and it is obtained using classes that extend \textit{BitTorrentClientRun}, like \textit{TransmissionRun}, \textit{TriblerRun}. These classes build the string by including static data about the client's configuration: path
+arguments' names.
+
+
+
\ No newline at end of file
projects / cs-p2p-next.git / commitdiff