\section{Design}
\label{sec:design}
-How this implementation is seen in the userspace.
+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}
\label{subsec:sender}
-How files are sent.
+
+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.
+
+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.
+
+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.
\subsection{P2PKP Received}
\label{subsec:receiver}
-How files are received.
+
+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.
+
+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.
projects / p2p-kernel-protocol.git / blobdiff