\section{Design}
\label{sec:design}
-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.
+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}
+ \label{fig:arch}
+ \caption{P2PKP Module Architecture}
+\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{P2PKP Sender}
\label{subsec:sender}
-The sender module use a socket, to communicate from user space to kernel space, The system calls used are connect and write. When a user want to transfer a file to one or more peers the name of the file, and the ip address of the receivers must be provided. The connect system call is used to specify a destination, for a file. Multiple destinations can be specified by using multiple connect operations. After all the destinations are sent from user space to kernel space, a write operation must be used, to send the name of the file, which must be transferred to the peers. The name of the file, represent the absolute path of the file which will be transferred to the peers. After this operations are sent from user space to kernel space, all the transfer will occur in kernel space, so no additional system calls will be made.
+The sender module uses the UNIX socket interface in order to communicate from
+user space to kernel space. The system calls used for a receiver scenario are
+\texttt{connect} and \texttt{write}. When an user wants to transfer a file to
+one or more peers, the module needs only the local filename and the set of
+peers address. The \texttt{connect} system call is used to specify
+destinations of a single file. Multiple destinations can be specified by using
+multiple \texttt{connect} operations. After all the destinations are specified
+from user space to kernel space, a \texttt{write} operation must be used, in
+order to send the file over the network to all specified peers. The name of the
+file, represents the absolute path of the file which will be transferred to the
+peers. After this operations are sent from user space to kernel space, the
+whole file transfer will occur in kernel space, hence no additional system calls
+must be made.
-For each connect system call the kernel module create a new socket for the communication with the specified peer. After the write system call the kernel module, try to open the file. If the operation succeed, the module start reading data from the file, and writing into all the sockets created after connect operations. After all the content of the file is read and write to each socket, the file and the sockets are closed.
+For each \texttt{connect} system call, the kernel module creates a new socket
+for each socket specified for communication. After the \texttt{write} system
+call, the kernel module tries to open the file. If the operation succeeds, the
+module start reading data from the file, and writing into to the sockets created
+after the \texttt{connect} operations. After the whole content of the file is
+transferred each socket, the file descriptor and the sockets are closed.
-Every socket created in the user space is designed to transfer one or more files to multiple destinations. The total number of system calls used to transfer multiple files to multiple recipients is equal with the number of files plus the number of recipients.
+Every socket created in the user space is designed to transfer one or more files
+to one or multiple destinations. The total number of system calls used to
+transfer the files to each peer is equal to the number of files transferred plus
+the total number of recipients.
\subsection{P2PKP Received}
\label{subsec:receiver}
-The receiver module is implemented with a kernel module. The communication with user space is realised using a socket. Bind system call is used to set the port on which the module will listen for incoming data. The read operation is used to specify the file in which the incoming informations are stored. The file is specified using a global path name. At this moment we store all the data in the same file. We only try to view if the transfer time is good enough.
+The receiver part of the module is also implemented in kernel module. The
+communication between the user space and the module is realised using the
+kernel socket interface. The \texttt{bind} system call is used to set the
+interface and the port that the module will listen on for incoming requests.
+The \texttt{read} operation is used in order to specify the file where the
+incoming data is stored. The file has to be specified using the global path,
+rather than relative name. Currently, our implementation stores the whole data
+in a single file. We haven't advanced in more complex scenarios, as our
+initial goal was only to see if this design is good enough to fight with other
+implementations, like \texttt{sendfile}.
-After the bind operation, the module start listening and when informations are received, they are stored in the file specified with read system call. At this time the total number of system calls used to receive files is only two.
+After the \texttt{bind} operation, the module starts listening for data. As
+pointed in the previous paragraph, the whole data is transferred in a single
+file specified by the \texttt{read} system call. Therefore, summing up all the
+system calls needed to receive a single file over the network reduces to two.
projects / p2p-kernel-protocol.git / blobdiff