doc: final revise of the document
[p2p-kernel-protocol.git] / doc / src / conclusions.tex
index bc5e6d1..aebc1f9 100644 (file)
@@ -1,6 +1,21 @@
 \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.