doc/src/design.tex

   1 \section{Design}
   2 \label{sec:design}
   3
   4 Nowadays the vast majority of the peer-to-peer applications run in user space.
   5 And this is one of the most important delays that appear at the Operating
   6 System layer, while file transfers occurs. For every file operation such as
   7 \texttt{open}, \texttt{read}, \texttt{write}, etc, as well as socket
   8 operations, a system call is made. This induces a huge overhead caused by the
   9 system calls interrupts and context switches.
  10
  11 In our design we have tried to eliminate as much system calls overhead as
  12 possible, by doing as many operations as possible directly in the kernel
  13 space. Having this in mind, we have outlined the module's architecture as
  14 illustrated in Figure \ref{fig:arch} and described in Section
  15 \ref{subsec:arch}.
  16
  17 Our model also changes the perspective of a user space programmer. Until now,
  18 in order to simulate our module's behavior, the sender would have to open the
  19 file it has to send, read data from it and then write the data through the
  20 socket. Similar, a receiver has to open the file for writing, read data from
  21 the network socket and write it down into the file. All these operations have
  22 to be done repetitively in order to ensure that the file was properly
  23 sent/received. And therefore a huge overhead could be avoided if all these
  24 operations would be implemented directly in kernel, and would be substituted
  25 with a single system call.
  26
  27 Our approach eliminates almost all the \texttt{open}, \texttt{read},
  28 \texttt{write} system calls, replacing them with a single
  29 \texttt{write}/\texttt{read} operation. The only information that has to be sent
  30 from user space into kernel space is, for the sender, the full path of the file
  31 that must be transferred and the IP address of the receiver, or receivers in
  32 case there are more than one. In the receivers' case, the system call can be
  33 used to get information about the transfer, like the files that are transferred
  34 or the status of the operation.
  35
  36 \begin{figure}[h!]
  37         \centering
  38         \includegraphics[scale=0.5]{img/architecture.png}
  39         \caption{P2PKP Module Architecture}
  40         \label{fig:arch}
  41 \end{figure}
  42
  43 Our implementation uses datagrams to send and receive information over
  44 the network. Although the UDP protocol is simple and the generated overhead is
  45 quite small, the protocol is not connection oriented which can lead to loss of
  46 packages/data. However, this matter is beyond our interests in this research,
  47 as we are now focusing on developing an efficient solution in terms of
  48 latency, without considering network issues.
  49
  50 \subsection{P2PKP Architecture}
  51 \label{subsec:arch}
  52
  53 The architecture of our protocol implementation resides completely in kernel
  54 space, in shape of a kernel module. As Figure \ref{fig:arch} illustrates, the
  55 communication between user space and our module is done completely through the
  56 \texttt{read}, \texttt{write}, \texttt{connect} system calls. However, our
  57 module is not a standalone entity, but it interacts with the Linux VFS
  58 (Virtual File System) and NET layer in order to read/write files in kernel
  59 space and deliver/receive them through the network. Section
  60 \ref{sec:implementation} describes the interactions between all these components
  61 and how they are linked together in order to provide the desired behavior.
  62
  63 \subsection{Sender User}
  64 \label{subsec:sender}
  65
  66 The sender module uses the UNIX socket interface in order to communicate from
  67 user space to kernel space. The system calls used for a receiver scenario are
  68 \texttt{connect} and \texttt{write}. When an user wants to transfer a file to
  69 one or more peers, the module needs only the local filename and the set of
  70 peers address. The \texttt{connect} system call is used to specify
  71 destinations of a single file. Multiple destinations can be specified by using
  72 multiple \texttt{connect} operations. After all the destinations are specified
  73 from user space to kernel space, a \texttt{write} operation must be used, in
  74 order to send the file over the network to all specified peers. The name of the
  75 file, represents the absolute path of the file which will be transferred to the
  76 peers. After this operations are sent from user space to kernel space, the
  77 whole file transfer will occur in kernel space, hence no additional system calls
  78 must be made.
  79
  80 For each \texttt{connect} system call, the kernel module creates a new socket
  81 for each socket specified for communication. After the \texttt{write} system
  82 call, the kernel module tries to open the file. If the operation succeeds, the
  83 module start reading data from the file, and writing into to the sockets created
  84 after the \texttt{connect} operations. After the whole content of the file is
  85 transferred each socket, the file descriptor and the sockets are closed.
  86
  87 Every socket created in the user space is designed to transfer one or more files
  88 to one or multiple destinations. The total number of system calls used to
  89 transfer the files to each peer is equal to the number of files transferred plus
  90 the total number of recipients.
  91
  92 \subsection{Receiver User}
  93 \label{subsec:receiver}
  94
  95 The receiver part of the module is also implemented in kernel module. The
  96 communication between the user space and the module is realised using the
  97 kernel socket interface. The \texttt{bind} system call is used to set the
  98 interface and the port that the module will listen on for incoming requests.
  99 The \texttt{read} operation is used in order to specify the file where the
 100 incoming data is stored. The file has to be specified using the global path,
 101 rather than relative name. Currently, our implementation stores the whole data
 102 in a single file. We haven't advanced in more complex scenarios, as our
 103 initial goal was only to see if this design is good enough to fight with other
 104 implementations, like \texttt{sendfile}.
 105
 106 After the \texttt{bind} operation, the module starts listening for data. As
 107 pointed in the previous paragraph, the whole data is transferred in a single
 108 file specified by the \texttt{read} system call. Therefore, summing up all the
 109 system calls needed to receive a single file over the network reduces to two.