Documentation/RelatedWork

   1 Work that relates to netsniff-ng and how we differ from it:
   2 ///////////////////////////////////////////////////////////
   3
   4 ntop
   5  * W: http://www.ntop.org/
   6
   7  The ntop projects offers zero-copy for network packets. Is this approach
   8  significantly different from the already built-in from the Linux kernel?
   9  High likely not. In both cases packets are memory mapped between both address
  10  spaces. The biggest difference is that you get this for free, without
  11  modifying your kernel with netsniff-ng since it uses the kernel's RX_RING
  12  and TX_RING functionality. Unfortunately this is not really mentioned on the
  13  ntop's website. Surely for promotional reasons. For many years the ntop
  14  projects lives on next to the Linux kernel, attempts have been made to
  15  integrate it [1] but discussions got stuck and both sides seem to have no
  16  interest in it anymore, e.g. [2]. Therefore, if you want to use ntop, you are
  17  dependent on ntop's modified drivers that are maintained out of the Linux
  18  kernel's mainline tree. Thus, this will not provide you with the latest
  19  improvements. Also, the Linux kernel's PF_PACKET is maintained by a much bigger
  20  audience, probably better reviewed and optimized. Therefore, also we decided
  21  to go with the Linux kernel's variant. So to keep it short: both approaches
  22  are zero-copy, both have similar performance (if someone tells you something
  23  different, he would lie due to their technical similarities) and we are using
  24  the kernel's built-in variant to reach a broader audience.
  25
  26  [1] http://lists.openwall.net/netdev/2009/10/14/37
  27  [2] http://www.spinics.net/lists/netfilter-devel/msg20212.html
  28
  29 tcpdump
  30  * W: http://www.tcpdump.org/
  31
  32  tcpdump is probably the oldest and most famous packet analyzer. It is based on
  33  libpcap and in fact the MIT team that maintains tcpdump also maintains libpcap.
  34  It has been ported to much more architectures and operating systems than
  35  netsniff-ng. However, we don't aim to rebuild or clone tcpdump. We rather focus
  36  on achieving a higher capturing speed by carefully tuning and optimizing our
  37  code. That said doesn't mean that tcpdump people do not take care of it. It
  38  just means that we don't have additional layers of abstractions for being as
  39  portable as possible. This already gives us a smaller code footprint. Also, on
  40  default we perform some system tuning such as remapping the NIC's IRQ affinity
  41  that tcpdump probably would never do due to its generic nature. By generic, we
  42  mean to serve as many different user groups as possible. We rather aim at
  43  serving users for high-speed needs. By that, they have less manual work to do
  44  since it's already performed in the background. Next to this, we also aim at
  45  being a useful networking toolkit rather than only an analyzer. So many other
  46  tools are provided such as trafgen for traffic generation.
  47
  48 Wireshark/tshark
  49  * W: http://www.wireshark.org/
  50
  51  Probably we could tell you the same as in the previous section. I guess it is
  52  safe to say that Wireshark might have the best protocol dissector out there.
  53  However, this is not a free lunch. You pay for it with a performance
  54  degradation, which is quite expensive. It is also based on libpcap (we are not)
  55  and it comes with a graphical user interface, whereas we rather aim at being
  56  used somewhere on a server or middle-box site where you only have access to a
  57  shell, for instance. Again, offline analysis of /large/ pcap files might even
  58  let it hang for a long time. Here netsniff-ng has a better performance also in
  59  capturing pcaps. Again, we furthermore aim at being a toolkit rather than only
  60  an analyzer.
  61
  62 libpcap
  63  * W: http://www.tcpdump.org/
  64
  65  Price question: why don't you rely on libpcap? The answer is quite simple. We
  66  started developing netsniff-ng with its zero-copy capabilities back in 2009
  67  when libpcap was still doing packet copies between address spaces. Since the
  68  API to the Linux kernel was quite simple, we felt more comfortable using it
  69  directly and bypassing this additional layer of libpcap code. Today we feel
  70  good about this decision, because since the TX_RING functionality was added to
  71  the Linux kernel we have a clean integration of both, RX_RING and TX_RING.
  72  libpcap on the other hand was designed for capturing and not for transmission
  73  of network packets. Therefore, it only uses RX_RING on systems where it's
  74  available but no TX_RING functionality. This would have resulted in a mess in
  75  our code. Additionally, with netsniff-ng, one is able to a more fine grained
  76  tuning of those rings. Why didn't you wrap netsniff-ng around your own library
  77  just like tcpdump and libpcap? Because we are ignorant. If you design a library
  78  than you have to design it well right at the beginning. A library would be a
  79  crappy one if it changes its API ever. Or, if it changes its API, than it has
  80  to keep its old one for the sake of being backwards compatible. Otherwise no
  81  trust in its user or developer base can be achieved. Further, by keeping this
  82  long tail of deprecated functions you will become a code bloat over time. We
  83  wanted to keep this freedom of large-scale refactoring our code and not having
  84  to maintain a stable API to the outer world. This is the whole story behind it.
  85  If you desperately need our internal functionality, you still can feel free to
  86  copy our code as long as your derived code complies with the GPL version 2.0.
  87  So no need to whine. ;-)