From 0692e6d487fc5ba4068a62525a592d693a0d2051 Mon Sep 17 00:00:00 2001 From: Adriana Draghici Date: Thu, 11 Feb 2010 16:00:47 +0200 Subject: [PATCH] report - parser --- report/logarch/parser.tex | 75 +++++++++++++++++++++++++++++++-------- 1 file changed, 60 insertions(+), 15 deletions(-) diff --git a/report/logarch/parser.tex b/report/logarch/parser.tex index 110b6a9..91e5124 100644 --- a/report/logarch/parser.tex +++ b/report/logarch/parser.tex @@ -8,9 +8,47 @@ All these scripts receive as arguments a client id corresponding to a row in \te 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 +compares the type of messages output by the clients. Libtorrent log parser has support for parsing messages +for both directions, because of the format used to display this information. Tribler prints these messages +from several files, using different formats, and in our research of its code we could not find output in both directions +for all the message types. +\\ + +\begin{tabular}{|l|c|r|} + \hline + \textbf{BT Message} & \textbf{Tribler} & \textbf{Libtorrent} \\ + \hline +BT\_REQUEST & both directions & both directions\\ +\hline +BT\_CHOKE &receive & both directions\\ +\hline +BT\_UNCHOKE & receive & both directions\\ +\hline +BT\_HAVE & receive & both directions\\ +\hline +BT\_PIECE & receive & both directions\\ +\hline +BT\_BITFIELD & receive & both directions\\ +\hline +BT\_CANCEL & send & none\\ +\hline +BT\_INTERESTED & receive & both directions\\ +\hline +BT\_NOT\_INTERESTED & none & both directions\\ +\hline +BT\_DHT\_PORT & none & both directions\\ +\hline +\end{tabular} \label{Table1} + + + \subsubsection {Tribler logs parsing} -[TODO] +Both parsers analyze line by line the log files and check for certain formats. When a line corresponds +to a message, it is split and its parts are checked and together with the client id are given as arguments to the functions from DatabaseWriter that add status/verbose messages. + Example of a status line (shown here split into two lines): \begin{verbatim} 03-Nov-2009 12:18:55 aqua.mpeg DLSTATUS_DOWNLOADING 29.84% @@ -18,19 +56,7 @@ Example of a status line (shown here split into two lines): \end{verbatim} -The verbose parser searches a given log for the following bit torrent messages taking into consideration -the direction of the message, that indicated if it is received or send from/to a peer: - \begin{itemize} - \item BT\_REQUEST - both directions - \item BT\_CHOKE - receive direction - \item BT\_UNCHOKE - receive direction - \item BT\_HAVE - receive direction - \item BT\_PIECE - receive direction - \item BT\_BITFIELD - receive direction - \item BT\_CANCEL - send direction - \item BT\_INTERESTED -receive direction - \end{itemize} - + Examples of protocol message lines: \begin{verbatim} 20-10-2009 12:56:39 Downloader: new_request 52 98304 16384 to 141.85.37.41 14398 @@ -44,4 +70,23 @@ large sizes of hundreds of MB, even a few GB. Therefore parsing such files deman on our test files, getting to 20-30 minutes for logs of approximately 300MB on dual core 2GHz processors, 2G RAM. - +\subsubsection {Libtorrent logs parsing} +The parsers have a similar structure to those for Tribler, differing in the way the message lines are analysed. + +Example of a status line : +\begin {verbatim} + ps: 1, dht: 8 <> dl: 119.51kb/s, ul: 3.63kb/s <> dld: 1mb, uld: 0mb, size: 698mb <> eta: 1h 39m 37s +\end{verbatim} + +Samples of protocol message lines: +\begin {verbatim} +Jan 08 22:39:50 <== REQUEST [ piece: 6cc | s: 14000 | l: 4000 ] +Jan 08 22:39:50 ==> PIECE [ piece: 5c6 | s: 24000 | l: 4000 ] +\end{verbatim} + +In libtorrent the messages are output a lot clearer than in tribler, also there are separate log files for each peer. +The $==>$ and $<==$ strings indicate the direction of the message: received or sent. + + + + -- 2.20.1