

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 peer discover will be part of the application implementation and it
will be at the developer choice how to implement and how to manage it. 

The multiparty protocol is implemented for now at user space level by a raw socket layer to validate our architecture.
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. This two phases are described in
\labelindexref{Figure}{img:kernel} 

\image[scale=0.5]{img/kernel.png}{img:kernel}{Detail architecture}

% RAW sockets
A socket is one of the most fundamental technologies of computer networking.
Sockets allow applications to communicate using standard mechanisms built into
network hardware and operating systems.

Raw mode is basically there to allow you to bypass some of the way that your
computer handles TCP/IP. Rather than going through the normal layers of
encapsulation/decapsulation that the TCP/IP stack on the kernel does, you just
pass the packet to the application that needs it. No TCP/IP processing -- so
it's not a processed packet, it's a raw packet. The application that's using
the packet is now responsible for stripping off the headers, analyzing the
packet, all the stuff that the TCP/IP stack in the kernel normally does for
you.

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 as the kernel implementation. Still, in the first
implementation, a swift socket will be available to act as only a seeder or a leecher, explicitly one operation transmit
data or receive data will be supported.
 
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.

\image[scale=0.55]{img/recvdata.png}{img:recvdata}{Leecher}

\labelindexref{Figure}{img:recvdata} presents the conceptual model of the Leecher. The Leecher is the one that wants
to receive a data. In order to do this it must connect to the multiparty protocol by creating and binding to a
multiparty socket. When it binds to a socket, it uses the hash as a parameter to find a connection with a peer that
has the respective file. This discovery is done the peer discovery overlay. The Leecher then waits for packets
from the seeders.
 

\image[scale=0.55]{img/sendmsg.png}{img:sendmsg}{Seeder}


\labelindexref{Figure}{img:sendmsg} presents the conceptual model of the Seeder. The Seeder is the one that serves
data to other Leechers. In order to do this it must connect to the multiparty protocol by creating, binding and
listening to a mutliparty socket. When binding the Seeder practically uses the hash as a parameter. This means that
for every file hashed there will be a socket on which the seeder can receive and serve requests. The Seeder then waits
for requests and sends data packets as requested.




