\section{Conclusions and Further Work}
\label{sec:conclusions}
-In this paper we presented an kernel alternative for building peer to peer systems. We done this because when files are transferred in peer to peer system important time is lost when context switch is done because of system calls. With our basic implementation, we demonstrate the viability of file transfer implemented in kernel, mainly because the performances were acceptable when a small number of peers are transferring the same file, compared to \texttt{sendfile}, and good for a large number of peers who transfer the same file.
+In this paper we have presented an alternative kernel implementation of a
+peer-to-peer protocol. Our purpose was to increase the performance of
+peer-to-peer applications by improving the delay caused by the Operating
+System design, namely the system calls latency. We have succeeded implementing
+an application layer protocol directly in kernel space, thus bypassing the
+numerous time-consuming system calls of actual implementations. Starting from
+our basic implementation, we have demonstrated the viability of the file
+Content distribution implemented in kernel when large number of peers are
+evolved. Compared to the \texttt{sendfile}, we have achieved better
+performance rate when sending a file to multiple destinations.
-To make the protocol viable for real peer-to-peer systems important improvements are needed. First a mechanism for sending just some parts of a file will be needed. Also support for the TCP protocol must be implemented in order to make transfers safe and reliable.
+In order to make the protocol more viable to peer-to-peer systems, there are a
+lot of important improvements needed. Firstly, we would need a mechanism for
+splitting the file in several chunks and send them iteratively. Also, we
+would have to completely implement the SWIFT protocol directly at the kernel
+level, as this design only shapes the primitives of the multiparty behavior.
+Finally, we would have to perform some tests in real-world scenarios in order
+to determine the performance of this solution.
\section{Results}
\label{sec:results}
-We want to view if our implementation is viable in terms of performances. To do this we compare our results with the results of \texttt{sendfile} system call. The \texttt{sendfile} command (\textbf{ssize\_t sendfile(int} \textit{out\_fd,} \textbf{int} \textit{in\_fd,} \textbf{off\_t *}\textit{offset,} \textbf{size\_t} \textit{count}\textbf{);}) is used to send \texttt{count} bytes from \texttt{in\_fd} to \texttt{out\_fd}.
+Our goal is to stress our implementation in order to determine if it is
+viable in terms of performance. In order to achieve this, we have compared our
+results with the \texttt{sendfile} system call. As already stated in Section
+\ref{sec:intro}, this function uses a zero-copy mechanism to avoid passing
+information from kernel space and back.
\begin{table}
\begin{center}
\label{sendfile-results}
\end{table}
-In the first test we sent files of 32, 64, 128 and 256 MB from one node to a different number of peers. We varied the number of peers from 1 to 8. The results can be seen in Table \ref{sendfile-results}. We can see that the time needed to send files of different size grows almost linearly, with a factor smaller than 1. This is expected because for each peer we execute a different sendfile system call.
+Section \ref{sec:testing} largely details the test scenarios we have
+performed. Particularly, this is the test where we varied the number of peers
+from 1 to 8. The results gathered are displayed in Table \ref{sendfile-results}.
+We can easily observe that the time needed to send files of different size grows
+almost linearly, with a factor lower than 1. This was expected because for each
+peer, we execute at least one more \texttt{sendfile} system call.
-In the second test, we used our peer-to-peer kernel protocol also on files with size growing from 32MB to 256MB. The number of peers used in test was varied from 1 to 8. The results presented in Table \ref{p2pkp-results}, show an almost linear growth of the time needed to send the files from the sender to peers but with a smaller factor than in the case of \texttt{sendfile}. For small number of peers, one two or three, the results were better in the tests made with sendfile, but for a greater number of peers the results are better when using the p2pkp.
+For the second test, we used our peer-to-peer kernel protocol for sending
+files on with sizes growing from 32MB up to 256MB. The number of peers used in
+this test was varied from 1 to 8. The results presented in Table,
+\ref{p2pkp-results}, show an almost linear growth of the time needed to send the
+files from sender to peers, but with a smaller factor than the one achieved in
+case of the \texttt{sendfile} system call. For small number of peers, one, two
+or three, \texttt{senfile} has a higher performance rate, but for a greater
+number of peers our implementation has better results.
\begin{table}
\begin{center}
\label{p2pkp-results}
\end{table}
-We also made a graphic shown in Figure \ref{fig:comp} to view more clearly the differences between sendfile and peer-to-peer kernel protocol. As we can see, with the increase of the number of peers p2pkp become more and more good, and finally overcame the performances of sendfile.
+We have also compiled a graphic, shown in Figure \ref{fig:comp}, that better
+exposes the differences between \texttt{sendfile} and the P2PKP kernel module.
+As we can see, while the number of peers increase, our implementation
+overcomes the performance of \texttt{sendfile}.
\begin{figure}[h!]
\centering
\includegraphics[scale=0.6]{img/comparison.png}
- \caption{Comparison}
+ \caption{\texttt{sendfile} vs P2PKP}
\label{fig:comp}
\end{figure}
projects / p2p-kernel-protocol.git / commitdiff