doc/research2/src/arch.tex

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