-Nowadays all the peer to peer protocols run in user space. One of the
-most important delay appear when file transfers occurs. For every open,
-read or write operation which is made on a file or a socket, a
-system call is made. This generate a context switch, which waste a
-lot of time, mainly because of the translation lookaside
-buffer(TLB) flush.
-
-In our design we try to remove this waste time, by doing all the
-operation which generate a system call in kernel space. This mean,
-from the sender perspective opening the file, reading from the
-file and writing data into the socket and from the receiver
-perspective, opening the file, reading data from socket and
-writing data into the file in kernel space. The approach eliminate
-almost all the system calls. The only informations which must be
-sent from user space into kernel space, are in the sender case,
-the name of the file which must be transferred and the address of
-the receiver or receivers. In the case of the receiver a system
-call can be used to get informations about the transfer, like the
-files which are transferred and the status of the operations.
-
-In our implementation we use datagram to send and receive information. The UDP protocol is simple and the overhead is very small, but the protocol is not connection oriented which can lead to loss of informations. In the next subsections I will give more information about the our sender and receiver kernel modules design.
-
-\subsection{P2PKP Sender}
+Nowadays the vast majority of the peer-to-peer applications run in user space.
+And this is one of the most important delays that appear at the Operating
+System layer, while file transfers occurs. For every file operation such as
+\texttt{open}, \texttt{read}, \texttt{write}, etc, as well as socket
+operations, a system call is made. This induces a huge overhead caused by the
+system calls interrupts and context switches.
+
+In our design we have tried to eliminate as much system calls overhead as
+possible, by doing as many operations as possible directly in the kernel
+space. Having this in mind, we have outlined the module's architecture as
+illustrated in Figure \ref{fig:arch} and described in Section
+\ref{subsec:arch}.
+
+Our model also changes the perspective of a user space programmer. Until now,
+in order to simulate our module's behavior, the sender would have to open the
+file it has to send, read data from it and then write the data through the
+socket. Similar, a receiver has to open the file for writing, read data from
+the network socket and write it down into the file. All these operations have
+to be done repetitively in order to ensure that the file was properly
+sent/received. And therefore a huge overhead could be avoided if all these
+operations would be implemented directly in kernel, and would be substituted
+with a single system call.
+
+Our approach eliminates almost all the \texttt{open}, \texttt{read},
+\texttt{write} system calls, replacing them with a single
+\texttt{write}/\texttt{read} operation. The only information that has to be sent
+from user space into kernel space is, for the sender, the full path of the file
+that must be transferred and the IP address of the receiver, or receivers in
+case there are more than one. In the receivers' case, the system call can be
+used to get information about the transfer, like the files that are transferred
+or the status of the operation.
+
+\begin{figure}[h!]
+ \centering
+ \includegraphics[scale=0.5]{img/architecture.png}
+ \caption{P2PKP Module Architecture}
+ \label{fig:arch}
+\end{figure}
+
+Our implementation uses datagrams to send and receive information over
+the network. Although the UDP protocol is simple and the generated overhead is
+quite small, the protocol is not connection oriented which can lead to loss of
+packages/data. However, this matter is beyond our interests in this research,
+as we are now focusing on developing an efficient solution in terms of
+latency, without considering network issues.
+
+\subsection{P2PKP Architecture}
+\label{subsec:arch}
+
+The architecture of our protocol implementation resides completely in kernel
+space, in shape of a kernel module. As Figure \ref{fig:arch} illustrates, the
+communication between user space and our module is done completely through the
+\texttt{read}, \texttt{write}, \texttt{connect} system calls. However, our
+module is not a standalone entity, but it interacts with the Linux VFS
+(Virtual File System) and NET layer in order to read/write files in kernel
+space and deliver/receive them through the network. Section
+\ref{sec:implementation} describes the interactions between all these components
+and how they are linked together in order to provide the desired behavior.
+
+\subsection{Sender User}