+
+
+In this section we present our current architectural design along with the motivation of choices. We are also going to
+detail our protocol and the packet structure used.
+
+In figure \labelindexref{Figure}{img:archov} we see the main conceptual modules: Application module,
+wrapper library, peer discovery overlay and the swift transport protocol layer.
+
+\image[scale=0.4]{img/archov.png}{img:archov}{Overview architecture}
+
+The Application module represents the remaining part of the old swift implementation. This is the part that remains in
+user space and contains the file management and hash management features.
+
+The wrapper library module defines a socket-like API for the user space applications. An regular program will use those
+calls instead of the normal socket ones to use the multiparty sockets. For the moment those calls are simulated system
+calls that initially are resolved with the socket raw implementation (still in user space) .
+In the future this wrapper library will represent entry points into the kernel.
+
+The peer discovery overlay will remain unchanged. It is still going to work based on UDP sockets and link the same
+levels in the swift implementation as before.
+
+The multiparty protocol is implemented for now by a user level socket raw layer. This has the advantage of simulating the
+real design modularization but also permit an easier debugging and testing procedure of the integration. In the next step
+this part will be represented by a kernel patch that will communicate through custom made system calls with the wrapper
+library.
+
+\image[scale=0.5]{img/kernel.png}{img:kernel}{Detail architecture}
+
+\begin{comment}
+In this picture we try to define more which elements are in US and which are in KS.
+In the first implementation we will make an US implementation for our protocol with raw socket to validate our architecture
+and to make easier our kernel implementation that will communicate with this implementation.
+
+Raw socket implementation will support all syscalls and it will be a copy of our kernel implementation.
+This implementation will have the same API and behavior with kernel implementation. The peer discover will be in
+Application implementation and it will be developer problems how to implement and how to manage it.
+When you make a syscall you need to pass the ips where the protocol can find the specify hash
+
+In the first implementation a swift socket will be available for only one operation transmit data or receive data.
+In the last implementation the swift protocol will be develop in kernel space, and it will be accessible with a datagram
+socket that will support all socket syscalls. It will intend to support both operations (receive/ send) data over only one socket.
+\end{comment}
\ No newline at end of file
projects / swifty.git / blobdiff