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
  14
  15 The second approach of the swift implementation is represent in the \labelindexref{Figure}{img:tree}.
  16
  17 \image[scale=0.45]{img/tree}{img:tree}{Tree}
  18
  19 The swift transport should have been a new kernel interface allowing the creation of specialized swift sockets. It
  20 should have implemented the multiparty protocol allowing piece transport to/from other hosts in a peer-to-peer fashion.
  21
  22 That implementation should have had specialized "request queues", metadata queues, to/from user space.  Specialized
  23 system call API should have allowed user space applications to interact with the above
  24 mentioned queues and, thus, with the multiparty transport protocol implementation.
  25
  26 Innate differences from a classical one-to-one communication such as UDP or TCP means the system call API shouldn't have
  27 followed the classical send/receive paradigm. In order to compensate this and to provide a rather "friendly" interface
  28 to user space applications, a library was designed that to provide a simpler interface. Peer and piece discovery should
  29 have been the responsibility of the user space application. The SWIFT Library may also provide wrappers over a UDP-based
  30 channel for discovery.
  31
  32 Merkle hashes should have stored and computed in user space. This approach couldn't be implemented because of the
  33 restriction of the library implementations (e.g. a users application design would be more restrictive). Moreover the
  34 kernel implementation should have been like an UDP which support multicast transfer.
  35
  36
  37 The third approach of the swift implementation was to detach the transport layer from the original swift implementation
  38 and to manage it. When we started to implement this we found a lot of inconvenience like our code duplicate a lot of
  39 application code, we cannot implement the discovery protocol, and again our kernel implementation should have been like
  40 a multicast-UDP.
  41
  42 This approach also couldn't be implemented because of the complexity of the transport layer management, moreover we
  43 didn't find strengths to confirm that our implementation could be better than original implementation.