X-Git-Url: http://p2p-next.cs.pub.ro/gitweb/?a=blobdiff_plain;f=doc%2Fsrc%2Fconclusions.tex;h=aebc1f9d60002121378715b25f60e09136b922d3;hb=HEAD;hp=d53f2d47d9ded9e074f82f552844a971271fffbb;hpb=a8b0cb2d31f3e36b3c845c1e5c6f86161b3925df;p=p2p-kernel-protocol.git

diff --git a/doc/src/conclusions.tex b/doc/src/conclusions.tex
index d53f2d4..aebc1f9 100644
--- a/doc/src/conclusions.tex
+++ b/doc/src/conclusions.tex
@@ -1,3 +1,21 @@
 \section{Conclusions and Further Work}
 \label{sec:conclusions}
-Our conclusions based on the results gathered at Section \ref{sec:results}.
+
+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.
+
+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.