doc/research2/src/preliminarywork.tex

   1 While designing our system, we have tackled a few different ideas, each with its strengths and weaknesees. We present
   2 now some of those preliminary ideas that lead to the our current desing choice.
   3
   4 The first approach we thought of was to include all of the swift protocol into the kernel space. This
   5 approach had the advantage of simplicity and would have implied minimal architectural changes. The current user space
   6 implementation could have been ported to a kernel module.
   7
   8 Though simple, this approach could not be implemented because of the restriction of memory size in the kernel.
   9 For the integrity check the swift protocol relies on Merkle hash tree. Keeping this tree in the kernel space memory is
  10 not scalable. The Internet content is too large to be stored in kernel. Even if the tree retains only hashes of the data
  11 disseminated, the space is insufficient.
  12
  13 \image[scale=0.4]{img/arch1.pdf}{img:arch1}{Previous Architecture}
  14
  15 The second approach of the swift implementation is represent in the \labelindexref{Figure}{img:arch1}. The swift transport
  16   should have been a new kernel interface allowing the creation of specialized swift sockets. It
  17 should have implemented the multiparty protocol allowing piece transport to/from other hosts in a peer-to-peer fashion.
  18
  19 That implementation should have had specialized "request queues", metadata queues, to/from user space.  Specialized
  20 system call API should have allowed user space applications to interact with the above
  21 mentioned queues and, thus, with the multiparty transport protocol implementation.
  22
  23 Innate differences from a classical one-to-one communication such as UDP or TCP means the system call API shouldn't have
  24 followed the classical send/receive paradigm. In order to compensate this and to provide a rather "friendly" interface
  25 to user space applications, a library was designed that to provide a simpler interface. Peer and piece discovery should
  26 have been the responsibility of the user space application. The SWIFT Library may also provide wrappers over a UDP-based
  27 channel for discovery.
  28
  29 Merkle hashes should have stored and computed in user space. This approach couldn't be implemented because of the
  30 restriction of the library implementations (e.g. a users application design would be more restrictive). Moreover the
  31 kernel implementation should have been like an UDP which support multicast transfer.
  32
  33
  34 The third approach of the swift implementation was to detach the transport layer from the original swift implementation
  35 and to manage it. When we started to implement this we found a lot of inconvenience like our code duplicate a lot of
  36 application code, we cannot implement the discovery protocol, and again our kernel implementation should have been like
  37 a multicast-UDP.
  38
  39 This approach also couldn't be implemented because of the complexity of the transport layer management, moreover we
  40 didn't find strengths to confirm that our implementation could be better than original implementation.