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. The peer discover will be part of the application implementation and it
  21 will be at the developer choice how to implement and how to manage it.
  22
  23 The multiparty protocol is implemented for now at user space level by a raw socket layer to validate our architecture.
  24 This has the advantage of simulating the real design modularization but also permit an easier debugging and testing
  25 procedure of the integration. In the next step this part will be represented by a kernel patch that will communicate
  26 through custom made system calls with the wrapper library. This two phases are described in
  27 \labelindexref{Figure}{img:kernel}
  28
  29 \image[scale=0.5]{img/kernel.png}{img:kernel}{Detail architecture}
  30
  31 % RAW sockets
  32 A socket is one of the most fundamental technologies of computer networking.
  33 Sockets allow applications to communicate using standard mechanisms built into
  34 network hardware and operating systems.
  35
  36 Raw mode is basically there to allow you to bypass some of the way that your
  37 computer handles TCP/IP. Rather than going through the normal layers of
  38 encapsulation/decapsulation that the TCP/IP stack on the kernel does, you just
  39 pass the packet to the application that needs it. No TCP/IP processing -- so
  40 it's not a processed packet, it's a raw packet. The application that's using
  41 the packet is now responsible for stripping off the headers, analyzing the
  42 packet, all the stuff that the TCP/IP stack in the kernel normally does for
  43 you.
  44
  45 Raw socket implementation will support all syscalls and it will be a copy of our kernel implementation.
  46 This implementation will have the same API and behavior as the kernel implementation. Still, in the first
  47 implementation, a swift socket will be available to act as only a seeder or a leecher, explicitly one operation transmit
  48 data or receive data will be supported.
  49
  50 In the last implementation the swift protocol will be develop in kernel space, and it will be accessible with a
  51 datagram socket that will support all socket syscalls. It will intend to support both operations (receive / send) data
  52 over only one socket.
  53
  54 \image[scale=0.55]{img/recvdata.png}{img:recvdata}{Leecher}
  55
  56 \labelindexref{Figure}{img:recvdata} presents the conceptual model of the Leecher. The Leecher is the one that wants
  57 to receive a data. In order to do this it must connect to the multiparty protocol by creating and binding to a
  58 multiparty socket. When it binds to a socket, it uses the hash as a parameter to find a connection with a peer that
  59 has the respective file. This discovery is done the peer discovery overlay. The Leecher then waits for packets
  60 from the seeders.
  61
  62
  63 \image[scale=0.55]{img/sendmsg.png}{img:sendmsg}{Seeder}
  64
  65
  66 \labelindexref{Figure}{img:sendmsg} presents the conceptual model of the Seeder. The Seeder is the one that serves
  67 data to other Leechers. In order to do this it must connect to the multiparty protocol by creating, binding and
  68 listening to a mutliparty socket. When binding the Seeder practically uses the hash as a parameter. This means that
  69 for every file hashed there will be a socket on which the seeder can receive and serve requests. The Seeder then waits
  70 for requests and sends data packets as requested.
  71
  72
  73
  74